I have two parties that want to communicate with each other based on a shared password. The protocol is using PBKDF2 (with HMAC-SHA256) to create a shared key on both sides (due to restrictions on the channel, ECDH is not possible). In order to run PBKDF2, they need to exchange a short message, the salt. The salt should be authenticated to prevent against MITM-Attacks.

This should be done by showing a 6-digit alphanumeric value on the display of each party (based on the Numeric Comparison approach of Bluetooth or the Compare-and-Confirm approach). The alphanumeric value consists of all letters of the alphabet, except I,O,Q and U, and all numbers from 0 to 9. Thus, there are in total 32 characters and a 1-digit alphanumeric value can describe 5 bits. The 6-digit value can describe 30 bits. Each party has to compare and confirm the correct value.

The question is how to compute the 6-digit alphanumeric value based on the salt that is 32 bytes long. Is the best way to use SHA-256 and truncate the output to 30 bits? Or might it be a better idea to use a slow cryptographic hash algorithm (maybe PBKDF2 again but values can actually be precomputed so there shouldn't be any advantage) in order to increase the computational time for a MITM-Adversary? This could also be enforced by setting a time limit for the authentication.

  • $\begingroup$ If you have shared secret keys then there's no need for manual verification. You only need this sort of approach if you try to authenticate an (EC)DH key exchange. $\endgroup$ – SEJPM Sep 22 '16 at 16:05
  • $\begingroup$ But what about replay attacks? If the salt is not authenticated then an adversary could exchange the salt with a salt that has already been used. Of course the two parties will soon notice that they do not have the same salt but maybe only after the party with the replayed salt has already sent a message (that might not be secure anymore). $\endgroup$ – budderick Sep 22 '16 at 16:17
  • $\begingroup$ Can you use TLS-PSK? It will take care of replay attacks for you. $\endgroup$ – SEJPM Sep 22 '16 at 16:19
  • $\begingroup$ No, TLS-PSK is too much overhead for me since the bandwidth of my communication channel is extremely limited. That's way my handshake is only one message (the salt) and every message is encrypted with AES-GCM-128 and appended to a 64-bits counter (that is used to create the IV for AES-GCM). Thus, every message only has a 196-bits overhead. $\endgroup$ – budderick Sep 22 '16 at 16:38
  • $\begingroup$ But why does the salt not need to be authenticated in general? An adversary could take a salt of his choice and precompute a table with all possible passwords. As soon as he gets a reply encrypted with his injected salt, he can try to decrypt the message based on his precomputed table. Thus, the advantage of the salt is gone and the security is solely based on the entropy of the password. $\endgroup$ – budderick Sep 22 '16 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.