5

I am looking to verify the integrity of a very small payload, approx 64 bytes, which will be stored in a QR code. I need to verify that the payload has not been generated or altered by an attacker. Adding a secure hash at the end of the payload will use up alot of my payload space. I was hoping to encrypt the entire payload with an asymmetric private key, and then attempt decryption with the public key. If decryption succeeds then the payload is assumed to be valid, and the data can be read.

Questions:

  1. Given such a small payload, would an asymmetric key be too short, and therefore too easily hacked through a brute force attack?

  2. Would a secure implementation of appended a hash or random padding, leave me with hardly any useable payload left for actual data?

  3. If 64 bytes is too small, what is a realistic smallest payload size that I could use? (I want to keep the physical size of the QR code as small as possible)

| improve this question | | | | |
  • 1
    Problem 1: the size of an encryption key is not related to the size of the data to be encrypted. It's fine for your payload to be small and for a key to be much longer, so your question 1 probably needs some reformulation. Problem 2: a good answer as to where/how/what to store along with your payload depends on who the attackers are, what prior secrets you share with the payload providers, etc. Give us some details! – Steve Dodier-Lazaro May 11 '15 at 15:42
3

Asymmetric keys are only really valuable if one of them needs to be made public (though "public" can mean different things in different contexts).

If you both generate and verify codes in private, than you can just use a private secret as part of an HMAC with a reasonable hashing algorithm.

If space is a premium, you can even get away with using the first X bytes of the resultant HMAC output, with the understanding that each byte you remove decreases your protection slightly.

If the codes need to be verified or generated in public, then first of all recognize that even a properly valid result can be subverted by some other aspect of the software chain, but ideally you can do the public part (generation of validation) using a public key and the private part using the private key.

| improve this answer | | | | |
2

Using symmetric or asymmetric encryption in this case really depends on the use case and not on the security aspects. How is the code generated? can the code requester have a common secret between himself and the code generator? If they do you can use HMAC to verify the sender and the integrity. If not, you can use asymmetric encryption to utilize signing of the message. You cannot use asymmetric encryption the way you described it because it works just the opposite way.

I was hoping to encrypt the entire payload with an asymmetric private key, and then attempt decryption with the public key

Just the opposite... In asymmetric encryption the public key is used to encrypt, private key to decrypt. But in your case encryption is not the need - you need a digital signature to verify the sender and integrity of message. That is done by signing with the private key of the sender, and verifying the message with the public key.

Adding a secure hash at the end of the payload will use up alot of my payload space

You can truncate the hash. For example, use only the first 32 bits of SHA-1 output. This will increase the chance for a collision and make it easier to bruteforce, but you need to consider how critical it is for your use case. ANY WAY - also with asymmetric encryption you will need to send the signature together with the message.

Given such a small payload, would an asymmetric key be too short, and therefore too easily hacked through a brute force attack?

I dont see the relation. The only thing I can think about is replay attacks. Once someone sees your QR code, he can use it as is. To mitigate replay attacks you need to add a random nonce to the code request, and include it in the output. For example HMAC the payload concatenated with the nonce.

| improve this answer | | | | |
  • I have a unique serial number in each payload, which I believe behaves as a unique nonce. I was hoping to use the message as the signature, to minimize the number of bits used up with an additional signature at the end of the message. – user3091170 May 11 '15 at 13:28
  • I was hoping to use asymmetric keys, but it now looks like sharing a secret key securely is the only way to sign the data that would be secure enough. – user3091170 May 11 '15 at 14:23
1

I'll answer in order:

  1. almost certainly yes, asymmetric signatures in general take more space than the symmetric counterparts - RSA requires a certain amount of padding and a minimum key size to be secure;
  2. if you use a HMAC the minimum requirements for a secure HMAC - a hash based Message Authentication Code or keyed hash - would be about 64 bits / 8 bytes - anything less will put you into a danger zone - it depends on the rest of the system if this risk can be mitigated (the larger the size of the authentication tag the better);
  3. that leaves you with 64 - 8 = 56 bytes for a payload with a secure MAC - you can grow your QR code if you require more.

For signatures the best bet is ISO/IEC 9796-2 which defines RSA signatures giving message recovery - but beware that there are known weaknesses. 64 * 8 = 512 bits of RSA is however much too short.

For a MAC it is common to use the leftmost bytes - i.e. the bytes with the least significant index in most programming environments - as authentication tag value. In many API's you can specify the size of authentication tag.

Note that you need a keyed hash otherwise an attacker can simply replace the payload and hash value together. Because of how the key is mixed in a smaller output and less secure hash method may be used.

| improve this answer | | | | |

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.