I have a small block of data (16 bytes) that I am required to encrypt, store (in an unsecure, visible location). Later I have to retrieve and decrypt it. I must use AES-CBC and a user-entered password.
After decrypting the data, I need to know if the correct password was used (so I can reject the data if not).
My initial plan:
- Encapsulate the 16-byte payload in a plaintext frame something like this:
Frame: 8-byte random salt 16-byte data block 8-byte checksum of salt+payload
Generate a random 128-bit IV.
Generate a 128 or 256 bit key from the user-entered password.
Encrypt the plaintext frame using IV+key.
Concatenate the IV and ciphertext frame and store them. [Using 48 bytes of storage.]
Storage size isn't critical: a hundred bytes (or two) is OK, but thousands is probably too much.
Do I really need a random IV if I salt the data? Prepending 128-bits of random salt to the data is the same as using a 128-bit random IV, right?
What should I use for a PBKDF? The application is running on a smallish, slowish embedded system and has rather limited crypto routines available (aes, arc4, des3, sha1, sha256, md2, md5). So, I'll have to roll my own PBKDF. A PBKDF algorithm that runs in one second on an attacker's machine will probably take thousands of seconds on this device -- so let's not get carried away: I need to do the encryption and decrypting in no more than a second or so.
Most discussions of using a PBKDF emphasize the importance of including a salt value. That means I also have to store the PBKDF salt along with the IV and the ciphertext, right?
I have access to the stored data produced by a previous version of this product (which I'm told uses AES-CBC to do the same thing), but I have no access to source code or the people responsible. The stored data is exactly 16-bytes long. AES-CBC always uses 16-byte blocks, so that must be a single block of ciphertext. That means
a) They aren't using any salt in the PBKDF algorithm?
b) They must be using an IV produced by the PBKDF (or a constant IV)?