On 01/04/2016 08:17 PM, Wang Weijun wrote:
On Jan 5, 2016, at 6:59 AM, Sean Mullan <sean.mul...@oracle.com>
wrote:
Here are some more comments on the API:
* EntropyInput:
29 * An interface of a source of entropy input.
"interface" is implied, so you can just say "A source of entropy
input." Also, I think this interface should be called
"EntropySource". To me, "Input" means the byte array that is
already populated, whereas "Source" produces those bytes. A
sentence or two with more details in the description would also be
helpful.
Well, as defined in Section 4 of SP 800-90Ar1, "Entropy Source" means
real random source based on a physical device. What we need here is
the "Randomness Source" or "Source of entropy input" (section 2 of
800-90B).
Ok, but in what cases would you really want someone to use a source that
is not based on a physical device? In the default implementation, isn't
the only case if the securerandom.source property is not set or is not
correct, and then the SHA1PRNG non-device algorithm is used? Perhaps we
could have an option which throws an exception and refuses to fall back
on that for the DRBG mechanisms. Also, whether it is an approved DRBG
implementation seems like a separate testing or compliance issue to me.
Shall we call it RandomnessSource?
EntropySource still seems like the best name to me. EntropySource
implementations produce entropy :)
RandomnessSource may lead to more confusion as to what is the difference
between that and SecureRandom.
Do we want to allow the generated entropy input to be longer than
the size requested (see section 7.1 of sp800-90Ar1)? Perhaps, a
method such as:
byte[] getFullEntropy(int length)
might be more suitable, and specify that a byte array longer than
the specified length may be returned.
This should be named getEntropy(), because full means every bit of
the output contains one bit of entropy.
Such a method is OK for most cases, but except for one, CtrDRBG with
no derivation function, where the entropy input must be full.
Therefore a getFullEntropy() is needed anyway so I just use it
everywhere. I also thought that every random source should have a
conditioning module to convert non-full entropy bytes to full ones.
If this is not true, 2 methods are needed:
byte[] getEntropy(int length); void getFullEntropy(byte[] entropy);
Detailed descriptions will be added on when and which is used.
And I don't think we need to provide any conditioning codes.
If you think getFullEntropy is sufficient, then let's just keep the one
method.
--Sean
