We were inventing a random number by starting with a long zero bignum
and then setting bits at random, which left an opportunity for the
result to be a non-normalised representation (with a leading zero
word) and hence fail an assertion in bignum_cmp.
[originally from svn r10147]
of the GET_32BIT macros and then used as length fields. Missing bounds
checks against zero have been added, and also I've introduced a helper
function toint() which casts from unsigned to int in such a way as to
avoid C undefined behaviour, since I'm not sure I trust compilers any
more to do the obviously sensible thing.
[originally from svn r9918]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
the ordering of the primes in a fully specified RSA private key:
when the key format typically has p > q, it will always output p > q
but be willing to tolerate p < q on input. (Inspired by seeing an
OpenSSH-format key file in the wild which had p < q, which I've
never seen before; I suspect a third-party application incautiously
generating the format.)
[originally from svn r8201]
keys. This _appears_ to be due to me computing the byte count of the
key by dividing the bit count by 8 and rounding _down_ rather than
up. Therefore, I can't see how this code could ever have worked on
any SSH2 RSA key whose length was not a multiple of 8 bits; and
therefore I'm staggered that we haven't noticed it before! OpenSSH's
keygen appears to be scrupulous about ensuring the returned key
length is exactly what you asked for rather than one bit less, but
even so I'm astonished that _all_ keygen implementations for servers
we've ever interoperated with have avoided tripping this bug...
[originally from svn r3815]
on Linux, but the (very few) platform-specific bits are already
abstracted out of the main code, so it should port to other
platforms with a minimum of fuss.
[originally from svn r3762]
numbers needed for RSA blinding are now done deterministically by
hashes of the private key, much the same way we do it for DSA.
[originally from svn r3149]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
attacks. In the PuTTY suite I'm pretty sure they're only applicable
to a forwarded Pageant, and if your remote sysadmin is abusing your
Pageant then you're shafted _anyway_; but it can't hurt to take
precautions now, just in case things change in future.
[originally from svn r2941]
load a key that is already loaded. This makes command lines such as
`pageant mykey -c mycommand' almost infinitely more useful.
[originally from svn r1522]
spawn another command after starting Pageant. Also, if Pageant is
already running, `pageant keyfile' and `pageant -c command' will do
the Right Thing, that is, add the key to the _first_ Pageant and/or
run a command and then exit. The only time you now get the `Pageant
is already running' error is if you try to start the second copy
with no arguments.
NB the affected files in this checkin are rather wide-ranging
because I renamed the not really SSH1-specific
`ssh1_bignum_bitcount' function to just `bignum_bitcount'.
[originally from svn r1044]
the private data (verifying that p > q and that iqmp really is the
inverse of q mod p). In addition, we _no longer_ check that e*d == 1
mod (p-1)(q-1): instead we do separate checks mod (p-1) and mod (q-1),
since the order of the multiplicative group mod n is actually equal to
lcm(p-1,q-1) rather than phi(n)=(p-1)(q-1). (In other words, the
Fermat-Euler theorem doesn't point both ways.)
[originally from svn r1024]
tampering with the unencrypted public part of the key but leaving
the private part intact ... we are now ultra-paranoid about RSA key
files, and we check that the public part matches the private part
_before_ we generate any signatures with them.
[originally from svn r1021]
error messages are currently wrong, and Pageant doesn't yet support
the new key type, and I haven't thoroughly tested that falling back
to password authentication and trying invalid keys etc all work. But
what I have here has successfully performed a public key
authentication, so it's working to at least some extent.
[originally from svn r973]
smalloc() macros and thence to the safemalloc() functions in misc.c.
This should allow me to plug in a debugging allocator and track
memory leaks and segfaults and things.
[originally from svn r818]
handling were failing when the key had an odd number of bytes. A
server with an 850-bit key was suffering connection failures as a
result. Now fixed.
[originally from svn r426]
