Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of liyilei1979@gmail.com
 designates 209.85.134.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=ETFQHnibUIfO+S7hSdNLvnef1bKyl2mhF7Zmsyb/Cf84PvZpsmHTtNppsH1WROlHyGe7Sbl+tzmvQU4dEQ0hUcS5GV8DMFxuNHP2AscT/VKcYikahoB149L/qrpboNArX0urpnFN6YqnMu8WNCHNYuvQMmDwBTpBZQlcCYg5a2Y=
Message-ID: <e66844de0712101605i1fabb3bcs46d24357ce242473@mail.gmail.com>
Date: Tue, 11 Dec 2007 08:05:44 +0800
From: "Leo Li" <liyilei1979@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS
In-Reply-To: <475D6D2D.2020304@googlemail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24492_10261995.1197331544460"
References: <475D6D2D.2020304@googlemail.com>

------=_Part_24492_10261995.1197331544460
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.
    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

------=_Part_24492_10261995.1197331544460--