I had a little experience in this. I used several rdtsc values, local and JNI variables addresses, java memory info and nanotime value.
Thanks, Yuri On Dec 13, 2007 9:12 PM, Oliver Deakin <[EMAIL PROTECTED]> wrote: > I have a basic native implementation coded up which we can fall back to > in the case of /dev/*random not existing and it is working well on z/OS. > > Are there any suggestions/opinions on how best to select a seed for the > random number generation? > > Regards, > Oliver > > > Yuri Dolgov wrote: > > Hello, > > > > This is actually quite a challenging task. According to my investigation > SUN > > can > > generate up to 160 random bits in GenerateSeed method. All the other > bits > > will be > > generated using PRNG algorithm. It's no so simple to generate so much > random > > > > data within Java context. As for me the better solution is to make > native > > platform > > independent implementation where much more "random" data is available. > > > > Thanks, > > Yuri > > > > On Dec 11, 2007 4:47 PM, Oliver Deakin <[EMAIL PROTECTED]> > wrote: > > > > > >> Leo Li wrote: > >> > >>> On 12/11/07, Oliver Deakin <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> Hi all, > >>>> > >>>> Currently, the SecureRandom.nextBytes() method has it's random byte > >>>> generation delegated to RandomBitsSupplier.getRandomBits() on Unix > >>>> systems. getRandomBits() expects us to be able to use one of > >>>> > >> /dev/random > >> > >>>> or /dev/urandom to read a certain number of bytes, throwing an > >>>> > >> exception > >> > >>>> if they are unavailable. > >>>> > >>>> On z/OS this is an issue because the availability of /dev/*random is > >>>> dependent on the hardware of the machine and we cannot assume they > can > >>>> be used. In cases where the hardware does not exist, > >>>> SecureRandom.nextBytes() fails with an exception [1]. We need a > >>>> > >> fallback > >> > >>>> case for z/OS for the non-availability of these devices so that we do > >>>> not fail every time we, for example, attempt to create a temporary > >>>> > >> file. > >> > >>>> So my question is - what's the best fallback method? I can think of > two > >>>> methods immediately: > >>>> - delegate to java.util.Random.nextBytes() implementation - I'm not > >>>> sure if this is secure enough for SecureRandom.nextBytes(). > >>>> - delegate to using the system srandom() and random() calls to seed > and > >>>> generate a sequence of numbers - again these may not be secure enough > >>>> and will also require the addition of z/OS specific native code to > the > >>>> security module to create the JNI layer between RandomBitsSupplier > and > >>>> the system libraries, although this code will be fairly trivial. > >>>> > >>>> > >>> > >>> Thoughts/Suggestions? > >>> > >>> > >>> I am for the next approach. It is reasonable to give a native > >>> implementation on z/OS just like what we have done on windows and > >>> > >> linux/unix > >> > >>> platforms. > >>> > >>> > >> Agreed, I prefer the 2nd approach. > >> I was thinking that in fact we don't necessarily need to make this code > >> z/OS specific - it could be a fallback for all unix platforms where > >> /dev/*random cannot be found. On most Linux/Unix systems this will not > >> make a difference since /dev/*random will exist, but those that don't > >> have these devices will seamlessly drop back to use random() instead of > >> throwing an Exception as they do now. > >> Does this sound reasonable? I will look at the code changes required. > >> > >> > >>> Actually, from the stacktrace, it is a problem in harmony's own > >>> > >> security > >> > >>> provider so I am wondering whether we can implement it independent on > >>> > >> the > >> > >>> platform API as a pure java program? > >>> > >>> > >>> > >> I think it is possible to go the pure Java direction, but I personally > >> would be more inclined to just use the available system devices/calls > to > >> provide random number generation and rely on their quality. > >> > >> Regards, > >> Oliver > >> > >> > >>> > >>>> Regards, > >>>> Oliver > >>>> > >>>> [1] > >>>> Exception in thread "main" java.security.ProviderException: > ATTENTION: > >>>> service is not available : no random devices > >>>> at > >>>> > >>>> > >>>> > >> > org.apache.harmony.security.provider.crypto.RandomBitsSupplier.getRandomBits > >> > >>>> (RandomBitsSupplier.java:172) > >>>> at > >>>> > >>>> > >>>> > >> > org.apache.harmony.security.provider.crypto.SHA1PRNG_SecureRandomImpl.engineNextBytes > >> > >>>> (SHA1PRNG_SecureRandomImpl.java:294) > >>>> at java.security.SecureRandom.nextBytes(SecureRandom.java:281) > >>>> > >>>> -- > >>>> Oliver Deakin > >>>> Unless stated otherwise above: > >>>> IBM United Kingdom Limited - Registered in England and Wales with > >>>> > >> number > >> > >>>> 741598. > >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > >>>> > >> 3AU > >> > >>>> > >>>> > >>> Good luck! > >>> > >>> > >>> > >> -- > >> Oliver Deakin > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with > number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > >> > >> > >> > > > > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >
