Upon registration an user has to specify an access code of five digits. This access code is also used as a password for the encryption and decryption of certain strings.

The user types in "12345" (ACCESS_CODE).

Obviously, we don't want to save this access code on the device.

Now, when the user wants to decrypt he types in the access code, and if the code is correct, the decryption will happen succesfully.

However, preferably, I would like, before the decyrption takes place, check whether the access code is right, without saving it on the device.

How can this be achieved?

One way I was thinking is to encrypt a string "CHECKSTRING" with the access code. Then the check would be:

  1. Decrypt the encrypted "CHECKSTRING" (ENCR_STRING) --> (DECR_STRING) with ACCESS_CODE
  2. Check if DEC_STRING == "CHECKSTRING", then code is correct, otherwise not.

But this seems to me quite unsafe, as someone could simulate an encryption of the "CHECKSTRING" (which is known and visible in the code) for all combinations of 12345 and then cross match which code I used to obtain the ENCR_STRING.

What other alternatives are there?


So you have a secret with low entropy which you want to verify in a secure way.

This is a standard scenario in password-based cryptography (PINs are sort of a password).

What you'll do in both scenarios described below:
The user first enters his access-code (=PIN), which get buffered in the RAM. Now storage media (the device/a drive) will provide the program (processor) with a random looking string that the media stored. (This is the salt) The media supplies parameters as well. (Iteration Counts, (N,R,P)-Values, (t_cost,m_cost)-Values). Now you use a password-hashing function (scrypt/winner of PHC) using the supplied parameters, the salt and the password to derive a tag/key.

You have two ways at approaching your problem:

  1. The straight forward way to do what you want is to get a tag generated by the PHS (password-hashing scheme), store this on first entry on the storage media (along with salt and parameters) and just check if the tag matches with what will be generated at verification-time.
    I wouldn't recommend this way, as it relies on your code to be bug-free.
  2. The better way (in my eyes) would be to derive a key using the PHS, which will be used for verification/decryption. So the security of the data would strongly rely on the password and not on some authorization code. The storage media would only store salt and parameters and you'd see that the access-code is correct as verification succeeds.
  • $\begingroup$ Thanks for that. I have incorporated indeed something similar as method 2; basically storing an encrypted string using the PIN and salt as parameters (I use AES-CBC). Then when decryption succeeds, the PIN passes. $\endgroup$ – JohnAndrews Apr 16 '15 at 21:15
  • $\begingroup$ please tell me you didn't use the PIN directly as key and rather use a PBKDF to derive the key. And please tell me you don't use plain AES-CBC as an attacker can quite simple change things to get a correct decryption in some (/many) cases. $\endgroup$ – SEJPM Apr 17 '15 at 19:09
  • $\begingroup$ Oops, I actually did use the 5 digit pin as an input. So have to convert it with PBKDF? I use the following AES-CBC from forge: digitalbazaar/forge $\endgroup$ – JohnAndrews Apr 18 '15 at 21:59
  • $\begingroup$ I looked into the library and I've got two recommendations: 1. rather use GCM than CBC (so you'll get authentication "for free", you'll only need to handle the tag). 2. Use the PIN as "password" for PBKDF2, store a (random) salt on your storage media (which you'll feed into the salt input of PBKDF2). Choose the iteration count appropriatly (100ms to 1s time consumption), Get 48 bytes in return (32 for AES-Key, 16 for Nonce/IV) $\endgroup$ – SEJPM Apr 19 '15 at 10:57
  • $\begingroup$ WOW Thanks a Lot! I am going to look into it. You seem quite an expert, do you maintain a blog or something that I can follow/read? $\endgroup$ – JohnAndrews Apr 20 '15 at 13:43

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.