2

I'm currently writing an examen about 'Lessons Learned in the IT-Security'. I already found some thing, which shouldn't be done. But right now I'm in trouble finding the reasons why not to do so. Maybe you could explain me why or even better know about any citable source, which describes the following:

  • Why don't I use the same key for encryption in both ways?
  • Why don't I use the same key for encryption and authentication?

It would also be helpful, if anyone could tell me about known attacks, that exploit the mistakes above.

By the way I used this site: Lessons learned and misconceptions regarding encryption and cryptology as the starting point for my research.

Community
  • 1
Mats
  • 21
  • 1

3 Answers3

1

In general, you should never use the same key for two different algorithms, because it makes related key attacks possible. That's why best practice is to use a KDF to generate separate keys for encryption and authentication operations. You can, of course, use an authenticated encryption mode, which will avoid the need to use two separate keys.

As to using different keys for different directions in a channel, while reducing your exposure to cryptographic vulnerabilities is certainly a concern, there is a much more fundamental reason: reflection attacks. Unless there is a clearly defined difference between what is a valid message for each of the two parties in a communication, an attacker can simply repeat what you say back to you to cause unexpected behavior. If the same key is used in both directions, what you transmit will pass your own authentication checks for incoming data, and then code that's expecting a guarantee of a secure channel will suddenly be dealing with unexpected invalid input. This can cause crashes or other unexpected behavior.

You can mitigate this at the protocol level by sending a message saying which side of the communication you are, but that adds parsing complexity just to mitigate a vulnerability, and that's really the job of the security layer. Using different keys for both ends of the connection avoids the problem entirely and is usually simpler to implement as well.

Reid Rankin
  • 1,062
  • 5
  • 10
0

Why don't I use the same key for encryption in both ways?

Remember, Each additional use of a "key" or "secret" increases its attack vector potential. so for reasons of segregation and mitigation its better to use DIFFERENT keys for each interaction.

Why don't I use the same key for encryption and authentication?

If you use 2 keys:

  • 1 for saying "Hey, this is me. You can trust it"
  • 1 for making sure no one can read the thing.

then this means an attack has to bypass 2 separate crypto systems.

You can also utilize this system to "sign" your digest and therefore have multiple people / systems be able to identify that it comes from you, without them being able to modify or see your "secret message".

This is especially true if one uses rings of trust like the PGP-rings system.

JohnDvorak
  • 107
  • 5
LvB
  • 8,217
  • 1
  • 26
  • 43
0

The reason is that there can exist weaknesses in the cryptosystems allowing they to be circumvented, since the keys have a mathimatical relationship with each other.

For example, lets say I eavesdrop a encrypted message from A to B. Then I take the encrypted message, and "blind" this message with a blinding factor. Then I send this encrypted+blinded message to B, and ask him to sign it. Lets say he have a reason to sign things from me too.

Since signing is effectively decryption, the message that is returned, is the blinded, unencrypted message, that you return to me. I unblind the message with the secret blinding factor, and then I have the message, unencrypted. and you know nothing that I have access to that message.

This can also apply to schemes where a symmetric key is used, since I could just send you the encrypted symmetric key, blinded. And blind signing requires that a hashing scheme is NOT used during signing, so a software must be able to detect a blind message to be signed, and sign it directly.

Thats why you should not use same key for encryption and signing.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • This is only practical against textbook RSA. Signing is *not* typically just the decryption step; it just happens to be for RSA. Furthermore, signing is almost always done over a fixed-length hash of a message for performance reasons, so sending a message to be signed does not mean you get to specify the data that will actually be signed. – Reid Rankin Sep 21 '15 at 01:07