Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

The normal method of providing an encrypted channel appears to be negotiating a

ID: 656760 • Letter: T

Question

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?

Explanation / Answer

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).

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote