0

I get a request from a client who encrypts the message with the wrong AES key. Is there a way for me to know what AES key the client actually used? I understand I may get the decrypted msg which is likely to be wrong, but from what I understand, the key itself cannot be retrieved from the request sent by the client.

In other words, is there a way for me to do something like this -

if (client.aeskey != server.aeskey), print Error.

Please confirm if my understanding is correct.

Omi
  • 101
  • 1
    AES is just a block cipher. That's a very low level primitive. The verification you are asking about belongs at a much higher level in the protocol design. This is concerning because it sounds like you don't know about the layers which would go in between. – kasperd Jun 15 '15 at 16:40

2 Answers2

1

To expand on what kasperd says in a comment. This sort of thing should be handled in the protocol. This would typically be done by adding message authentication code (MAC) in the traditional encrypt-then-mac paradigm or using authenticated encryption.

So then instead of doing if (client.aeskey != server.aeskey), print Error, you would be doing if (MAC(received_ciphertext, correct_key) != received_mac), print Error (in practice your crypto library that has built in authentication checks would do this for you and return an error).

As far as

a way for me to know what AES key the client actually used

goes. There isn't a reliable way without additional assumptions (e.g., we assume that at most 2 bits were flipped).

We traditionally think of these designs as checking for modifications of the ciphertext, but if the incorrect key is used (say due to errors in the storage mechanism or whatever), it would also detect that. The benefit of doing this is you don't have to decrypt before realizing that something is wrong. Instead, you check the MAC and if that fails, you don't decrypt at all.

There are some practical things you should take into consideration. Your best bet would be to use a commercial library. The right one will depend on your setup and needs.

Warning, the absolute wrong way to do this would be to check the padding at the end of the plaintext (assuming you are using mode like CBC that requires padding), and then return an error if the padding is incorrect. This leads to a devastating attack known as a padding oracle attack.

Community
  • 1
mikeazo
  • 38,563
  • 8
  • 112
  • 180
0

It is suspicious that the client have send to the server something with a different key than the symmetric one they had agree before, isn't it?

A way how one side could known that the other has used a different key is when the decrypted message doesn't have sense (like doesn't pass a validation system you prepare).

Your server can detect if the key it has, works, but it is cryptanalysis to request which unknown key was used.

srgblnch
  • 737
  • 5
  • 13