3

A simple symmetric encryption scheme uses the same key, derived from a password, for both directions of the communication. Is this bad practice, and if so what should be done about it? Is it 'good enough' for many things?

Ken - Enough about Monica
  • 167
  • 7
  • It should not be a problem. – Guut Boy Dec 02 '14 at 16:28
  • More info: I am using an HMAC in both directions also. And they are sharing an IV of course, and are using AES CBC – Ken - Enough about Monica Dec 02 '14 at 16:57
  • "They are sharing an IV" -- what do you mean by that? – poncho Dec 02 '14 at 20:17
  • 1
    Doesn't TLS 1.2 use different keys on each end? – Richie Frame Dec 02 '14 at 20:32
  • @poncho - The client generates a random IV then sends it along with the first encrypted data to the server, who uses the IV and its own copy of the key to initialize the crypto – Ken - Enough about Monica Dec 02 '14 at 21:00
  • @Richie all versions of SSL and TLS (even the awful SSL2) use different encryption keys in each direction, also different HMAC keys except for AEAD suites (in TLS1.2 only) which doen't use HMAC, also IVs for CBC suites before TLS1.1 (which switched to per-message IVs due to attacks like BEAST). That doesn't necessarily mean everything else must though. – dave_thompson_085 Dec 08 '14 at 09:16
  • @dave_thompson_085 Since they use different keys for each direction, isn't it normal that they'd use different HMAC keys (same keys as the encryption keys)? – Ken - Enough about Monica Dec 08 '14 at 16:33
  • @horse SSL/TLS HMAC keys (where used) are not the same as the encryption keys and best practice is they SHOULD NOT BE because past sytems have been attacked or broken by exploiting the same key used for two different algorithms or purposes. Different encryption keys in different directions is necessary in cases where one party can be tricked into decrypting (or sometimes encrypting) for another; SSL/TLS MACs (including seqnum) should block any such oracle, but multiple defenses is also good practice. – dave_thompson_085 Dec 09 '14 at 08:39
  • @dave_thompson_085 Hm that complicates things. Is it ok to use a key stretching algorithm on a password to generate a lot of bits (enough for two keys) then split that for key and hmac key, then send the salt to the client to do the same? But if you do that, you can't check the integrity of the first packet. How could you possibly implement that? – Ken - Enough about Monica Dec 09 '14 at 16:15
  • 1
    Yes just using a long-enough PBKDF is valid and has been common/accepted practice. But if your key sizes exceed the hash size it may require multiple "chunks" which is relatively inefficient for eg PBKDF2. A newer alternative approach is to "distill" the password to one chunk with PBKDF and then "expand" to the needed size(s) with a cheaper method HKDF; see http://crypto.stackexchange.com/questions/5976/how-to-salt-pbkdf2-when-generating-both-an-aes-key-and-a-hmac-key-for-encrypt-t http://crypto.stackexchange.com/questions/17830/deriving-2-keys-using-hkdf ... – dave_thompson_085 Dec 13 '14 at 04:49
  • 1
    ... In either/any case you cannot protect the salt with its own derived key; that's chicken-and-egg. If the salt is wrong either by accident or attack the verifier (receiver etc) will (must!) derive wrong keys causing the MAC to misverify. And even if you don't have or fail to check the MAC, fairly often the cipher has enough redunancy it will fail (but you should never rely on that). – dave_thompson_085 Dec 13 '14 at 04:54

3 Answers3

6

It can be safe, but using the same key in both directions adds several things you need to be careful about:

  • One thing you need to make sure is not a problem is if an attacker takes a message from Alice to Bob, and sends it back to Alice as if it were from Bob. Since Bob to Alice communications use the same key, Alice might decrypt the message, and act as if it came from Bob. There are several possible defenses against this; the easiest (if you include a Message Authentication Code, which you really ought) is to include a direction flag within the authentication data; that way, a wrong way message would be rejected.

  • If you use a nonce-based encryption method (such as Counter Mode or GCM), you need to make sure that both sides don't use the same nonce. This can be as easy as telling Alice to use even nonces, and Bob to use odd ones. However, if you are going to use the same password (and hence the same keys) for multiple sessions, this would indicate that a nonce-based encryption method is probably the Wrong Answer; something like CBC mode + HMAC would make rather more sense.

However, even though it can be done safely, I would suggest you avoid the issue entirely. Instead, when you send your password to the KDF, ask the KDF for twice the key length (say, 256 bits instead of 128), and use the first 128 bits for Alice to Bob messages, and the second half for Bob to Alice messages.

poncho
  • 147,019
  • 11
  • 229
  • 360
0

The question is quite vague, but I'll answer the part of it that's specific.

It's not bad practice to use one symmetric key for both directions of the communication. It's the normal way to use symmetric crypto.

Having a separate symmetric key for each direction would not make it more secure, nor would it add authentication or non-repudiation. Even though the key is derived from a secret, that same secret would need to be known by the receiving end as well.

There's almost no value to be gained by using a separate key in each direction, and in fact, relying on such a scheme to provide any extra security may weaken the overall security.

As for it being "good enough" for "many things", that's just way too vague.

thera
  • 346
  • 2
  • 8
  • This is verifiably false. Per-direction symmetric keys prevent replay attacks. – pg1989 Dec 02 '14 at 18:50
  • Sure, I wasn't thinking in those terms. I agree that it could be one way of indicating the direction of the communication. It seems like overkill, however. As long as the sender & receiver are included in some headers, or a direction flag as indicated above, there's no need to keep two separate keys. – thera Dec 02 '14 at 19:02
0

In general - no, as mentioned above. But if it's used in addition with message sequencing and hashing - yes. Any symmetric cipher suffers from the simple problem, regardless of direction, that the same key is on both sides.

Alexey Vesnin
  • 226
  • 5
  • 7