harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuri Dolgov" <dolgov.g.y...@gmail.com>
Subject Re: [classlib][security]SecureRandom will seed itself before the first call to nextBytes if it has not been seeded?
Date Thu, 07 Jun 2007 10:11:36 GMT
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 <liyilei1979@gmail.com> 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 <dolgov.g.yuri@gmail.com> 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 <liyilei1979@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message