Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

> On Jan 6, 2016, at 5:53 PM, ecki at zusammenkunft.net wrote:
> 
> Hello,
> 
> Wang Weijun <weijun.wang at oracle.com>:
>>> On Jan 6, 2016, at 3:31 PM, ecki at zusammenkunft.net wrote:
>>> is the Intention of the default implementation of getFullEntropy to expand a too short array with the DF as well (which is a dangerous thing to do IMHO) or is the conditional conditioning only to condense (aka shorten)?
>> Only shorten. Should check.
> 
>>> In that case you should maybe add an assert and make the if compare against bigger length only? (On the other hand I wonder why not simly discarding the bytes would be fine, too. I dont see an implementation providing excessive bytes anyway.
>> Discard extra bytes? At least the current code is an approved conditioning function.
> 
> I dont know what the reason for an entropy source to return more bytes than requested would be. For a framework it is hard to make the call if the entropy source is good (and a conditioning with possible limited internal state could make it worse). If you want to allow a entropy source to return more bytes because its internal accounting might estimate bad entropy, then calling the conditioning function would be aproperiate, but then the question is if this a good idea to design a API which expects weak entropy (but only implicite control of post-processing).

I used to only have getFullEntropy(), but at every corner of SP 800-90A you can see the word min-entropy which seems to suggest that in the DRBG world an entropy source with weak entropy is quite a common thing and should be considered in API design.

Also in the real world I believe there are cases where it's much more efficient to implement getEntropy() than getFullEntropy(). When getEntropy() is usable it should be preferred.

> 
>>> Why not have a int fillEntropy (byte [] out, boolean partial (, int pos, int len)) methods instead? (This also avoids the need to exlain "full" as well as "get".
>> So if partial is true, the method may return a value smaller than len? Is this really useful? Should the caller call it again and again until enough bytes are available?
> 
> Yes it is only useful if it is needed for stuff like timed background reseeding. It would probably not be used by the normal DRG codebase. Instead of using "partial" an alternative would be "blocking" or "timeout" parameters.

Sounds useful.

This JEP is focused on DRBG and we only want to define an EntropyInput interface with very few methods. We can enhance it in another JEP in JDK 10.

Thanks
Max

> 
> Gruss
> Bernd