From dev-return-31183-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Thu Dec 13 15:13:36 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 36077 invoked from network); 13 Dec 2007 15:13:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Dec 2007 15:13:34 -0000 Received: (qmail 63125 invoked by uid 500); 13 Dec 2007 15:13:21 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 63106 invoked by uid 500); 13 Dec 2007 15:13:21 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 63097 invoked by uid 99); 13 Dec 2007 15:13:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Dec 2007 07:13:21 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of oliver.deakin@googlemail.com designates 64.233.178.249 as permitted sender) Received: from [64.233.178.249] (HELO hs-out-2122.google.com) (64.233.178.249) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Dec 2007 15:12:57 +0000 Received: by hs-out-2122.google.com with SMTP id m63so772216hsc.4 for ; Thu, 13 Dec 2007 07:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=U7iIzPvoVu/Yx4V8FqdOBNXGOI91z18HxbRLg9bxH/0=; b=JwFJ+DS76Qaip0g4E4LVnKAJCvh2m/IaRuWxT342lemYmLK1cmluNczCcid/hN5wgRVMKHCAOwxBaUMXURXIzwZr1E7tTqg9wPrD/7okCLPu4S0VW10zi0FdQIHnLT18eElguX0352oGjjqBTCNRDpNLrstR8JOa/KfAf19n9Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XEg5HsDIEMs0+wcGDpzS/qc9+HBBQgsbRFAGYPoKlTrqwp/wQRFjEEjXYznXiIUPNTN82QxPsZ3QImUHycMc0A3H4JBNfQNPA1ExaAVgHW/KyeNQFqP9aWEvLB4+Qq9nSTKq8+mEG9ggFOmuNcz2UX+MIfpPA9GdIwJIB6JqnFo= Received: by 10.78.83.15 with SMTP id g15mr2517368hub.6.1197558775520; Thu, 13 Dec 2007 07:12:55 -0800 (PST) Received: from ?9.20.183.175? ( [195.212.29.83]) by mx.google.com with ESMTPS id f6sm434352nfh.2007.12.13.07.12.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Dec 2007 07:12:53 -0800 (PST) Message-ID: <47614BF5.3050103@googlemail.com> Date: Thu, 13 Dec 2007 15:12:53 +0000 From: Oliver Deakin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [classlib][security] RandomBitsSupplier.getRandomBits() on zOS References: <475D6D2D.2020304@googlemail.com> <475E6AA4.2010503@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: > > >> Leo Li wrote: >> >>> On 12/11/07, Oliver Deakin 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