For the purpose of the tool I am currently writing, I need to perform some AES encryption/decryption on some input. It's like a pipeline: you feed it data, it runs the algorithm and pass it out to the next modifier.
I'm used to
openssl enc -aes-256-cbc to encrypt and decrypt everything. My understanding of this is, it first derive the key you enter using some kind of
pbkdf-sha1 with some 8 bytes generated
salt, then derive the
iv from the
derived key + salt.
It obviously only works with OpenSSL since I wasn't able to find any standard regarding how to communicate – or write to file – the
salt parameters. I was expecting some kind of RFC (like for elliptic curve parameters) but no luck.
My idea is to have a 64 bytes header:
salt + iv first in the file, then it is followed by the encrypted data. I will use the
pbkdf2-sha256 to derive the key.
The headers don't have a fixed length, adjusting the right parameters when you start the program will get the
iv set to the right values.
I don't want to make no mistake. I was amazed how it could be the weakest link and how easy it is to recover a password from a bad key derivation and/or IV generation.
I am pretty sure every aes implementation rolls their own protocol on parameters. And I think it is sad.
I will of course be using
crypto/aes from Go and their
pbkdf2, always taking the random source from
crypto/rand and not
To sum up:
Is there any standard on having AES parameters like
Should I generate the
ivor derive it from the
salt || dk?
I forgot to mention that I was going to use
PKCS 5#2.0 which specify how to derive the key, but this question was more towards best practices on the
salt storing for broader compatibility.