2

DSA & RSA

It's not about which one is stronger.

I've been researching the subject on the internet and below is the summary of information I've got. Can you please advise if it is correct or not, and if there are any additional important issues which I don't mention here.

Here I am talking only about DSA vs RSA in application to Java. My main goal - to use Public key algorithm to send Session key (AES) from client to server and then to check authencity of client.

DSA.
1. In Java you're are supposed to encrypt the file with private key.
2. It means that IT IS a signature - anyone with a public key can read it, but only the owner can sign it.
3. If you try using public key as private and vice versa, you'll run into trouble, because it is not that difficult to guess public key by private.
4. You effectively can't use DSA to send Session key, because everyone will be able to decrypt it.

RSA.
1. In Java you're are supposed to encrypt file with public key.
2. It means that this is best way to deliver secret messages to one specific recepient. Nobody can read it after being signed, except for the owner.
3. If you try switching keys with each other it will bring troubles (the same as above)
4. You can effectively use RSA for a client to send Session key encrypted with Server's open key and then receive confirmation from servers signed with Client's open key.

Based on this I decided to use RSA for my purposes.

AES256 vs AES128

Another unrelated question - do you think that for session encryption without any extremely sensitive data it makes sense to use AES256?

I'd like to, but it creates problems for end user. I know it is very easy to install update to Java which allows 256 bit keys, but the sad truth is that even such simple thing can cut potential userbase by half.

On the other hand - if I don't send sensitive information (like credit card numbers) and each key is used for not more than a few days, maybe AES128 is enough?

Obviously I am going to include the option to use AES256 for those users who are not bothered by the need to install update.

Thanks for any comments!

Stanislav
  • 87
  • 1
  • 9
  • 2
    Bluntly put, the choice of cipher is your least concern, since you will be making *so many* other mistakes that compromise the security of the system in countless ways. As Bruce Schneier says, "cryptography is hard, and cryptography is the easy part." Pick an existing, high-quality security framework and don't roll this yourself. – Kerrek SB Feb 20 '12 at 21:27
  • Just to prevent any comments on OpenSSL and https I know what it is - can't use that. – Stanislav Feb 20 '12 at 21:29
  • Use SSL/TLS, and it will work. (Doesn't have to be OpenSSL, there is an SSLEngine available in Java. Or you can even implement the protocol yourself, if needed.) – Paŭlo Ebermann Feb 20 '12 at 21:29
  • Kerrek SB, thanks for honest reply. – Stanislav Feb 20 '12 at 21:33
  • @Paŭlo Ebermann: actually, implementing the protocol yourself is exactly what you should *not*, under any circumstances, do, unless you have *very* long experience developing cryptographic software and can get cryptography experts to review your implementation. – Michael Borgwardt Feb 20 '12 at 21:34
  • I know that I am probably not that smart Paul Kocher and I have incomaparbly smaller experience when it comes to computer security, compared to him. But, he was designing protocol to work under any conditions between any hosts with maximum security available. In my case it is only between my server and my applet and it is only with specified security level. I know I can still make lots of mistakes, but I will be extremely careful. After everything starts working as designed, I'll find good expert to look at it. – Stanislav Feb 20 '12 at 21:39
  • @MichaelBorgwardt: Implementing a proven protocol yourself is still a lot better than inventing a new protocol, though. – Paŭlo Ebermann Feb 20 '12 at 21:42

2 Answers2

3

As you found out, DSA is only a signature algorithm, not a encryption one, and as such not suitable for key exchange.

If you have a online connection (and not just transport from one point to another), you can use Diffie-Hellman (which is based on similar ideas like DSA), and use DSA or RSA in signature mode to authenticate the other side to avoid a man-in-the-middle attack.

Other than that, RSA key exchange is also quite usual (i.e. sending the key AES key encrypted with the RSA key of the server).

For the AES variants, AES-128 should be secure for about any time (i.e. bruteforcing should take longer than you'll live). There is only a larger key variant as the US military wanted to use different levels of security for different stuff. (And also, AES-256 is lately showing some (theoretical) weaknesses which are not in AES-128, which could mean that AES-128 is actually more secure.)

But as Kerrek commented, don't try to invent your own protocol, use existing ones. You will make all mistakes the other ones did before, and add new ones. (You can do your own implementation of these protocols if you want, but it is also often easier and safer to reuse existing implementations, too - there are lots of things to do wrong even with secure protocols, like using bad random numbers.)

For online (two-sided) communication, SSL (or now better its successor TLS) is the way to go. In Java, it is available as the SSLEngine class (if you want to use asynchronous I/O), or with a SSL(Server)SocketFactory (for normal socket read/write). I used this for applet/server communication (for my project fencing-game).

For offline (one-directed) communication (like e-mail) or storage, use the PGP data format (which also can use RSA and AES). (I don't know of an existing Java implementation, though.)

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
1

DSA means "Digital Signature Algorithm". It's meant for signatures. You cannot use it to encrypt anything.

AES128 is plenty secure enough for sensitive information. Even the US government allows its use for anything except information classified as TOP SECRET, and that only because of a "better safe than sorry" mentality and considering that such information may still be harmful if decoded 50 years from now. I wouldn't hesitate a second to use it for transmitting credit card numbers (which, after all, expire in less than 10 years).

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
  • In theory the general idea behind DSA and RSA is the same - two set of keys - one for encryption, one for decryption. So it is easy to call DSA's open key - "private key" and DSA's private key - "open key" and use it for encrypting. But then you run in troubles, because it was not designed that way and it is extremely vulnerable. I hear what you're saying, that's what I understood right. My choice then is RAS + AES128 with option for AES256 for those who need it. – Stanislav Feb 20 '12 at 21:36
  • @Stanislav: No, DSA will not work for encryption. Each signature of the same data is different, and the checking procedure is not like "decrypting", it will only give you a "true" or "false". – Paŭlo Ebermann Feb 20 '12 at 21:44