question about whether Java AES-CBC-256 meets client-specified requirements

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

question about whether Java AES-CBC-256 meets client-specified requirements

Bennett Haselton
I am writing an app for a client and they have specific externally imposed requirements for their encryption, and I am trying to find out if the BouncyCastle implementation of AES-CBC-256 in Java meets these requirements.  I have already Google searched and read the relevant documentation but cannot find anything that directly answers these questions.

The requirements are:
- "128-bit cryptographically random initialization vector"
- "PKCS7 padding"
- "HMAC of encrypted output for integrity verification"

In order:
1) My understanding is that AES uses 128-bit blocks and *has* to start with a 128-bit IV by definition; on the other hand, I don't know if it's guaranteed to be random.
2) "PKCS7 padding" -- cannot find out if BouncyCastle AES-CBC-256 does this
3) "HMAC of encrypted output for integrity verification " -- well, my guess is this is something we have to do manually in our own code.  However, I thought I might get lucky and maybe BouncyCastle implements this in some kind of envelope, so that all we have to do is call the envelope and de-envelope functions and it does the HMAC automatically.
(It's also not clear to me how this is supposed to increase security.  If the idea is to use a HMAC to verify that the encrypted contents have not been altered -- well, if the HMAC is stored alongside the encrypted output, then if the attacker changes the encrypted output, the attacker can change the HMAC too!  The only way this could conceivably gain anything is if the HMAC is stored somewhere else with write permissions different from the encrypted output.  I've asked them for more clarification.)