2

I want to preface this by saying i will not be using any of this code/information in a live project, this is only for learning/fun (so I welcome some speculation)

I was looking at how the PHP crypt() function works, and i had an idea. crypt() prepends a few characters at the start of the hash it creates that convey information about how the hash was created (algorithm used, number of rounds, etc...). This gives a beneficial side effect of being able to check if the hash was created up to a certain standard (check if it was hashed with a minimum amount of rounds) and rehash it if it was not.

I had the idea to use this idea for symmetric key encryption (AES128) as well. It would allow me to very simply enforce a "minimum security level" that i can increase at any time and run on my entire database, and it will re-encrypt any data that does not meet the standards. Changing cipher, salt-size, hashing algos, rounds for PBKDF2, etc. will be much easier to do and much faster to implement, the only thing that would be kept secret is the key.

The exact data i wanted to include is:

  • Salt Size
  • MAC Size
  • Number of rounds used for PBKDF2
  • The hashing algorithm used to create the MAC (ex. SHA512)
  • The hashing algorithm used for PBKDF2 (ex. SHA512)
  • The cipher algorithm used in the encryption (ex. AES128)
  • The mcrypt mode used in the encryption (ex. CBC)

Essentially the hash would look like 128|64|1000|SHA512|SHA512|rijndael-128|cbc|CipherText

So please, tell me why I'm stupid!

Klathmon
  • 21
  • 1
  • Appending/prepending metadata to facilitate authentication and/or decryption (such as you've described) is commonplace. The only issue I see is that if you're using CBC mode, then you need to include the IV also, and be sure that this is included in the MAC as well. – hunter Jun 08 '13 at 14:43
  • The IV is derived from the key using key-stretching, so there is reason to store it. (and i'd assume no reason to include it in the mac either, as the key is already included) – Klathmon Jun 08 '13 at 14:54

2 Answers2

1

This is fine. Be sure to verify all the values and include them when computing the MAC.

user7160
  • 11
  • 1
1

  1. $\:$ Include the kdf algorithm used, since you may later wish to upgrade to bcrypt or scrypt.

  2. $\:$ "Number of rounds used" should be able to hold an ordered pair, so that if
    $\;$ you upgrade to scrypt then the second coordinate can be the memory bound.

  3. $\:$ "The hashing algorithm used to create" should probably be "The algorithm
    $\;$ used to create", since your "specification" (so to speak) should not
    $\;$ rule out the use of MAC algorithms that are not based on hashing.

  4. $\:$ It seems like it would be more convenient to put the MAC size right after the MAC algorithm.

  5. $\:$ "The hashing algorithm used for PBKDF2" should be removed,
    $\;$ since that would be part of "the kdf algorithm used".

  6. $\:$ From your comment, "the IV is derived from the key using key-stretching", nonononono.
    $\;$ IVs should be generated independently from the key, distinct from other
    $\;$ IVs generated for the same key, and sometimes satisfy other requirements.
    $\;$ (If that would be difficult, then you can use the nonce-based version of SIV mode.)

  • Regarding your final point, the key is salted before it is stretched, so the cipher key, mac key, and iv are all unique to that use. Is this still an issue? I can generate a random IV per use, however i found some resources that show that not including the IV in the output can be more secure. – Klathmon Jun 09 '13 at 17:25
  • If "that use" is that ciphertext, then IVs don't matter. $:$ (So you can just use all-zero IVs.) $\hspace{.6 in}$ –  Jun 09 '13 at 23:21
  • @Klathmon - can you cite these resources that claim that keeping the IV secret can be more secure? – hunter Jun 10 '13 at 19:40
  • Perhaps a better question would have been: Are there existing standards for this metadata? – Steve Clay Jun 10 '13 at 19:55
  • @steve_clay i would have asked that, however i did not know if it was even commonplace/acceptable to do it. – Klathmon Jun 10 '13 at 20:58