k3d3
commented
8 years ago but I think the practice of using a single value (especially one shorter than the length of your output) and passing that through a hash function in order to use subsets of that output as the key and IV is questionable.
Why would that be questionable? The randomly generated value has 128 bits of entropy, and the only way to get any specific (key, IV, ident) tuple is to either brute-force the input (128 bits) or to brute-force the output (512 bits). Also, when splitting a value in half, the total entropy doesn't necessarily split in half (in this case, the 512 bits have 128 bits of entropy, and each piece has 128 bits of entropy on its own (depending on the strength of the hash function, of course), or 128 bits of entropy altogether). Hopefully that gives a better understanding as to why we generate the key and IV the way we do.
You may want to consider using a key derivation function (like PBKDF2) instead of a hash function.
Something like PBKDF2 is only really useful when the input could be considered weak (such as a password) and you want to slow down the speed of dictionary or brute-force attacks. We're using a 128-bit randomly generated value, however, which is very strong.
ultramancool
The AES key and IV generation process sounds a bit dubious. I'm no crypto expert, but I think the practice of using a single value (especially one shorter than the length of your output) and passing that through a hash function in order to use subsets of that output as the key and IV is questionable.
You may want to consider using a key derivation function (like PBKDF2) instead of a hash function.