RSA vs DSA

hi all. i'm not sure if this has been discussed or not.

ok. forget about telnet. that old protocol should only be used on routers, and nowhere else.

i've set up an openssh server using protocol version 2 and a 1024 bits rsa2 host key. i understand that there are problems in protocol version 1, so protocol version 2 is now recommended. but anyone knows which key type is preferred, rsa or dsa, in terms of security and speed? and how many bits key should i use? :confused:

any thoughts are welcome. thanks.

peace always,
<jdenny>

I'm not sure what's the difference between rsa & dsa. What I do know is that RSA 128bit encryption is chosen for SSL sessions between browsers/web servers. So RSA-128 is the market leader in this type of environments, and perhaps the best choice.

Quote:

---

So RSA-128 is the market leader in this type of environments, and perhaps the best choice.

---

whoa... sounds like micro$oft. :D thanks anyway...

since nobody else is gonna answer my question, i decided to googling around and here is the best i can get (forgive the cut-and-paste):

... The National Institute of Standards and Technology (NIST) (see Question 6.2.1) published the Digital Signature Algorithm (DSA) in the Digital Signature Standard (DSS), which is a part of the U.S. government's Capstone project (see Question 6.2.3). DSS was selected by NIST, in cooperation with the NSA (see Question 6.2.2), to be the digital authentication standard of the U.S. government. The standard was issued in May 1994.

DSA is based on the discrete logarithm problem (see Question 2.3.7) and is related to signature schemes that were proposed by Schnorr [Sch90] and ElGamal (see Question 3.6.8). While the RSA system can be used for both encryption and digital signatures (see Question 2.2.2) the DSA can only be used to provide digital signatures. For a detailed description of DSA, see [NIS94b] or [NIS92].

In DSA, signature generation is faster than signature verification, whereas with the RSA algorithm, signature verification is very much faster than signature generation. ...

complete text can be seen here:
http://www.rsasecurity.com/rsalabs/faq/3-4-1.html

i'm still looking for a more satisfactory answer though. :( any cryptography gurus out there?

peace always,
<jdenny>

Hi!
jdenny, on http://www.cacr.math.uwaterloo.ca/hac/ you can find a great book on cryptography. Chapter 11 is dedicated to digital signatures. (strong math)
Another good source is Applied Cryptography by Bruce Schneier.
ByE!
Groby

Quote:

---

DSA can only be used to provide digital signatures.

---

One other comment:
If you're using the protocol for secure transmission, doesn't that leave DSA out as it's only used for digital signatures?

now we're talking!!!

thanks groby for the pointer. i'm reading it as one of my bedtime stories... ;) what a math!

Quote:

---

One other comment:
If you're using the protocol for secure transmission, doesn't that leave DSA out as it's only used for digital signatures?

---

well, as in ssl, digital signatures are only used for authentication. the rest of the session is then encrypted using a conventional symmetric key. does it make sense?

from man sshd:

Protocol version 1

Whenever a client connects the daemon, responds with its public host and server keys. The client compares the RSA host key against its own database to verify that it has not changed. The client then generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the server. Both sides then use this random number as a session key which is used to encrypt all further communications in the session. The rest of the session is encrypted using a conventional cipher, currently Blowfish or 3DES, with 3DES being used by default. The client selects the encryption algorithm to use from those offered by the server.

Protocol version 2

Version 2 works similarly: Each host has a host-specific key (RSA or DSA) used to identify the host. However, when the daemon starts, it does not generate a server key. Forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key.

The rest of the session is encrypted using a symmetric cipher, currently 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, or 256 bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-sha1 or hmac-md5).

some other thoughts maybe?

peace always,
<jdenny>