SSH DSA logins on crank.

John Gilmore gnu at
Thu May 22 03:35:50 EDT 2008

> one reason would be that DSA is more secure then RSA. If you have a copy 
> of the secret key from one end of the conversation and they are using RSA 
> you can decrypt the communication, with DSA you cannot do so.

That blanket statement is false.

I'm still working my way through the RFC's for SSH, but my impression
at this point is that ssh's RSA implements "perfect forward secrecy",
which involves doing a signed Diffie-Hellman exchange that generates
an ephemeral session key that can't be decrypted by a non-party to the

> several products on the market that take advantage of this fact and have 
> you load your keys on a seperate box that then intercepts the 
> communication to your webservers and decrypts the traffic...

The products you're talking about seem to be for monitoring https 
traffic, which use a different protocol than ssh.

In general, RSA's security properties are better understood than
DSA's.  It has withstood the test of time for decades longer; it is
not limited to a fixed length key; it was not designed by NSA; and it
has no inherent covert channels.  (DSA looks like it was designed to
make huge covert channels.)  And as we discovered from the Debian
cluelessness: when signing with yuor key, if your random numbers are
corrupt, RSA doesn't leak your private key, but DSA does.

(I've been exclusively using RSA for my own encryption for a long time.
And when generating RSA keys, I generate large ones in the 4200-8000 bit
range, size pseudo-randomly selected.  This avoids one possible attack,
which is:  if 90% of the RSA keys are 2048 bits, clearly a major attacker
like NSA would build a brute force attack machine that handles 2048 bits.
If no particular bit length has more than 20% of the market, you have to
build a cracker for a much longer length to capture a significant part
of the traffic.  The one-time time to generate the keys is a minute or
two; but computers are so fast you don't notice any extra overhead while
in everyday use.)


More information about the Devel mailing list