Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- DSA & Symmetric Keys
- Italy Anonymous Remailer
January 14, 2005, 1:48 pm
rate this thread
Please could someone clarify something for me in simple terms, since I'm
not too knowing about the mathematical side of things..
In basic terms.. RSA can be used to sign and also to encrypt and I'm told
that DSA is a signing only algorithm.
Presumably when an ssh connection is made the client and the server
somehow 'handshake' to decide on a cipher and a session key. The cipher
doesn't have to be kept hidden, but the key does..
So.. if the server is using a DSA key to identify itsself.. and the client
is using a DSA key to authenticate.. and DSA is a signature only
algorithm.. how is the key transferred from one side to the other, and
which way is it transferred?
The reason I ask is that I would like to increase the security of the
connection. I use aes256 as the cipher (configured in the config files
without a problem, and verified using ssh -v) and using 1024 bit keys is
not a comparable strength for the assymetric algorithm. I like to use DSA
rather than RSA, and both the host key and my user's public key are DSA.
This leads me to wonder how a symmetric key can be agreed on when both
sides can only sign data to each other, and not encrypt it.
Am I understanding the limitations of DSA incorrectly? or maybe
Diffie-Hellman does not require data to be encrypted at all.
Please excuse my poor english, and thankyou to anyone who replies to this.
P.S - I would like to use at least 4096 bit keylength, and I have this
size key on the server with a 2048 bit key on the client. Is the symmetric
key protected by the 4096 bit key on the server, or the 2048 bit key on
Re: DSA & Symmetric Keys
The actual key transfer is done by Diffie-Hellman key exchange:
- the client and server each think of a private value
- each side computes a public value from the private value
- they exchange public values
- the same key can be derived from either private value and the
other public one, but cannot (feasibly) be derived from just the
two public values.
This allows the client and server to agree a secret key which an
eavesdropper cannot know. An _active_ attacker could intercept a
bare DH key exchange and send its own public values in place of the
real ones (leading to two different shared secrets, one between him
and the client, and another between him and the server), but in SSH
the signature from the host key defeats that attack.
Host keys and user authentication keys in SSH2 are only ever used
for signing, never for encryption. (Even if they're RSA, which is
capable of supporting encryption.)
Simon Tatham These are my opinions. There are many
- Richard E. Silverman
January 14, 2005, 6:42 pm
Re: DSA & Symmetric Keys
As Simon pointed out, the session key is "protected" in the sense of being
signed (anti-spoofing) with the host keys, but it is not encrypted with
them, so if you're talking about privacy protection these key lengths are
There are two Diffie-Hellman exchanges defined in the SSH transport
protocol, using fixed key lengths of 1024 and 2048 bits -- but the
2048-bit exchange (diffie-hellman-group14-sha1) is new, so not all SSH
software supports it yet. Furthermore, most SSH products do not allow you
to set the key exchange algorithm to use (note that this is different from
the host key algorithm). There is a proposed third exchange called
diffie-hellman-group-exchange-sha1, not part of the SSH transport draft
but implemented by various SSH products including OpenSSH. It negotiates
the Diffie-Hellman group rather than using a single fixed one; with the
OpenSSH server, you can get some control over the key size by editing
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum