2

I'm looking at some code that encrypts data in a database using AES. Before doing so, the encryption key is passed through a PBKDF2 function. Reading up on this, it appears this is for when the key space can be guessed, i.e. like someone's password that might use words out of an English dictionary. The encryption key however is purely random, something like:

M39UrEEveje3J#PB=jPG9+&eUSTJG*SAK&s_xHLRu$?Hrbg&7Vn5X^P298$W2z2#r6_!yfGQMQ@ArXjgefq-?9^b?y786ZL5cYcqE6#!c4@rE$scZxR$$e6cYPX$U-m7

In a predictable key space, you want there to be an increased workload for brute-forcing the encryption. Thus, hashing the password through so many rounds of PBKDF2. If the key space is completely uniform and non-predictable though, isn't this just a waste of CPU cycles? Is it good practice to do anyways?

8
  • Out of curiosity, are you planning on doing the encryption in the database itself, or in the application before it gets sent to the database? There are issues you should be aware of if using the database's native support for encryption. Commented Aug 10, 2018 at 19:29
  • in theory it's not needed but in practice it doesn't hurt and guards against randomness flaws. compromise: go fewer rounds than a plain-text password, but don't leave it out.
    – dandavis
    Commented Aug 10, 2018 at 19:43
  • 2
    Can you clarify how that "random" string is being generated? I hope you're using SecureRandom (or /dev/random or equiv) to populate a byte array, and that string is some kind of pretty-print of the byte array. On the other hand, if you're actually generating ASCII strings and using them as keys, then your key space is probably a lot smaller than you realize and you should see AndrolGenhald's answer. Commented Aug 10, 2018 at 19:50
  • @AndrolGenhald doing it in the application and bypassing DB native encryption for reasons specified. Commented Aug 11, 2018 at 16:34
  • @MikeOunsworth this was just an example key I grabbed from an online tool. Very valid point however, unless I can guarantee that all 256 values of a byte are used for each "character", I need to run it through a hash. Commented Aug 11, 2018 at 16:35

1 Answer 1

5

If you have a 128 bit secret random value (or 192 or 256 bits for AES-192 or AES-256), then yes, you can use that as an AES key without running it through a key derivation function.

However, the example you provided does not contain random bytes, it contains (presumably) random characters from a certain character space with at least 56 characters and probably not more than 100. A truly random byte will have one of 256 values with equal probability, whereas a byte in this secret has one of 56-100(ish) values with (hopefully) equal probability.

It is also not 128, 192, or 256 bits. It is actually 128 bytes, which suggests to me that someone may have misunderstood what key size they needed, and generated it incorrectly.

If you try using the secret directly as a key, likely one of three things will happen:

  • The software already does its own key derivation (not necessarily a slow key derivation like PBKDF2, but some sort of key derivation). Since the key (hopefully) contains significantly more than 128 bits of entropy this is fine.
  • The software will warn you that the key isn't the correct length and fail.
  • The software will truncate your key to the correct length and use it. This can be very bad in some cases, but sadly it does happen.
5
  • Are you sure that's not base64 or some other encoding of random bytes? Commented Aug 10, 2018 at 19:35
  • @MikeOunsworth It's definitely not standard base64, and it's not base64 with special characters swapped like base64url. I count at least 11 non alpha-numeric characters. I suppose it could be some weird encoding, but that's still not something you should use directly as a key without decoding it (unless the encryption function actually handles keys with that encoding), and I worry that OP may not understand that. Commented Aug 10, 2018 at 19:41
  • Fair. If the OP is generating random strings and using that, then the PBKDF2 is probably there to convert the string to a suitably whitened byte array and your answer is appropriate. However if that is just an output representation of a number, then it may be fine as-is. Worth a clarifying question. Commented Aug 10, 2018 at 19:46
  • 1
    (minor edit to your answer: I see lowers, uppers, numbers, 11 symbols which gives a character space of at least 73 characters) Commented Aug 10, 2018 at 19:55
  • @MikeOunsworth you're probably right that the keyspace is larger, I ran it through echo '...' | fold -w 1 | sort | uniq -c | sort -n and came up with 56 characters and some appearing 4, 5, or 6 times. Not being a statistician I jumped to conclusions that can't be supported with the small sample size. Commented Aug 10, 2018 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .