CODEWITHSUNDEEP
c#securityencryptionhashhmac
Nicholas Hill
Nicholas Hill

Reputation: 316

Allowing any data to be decrypted using AES 256 for the purposes of HMAC

Consider a file that will be encrypted by a C# library that I will write, consisting of a 64 byte HMAC followed immediately by the encrypted data encrypted with AES 256. The 16-byte IV, 32-byte Key and 64-byte HMACSHA512 initialisation key will come from Rfc2898DeriveBytes via a single string password, entered by the user (4096 iterations, and a single salt from random.org).

  1. Are there any negative security implications of this design?

  2. Have I gone overboard? (it, with the 64-byte initialisation key or 4096 iterations)

  3. I want to be able to decrypt any data whatsoever in order to use the embedded HMAC to verify that the password was correct (that is, that the 'decrypted file is the original file'). Specifically, I'm looking to avoid errors such as "Padding is invalid and cannot be removed.". Any ideas on how to go about this?

Upvotes: 2

Views: 801

Answers (1)

Maarten Bodewes
Maarten Bodewes

Reputation: 94018

  1. Yes, the IV should be prepended to the cipher text and should be random. If you use Rfc2898DeriveBytes you will get the same IV each time, so encrypting different plain texts will result in identical cipher texts, leaking information.

  2. Yes, the 64 byte initialization key is a bit much. 16 to 32 bytes should be more than enough. That said, it does not make much difference regarding performance, so... 4Ki iterations is fine (why not just 4000, the algorithm does not change).

  3. Yes, place the HMAC over the encrypted data, and make sure you verify the HMAC before you decrypt (the last block). Normally the HMAC is placed after the cipher text (as a streaming implementation will only know the HMAC once it encrypted all the cipher text).

Alternatively you could use AES in GCM mode so you don't need the HMAC anymore. GCM (or EAX) mode is not always available though.

Upvotes: 1

Related Questions