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

[ecki at zusammenkunft.net]

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

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

Gruss
Bernd