[Cryptography] Looking for feedback on new Java crypto library

[Jerry Leichter]

On Nov 11, 2013, at 4:09 PM, James Yonan <james at openvpn.net> wrote:
> I'm releasing a new open source Java library that focuses on encryption of files and streams in a way that tries to integrate current crypto best-practices with a foolproof API, while building on the existing Java Cryptography Extension (JCE).
> 
> The primary use case is enabling client-side encryption of files pushed to the cloud with a simple API that automatically incorporates Explicit IV, HMAC-based integrity checking, and strong key-derivation methods to foil hardware-accelerated password cracking.
> 
> I would appreciate any comments or feedback, especially on the security model.
A couple of quick responses:
1.  The security analysis says nothing about the algorithm used.  In particular, it says nothing about how the "IV" is used.  "IV" is a term usually associated with CBC mode.  It appears that you *are* using CBC mode ... you probably shouldn't be.

2.  More specifically, the user provides an IV, but there's no indication of what the constraints on the IV are.  Does it have to be random?  Or simply never re-used in a given cryptographic context (which in the case of these interfaces appears to translate to "with the same key")?  It says "Explicit, never reused, generated from strong PRNG" which doesn't answer any of the questions.  "Explicit" - well, of course.  "Never reused" - even with different keys?  Why? "generated from a strong PRNG".  Why?  And why a *PRNG*.

3.  Why provide whole separate functions to handle Base64, which has nothing to do with crypto?  Can't a caller just wrap the function in appropriate encoders and decoders?

4.  There are multiple constant salts used in the algorithm.  They are documented as having come from /dev/urandom.  But of course there's absolutely no way for anyone to know where they came from.  While I doubt these values would provide any kind of back door, the right way to pick such constants is to avoid any *possibility* that they are "cooked" somehow - e.g., use values from pi *starting at the first position*.

                                                        -- Jerry