You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Oliver Deakin <ol...@googlemail.com> on 2007/12/10 17:45:33 UTC
[classlib][security] RandomBitsSupplier.getRandomBits() on zOS
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?
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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Mark Hindess <ma...@googlemail.com>.
On 8 January 2008 at 1:19, "Imran Ghory" <im...@gmail.com> wrote:
>
> On Jan 8, 2008 12:35 AM, Endre St=F8lsvik <En...@stolsvik.com> wrote:
>
> > 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.
> >
> > Once upon a time, I also had the great idea to seed a random number
> > generator by using the hashCode() (they say it is the "address" of the
> > object on many JVMs) of some specific object.
>
> There was an incident a while back where an online poker service was
> exploited by the fact they seeded their randomness from time - someone
> just brute forced all the possible time combinations and with the
> information about which cards they had been dealt they were able to
> figure out what the seed was.
>
> Incidently, I know I'm coming a bit late to this conversation but
> couldn't we just resort to throwing a NoSuchAlgorithmException in the
> case we don't have a random source - wouldn't that be better then
> using a non-random source to avoid a false sense of security ?
But one might also argue that the existing code using /dev/urandom in
preference to the more secure /dev/random is also wrong in this respect.
> Looking at the SecureRandom docs a SecureRandom source has to comply
> with FIPS 140-2 & RFC 1750 - which unix random() almost certainly
> won't.
Certainly not on my linux box, but then /dev/urandom isn't either than
that is used by default on Linux.
In any case, this argument is possibly slightly misleading since AIUI we
are talking about the seed for the SecureRandom source rather than the
source itself.
-Mark.
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Imran Ghory <im...@gmail.com>.
On Jan 8, 2008 12:35 AM, Endre Stølsvik <En...@stolsvik.com> wrote:
> 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.
>
> Once upon a time, I also had the great idea to seed a random number
> generator by using the hashCode() (they say it is the "address" of the
> object on many JVMs) of some specific object.
>
>
There was an incident a while back where an online poker service was
exploited by the fact they seeded their randomness from time - someone just
brute forced all the possible time combinations and with the information
about which cards they had been dealt they were able to figure out what the
seed was.
Incidently, I know I'm coming a bit late to this conversation but couldn't
we just resort to throwing a NoSuchAlgorithmException in the case we don't
have a random source - wouldn't that be better then using a non-random
source to avoid a false sense of security ?
Looking at the SecureRandom docs a SecureRandom source has to comply with
FIPS 140-2 & RFC 1750 - which unix random() almost certainly won't.
Imran
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Endre Stølsvik <En...@stolsvik.com>.
Oliver Deakin wrote:
> Endre Stølsvik wrote:
>> Envision a server that's booting up.
>>
>> Playing the devils advocate here, assuming that no network activity
>> happened before our java process started, what's really random with
>> those three "seeds"?
>>
>> Oliver Deakin wrote:
>>> I found that, although fairly simple, this produced a good variety of
>>> seeds.
>>
>> On a system that's already running, it might. On a system that is
>> starting up, there will be _no_ variety in those three variables
>> except for the time, and that isn't really "variable" either!
>
> Actually when I tested these values I launched the VM separately for
> every run, so at least for the process time (and obviously system clock)
> it was as if the system was starting up every time.
Not really - lots of other processes are then running, and you thus have
some unpredictable elements in regard to _when you_ hit enter as opposed
to which other processes are in the run queue, where they are, state,
kernel threading, timeslices and pre-empting of processes, and whatnot.
How many times did you run your "reboot"?
Here's what I actually stated: Stick the JVM startup in a /etc/rc2.d/
script, WAY early in the boot sequence (in particular before the network
is brought up, since that can introduce actual randomness due to
latency, human intervention on other boxes in your network, name server
delays, DHCP, whathaveyous), on a physical box (not running on
virtualization, as that basically introduces the same problems as
described as when running on an OS), sampling each of your values, and
then appending them to a some log-file.
Now reboot the physical box 100 times (at least not only two). Check the
values. Due to some possible randomness in regard to variation between
e.g. two different clocks, or the angle of the disc in the hard disk
when spinning up, or other such very limited sources of entropy, there
might be more than one set of values that emerge - my point is that
there might be _some_ such sets, but not plenty. Checking the actual bit
patterns as opposed to decimal values also might reveal something. If
you get the same value more than just once, the point is proven, I feel
(obviously in comparison to how many bits of entropy you feel that you
get out of these values).
This is actually very relevant in regard to a _server_, as in "web
server", "application server" etc.
Endre.
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
Endre Stølsvik wrote:
> Oliver Deakin wrote:
>> <SNIP>
>
> Envision a server that's booting up.
>
> Playing the devils advocate here, assuming that no network activity
> happened before our java process started, what's really random with
> those three "seeds"?
>
>> I found that, although fairly simple, this produced a good variety of
>> seeds.
>
> On a system that's already running, it might. On a system that is
> starting up, there will be _no_ variety in those three variables
> except for the time, and that isn't really "variable" either!
Actually when I tested these values I launched the VM separately for
every run, so at least for the process time (and obviously system clock)
it was as if the system was starting up every time. I still found that
the seeds generated were very variable, however I understand your
concerns - Im not convinced the seed generation would work so well if
the function were called many times in a row quickly by an application.
I see the code I committed as a starting point which can be built on as
we come up with better ideas for seed generation. This is not intended
as a replacement for reading directly from /dev/*random - my initial
post in this thread [1] was concerned with scenarios where entropy data
and random system devices are not available. We only fall back to using
random() if we cannot access random devices, so for the most part this
code will never be used. The code I have provided is not a final
solution, but enables me (and any others in my position) to work on
systems where random devices are not available whilst improving the
quality of the seeds.
>
> Time cannot be assumed to be _variable_, just because it isn't -
> assuming that you synch to some proper time server, I can do it too,
> and our milliseconds deviation will be just a couple of tens or maybe
> hundreds if we're extremely unlucky.
>
> If you get any variety through those seeds, I bet the true entropy is
> a couple of bits at the most.
>
> Check how linux's /dev/random works - it ONLY accepts humanly
> generated entropy, because it feels that even network activity can be
> tricked, e.g. (IIRC) by pounding the server with extremely regular
> packets for an hour, and then start to attack it on its randomness
> (e.g. stealing some SSL session).
> Since entropy is so hard to get hold of, linux saves its stash of
> collected randomness, the /entropy pool/, on system shutdown (IIRC).
The difference here is that the OS is capable of constantly monitoring
human interaction with the system (which will almost certainly occur at
some point), but in our situation the user may launch the VM with a
class that requests random numbers without any kind of interaction from
the user between the time the VM launches and the time the random seed
is generated. In our case there is no source of human interaction to
generate a seed from and on a system without entropy based random
devices we have no other fallback mechanism.
>
> Read:
> http://en.wikipedia.org/wiki/Entropy_pool#Using_observed_events
>
>>
>> If anyone has suggestions on improvements to the seed selection, they
>> would be gratefully received. A patch with the improvements in would
>> be even more gratefully received ;)
>
> Sorry, can't help you there. Why not peek in other implementations?
I definitely won't be peeking at any other implementations! ;)
> I know that firing up the default SecureRandom on .. what was it ..
> Linux .. a couple of java versions ago, took ages - so it must have
> been doing some entropy-collecting in that time. What about trying to
> suck a couple of bytes from /dev/random for a couple of seconds, and
> if it doesn't work out, suck the rest out of /dev/urandom, with a
> warning on standard error?
As I said above, this thread originated due to the existence of systems
that do not have these random devices. Im hoping to be able to find a
satisfactory solution to this problem.
>
> I nevertheless mean that you _shall not_ implement a default
> _SecureRandom_ that produces entirely and absolutely predictable
> values!! Throw an exception in case the underlying system cannot
> produce any entropy on its own.
This is what we did previously. If we cannot come up with a good
solution then we may have to revert to throwing an exception.
>
> Don't take lightly on this - it will blow up as a huge security alert
> later on if you do.
That's exactly why I opened this up to the dev list for opinions and
patches.
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200712.mbox/%3c475D6D2D.2020304@googlemail.com%3e
>
> Endre
>
--
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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Endre Stølsvik <En...@stolsvik.com>.
Oliver Deakin wrote:
> Thanks Endre - that's an interesting account.
>
> To generate the random seed I used the current system time, the running
> time of the current process and an address of a local variable allocated
> with the port library equivalent of malloc.
Envision a server that's booting up.
Playing the devils advocate here, assuming that no network activity
happened before our java process started, what's really random with
those three "seeds"?
> I found that, although
> fairly simple, this produced a good variety of seeds.
On a system that's already running, it might. On a system that is
starting up, there will be _no_ variety in those three variables except
for the time, and that isn't really "variable" either!
Time cannot be assumed to be _variable_, just because it isn't -
assuming that you synch to some proper time server, I can do it too, and
our milliseconds deviation will be just a couple of tens or maybe
hundreds if we're extremely unlucky.
If you get any variety through those seeds, I bet the true entropy is a
couple of bits at the most.
Check how linux's /dev/random works - it ONLY accepts humanly generated
entropy, because it feels that even network activity can be tricked,
e.g. (IIRC) by pounding the server with extremely regular packets for an
hour, and then start to attack it on its randomness (e.g. stealing some
SSL session).
Since entropy is so hard to get hold of, linux saves its stash of
collected randomness, the /entropy pool/, on system shutdown (IIRC).
Read:
http://en.wikipedia.org/wiki/Entropy_pool#Using_observed_events
>
> If anyone has suggestions on improvements to the seed selection, they
> would be gratefully received. A patch with the improvements in would be
> even more gratefully received ;)
Sorry, can't help you there. Why not peek in other implementations? I
know that firing up the default SecureRandom on .. what was it .. Linux
.. a couple of java versions ago, took ages - so it must have been doing
some entropy-collecting in that time. What about trying to suck a couple
of bytes from /dev/random for a couple of seconds, and if it doesn't
work out, suck the rest out of /dev/urandom, with a warning on standard
error?
I nevertheless mean that you _shall not_ implement a default
_SecureRandom_ that produces entirely and absolutely predictable
values!! Throw an exception in case the underlying system cannot produce
any entropy on its own.
Don't take lightly on this - it will blow up as a huge security alert
later on if you do.
Endre
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
Thanks Endre - that's an interesting account.
To generate the random seed I used the current system time, the running
time of the current process and an address of a local variable allocated
with the port library equivalent of malloc. I found that, although
fairly simple, this produced a good variety of seeds. I deliberately
avoided using the JNIEnv, jclass, jbytearray and jint addresses passed
as parameters to the function as I found they were often consistent
between runs.
If anyone has suggestions on improvements to the seed selection, they
would be gratefully received. A patch with the improvements in would be
even more gratefully received ;)
Regards,
Oliver
Endre Stølsvik wrote:
> 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.
>
> Once upon a time, I also had the great idea to seed a random number
> generator by using the hashCode() (they say it is the "address" of the
> object on many JVMs) of some specific object.
>
> However, by pretty much pure luck, I tested out a bit-print method
> (basically, toBinaryString()) on the first random number that the
> system made. And what do you know - it was the same every time I
> started the web application! It soon hit me that of course it would
> be: starting up big old Tomcat and this rather heavy application would
> nevertheless be very deterministic: the sequence of objects created
> will be exactly the same every single time - including the hashCode()
> of that particular object I used. I guess the same can happen for
> local addresses too.
>
> Please be careful when creating and seeding _secure_ system random
> number generators - they ought to be pretty random!
>
> Kind regards,
> Endre.
>
--
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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Endre Stølsvik <En...@stolsvik.com>.
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.
Once upon a time, I also had the great idea to seed a random number
generator by using the hashCode() (they say it is the "address" of the
object on many JVMs) of some specific object.
However, by pretty much pure luck, I tested out a bit-print method
(basically, toBinaryString()) on the first random number that the system
made. And what do you know - it was the same every time I started the
web application! It soon hit me that of course it would be: starting up
big old Tomcat and this rather heavy application would nevertheless be
very deterministic: the sequence of objects created will be exactly the
same every single time - including the hashCode() of that particular
object I used. I guess the same can happen for local addresses too.
Please be careful when creating and seeding _secure_ system random
number generators - they ought to be pretty random!
Kind regards,
Endre.
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
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 <ol...@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 <ol...@googlemail.com>
>>>>
>>> wrote:
>>>
>>>>
>>>>> Leo Li wrote:
>>>>>
>>>>>
>>>>>> On 12/11/07, Oliver Deakin <ol...@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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
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 <ol...@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 <ol...@googlemail.com>
>>>
>> wrote:
>>
>>>
>>>> Leo Li wrote:
>>>>
>>>>
>>>>> On 12/11/07, Oliver Deakin <ol...@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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Yuri Dolgov <do...@gmail.com>.
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 <ol...@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 <ol...@googlemail.com>
> wrote:
> >
> >
> >> Leo Li wrote:
> >>
> >>> On 12/11/07, Oliver Deakin <ol...@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
>
>
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
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 <ol...@googlemail.com> wrote:
>
>
>> Leo Li wrote:
>>
>>> On 12/11/07, Oliver Deakin <ol...@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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Yuri Dolgov <do...@gmail.com>.
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 <ol...@googlemail.com> wrote:
> Leo Li wrote:
> > On 12/11/07, Oliver Deakin <ol...@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
>
>
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Oliver Deakin <ol...@googlemail.com>.
Leo Li wrote:
> On 12/11/07, Oliver Deakin <ol...@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
Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
Posted by Leo Li <li...@gmail.com>.
On 12/11/07, Oliver Deakin <ol...@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.
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?
> 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!
--
Leo Li
China Software Development Lab, IBM