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]
