Thanks Yuri! I will use a combination of values from time(), clock() and local and Java variable addresses - that should be suitably random :) Regards, Oliver Yuri Dolgov wrote: > 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 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 >>> >> wrote: >> >>> >>>> Leo Li wrote: >>>> >>>> >>>>> On 12/11/07, Oliver Deakin 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 >> >> >> > > -- 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