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

Bennett Haselton <[email protected]> Tue, 17 Sep 2019 09:39:20 -0700
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Message-ID <CA+ThrRSOmiE-uk-9j0Z_fie_xEX=5C4JiL0XXX1tRpZa3xDOEg@mail.gmail.com>
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.)

Thanks!

Bennett