2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
ssh_cipher ciph;
|
2005-04-15 02:58:29 +04:00
|
|
|
} ArcfourContext;
|
|
|
|
|
2018-05-26 10:31:34 +03:00
|
|
|
static void arcfour_block(void *handle, void *vblk, int len)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-05-26 10:31:34 +03:00
|
|
|
unsigned char *blk = (unsigned char *)vblk;
|
2005-04-15 02:58:29 +04: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 21:24:07 +03:00
|
|
|
for (k = 0; (int)k < len; k++) {
|
2019-09-08 22:29:00 +03: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-15 02:58:29 +04:00
|
|
|
}
|
|
|
|
ctx->i = i; ctx->j = j;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void arcfour_setkey(ArcfourContext *ctx, unsigned char const *key,
|
2019-09-08 22:29:00 +03:00
|
|
|
unsigned keybytes)
|
2005-04-15 02:58:29 +04: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 22:29:00 +03:00
|
|
|
s[i] = i;
|
|
|
|
k[i] = key[i % keybytes];
|
2005-04-15 02:58:29 +04:00
|
|
|
}
|
|
|
|
j = 0;
|
|
|
|
for (i = 0; i < 256; i++) {
|
2019-09-08 22:29:00 +03:00
|
|
|
j = (j + s[i] + k[i]) & 0xff;
|
|
|
|
tmp = s[i]; s[i] = s[j]; s[j] = tmp;
|
2005-04-15 02:58:29 +04: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 22:29:00 +03:00
|
|
|
*
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static ssh_cipher *arcfour_new(const ssh_cipheralg *alg)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-09-13 16:43:04 +03:00
|
|
|
ArcfourContext *ctx = snew(ArcfourContext);
|
2018-11-27 00:02:28 +03:00
|
|
|
ctx->ciph.vt = alg;
|
|
|
|
return &ctx->ciph;
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static void arcfour_free(ssh_cipher *cipher)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-11-27 00:02:28 +03:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
2018-09-13 16:43:04 +03:00
|
|
|
smemclr(ctx, sizeof(*ctx));
|
|
|
|
sfree(ctx);
|
2005-04-15 02:58:29 +04: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 23:51:50 +04:00
|
|
|
smemclr(junk, 1536);
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static void arcfour_ssh2_setiv(ssh_cipher *cipher, const void *key)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-09-13 16:43:04 +03:00
|
|
|
/* As a pure stream cipher, Arcfour has no IV separate from the key */
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static void arcfour_ssh2_setkey(ssh_cipher *cipher, const void *key)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-11-27 00:02:28 +03:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
|
|
|
arcfour_setkey(ctx, key, ctx->ciph.vt->padded_keybytes);
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static void arcfour_ssh2_block(ssh_cipher *cipher, void *blk, int len)
|
2005-04-15 02:58:29 +04:00
|
|
|
{
|
2018-11-27 00:02:28 +03:00
|
|
|
ArcfourContext *ctx = container_of(cipher, ArcfourContext, ciph);
|
2018-09-13 16:43:04 +03:00
|
|
|
arcfour_block(ctx, blk, len);
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
const ssh_cipheralg ssh_arcfour128_ssh2 = {
|
2018-09-13 16:43:04 +03:00
|
|
|
arcfour_new, arcfour_free, arcfour_ssh2_setiv, arcfour_ssh2_setkey,
|
|
|
|
arcfour_ssh2_block, arcfour_ssh2_block, NULL, NULL,
|
2005-09-03 21:03:49 +04:00
|
|
|
"arcfour128",
|
2015-09-10 10:10:52 +03:00
|
|
|
1, 128, 16, 0, "Arcfour-128",
|
2015-06-07 15:40:11 +03:00
|
|
|
NULL
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
const ssh_cipheralg ssh_arcfour256_ssh2 = {
|
2018-09-13 16:43:04 +03:00
|
|
|
arcfour_new, arcfour_free, arcfour_ssh2_setiv, arcfour_ssh2_setkey,
|
|
|
|
arcfour_ssh2_block, arcfour_ssh2_block, NULL, NULL,
|
2005-09-03 21:03:49 +04:00
|
|
|
"arcfour256",
|
2015-09-10 10:10:52 +03:00
|
|
|
1, 256, 32, 0, "Arcfour-256",
|
2015-06-07 15:40:11 +03:00
|
|
|
NULL
|
2005-04-15 02:58:29 +04: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 21:06:08 +03:00
|
|
|
static const ssh_cipheralg *const arcfour_list[] = {
|
2005-04-21 00:57:00 +04:00
|
|
|
&ssh_arcfour256_ssh2,
|
2005-04-15 02:58:29 +04:00
|
|
|
&ssh_arcfour128_ssh2,
|
|
|
|
};
|
|
|
|
|
2019-01-04 10:13:08 +03:00
|
|
|
const ssh2_ciphers ssh2_arcfour = { lenof(arcfour_list), arcfour_list };
|