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 Mon, 07 Jan 2008 14:32:16 GMT
Committed at r609614.

Regards,
Oliver

Oliver Deakin wrote:
> 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