> On Jan 6, 2016, at 5:53 PM, e...@zusammenkunft.net wrote: > > Hello, > > Wang Weijun <weijun.w...@oracle.com>: >>> On Jan 6, 2016, at 3:31 PM, e...@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
