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 <[EMAIL PROTECTED]> wrote:
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
--
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
