Hi Leo, Actually System.currentTimeMillis is not good enough to make cryptographically strong implementation of random number generator. The most easy way is to use OS functions for seed generation. Anyway, usage of the data generated by SecureRandom.generateSeed(int numBytes) should be good enough.
Thanks, Yuri On 6/7/07, Leo Li <[EMAIL PROTECTED]> wrote:
Thank you, Yuri. I have reported it as https://issues.apache.org/jira/browse/HARMONY-4089. And I have another problem: what data should we seed the SecureRandom? Is the System.currentTimeMillis good enough? Any better candidate? Thanks. On 6/7/07, Yuri Dolgov <[EMAIL PROTECTED]> wrote: > > Hi Leo, > I'll try to answer your questions > > So my question is: > 1. Is the SecureRandom really been seeded? > 3. Is the implementation of SecureRandomSpi that seeds itself? > Yes, it is been seeded. You had a right asumption, currently > implementation > of SEcureRandomSpi seeds itself: > > protected void engineNextBytes(byte[] bytes) { > ... > if (state == UNDEFINED) { > > // no seed supplied by user, hence it is generated thus > randomizing internal state > updateSeed(RandomBitsSupplier.getRandomBits(DIGEST_LENGTH)); > nextBIndex = HASHBYTES_TO_USE; > ... > > > 2. How is it seeded as spec says? > Spec doesn't permit to organize seeding this way, but on the other hand, > spec doesn't say that SecureRandomSpi must seed itself at first call of > engineNextBytes(byte[] bytes) method, thus we could potentionaly have a > problem when operating with thirdparty provider implementing SecureRandom > . > I think that we should file a JIRA to call setSeed method for first call > of > nextBytes(byte[] bytes) in SecureRandom implementation. > > Thanks, > Yuri > > > > > > On 6/7/07, Leo Li <[EMAIL PROTECTED]> wrote: > > > > Hi, > > I found the spec says, to a non-argument constructor for > > SecurityRandom, the SecurityRandom(): > > > > *Note that this instance of SecureRandom has not been seeded. A call > > to > > the setSeed method will seed the SecureRandom object. If a call is not > > made > > to setSeed, the first call to the nextBytes method will force the > > SecureRandom object to seed itself.* > > * * > > * * > > But it seems that SecureRandom does not call setSeed before the first > call > > to nextBytes when it is not seeded.* * > > Here is a testcase: > > > > public class TestSecureRandom { > > > > public static void main(String[] args) { > > SecureRandom secureRandom = new MockSecureRandom(); > > secureRandom.nextBytes(new byte[32]); > > System.out.println("Succeed!"); > > } > > } > > > > > > class MockSecureRandom extends SecureRandom { > > @Override > > public synchronized void setSeed(byte[] seed) { > > System.out.println("setSeed called!"); > > super.setSeed(seed); > > } > > } > > Which shows that although the secureRandom is not seeded, and when we > > get > > the nextBytes, it is not seeded by setSeed. > > > > So my question is: > > 1. Is the SecureRandom really been seeded? > > 2. How is it seeded as spec says? > > 3. Is the implementation of SecureRandomSpi that seeds itself? > > > > Thanks. > > Good luck! > > > > -- > > Leo Li > > China Software Development Lab, IBM > > > -- Leo Li China Software Development Lab, IBM
