[Cryptography] Looking for feedback on new Java crypto library

[James Yonan]

On 11/11/2013 16:14, Jerry Leichter wrote:
> 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.

Currently the library uses AES-256-CBC, but can be easily extended to 
use other ciphers such Twofish or Serpent.

> 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.

Yes, the library is using CBC mode and "Explicit IV" in the same way as 
TLS 1.1, i.e.:

1. The IV is random and unpredictable, i.e. it is generated from a 
strong random source (such as /dev/urandom) for each message (in this 
case a message is a single encrypted stream).

2. The IV is public and prefixed to the ciphertext.

3. The IV and all ciphertext are authenticated with a MAC, in this case 
HMAC-SHA256.

> 2.  More specifically, the user provides an IV, but there's no
> indication of what the constraints on the IV are.

The constraints are those of CBC mode: randomness and unpredictability.

> 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*.

The IV needs to be random and unpredictable.

It should also be unique since an IV collision could lead to a key 
stream attack.

But since the IV size equals the cipher block size, i.e. at least 128 
bits, and since the number of messages per key is likely to be far below 
the birthday paradox threshold, IV collisions are unlikely.

I'm not sure that using a different mode such as CFB, OFB, or CTR with 
an incrementing nonce would be viable for this kind of application, 
because of the requirement to guarantee nonce uniqueness, which usually 
imposes a state maintenance burden.

> 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?

Providing the Base64 variants of the function allow metadata such as the 
algorithm name and key derivation strength to be encoded in a header, so 
that the decryption function only needs the key/passphrase and Base64 
data.  Other libraries use this approach, such as OpenSSL when it 
encodes encrypted RSA private keys as Base64 but adds metadata such as 
the crypto algorithm used.

> 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*.

But doesn't that lead to a salt monoculture?

I would tend to prefer something like xkcd's geohashing concept, i.e. 
hashing a current timestamp together with a publicly known quantity that 
would have been unpredictable before the timestamp, to generate constant 
salts that are demonstrably uncooked.

James