harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuri Dolgov" <dolgov.g.y...@gmail.com>
Subject Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Date Tue, 11 Dec 2007 11:53:25 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message