0

I have to protects confidentiality, integrity and authenticity of a file of records with a password. The number of records can potentially be more then 32^2 and each record can be accessed independently.

One way to implement it is

  1. Generate a 256-bit random salt and store it in the file header.
  2. Generate a derived key from the password and the salt using PBKDF2 with HMAC-SHA256 from PKCS #5.
  3. For each record generate a 96-bit random initialization vector.
  4. Encrypt each record's content using AES-256 in GCM mode using the derived key, the initialization vector, and (as additional authenticated data) the position of the record in a file.
  5. As a result, each record will store an initialization vector, an encrypted content, and a MAC.

But the NIST Special Publication SP800-38D defining GCM and GMAC requires the number of records to be less than 32^2 for the initialization vectors to be unique.

So I devised another solution: create a key for each record with HMAC-SHA256 using the derived key as a key and the position of the record in a file as a message to be authenticated (salt).

So the question is do I need to provide the position of the record in a file to the authenticated encryption algorithm as an additional authenticated data since I've already taken care of it when generating the key?

Additionally do I really need to use initialization vectors at all since all the records will be encrypted and authenticated using supposedly different keys generated by HMAC-SHA256(PBKDF2(HMAC-SHA256, password, salt, iterationCount, 256), blockAddress) ?

I don't know what the size of the file will be, so I presume it can be very large.

Taras Puchko
  • 3
  • 2

1 Answers1

0

If I understood you correctly (bit of a disclaimer, sorry) then you should be fine without adding the position within the record in the file.

No you don't need a random IV if you only use a (session) key once. Using an IV consisting of zero's would be enough (deterministic construction, using one device and a counter set to zero, if we keep with the NIST nomenclature).

Maarten Bodewes
  • 80,169
  • 13
  • 121
  • 225
  • As usual, some security advice: make sure you can distinquish between bad passwords, altered cipher text and *reordered* records, or you may find yourself in a bit of a spot if anything happens with either one. Also, it pays to use the same security level for all primitives, e.g. use SHA-512 (security ~ 256 bits) with AES 256 (security also ~ 256 bits). – Maarten Bodewes Dec 17 '11 at 10:03
  • 1. For me it makes sense to only distinguish between a wrong password and a corrupted file (altered cipher text, reordered records, altered salt), but if an adversary changes the salt I cannot distinguish it from a wrong password. – Taras Puchko Dec 17 '11 at 22:48
  • 2. I don't understand how I can use a key produced by SHA-512 with AES-256, since the latter requires 256-bit keys. One option is truncating, but it effectively weakens the key. And while NIST-SP-800-107 says truncating is ok, googling for "SHA truncating" gives mixed results. Another option is similar but with using the other 256 bits as an IV. – Taras Puchko Dec 17 '11 at 22:57
  • Answer to 2) There is nothing wrong with truncating a secure hash algorithm. It is used constantly in all kinds of key derivation techniques, and SHA-384 is even SHA-512 with bits removed, and different internal constants. – Maarten Bodewes Dec 18 '11 at 02:03
  • 1) uh, no, you can't distinquish between a wrong password and the salt, that's the point of the salt. Sorry if that was not clear. As long as you can find out what's wrong as good as possible. Design for failure, is what I was trying to say. Decide what to do if something fails beforehand. For such a large number of records, that would make sense. – Maarten Bodewes Dec 18 '11 at 02:06
  • I still don't understand why would I want to generate a key with SHA-512 and then truncate it to 256 bit instead of just using SHA-256. Both options give me the same resistance strength. I can only think of using some extra bit from SHA-512 for other purposes like password verification. But as I said before I felt a little uneasy about simple truncating when I'd read http://eprint.iacr.org/2010/548.pdf and http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf – Taras Puchko Dec 18 '11 at 11:20
  • Hmm, OK, read through both of the documents and although I cannot directly see if this is fully applicable (the first link claims it is at least), you might want to opt for SHA-256. My general rule of thumb is to use same strenght primitives and parameters thoughout, and SHA-512 and AES-256 are more or less 'on the same level. As this is less important for key derivation, and since half of the output is discarded anyway, I must admit it makes sense to use SHA-256 (or SHA-512/256 if the attacks in the first paper are not applicable to that algorithm). – Maarten Bodewes Dec 18 '11 at 21:46