harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Date Thu, 13 Dec 2007 15:12:53 GMT
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 <oliver.deakin@googlemail.com> wrote:
>
>   
>> Leo Li wrote:
>>     
>>> On 12/11/07, Oliver Deakin <oliver.deakin@googlemail.com> 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


Mime
View raw message