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?
$\begingroup$
$\endgroup$
11
-
$\begingroup$ It should not be a problem. $\endgroup$– Guut BoyDec 2, 2014 at 16:28
-
$\begingroup$ More info: I am using an HMAC in both directions also. And they are sharing an IV of course, and are using AES CBC $\endgroup$– Ken - Enough about MonicaDec 2, 2014 at 16:57
-
1$\begingroup$ Doesn't TLS 1.2 use different keys on each end? $\endgroup$– Richie FrameDec 2, 2014 at 20:32
-
1$\begingroup$ 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 crypto.stackexchange.com/questions/5976/… crypto.stackexchange.com/questions/17830/… ... $\endgroup$– dave_thompson_085Dec 13, 2014 at 4:49
-
1$\begingroup$ ... 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). $\endgroup$– dave_thompson_085Dec 13, 2014 at 4:54
|
Show 6 more comments
3 Answers
$\begingroup$
$\endgroup$
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.
-
$\begingroup$ Shouldn't the underlaying connection-oriented protocol (TCP) take care of the direction issue? $\endgroup$ Dec 2, 2014 at 17:02
-
$\begingroup$ @horsehair No, the attacker wouldn't replay the TCP packets, they would replay the message in new TCP packets that go the other way. $\endgroup$– bmm6oDec 2, 2014 at 17:13
-
$\begingroup$ But the new packets would have to be part of the established TCP connection which key negotiation took part over, otherwise TCP would drop it $\endgroup$ Dec 2, 2014 at 17:20
-
1$\begingroup$ If your attacker can't inject messages then that's not something you have to worry about. TCP provides less of a barrier than you seem to think, though. $\endgroup$– bmm6oDec 2, 2014 at 20:00
-
$\begingroup$ Oh, there is an underlying protocol that is being encrypted, so the sender and receiver are addressed in the payload. Good enough? $\endgroup$ Dec 2, 2014 at 21:05
$\begingroup$
$\endgroup$
2
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.
-
$\begingroup$ This is verifiably false. Per-direction symmetric keys prevent replay attacks. $\endgroup$– pg1989Dec 2, 2014 at 18:50
-
$\begingroup$ 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. $\endgroup$– theraDec 2, 2014 at 19:02
$\begingroup$
$\endgroup$
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.
