2

The normal method of providing an encrypted channel appears to be negotiating a session key (using Diffie Hellman or similar), then using this key for a long lived session. Even IPSec that is message based negotiates a key first that is later used for many individual messages.

What are the reasons against instead having each individual message be encrypted using a symmetric cipher, with its one off encryption key being derived from the message, using Diffie Hellman, encrypted using RSA etc? Is it simply due to higher computational complexity in deriving this key vs decrypting the symmetric cipher using a known key, or are there other reasons for this?

1

The main reason is that it isn't necessary: there's no real reason why you would create a new key for each message, because using one key for all messages is perfectly secure with modern encryption algorithms. While you can't use one key for too much data, with AES "too much" is 256 exabytes (that's around 256 million terabytes), which is far more data than you actually end up using a session key for. Using one key for a whole session doesn't make it relevantly easier for an attacker to recover the key, for realistic sessions.

I'm not sure what you mean by "deriving a key using Diffie-Hellman" or "encrypted using RSA," but I assume you mean renegotiating the key every message (i.e. both parties communicate to negotiate a new key; "derive" is an odd word to use, because it generally refers to something computed on one end without having to talk to the other end). Renegotiating a key for every message isn't done because it's a waste of time. Key negotiation takes a few messages back and forth, and is somewhat slow (it involves at least one asymmetric algorithm, and a common trait of asymmetric algorithms is that they're slow).

For deriving keys, while it's possible, there isn't really a need for it, and it again adds complexity. You can't derive your key for a message from the plaintext of that message for obvious reasons (the other end doesn't know that plaintext until it decrypts it with the key). You can derive a unique key for every message from a master key (this is common in payment processing systems), but it's not needed in typical communications, and it isn't done to make it harder to recover a transaction key (it's done so that recovering a transaction key doesn't let you decrypt all transactions).

  • I understand that renegotiating a key using traditional Diffie Hellman would be costly, but I was suggesting instead either encrypting a message key with a known public key or rely on known DH parameters for the receiving side and providing new DH parameters on the sending side, either method avoiding extra roundtrips. It sounds from your reply that it boils down to this being slow, i.e. computationally expensive, that's the core of it? – Amanda West Jan 7 '15 at 23:35
  • Pretty much. It's precisely the reason for TLS abbreviated handshakes, for example. – cpast Jan 7 '15 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.