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 Fri, 14 Dec 2007 15:29:46 GMT
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 <oliver.deakin@googlemail.com> 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 <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
>>
>>
>>     
>
>   

-- 
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