3

I need a solution to encrypt USB communication between device A and device B. I was thinking about configuring each device with a secret RSA-2048 key, which would be used to exchange an AES-256 session key.

  1. A and B are pre-configured with secret RSA-2048 asymmetric keys.
  2. A sends an unencrypted message to B indicating that encryption should be used.
  3. B uses its RSA-2048 key to encrypt an AES-256 symmetric session key and sends it to A.
  4. A uses its RSA-2048 key to decrypt the message and obtain the AES-256 session key.
  5. The AES-256 session key is used for encrypting/decrypting communication going forward.

Since the RSA-2048 keys are both secret, is there any point in using RSA over AES for encrypting the session key exchange? In other words, is it acceptable for both A and B to be pre-configured with a secret AES-256 key (instead of secret RSA-2048 keys) that is used to generate an AES-256 session key?

Anti-weakpasswords
  • 9,850
  • 2
  • 24
  • 52

3 Answers3

1

It depends.

If A and B are configured with secret AES keys, then A and B's previously intercepted communications can be trivially decrypted after the AES key comes to light (B is pulled out of the trash can your SO threw it in next year).

If you use secret RSA keys, then it's very similar, though each intercept must have the packets containing the cryptographically randomly generated AES key for that "session" to decrypt data previously intercepted from that session.

If you use something like TLS-DHE-* or TLS-ECDHE-*, then retrieving the device later does NOT help decrypt previously intercepted communications; this is the big deal about forward secrecy using ephemeral keys.

Anti-weakpasswords
  • 9,850
  • 2
  • 24
  • 52
  • I think you misunderstood my question. The question boils down to "Is there any difference between using RSA vs AES for passing the AES session key?" The key(s) would be secret on both devices regardless of whether RSA or AES is used. The session key would always be AES. I will look into what you mentioned in the last paragraph. – User1234321 Jan 21 '15 at 17:41
1

I will answer you question at the end. Please go through this first to get a context of my answer:

RSA is an asymmetric encryption algorithm. So, it generates a private/public key pair. When you say you are sharing A's keys to B, you must only share A's public key. Similarly, B's public key must be shared with A. This can be done by putting the public key in a certificate and sending the certificate. Or, public key can also be sent in a text file as it is. But A's private key will remain with A and B's private key will remain with B.

Now, what A needs to do is generate a random number say X, encrypt X with B's public key and send it over to B. B will decrypt it with its private key.

B will generate a random number Y, encrypt Y with public key of A and send it over to A. A will decrypt it with its private key.

At this point, both A and B will have X ad Y. Now, they can generate an AES session key out of X and Y(say as simple as by multiplying them and forming XY). This session key can be used to encrypt/decrypt application data.

Usually, this is how an AES session key is generated. RSA provides a way to exchange the components of a key and the components are put together to form the real key. Real key is used in AES for encryption/decryption.

Now coming to your question, you're asking "is it acceptable for both A and B to be pre-configured with a secret AES-256 key (instead of secret RSA-2048 keys) that is used to generate an AES-256 session key?"

The answer is, the whole point of using RSA is to act as a key exchange mechanism to derive an AES key. If both A and B are pre-configured with the same AES key already, there is no point in using RSA. You can directly encrypt/decrypt using the AES key. Anyway, AES is faster than RSA(http://forums.windowsecurity.com/viewtopic.php?p=81177 and symmetric encryption session keys in SSL/TLS).

0

The reason we have hybrid crypto-systems (TLS, PGP, IPSec, etc), is that asymmetric encryption is more cpu intensive than symmetric encryption.

You should use symmetric encryption to perform the bulk of your encryption - that is, encrypting the target data.

Use asymmetric encryption to encrypt the key exchange.