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 Thu, 13 Dec 2007 15:22:16 GMT
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
>
>

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