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 Tue, 11 Dec 2007 10:47:00 GMT
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


Mime
View raw message