Leo Li wrote:
On 12/11/07, Oliver Deakin <[EMAIL PROTECTED]> 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
