1999-01-08 16:02:13 +03:00
|
|
|
/*
|
2003-03-15 20:51:05 +03:00
|
|
|
* RSA implementation for PuTTY.
|
1999-01-08 16:02:13 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2001-03-03 14:54:34 +03:00
|
|
|
#include <assert.h>
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2000-09-05 18:28:17 +04:00
|
|
|
#include "ssh.h"
|
2002-01-01 19:51:03 +03:00
|
|
|
#include "misc.h"
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
void BinarySource_get_rsa_ssh1_pub(
|
2018-06-03 10:23:07 +03:00
|
|
|
BinarySource *src, struct RSAKey *rsa, RsaSsh1Order order)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2018-05-27 23:51:36 +03:00
|
|
|
unsigned bits;
|
|
|
|
Bignum e, m;
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
bits = get_uint32(src);
|
|
|
|
if (order == RSA_SSH1_EXPONENT_FIRST) {
|
|
|
|
e = get_mp_ssh1(src);
|
|
|
|
m = get_mp_ssh1(src);
|
|
|
|
} else {
|
|
|
|
m = get_mp_ssh1(src);
|
|
|
|
e = get_mp_ssh1(src);
|
|
|
|
}
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
if (rsa) {
|
|
|
|
rsa->bits = bits;
|
|
|
|
rsa->exponent = e;
|
|
|
|
rsa->modulus = m;
|
|
|
|
rsa->bytes = (bignum_bitcount(m) + 7) / 8;
|
|
|
|
} else {
|
|
|
|
freebn(e);
|
|
|
|
freebn(m);
|
2004-08-01 16:07:11 +04:00
|
|
|
}
|
2018-05-27 23:51:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void BinarySource_get_rsa_ssh1_priv(
|
|
|
|
BinarySource *src, struct RSAKey *rsa)
|
|
|
|
{
|
|
|
|
rsa->private_exponent = get_mp_ssh1(src);
|
1999-01-08 16:02:13 +03:00
|
|
|
}
|
|
|
|
|
2018-05-24 10:22:44 +03:00
|
|
|
int rsa_ssh1_encrypt(unsigned char *data, int length, struct RSAKey *key)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
1999-01-08 16:02:13 +03:00
|
|
|
Bignum b1, b2;
|
2001-03-01 20:41:26 +03:00
|
|
|
int i;
|
1999-01-08 16:02:13 +03:00
|
|
|
unsigned char *p;
|
|
|
|
|
2004-08-01 16:07:11 +04:00
|
|
|
if (key->bytes < length + 4)
|
|
|
|
return 0; /* RSA key too short! */
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
memmove(data + key->bytes - length, data, length);
|
1999-01-08 16:02:13 +03:00
|
|
|
data[0] = 0;
|
|
|
|
data[1] = 2;
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = 2; i < key->bytes - length - 1; i++) {
|
1999-01-08 16:02:13 +03:00
|
|
|
do {
|
|
|
|
data[i] = random_byte();
|
|
|
|
} while (data[i] == 0);
|
|
|
|
}
|
2001-05-06 18:35:20 +04:00
|
|
|
data[key->bytes - length - 1] = 0;
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2001-03-01 20:41:26 +03:00
|
|
|
b1 = bignum_from_bytes(data, key->bytes);
|
1999-01-08 16:02:13 +03:00
|
|
|
|
2000-10-23 20:11:31 +04:00
|
|
|
b2 = modpow(b1, key->exponent, key->modulus);
|
1999-01-08 16:02:13 +03:00
|
|
|
|
|
|
|
p = data;
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = key->bytes; i--;) {
|
|
|
|
*p++ = bignum_byte(b2, i);
|
1999-01-08 16:02:13 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
freebn(b1);
|
|
|
|
freebn(b2);
|
2004-08-01 16:07:11 +04:00
|
|
|
|
|
|
|
return 1;
|
1999-01-08 16:02:13 +03:00
|
|
|
}
|
|
|
|
|
2003-03-15 20:51:05 +03:00
|
|
|
/*
|
2011-02-18 11:25:39 +03:00
|
|
|
* Compute (base ^ exp) % mod, provided mod == p * q, with p,q
|
|
|
|
* distinct primes, and iqmp is the multiplicative inverse of q mod p.
|
|
|
|
* Uses Chinese Remainder Theorem to speed computation up over the
|
|
|
|
* obvious implementation of a single big modpow.
|
|
|
|
*/
|
|
|
|
Bignum crt_modpow(Bignum base, Bignum exp, Bignum mod,
|
|
|
|
Bignum p, Bignum q, Bignum iqmp)
|
|
|
|
{
|
|
|
|
Bignum pm1, qm1, pexp, qexp, presult, qresult, diff, multiplier, ret0, ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reduce the exponent mod phi(p) and phi(q), to save time when
|
|
|
|
* exponentiating mod p and mod q respectively. Of course, since p
|
|
|
|
* and q are prime, phi(p) == p-1 and similarly for q.
|
|
|
|
*/
|
|
|
|
pm1 = copybn(p);
|
|
|
|
decbn(pm1);
|
|
|
|
qm1 = copybn(q);
|
|
|
|
decbn(qm1);
|
|
|
|
pexp = bigmod(exp, pm1);
|
|
|
|
qexp = bigmod(exp, qm1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do the two modpows.
|
|
|
|
*/
|
|
|
|
presult = modpow(base, pexp, p);
|
|
|
|
qresult = modpow(base, qexp, q);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recombine the results. We want a value which is congruent to
|
|
|
|
* qresult mod q, and to presult mod p.
|
|
|
|
*
|
|
|
|
* We know that iqmp * q is congruent to 1 * mod p (by definition
|
|
|
|
* of iqmp) and to 0 mod q (obviously). So we start with qresult
|
|
|
|
* (which is congruent to qresult mod both primes), and add on
|
|
|
|
* (presult-qresult) * (iqmp * q) which adjusts it to be congruent
|
|
|
|
* to presult mod p without affecting its value mod q.
|
|
|
|
*/
|
|
|
|
if (bignum_cmp(presult, qresult) < 0) {
|
|
|
|
/*
|
|
|
|
* Can't subtract presult from qresult without first adding on
|
|
|
|
* p.
|
|
|
|
*/
|
|
|
|
Bignum tmp = presult;
|
|
|
|
presult = bigadd(presult, p);
|
|
|
|
freebn(tmp);
|
|
|
|
}
|
|
|
|
diff = bigsub(presult, qresult);
|
|
|
|
multiplier = bigmul(iqmp, q);
|
|
|
|
ret0 = bigmuladd(multiplier, diff, qresult);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Finally, reduce the result mod n.
|
|
|
|
*/
|
|
|
|
ret = bigmod(ret0, mod);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free all the intermediate results before returning.
|
|
|
|
*/
|
|
|
|
freebn(pm1);
|
|
|
|
freebn(qm1);
|
|
|
|
freebn(pexp);
|
|
|
|
freebn(qexp);
|
|
|
|
freebn(presult);
|
|
|
|
freebn(qresult);
|
|
|
|
freebn(diff);
|
|
|
|
freebn(multiplier);
|
|
|
|
freebn(ret0);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is a wrapper on modpow(). It has the same effect as
|
|
|
|
* modpow(), but employs RSA blinding to protect against timing
|
|
|
|
* attacks and also uses the Chinese Remainder Theorem (implemented
|
|
|
|
* above, in crt_modpow()) to speed up the main operation.
|
2003-03-15 20:51:05 +03:00
|
|
|
*/
|
|
|
|
static Bignum rsa_privkey_op(Bignum input, struct RSAKey *key)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2003-03-15 20:51:05 +03:00
|
|
|
Bignum random, random_encrypted, random_inverse;
|
|
|
|
Bignum input_blinded, ret_blinded;
|
2000-09-07 20:33:49 +04:00
|
|
|
Bignum ret;
|
2003-03-15 20:51:05 +03:00
|
|
|
|
2003-04-27 13:45:35 +04:00
|
|
|
SHA512_State ss;
|
|
|
|
unsigned char digest512[64];
|
|
|
|
int digestused = lenof(digest512);
|
|
|
|
int hashseq = 0;
|
|
|
|
|
2003-03-15 20:51:05 +03:00
|
|
|
/*
|
|
|
|
* Start by inventing a random number chosen uniformly from the
|
|
|
|
* range 2..modulus-1. (We do this by preparing a random number
|
|
|
|
* of the right length and retrying if it's greater than the
|
|
|
|
* modulus, to prevent any potential Bleichenbacher-like
|
|
|
|
* attacks making use of the uneven distribution within the
|
|
|
|
* range that would arise from just reducing our number mod n.
|
|
|
|
* There are timing implications to the potential retries, of
|
|
|
|
* course, but all they tell you is the modulus, which you
|
|
|
|
* already knew.)
|
2003-04-27 13:45:35 +04:00
|
|
|
*
|
|
|
|
* To preserve determinism and avoid Pageant needing to share
|
|
|
|
* the random number pool, we actually generate this `random'
|
|
|
|
* number by hashing stuff with the private key.
|
2003-03-15 20:51:05 +03:00
|
|
|
*/
|
|
|
|
while (1) {
|
|
|
|
int bits, byte, bitsleft, v;
|
|
|
|
random = copybn(key->modulus);
|
|
|
|
/*
|
|
|
|
* Find the topmost set bit. (This function will return its
|
|
|
|
* index plus one.) Then we'll set all bits from that one
|
|
|
|
* downwards randomly.
|
|
|
|
*/
|
|
|
|
bits = bignum_bitcount(random);
|
|
|
|
byte = 0;
|
|
|
|
bitsleft = 0;
|
|
|
|
while (bits--) {
|
2003-04-27 13:45:35 +04:00
|
|
|
if (bitsleft <= 0) {
|
|
|
|
bitsleft = 8;
|
|
|
|
/*
|
|
|
|
* Conceptually the following few lines are equivalent to
|
|
|
|
* byte = random_byte();
|
|
|
|
*/
|
|
|
|
if (digestused >= lenof(digest512)) {
|
|
|
|
SHA512_Init(&ss);
|
2018-05-24 12:03:36 +03:00
|
|
|
put_data(&ss, "RSA deterministic blinding", 26);
|
2018-05-24 11:42:02 +03:00
|
|
|
put_uint32(&ss, hashseq);
|
|
|
|
put_mp_ssh2(&ss, key->private_exponent);
|
2003-04-27 13:45:35 +04:00
|
|
|
SHA512_Final(&ss, digest512);
|
|
|
|
hashseq++;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now hash that digest plus the signature
|
|
|
|
* input.
|
|
|
|
*/
|
|
|
|
SHA512_Init(&ss);
|
2018-05-24 12:03:36 +03:00
|
|
|
put_data(&ss, digest512, sizeof(digest512));
|
2018-05-24 11:42:02 +03:00
|
|
|
put_mp_ssh2(&ss, input);
|
2003-04-27 13:45:35 +04:00
|
|
|
SHA512_Final(&ss, digest512);
|
|
|
|
|
|
|
|
digestused = 0;
|
|
|
|
}
|
|
|
|
byte = digest512[digestused++];
|
|
|
|
}
|
2003-03-15 20:51:05 +03:00
|
|
|
v = byte & 1;
|
|
|
|
byte >>= 1;
|
|
|
|
bitsleft--;
|
|
|
|
bignum_set_bit(random, bits, v);
|
|
|
|
}
|
2014-02-25 03:35:55 +04:00
|
|
|
bn_restore_invariant(random);
|
2003-03-15 20:51:05 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now check that this number is strictly greater than
|
|
|
|
* zero, and strictly less than modulus.
|
|
|
|
*/
|
|
|
|
if (bignum_cmp(random, Zero) <= 0 ||
|
|
|
|
bignum_cmp(random, key->modulus) >= 0) {
|
|
|
|
freebn(random);
|
|
|
|
continue;
|
|
|
|
}
|
2013-08-04 23:34:07 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Also, make sure it has an inverse mod modulus.
|
|
|
|
*/
|
|
|
|
random_inverse = modinv(random, key->modulus);
|
|
|
|
if (!random_inverse) {
|
|
|
|
freebn(random);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
2003-03-15 20:51:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RSA blinding relies on the fact that (xy)^d mod n is equal
|
|
|
|
* to (x^d mod n) * (y^d mod n) mod n. We invent a random pair
|
2003-03-15 21:39:10 +03:00
|
|
|
* y and y^d; then we multiply x by y, raise to the power d mod
|
|
|
|
* n as usual, and divide by y^d to recover x^d. Thus an
|
|
|
|
* attacker can't correlate the timing of the modpow with the
|
|
|
|
* input, because they don't know anything about the number
|
|
|
|
* that was input to the actual modpow.
|
2003-03-15 20:51:05 +03:00
|
|
|
*
|
|
|
|
* The clever bit is that we don't have to do a huge modpow to
|
|
|
|
* get y and y^d; we will use the number we just invented as
|
2003-03-15 21:39:10 +03:00
|
|
|
* _y^d_, and use the _public_ exponent to compute (y^d)^e = y
|
|
|
|
* from it, which is much faster to do.
|
2003-03-15 20:51:05 +03:00
|
|
|
*/
|
2011-02-18 11:25:39 +03:00
|
|
|
random_encrypted = crt_modpow(random, key->exponent,
|
|
|
|
key->modulus, key->p, key->q, key->iqmp);
|
2003-03-15 20:51:05 +03:00
|
|
|
input_blinded = modmul(input, random_encrypted, key->modulus);
|
2011-02-18 11:25:39 +03:00
|
|
|
ret_blinded = crt_modpow(input_blinded, key->private_exponent,
|
|
|
|
key->modulus, key->p, key->q, key->iqmp);
|
2003-03-15 20:51:05 +03:00
|
|
|
ret = modmul(ret_blinded, random_inverse, key->modulus);
|
|
|
|
|
|
|
|
freebn(ret_blinded);
|
|
|
|
freebn(input_blinded);
|
|
|
|
freebn(random_inverse);
|
|
|
|
freebn(random_encrypted);
|
|
|
|
freebn(random);
|
|
|
|
|
2000-09-07 20:33:49 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-05-24 10:22:44 +03:00
|
|
|
Bignum rsa_ssh1_decrypt(Bignum input, struct RSAKey *key)
|
2003-03-15 20:51:05 +03:00
|
|
|
{
|
|
|
|
return rsa_privkey_op(input, key);
|
|
|
|
}
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
int rsastr_len(struct RSAKey *key)
|
|
|
|
{
|
1999-01-08 16:02:13 +03:00
|
|
|
Bignum md, ex;
|
2001-03-01 20:41:26 +03:00
|
|
|
int mdlen, exlen;
|
1999-01-08 16:02:13 +03:00
|
|
|
|
|
|
|
md = key->modulus;
|
|
|
|
ex = key->exponent;
|
2001-05-06 18:35:20 +04:00
|
|
|
mdlen = (bignum_bitcount(md) + 15) / 16;
|
|
|
|
exlen = (bignum_bitcount(ex) + 15) / 16;
|
|
|
|
return 4 * (mdlen + exlen) + 20;
|
1999-01-08 16:02:13 +03:00
|
|
|
}
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
void rsastr_fmt(char *str, struct RSAKey *key)
|
|
|
|
{
|
1999-01-08 16:02:13 +03:00
|
|
|
Bignum md, ex;
|
2000-09-27 19:21:04 +04:00
|
|
|
int len = 0, i, nibbles;
|
|
|
|
static const char hex[] = "0123456789abcdef";
|
1999-01-08 16:02:13 +03:00
|
|
|
|
|
|
|
md = key->modulus;
|
|
|
|
ex = key->exponent;
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
len += sprintf(str + len, "0x");
|
2000-09-27 19:21:04 +04:00
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
nibbles = (3 + bignum_bitcount(ex)) / 4;
|
|
|
|
if (nibbles < 1)
|
|
|
|
nibbles = 1;
|
|
|
|
for (i = nibbles; i--;)
|
|
|
|
str[len++] = hex[(bignum_byte(ex, i / 2) >> (4 * (i % 2))) & 0xF];
|
2000-09-27 19:21:04 +04:00
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
len += sprintf(str + len, ",0x");
|
2000-09-27 19:21:04 +04:00
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
nibbles = (3 + bignum_bitcount(md)) / 4;
|
|
|
|
if (nibbles < 1)
|
|
|
|
nibbles = 1;
|
|
|
|
for (i = nibbles; i--;)
|
|
|
|
str[len++] = hex[(bignum_byte(md, i / 2) >> (4 * (i % 2))) & 0xF];
|
2000-09-27 19:21:04 +04:00
|
|
|
|
1999-01-08 16:02:13 +03:00
|
|
|
str[len] = '\0';
|
|
|
|
}
|
|
|
|
|
2000-09-26 18:26:21 +04:00
|
|
|
/*
|
|
|
|
* Generate a fingerprint string for the key. Compatible with the
|
|
|
|
* OpenSSH fingerprint code.
|
|
|
|
*/
|
2018-06-03 10:08:53 +03:00
|
|
|
char *rsa_ssh1_fingerprint(struct RSAKey *key)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2000-09-26 18:26:21 +04:00
|
|
|
struct MD5Context md5c;
|
|
|
|
unsigned char digest[16];
|
2018-06-03 10:08:53 +03:00
|
|
|
strbuf *out;
|
|
|
|
int i;
|
2000-09-26 18:26:21 +04:00
|
|
|
|
|
|
|
MD5Init(&md5c);
|
2018-05-24 12:03:36 +03:00
|
|
|
put_mp_ssh1(&md5c, key->modulus);
|
|
|
|
put_mp_ssh1(&md5c, key->exponent);
|
2000-09-26 18:26:21 +04:00
|
|
|
MD5Final(digest, &md5c);
|
|
|
|
|
2018-06-03 10:08:53 +03:00
|
|
|
out = strbuf_new();
|
|
|
|
strbuf_catf(out, "%d ", bignum_bitcount(key->modulus));
|
2000-09-26 18:26:21 +04:00
|
|
|
for (i = 0; i < 16; i++)
|
2018-06-03 10:08:53 +03:00
|
|
|
strbuf_catf(out, "%s%02x", i ? ":" : "", digest[i]);
|
|
|
|
if (key->comment)
|
|
|
|
strbuf_catf(out, " %s", key->comment);
|
|
|
|
return strbuf_to_str(out);
|
2000-09-26 18:26:21 +04:00
|
|
|
}
|
|
|
|
|
2001-03-23 00:48:33 +03:00
|
|
|
/*
|
|
|
|
* Verify that the public data in an RSA key matches the private
|
2001-03-23 16:02:39 +03:00
|
|
|
* data. We also check the private data itself: we ensure that p >
|
|
|
|
* q and that iqmp really is the inverse of q mod p.
|
2001-03-23 00:48:33 +03:00
|
|
|
*/
|
2001-05-06 18:35:20 +04:00
|
|
|
int rsa_verify(struct RSAKey *key)
|
|
|
|
{
|
2001-03-23 16:02:39 +03:00
|
|
|
Bignum n, ed, pm1, qm1;
|
2001-03-23 00:48:33 +03:00
|
|
|
int cmp;
|
|
|
|
|
|
|
|
/* n must equal pq. */
|
|
|
|
n = bigmul(key->p, key->q);
|
|
|
|
cmp = bignum_cmp(n, key->modulus);
|
|
|
|
freebn(n);
|
|
|
|
if (cmp != 0)
|
|
|
|
return 0;
|
|
|
|
|
2001-03-23 16:02:39 +03:00
|
|
|
/* e * d must be congruent to 1, modulo (p-1) and modulo (q-1). */
|
2001-03-23 00:48:33 +03:00
|
|
|
pm1 = copybn(key->p);
|
|
|
|
decbn(pm1);
|
2001-03-23 16:02:39 +03:00
|
|
|
ed = modmul(key->exponent, key->private_exponent, pm1);
|
2013-07-14 14:46:07 +04:00
|
|
|
freebn(pm1);
|
2001-03-23 16:02:39 +03:00
|
|
|
cmp = bignum_cmp(ed, One);
|
2013-08-02 10:28:00 +04:00
|
|
|
freebn(ed);
|
2001-03-23 16:02:39 +03:00
|
|
|
if (cmp != 0)
|
|
|
|
return 0;
|
|
|
|
|
2001-03-23 00:48:33 +03:00
|
|
|
qm1 = copybn(key->q);
|
|
|
|
decbn(qm1);
|
2001-03-23 16:02:39 +03:00
|
|
|
ed = modmul(key->exponent, key->private_exponent, qm1);
|
2013-07-14 14:46:07 +04:00
|
|
|
freebn(qm1);
|
2001-03-23 00:48:33 +03:00
|
|
|
cmp = bignum_cmp(ed, One);
|
2013-08-02 10:28:00 +04:00
|
|
|
freebn(ed);
|
2001-03-23 00:48:33 +03:00
|
|
|
if (cmp != 0)
|
|
|
|
return 0;
|
2001-03-23 12:20:43 +03:00
|
|
|
|
2001-03-23 16:02:39 +03:00
|
|
|
/*
|
|
|
|
* Ensure p > q.
|
2008-10-07 21:48:59 +04:00
|
|
|
*
|
|
|
|
* I have seen key blobs in the wild which were generated with
|
|
|
|
* p < q, so instead of rejecting the key in this case we
|
|
|
|
* should instead flip them round into the canonical order of
|
|
|
|
* p > q. This also involves regenerating iqmp.
|
2001-03-23 16:02:39 +03:00
|
|
|
*/
|
2008-10-07 21:48:59 +04:00
|
|
|
if (bignum_cmp(key->p, key->q) <= 0) {
|
|
|
|
Bignum tmp = key->p;
|
|
|
|
key->p = key->q;
|
|
|
|
key->q = tmp;
|
|
|
|
|
|
|
|
freebn(key->iqmp);
|
|
|
|
key->iqmp = modinv(key->q, key->p);
|
2013-08-04 23:34:07 +04:00
|
|
|
if (!key->iqmp)
|
|
|
|
return 0;
|
2008-10-07 21:48:59 +04:00
|
|
|
}
|
2001-03-23 16:02:39 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure iqmp * q is congruent to 1, modulo p.
|
|
|
|
*/
|
|
|
|
n = modmul(key->iqmp, key->q, key->p);
|
|
|
|
cmp = bignum_cmp(n, One);
|
2013-08-02 10:28:00 +04:00
|
|
|
freebn(n);
|
2001-03-23 16:02:39 +03:00
|
|
|
if (cmp != 0)
|
2001-05-06 18:35:20 +04:00
|
|
|
return 0;
|
2001-03-23 16:02:39 +03:00
|
|
|
|
2001-03-23 12:20:43 +03:00
|
|
|
return 1;
|
2001-03-23 00:48:33 +03:00
|
|
|
}
|
|
|
|
|
2018-05-24 12:59:39 +03:00
|
|
|
void rsa_ssh1_public_blob(BinarySink *bs, struct RSAKey *key,
|
|
|
|
RsaSsh1Order order)
|
2001-12-30 18:58:17 +03:00
|
|
|
{
|
2018-05-24 12:59:39 +03:00
|
|
|
put_uint32(bs, bignum_bitcount(key->modulus));
|
2018-05-24 10:22:44 +03:00
|
|
|
if (order == RSA_SSH1_EXPONENT_FIRST) {
|
2018-05-24 12:59:39 +03:00
|
|
|
put_mp_ssh1(bs, key->exponent);
|
|
|
|
put_mp_ssh1(bs, key->modulus);
|
2018-05-24 10:22:44 +03:00
|
|
|
} else {
|
2018-05-24 12:59:39 +03:00
|
|
|
put_mp_ssh1(bs, key->modulus);
|
|
|
|
put_mp_ssh1(bs, key->exponent);
|
2018-05-24 10:22:44 +03:00
|
|
|
}
|
2001-12-30 18:58:17 +03:00
|
|
|
}
|
|
|
|
|
2018-06-03 10:12:57 +03:00
|
|
|
/* Given an SSH-1 public key blob, determine its length. */
|
|
|
|
int rsa_ssh1_public_blob_len(void *data, int maxlen)
|
2001-12-30 18:58:17 +03:00
|
|
|
{
|
2018-05-27 23:51:36 +03:00
|
|
|
BinarySource src[1];
|
2001-12-30 18:58:17 +03:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
BinarySource_BARE_INIT(src, data, maxlen);
|
2004-08-01 16:07:11 +04:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
/* Expect a length word, then exponent and modulus. (It doesn't
|
|
|
|
* even matter which order.) */
|
|
|
|
get_uint32(src);
|
|
|
|
freebn(get_mp_ssh1(src));
|
|
|
|
freebn(get_mp_ssh1(src));
|
2004-08-01 16:07:11 +04:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
if (get_err(src))
|
2004-08-01 16:07:11 +04:00
|
|
|
return -1;
|
2001-12-30 18:58:17 +03:00
|
|
|
|
2018-05-27 23:51:36 +03:00
|
|
|
/* Return the number of bytes consumed. */
|
|
|
|
return src->pos;
|
2001-12-30 18:58:17 +03:00
|
|
|
}
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
void freersakey(struct RSAKey *key)
|
|
|
|
{
|
|
|
|
if (key->modulus)
|
|
|
|
freebn(key->modulus);
|
|
|
|
if (key->exponent)
|
|
|
|
freebn(key->exponent);
|
|
|
|
if (key->private_exponent)
|
|
|
|
freebn(key->private_exponent);
|
2008-10-07 21:48:59 +04:00
|
|
|
if (key->p)
|
|
|
|
freebn(key->p);
|
|
|
|
if (key->q)
|
|
|
|
freebn(key->q);
|
|
|
|
if (key->iqmp)
|
|
|
|
freebn(key->iqmp);
|
2001-05-06 18:35:20 +04:00
|
|
|
if (key->comment)
|
|
|
|
sfree(key->comment);
|
2000-09-14 19:02:50 +04:00
|
|
|
}
|
2001-03-02 20:13:36 +03:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Implementation of the ssh-rsa signing key type.
|
|
|
|
*/
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
static void rsa2_freekey(ssh_key *key); /* forward reference */
|
2013-08-04 23:34:10 +04:00
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static ssh_key *rsa2_new_pub(const ssh_keyalg *self, ptrlen data)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource src[1];
|
2001-03-02 20:13:36 +03:00
|
|
|
struct RSAKey *rsa;
|
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource_BARE_INIT(src, data.ptr, data.len);
|
|
|
|
if (!ptrlen_eq_string(get_string(src), "ssh-rsa"))
|
2001-03-02 20:13:36 +03:00
|
|
|
return NULL;
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
|
|
|
|
rsa = snew(struct RSAKey);
|
2018-06-03 14:58:05 +03:00
|
|
|
rsa->sshk = &ssh_rsa;
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
rsa->exponent = get_mp_ssh2(src);
|
|
|
|
rsa->modulus = get_mp_ssh2(src);
|
2001-03-02 20:13:36 +03:00
|
|
|
rsa->private_exponent = NULL;
|
2008-10-08 22:09:56 +04:00
|
|
|
rsa->p = rsa->q = rsa->iqmp = NULL;
|
2001-03-02 20:13:36 +03:00
|
|
|
rsa->comment = NULL;
|
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
if (get_err(src)) {
|
|
|
|
rsa2_freekey(&rsa->sshk);
|
|
|
|
return NULL;
|
2013-08-04 23:34:10 +04:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
return &rsa->sshk;
|
2001-03-02 20:13:36 +03:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
static void rsa2_freekey(ssh_key *key)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2001-03-02 20:13:36 +03:00
|
|
|
freersakey(rsa);
|
|
|
|
sfree(rsa);
|
|
|
|
}
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static char *rsa2_cache_str(ssh_key *key)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2001-03-02 20:13:36 +03:00
|
|
|
char *p;
|
|
|
|
int len;
|
2001-05-06 18:35:20 +04:00
|
|
|
|
2001-03-02 20:13:36 +03:00
|
|
|
len = rsastr_len(rsa);
|
2003-03-29 19:14:26 +03:00
|
|
|
p = snewn(len, char);
|
2001-05-06 18:35:20 +04:00
|
|
|
rsastr_fmt(p, rsa);
|
2001-03-02 20:13:36 +03:00
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
static void rsa2_public_blob(ssh_key *key, BinarySink *bs)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2001-03-03 14:54:34 +03:00
|
|
|
|
2018-05-24 12:59:39 +03:00
|
|
|
put_stringz(bs, "ssh-rsa");
|
|
|
|
put_mp_ssh2(bs, rsa->exponent);
|
|
|
|
put_mp_ssh2(bs, rsa->modulus);
|
2001-03-03 14:54:34 +03:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
static void rsa2_private_blob(ssh_key *key, BinarySink *bs)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2001-03-03 14:54:34 +03:00
|
|
|
|
2018-05-24 12:59:39 +03:00
|
|
|
put_mp_ssh2(bs, rsa->private_exponent);
|
|
|
|
put_mp_ssh2(bs, rsa->p);
|
|
|
|
put_mp_ssh2(bs, rsa->q);
|
|
|
|
put_mp_ssh2(bs, rsa->iqmp);
|
2001-03-03 14:54:34 +03:00
|
|
|
}
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static ssh_key *rsa2_new_priv(const ssh_keyalg *self,
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
ptrlen pub, ptrlen priv)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource src[1];
|
2018-05-31 20:32:09 +03:00
|
|
|
ssh_key *sshk;
|
2001-03-03 14:54:34 +03:00
|
|
|
struct RSAKey *rsa;
|
2001-05-06 18:35:20 +04:00
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
sshk = rsa2_new_pub(self, pub);
|
2018-05-31 20:32:09 +03:00
|
|
|
if (!sshk)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
rsa = FROMFIELD(sshk, struct RSAKey, sshk);
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource_BARE_INIT(src, priv.ptr, priv.len);
|
|
|
|
rsa->private_exponent = get_mp_ssh2(src);
|
|
|
|
rsa->p = get_mp_ssh2(src);
|
|
|
|
rsa->q = get_mp_ssh2(src);
|
|
|
|
rsa->iqmp = get_mp_ssh2(src);
|
2001-03-03 14:54:34 +03:00
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
if (get_err(src) || !rsa_verify(rsa)) {
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
rsa2_freekey(&rsa->sshk);
|
2001-03-23 00:48:33 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
return &rsa->sshk;
|
2001-03-03 14:54:34 +03:00
|
|
|
}
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static ssh_key *rsa2_new_priv_openssh(const ssh_keyalg *self,
|
|
|
|
BinarySource *src)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
2001-03-03 18:31:35 +03:00
|
|
|
struct RSAKey *rsa;
|
|
|
|
|
2003-03-29 19:14:26 +03:00
|
|
|
rsa = snew(struct RSAKey);
|
2018-06-03 14:58:05 +03:00
|
|
|
rsa->sshk = &ssh_rsa;
|
2001-03-03 18:31:35 +03:00
|
|
|
rsa->comment = NULL;
|
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
rsa->modulus = get_mp_ssh2(src);
|
|
|
|
rsa->exponent = get_mp_ssh2(src);
|
|
|
|
rsa->private_exponent = get_mp_ssh2(src);
|
|
|
|
rsa->iqmp = get_mp_ssh2(src);
|
|
|
|
rsa->p = get_mp_ssh2(src);
|
|
|
|
rsa->q = get_mp_ssh2(src);
|
2001-03-03 18:31:35 +03:00
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
if (get_err(src) || !rsa_verify(rsa)) {
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
rsa2_freekey(&rsa->sshk);
|
2013-08-02 10:28:05 +04:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
return &rsa->sshk;
|
2001-03-03 18:31:35 +03:00
|
|
|
}
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static void rsa2_openssh_blob(ssh_key *key, BinarySink *bs)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2018-05-24 12:59:39 +03:00
|
|
|
|
|
|
|
put_mp_ssh2(bs, rsa->modulus);
|
|
|
|
put_mp_ssh2(bs, rsa->exponent);
|
|
|
|
put_mp_ssh2(bs, rsa->private_exponent);
|
|
|
|
put_mp_ssh2(bs, rsa->iqmp);
|
|
|
|
put_mp_ssh2(bs, rsa->p);
|
|
|
|
put_mp_ssh2(bs, rsa->q);
|
2001-04-16 15:16:58 +04:00
|
|
|
}
|
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
static int rsa2_pubkey_bits(const ssh_keyalg *self, ptrlen pub)
|
2004-01-22 22:15:32 +03:00
|
|
|
{
|
2018-05-31 20:32:09 +03:00
|
|
|
ssh_key *sshk;
|
2004-01-22 22:15:32 +03:00
|
|
|
struct RSAKey *rsa;
|
|
|
|
int ret;
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
sshk = rsa2_new_pub(self, pub);
|
2018-05-31 20:32:09 +03:00
|
|
|
if (!sshk)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
rsa = FROMFIELD(sshk, struct RSAKey, sshk);
|
2004-01-22 22:15:32 +03:00
|
|
|
ret = bignum_bitcount(rsa->modulus);
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
rsa2_freekey(&rsa->sshk);
|
2004-01-22 22:15:32 +03:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2001-03-02 20:13:36 +03:00
|
|
|
/*
|
|
|
|
* This is the magic ASN.1/DER prefix that goes in the decoded
|
|
|
|
* signature, between the string of FFs and the actual SHA hash
|
2001-03-09 16:30:43 +03:00
|
|
|
* value. The meaning of it is:
|
2001-03-02 20:13:36 +03:00
|
|
|
*
|
|
|
|
* 00 -- this marks the end of the FFs; not part of the ASN.1 bit itself
|
|
|
|
*
|
|
|
|
* 30 21 -- a constructed SEQUENCE of length 0x21
|
|
|
|
* 30 09 -- a constructed sub-SEQUENCE of length 9
|
|
|
|
* 06 05 -- an object identifier, length 5
|
2001-03-09 16:30:43 +03:00
|
|
|
* 2B 0E 03 02 1A -- object id { 1 3 14 3 2 26 }
|
|
|
|
* (the 1,3 comes from 0x2B = 43 = 40*1+3)
|
2001-03-02 20:13:36 +03:00
|
|
|
* 05 00 -- NULL
|
|
|
|
* 04 14 -- a primitive OCTET STRING of length 0x14
|
|
|
|
* [0x14 bytes of hash data follows]
|
2001-03-09 16:30:43 +03:00
|
|
|
*
|
|
|
|
* The object id in the middle there is listed as `id-sha1' in
|
|
|
|
* ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2.asn (the
|
|
|
|
* ASN module for PKCS #1) and its expanded form is as follows:
|
|
|
|
*
|
|
|
|
* id-sha1 OBJECT IDENTIFIER ::= {
|
|
|
|
* iso(1) identified-organization(3) oiw(14) secsig(3)
|
|
|
|
* algorithms(2) 26 }
|
2001-03-02 20:13:36 +03:00
|
|
|
*/
|
2002-10-25 16:59:57 +04:00
|
|
|
static const unsigned char asn1_weird_stuff[] = {
|
2001-05-06 18:35:20 +04:00
|
|
|
0x00, 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B,
|
|
|
|
0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14,
|
2001-03-02 20:13:36 +03:00
|
|
|
};
|
|
|
|
|
2001-03-05 20:31:36 +03:00
|
|
|
#define ASN1_LEN ( (int) sizeof(asn1_weird_stuff) )
|
|
|
|
|
2018-06-03 14:58:05 +03:00
|
|
|
static int rsa2_verify(ssh_key *key, ptrlen sig, ptrlen data)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource src[1];
|
|
|
|
ptrlen type, in_pl;
|
2001-03-02 20:13:36 +03:00
|
|
|
Bignum in, out;
|
|
|
|
int bytes, i, j, ret;
|
|
|
|
unsigned char hash[20];
|
|
|
|
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
BinarySource_BARE_INIT(src, sig.ptr, sig.len);
|
|
|
|
type = get_string(src);
|
|
|
|
/*
|
|
|
|
* RFC 4253 section 6.6: the signature integer in an ssh-rsa
|
|
|
|
* signature is 'without lengths or padding'. That is, we _don't_
|
|
|
|
* expect the usual leading zero byte if the topmost bit of the
|
|
|
|
* first byte is set. (However, because of the possibility of
|
|
|
|
* BUG_SSH2_RSA_PADDING at the other end, we tolerate it if it's
|
|
|
|
* there.) So we can't use get_mp_ssh2, which enforces that
|
|
|
|
* leading-byte scheme; instead we use get_string and
|
|
|
|
* bignum_from_bytes, which will tolerate anything.
|
|
|
|
*/
|
|
|
|
in_pl = get_string(src);
|
|
|
|
if (get_err(src) || !ptrlen_eq_string(type, "ssh-rsa"))
|
2001-05-06 18:35:20 +04:00
|
|
|
return 0;
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
|
|
|
|
in = bignum_from_bytes(in_pl.ptr, in_pl.len);
|
2001-03-02 20:13:36 +03:00
|
|
|
out = modpow(in, rsa->exponent, rsa->modulus);
|
|
|
|
freebn(in);
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
|
2004-02-07 13:02:20 +03:00
|
|
|
bytes = (bignum_bitcount(rsa->modulus)+7) / 8;
|
2001-03-02 20:13:36 +03:00
|
|
|
/* Top (partial) byte should be zero. */
|
2001-05-06 18:35:20 +04:00
|
|
|
if (bignum_byte(out, bytes - 1) != 0)
|
|
|
|
ret = 0;
|
2001-03-02 20:13:36 +03:00
|
|
|
/* First whole byte should be 1. */
|
2001-05-06 18:35:20 +04:00
|
|
|
if (bignum_byte(out, bytes - 2) != 1)
|
|
|
|
ret = 0;
|
2001-03-02 20:13:36 +03:00
|
|
|
/* Most of the rest should be FF. */
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = bytes - 3; i >= 20 + ASN1_LEN; i--) {
|
|
|
|
if (bignum_byte(out, i) != 0xFF)
|
|
|
|
ret = 0;
|
2001-03-02 20:13:36 +03:00
|
|
|
}
|
|
|
|
/* Then we expect to see the asn1_weird_stuff. */
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = 20 + ASN1_LEN - 1, j = 0; i >= 20; i--, j++) {
|
|
|
|
if (bignum_byte(out, i) != asn1_weird_stuff[j])
|
|
|
|
ret = 0;
|
2001-03-02 20:13:36 +03:00
|
|
|
}
|
|
|
|
/* Finally, we expect to see the SHA-1 hash of the signed data. */
|
Clean up ssh_keyalg APIs and implementations.
Quite a few of the function pointers in the ssh_keyalg vtable now take
ptrlen arguments in place of separate pointer and length pairs.
Meanwhile, the various key types' implementations of those functions
now work by initialising a BinarySource with the input ptrlen and
using the new decode functions to walk along it.
One exception is the openssh_createkey method which reads a private
key in the wire format used by OpenSSH's SSH-2 agent protocol, which
has to consume a prefix of a larger data stream, and tell the caller
how much of that data was the private key. That function now takes an
actual BinarySource, and passes that directly to the decode functions,
so that on return the caller finds that the BinarySource's read
pointer has been advanced exactly past the private key.
This let me throw away _several_ reimplementations of mpint-reading
functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still,
they didn't all have exactly the SSH-2 semantics, because the thing in
sshrsa.c whose name suggested it was an mpint-reading function
actually tolerated the wrong number of leading zero bytes, which it
had to be able to do to cope with the "ssh-rsa" signature format which
contains a thing that isn't quite an SSH-2 mpint. Now that deviation
is clearly commented!
2018-05-31 20:40:51 +03:00
|
|
|
SHA_Simple(data.ptr, data.len, hash);
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = 19, j = 0; i >= 0; i--, j++) {
|
|
|
|
if (bignum_byte(out, i) != hash[j])
|
|
|
|
ret = 0;
|
2001-03-02 20:13:36 +03:00
|
|
|
}
|
2003-12-19 15:44:46 +03:00
|
|
|
freebn(out);
|
2001-03-02 20:13:36 +03:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
static void rsa2_sign(ssh_key *key, const void *data, int datalen,
|
2018-05-24 12:59:39 +03:00
|
|
|
BinarySink *bs)
|
2001-05-06 18:35:20 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *rsa = FROMFIELD(key, struct RSAKey, sshk);
|
2001-03-03 14:54:34 +03:00
|
|
|
unsigned char *bytes;
|
|
|
|
int nbytes;
|
|
|
|
unsigned char hash[20];
|
|
|
|
Bignum in, out;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
SHA_Simple(data, datalen, hash);
|
|
|
|
|
2001-05-06 18:35:20 +04:00
|
|
|
nbytes = (bignum_bitcount(rsa->modulus) - 1) / 8;
|
2005-01-20 02:30:38 +03:00
|
|
|
assert(1 <= nbytes - 20 - ASN1_LEN);
|
2003-03-29 19:14:26 +03:00
|
|
|
bytes = snewn(nbytes, unsigned char);
|
2001-03-03 14:54:34 +03:00
|
|
|
|
|
|
|
bytes[0] = 1;
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = 1; i < nbytes - 20 - ASN1_LEN; i++)
|
2001-03-03 14:54:34 +03:00
|
|
|
bytes[i] = 0xFF;
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = nbytes - 20 - ASN1_LEN, j = 0; i < nbytes - 20; i++, j++)
|
2001-03-03 14:54:34 +03:00
|
|
|
bytes[i] = asn1_weird_stuff[j];
|
2001-05-06 18:35:20 +04:00
|
|
|
for (i = nbytes - 20, j = 0; i < nbytes; i++, j++)
|
2001-03-03 14:54:34 +03:00
|
|
|
bytes[i] = hash[j];
|
|
|
|
|
|
|
|
in = bignum_from_bytes(bytes, nbytes);
|
|
|
|
sfree(bytes);
|
|
|
|
|
2003-03-15 20:51:05 +03:00
|
|
|
out = rsa_privkey_op(in, rsa);
|
2001-03-03 14:54:34 +03:00
|
|
|
freebn(in);
|
|
|
|
|
2018-05-24 12:59:39 +03:00
|
|
|
put_stringz(bs, "ssh-rsa");
|
2001-05-06 18:35:20 +04:00
|
|
|
nbytes = (bignum_bitcount(out) + 7) / 8;
|
2018-05-24 12:59:39 +03:00
|
|
|
put_uint32(bs, nbytes);
|
2001-03-03 14:54:34 +03:00
|
|
|
for (i = 0; i < nbytes; i++)
|
2018-05-24 12:59:39 +03:00
|
|
|
put_byte(bs, bignum_byte(out, nbytes - 1 - i));
|
2001-03-03 14:54:34 +03:00
|
|
|
|
2018-05-24 12:59:39 +03:00
|
|
|
freebn(out);
|
2001-03-02 20:13:36 +03:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
const ssh_keyalg ssh_rsa = {
|
2018-06-03 14:58:05 +03:00
|
|
|
rsa2_new_pub,
|
|
|
|
rsa2_new_priv,
|
|
|
|
rsa2_new_priv_openssh,
|
|
|
|
|
2001-03-02 20:13:36 +03:00
|
|
|
rsa2_freekey,
|
2018-06-03 14:58:05 +03:00
|
|
|
rsa2_sign,
|
|
|
|
rsa2_verify,
|
2001-03-03 14:54:34 +03:00
|
|
|
rsa2_public_blob,
|
|
|
|
rsa2_private_blob,
|
2018-06-03 14:58:05 +03:00
|
|
|
rsa2_openssh_blob,
|
|
|
|
rsa2_cache_str,
|
|
|
|
|
2004-01-22 22:15:32 +03:00
|
|
|
rsa2_pubkey_bits,
|
2018-06-03 14:58:05 +03:00
|
|
|
|
2001-03-02 20:13:36 +03:00
|
|
|
"ssh-rsa",
|
2015-05-15 12:12:08 +03:00
|
|
|
"rsa2",
|
|
|
|
NULL,
|
2001-03-02 20:13:36 +03:00
|
|
|
};
|
2007-05-01 02:09:26 +04:00
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
struct RSAKey *ssh_rsakex_newkey(const void *data, int len)
|
2007-05-01 02:09:26 +04:00
|
|
|
{
|
2018-06-03 14:58:05 +03:00
|
|
|
ssh_key *sshk = rsa2_new_pub(&ssh_rsa, make_ptrlen(data, len));
|
2018-05-31 20:32:09 +03:00
|
|
|
if (!sshk)
|
|
|
|
return NULL;
|
|
|
|
return FROMFIELD(sshk, struct RSAKey, sshk);
|
2007-05-01 02:09:26 +04:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
void ssh_rsakex_freekey(struct RSAKey *key)
|
2007-05-01 02:09:26 +04:00
|
|
|
{
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
rsa2_freekey(&key->sshk);
|
2007-05-01 02:09:26 +04:00
|
|
|
}
|
|
|
|
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
int ssh_rsakex_klen(struct RSAKey *rsa)
|
2007-05-01 02:09:26 +04:00
|
|
|
{
|
|
|
|
return bignum_bitcount(rsa->modulus);
|
|
|
|
}
|
|
|
|
|
2018-09-13 18:41:46 +03:00
|
|
|
static void oaep_mask(const struct ssh_hashalg *h, void *seed, int seedlen,
|
2007-05-01 02:09:26 +04:00
|
|
|
void *vdata, int datalen)
|
|
|
|
{
|
|
|
|
unsigned char *data = (unsigned char *)vdata;
|
|
|
|
unsigned count = 0;
|
|
|
|
|
|
|
|
while (datalen > 0) {
|
|
|
|
int i, max = (datalen > h->hlen ? h->hlen : datalen);
|
2018-09-13 18:41:46 +03:00
|
|
|
ssh_hash *s;
|
2018-05-24 15:05:48 +03:00
|
|
|
unsigned char hash[SSH2_KEX_MAX_HASH_LEN];
|
2007-05-01 02:09:26 +04:00
|
|
|
|
2007-05-02 00:29:11 +04:00
|
|
|
assert(h->hlen <= SSH2_KEX_MAX_HASH_LEN);
|
2018-09-13 18:41:46 +03:00
|
|
|
s = ssh_hash_new(h);
|
|
|
|
put_data(s, seed, seedlen);
|
|
|
|
put_uint32(s, count);
|
|
|
|
ssh_hash_final(s, hash);
|
2007-05-01 02:09:26 +04:00
|
|
|
count++;
|
|
|
|
|
|
|
|
for (i = 0; i < max; i++)
|
|
|
|
data[i] ^= hash[i];
|
|
|
|
|
|
|
|
data += max;
|
|
|
|
datalen -= max;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-13 18:41:46 +03:00
|
|
|
void ssh_rsakex_encrypt(const struct ssh_hashalg *h,
|
|
|
|
unsigned char *in, int inlen,
|
Invent a struct type for polymorphic SSH key data.
During last week's work, I made a mistake in which I got the arguments
backwards in one of the key-blob-generating functions - mistakenly
swapped the 'void *' key instance with the 'BinarySink *' output
destination - and I didn't spot the mistake until run time, because in
C you can implicitly convert both to and from void * and so there was
no compile-time failure of type checking.
Now that I've introduced the FROMFIELD macro that downcasts a pointer
to one field of a structure to retrieve a pointer to the whole
structure, I think I might start using that more widely to indicate
this kind of polymorphic subtyping. So now all the public-key
functions in the struct ssh_signkey vtable handle their data instance
in the form of a pointer to a subfield of a new zero-sized structure
type 'ssh_key', which outside the key implementations indicates 'this
is some kind of key instance but it could be of any type'; they
downcast that pointer internally using FROMFIELD in place of the
previous ordinary C cast, and return one by returning &foo->sshk for
whatever foo they've just made up.
The sshk member is not at the beginning of the structure, which means
all those FROMFIELDs and &key->sshk are actually adding and
subtracting an offset. Of course I could have put the member at the
start anyway, but I had the idea that it's actually a feature _not_ to
have the two types start at the same address, because it means you
should notice earlier rather than later if you absentmindedly cast
from one to the other directly rather than by the approved method (in
particular, if you accidentally assign one through a void * and back
without even _noticing_ you perpetrated a cast). In particular, this
enforces that you can't sfree() the thing even once without realising
you should instead of called the right freekey function. (I found
several bugs by this method during initial testing, so I think it's
already proved its worth!)
While I'm here, I've also renamed the vtable structure ssh_signkey to
ssh_keyalg, because it was a confusing name anyway - it describes the
_algorithm_ for handling all keys of that type, not a specific key. So
ssh_keyalg is the collection of code, and ssh_key is one instance of
the data it handles.
2018-05-27 10:32:21 +03:00
|
|
|
unsigned char *out, int outlen, struct RSAKey *rsa)
|
2007-05-01 02:09:26 +04:00
|
|
|
{
|
|
|
|
Bignum b1, b2;
|
|
|
|
int k, i;
|
|
|
|
char *p;
|
|
|
|
const int HLEN = h->hlen;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Here we encrypt using RSAES-OAEP. Essentially this means:
|
|
|
|
*
|
|
|
|
* - we have a SHA-based `mask generation function' which
|
|
|
|
* creates a pseudo-random stream of mask data
|
|
|
|
* deterministically from an input chunk of data.
|
|
|
|
*
|
|
|
|
* - we have a random chunk of data called a seed.
|
|
|
|
*
|
|
|
|
* - we use the seed to generate a mask which we XOR with our
|
|
|
|
* plaintext.
|
|
|
|
*
|
|
|
|
* - then we use _the masked plaintext_ to generate a mask
|
|
|
|
* which we XOR with the seed.
|
|
|
|
*
|
|
|
|
* - then we concatenate the masked seed and the masked
|
|
|
|
* plaintext, and RSA-encrypt that lot.
|
|
|
|
*
|
|
|
|
* The result is that the data input to the encryption function
|
|
|
|
* is random-looking and (hopefully) contains no exploitable
|
|
|
|
* structure such as PKCS1-v1_5 does.
|
|
|
|
*
|
|
|
|
* For a precise specification, see RFC 3447, section 7.1.1.
|
|
|
|
* Some of the variable names below are derived from that, so
|
|
|
|
* it'd probably help to read it anyway.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* k denotes the length in octets of the RSA modulus. */
|
|
|
|
k = (7 + bignum_bitcount(rsa->modulus)) / 8;
|
|
|
|
|
|
|
|
/* The length of the input data must be at most k - 2hLen - 2. */
|
|
|
|
assert(inlen > 0 && inlen <= k - 2*HLEN - 2);
|
|
|
|
|
|
|
|
/* The length of the output data wants to be precisely k. */
|
|
|
|
assert(outlen == k);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now perform EME-OAEP encoding. First set up all the unmasked
|
|
|
|
* output data.
|
|
|
|
*/
|
|
|
|
/* Leading byte zero. */
|
|
|
|
out[0] = 0;
|
|
|
|
/* At position 1, the seed: HLEN bytes of random data. */
|
|
|
|
for (i = 0; i < HLEN; i++)
|
|
|
|
out[i + 1] = random_byte();
|
|
|
|
/* At position 1+HLEN, the data block DB, consisting of: */
|
|
|
|
/* The hash of the label (we only support an empty label here) */
|
2018-09-13 18:41:46 +03:00
|
|
|
{
|
|
|
|
ssh_hash *s = ssh_hash_new(h);
|
|
|
|
ssh_hash_final(s, out + HLEN + 1);
|
|
|
|
}
|
2007-05-01 02:09:26 +04:00
|
|
|
/* A bunch of zero octets */
|
|
|
|
memset(out + 2*HLEN + 1, 0, outlen - (2*HLEN + 1));
|
|
|
|
/* A single 1 octet, followed by the input message data. */
|
|
|
|
out[outlen - inlen - 1] = 1;
|
|
|
|
memcpy(out + outlen - inlen, in, inlen);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now use the seed data to mask the block DB.
|
|
|
|
*/
|
|
|
|
oaep_mask(h, out+1, HLEN, out+HLEN+1, outlen-HLEN-1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And now use the masked DB to mask the seed itself.
|
|
|
|
*/
|
|
|
|
oaep_mask(h, out+HLEN+1, outlen-HLEN-1, out+1, HLEN);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now `out' contains precisely the data we want to
|
|
|
|
* RSA-encrypt.
|
|
|
|
*/
|
|
|
|
b1 = bignum_from_bytes(out, outlen);
|
|
|
|
b2 = modpow(b1, rsa->exponent, rsa->modulus);
|
2007-06-30 22:18:20 +04:00
|
|
|
p = (char *)out;
|
2007-05-01 02:09:26 +04:00
|
|
|
for (i = outlen; i--;) {
|
|
|
|
*p++ = bignum_byte(b2, i);
|
|
|
|
}
|
|
|
|
freebn(b1);
|
|
|
|
freebn(b2);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And we're done.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct ssh_kex ssh_rsa_kex_sha1 = {
|
2015-05-15 12:12:08 +03:00
|
|
|
"rsa1024-sha1", NULL, KEXTYPE_RSA, &ssh_sha1, NULL,
|
2007-05-01 02:09:26 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct ssh_kex ssh_rsa_kex_sha256 = {
|
2015-05-15 12:12:08 +03:00
|
|
|
"rsa2048-sha256", NULL, KEXTYPE_RSA, &ssh_sha256, NULL,
|
2007-05-01 02:09:26 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct ssh_kex *const rsa_kex_list[] = {
|
|
|
|
&ssh_rsa_kex_sha256,
|
|
|
|
&ssh_rsa_kex_sha1
|
|
|
|
};
|
|
|
|
|
|
|
|
const struct ssh_kexes ssh_rsa_kex = {
|
|
|
|
sizeof(rsa_kex_list) / sizeof(*rsa_kex_list),
|
|
|
|
rsa_kex_list
|
|
|
|
};
|