2005-04-14 22:58:29 +00:00
|
|
|
/*
|
|
|
|
* Arcfour (RC4) implementation for PuTTY.
|
|
|
|
*
|
|
|
|
* Coded from Schneier.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include "ssh.h"
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
unsigned char i, j, s[256];
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
ssh_cipher ciph;
|
2005-04-14 22:58:29 +00:00
|
|
|
} ArcfourContext;
|
|
|
|
|
2018-05-26 07:31:34 +00:00
|
|
|
static void arcfour_block(void *handle, void *vblk, int len)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-05-26 07:31:34 +00:00
|
|
|
unsigned char *blk = (unsigned char *)vblk;
|
2005-04-14 22:58:29 +00:00
|
|
|
ArcfourContext *ctx = (ArcfourContext *)handle;
|
|
|
|
unsigned k;
|
|
|
|
unsigned char tmp, i, j, *s;
|
|
|
|
|
|
|
|
s = ctx->s;
|
|
|
|
i = ctx->i; j = ctx->j;
|
2007-01-09 18:24:07 +00:00
|
|
|
for (k = 0; (int)k < len; k++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
i = (i + 1) & 0xff;
|
|
|
|
j = (j + s[i]) & 0xff;
|
|
|
|
tmp = s[i]; s[i] = s[j]; s[j] = tmp;
|
|
|
|
blk[k] ^= s[(s[i]+s[j]) & 0xff];
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
ctx->i = i; ctx->j = j;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void arcfour_setkey(ArcfourContext *ctx, unsigned char const *key,
|
2019-09-08 19:29:00 +00:00
|
|
|
unsigned keybytes)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
|
|
|
unsigned char tmp, k[256], *s;
|
|
|
|
unsigned i, j;
|
|
|
|
|
|
|
|
s = ctx->s;
|
|
|
|
assert(keybytes <= 256);
|
|
|
|
ctx->i = ctx->j = 0;
|
|
|
|
for (i = 0; i < 256; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
s[i] = i;
|
|
|
|
k[i] = key[i % keybytes];
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
j = 0;
|
|
|
|
for (i = 0; i < 256; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
j = (j + s[i] + k[i]) & 0xff;
|
|
|
|
tmp = s[i]; s[i] = s[j]; s[j] = tmp;
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* -- Interface with PuTTY -- */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't implement Arcfour in SSH-1 because it's utterly insecure in
|
|
|
|
* several ways. See CERT Vulnerability Notes VU#25309, VU#665372,
|
|
|
|
* and VU#565052.
|
2019-09-08 19:29:00 +00:00
|
|
|
*
|
2005-04-14 22:58:29 +00:00
|
|
|
* We don't implement the "arcfour" algorithm in SSH-2 because it doesn't
|
|
|
|
* stir the cipher state before emitting keystream, and hence is likely
|
|
|
|
* to leak data about the key.
|
|
|
|
*/
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static ssh_cipher *arcfour_new(const ssh_cipheralg *alg)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-09-13 13:43:04 +00:00
|
|
|
ArcfourContext *ctx = snew(ArcfourContext);
|
2018-11-26 21:02:28 +00:00
|
|
|
ctx->ciph.vt = alg;
|
|
|
|
return &ctx->ciph;
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static void arcfour_free(ssh_cipher *cipher)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-11-26 21:02:28 +00:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
2018-09-13 13:43:04 +00:00
|
|
|
smemclr(ctx, sizeof(*ctx));
|
|
|
|
sfree(ctx);
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void arcfour_stir(ArcfourContext *ctx)
|
|
|
|
{
|
|
|
|
unsigned char *junk = snewn(1536, unsigned char);
|
|
|
|
memset(junk, 0, 1536);
|
|
|
|
arcfour_block(ctx, junk, 1536);
|
2012-07-22 19:51:50 +00:00
|
|
|
smemclr(junk, 1536);
|
2005-04-14 22:58:29 +00:00
|
|
|
sfree(junk);
|
|
|
|
}
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static void arcfour_ssh2_setiv(ssh_cipher *cipher, const void *key)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-09-13 13:43:04 +00:00
|
|
|
/* As a pure stream cipher, Arcfour has no IV separate from the key */
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static void arcfour_ssh2_setkey(ssh_cipher *cipher, const void *key)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-11-26 21:02:28 +00:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
|
|
|
arcfour_setkey(ctx, key, ctx->ciph.vt->padded_keybytes);
|
2005-04-14 22:58:29 +00:00
|
|
|
arcfour_stir(ctx);
|
|
|
|
}
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static void arcfour_ssh2_block(ssh_cipher *cipher, void *blk, int len)
|
2005-04-14 22:58:29 +00:00
|
|
|
{
|
2018-11-26 21:02:28 +00:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
2018-09-13 13:43:04 +00:00
|
|
|
arcfour_block(ctx, blk, len);
|
2005-04-14 22:58:29 +00:00
|
|
|
}
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
const ssh_cipheralg ssh_arcfour128_ssh2 = {
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.new = arcfour_new,
|
|
|
|
.free = arcfour_free,
|
|
|
|
.setiv = arcfour_ssh2_setiv,
|
|
|
|
.setkey = arcfour_ssh2_setkey,
|
|
|
|
.encrypt = arcfour_ssh2_block,
|
|
|
|
.decrypt = arcfour_ssh2_block,
|
2022-08-16 17:27:06 +00:00
|
|
|
.next_message = nullcipher_next_message,
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.ssh2_id = "arcfour128",
|
|
|
|
.blksize = 1,
|
|
|
|
.real_keybits = 128,
|
|
|
|
.padded_keybytes = 16,
|
|
|
|
.flags = 0,
|
|
|
|
.text_name = "Arcfour-128",
|
2005-04-14 22:58:29 +00:00
|
|
|
};
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
const ssh_cipheralg ssh_arcfour256_ssh2 = {
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.new = arcfour_new,
|
|
|
|
.free = arcfour_free,
|
|
|
|
.setiv = arcfour_ssh2_setiv,
|
|
|
|
.setkey = arcfour_ssh2_setkey,
|
|
|
|
.encrypt = arcfour_ssh2_block,
|
|
|
|
.decrypt = arcfour_ssh2_block,
|
2022-08-16 17:27:06 +00:00
|
|
|
.next_message = nullcipher_next_message,
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.ssh2_id = "arcfour256",
|
|
|
|
.blksize = 1,
|
|
|
|
.real_keybits = 256,
|
|
|
|
.padded_keybytes = 32,
|
|
|
|
.flags = 0,
|
|
|
|
.text_name = "Arcfour-256",
|
2005-04-14 22:58:29 +00:00
|
|
|
};
|
|
|
|
|
Merge the ssh1_cipher type into ssh2_cipher.
The aim of this reorganisation is to make it easier to test all the
ciphers in PuTTY in a uniform way. It was inconvenient that there were
two separate vtable systems for the ciphers used in SSH-1 and SSH-2
with different functionality.
Now there's only one type, called ssh_cipher. But really it's the old
ssh2_cipher, just renamed: I haven't made any changes to the API on
the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
adapted the SSH-1 BPP to use the SSH-2 style API.
(The relevant differences are that ssh1_cipher encapsulated both the
sending and receiving directions in one object - so now ssh1bpp has to
make a separate cipher instance per direction - and that ssh1_cipher
automatically initialised the IV to all zeroes, which ssh1bpp now has
to do by hand.)
The previous ssh1_cipher vtable for single-DES has been removed
completely, because when converted into the new API it became
identical to the SSH-2 single-DES vtable; so now there's just one
vtable for DES-CBC which works in both protocols. The other two SSH-1
ciphers each had to stay separate, because 3DES is completely
different between SSH-1 and SSH-2 (three layers of CBC structure
versus one), and Blowfish varies in endianness and key length between
the two.
(Actually, while I'm here, I've only just noticed that the SSH-1
Blowfish cipher mis-describes itself in log messages as Blowfish-128.
In fact it passes the whole of the input key buffer, which has length
SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
Blowfish-256, and has been all along!)
2019-01-17 18:06:08 +00:00
|
|
|
static const ssh_cipheralg *const arcfour_list[] = {
|
2005-04-20 20:57:00 +00:00
|
|
|
&ssh_arcfour256_ssh2,
|
2005-04-14 22:58:29 +00:00
|
|
|
&ssh_arcfour128_ssh2,
|
|
|
|
};
|
|
|
|
|
2019-01-04 07:13:08 +00:00
|
|
|
const ssh2_ciphers ssh2_arcfour = { lenof(arcfour_list), arcfour_list };
|