Generate Keypairs with strong prng provider (SHA1PRNG)

[Bernd Eckenfels]

Hello,

The Windows-PNRG in 8 dispatches 1:1 to the old CAPI CryptGenRandom which is not well documented or configurable (unlike the CNG variant). I think MS switched from SHA1 to AES-CTR in Vista SP1 but the configuration settings of that DRBG are not published. It does however reseeding and shares the state with all user sessions (including additional input data) so that would be a plus compared to SHA1PRNG.

(Haven't looked at NativeRandom & /dev/random in a while but the situation (sans doc) is similar)

I think for 9 it would be good to use DRBG with 256bit security in over sampling mode (or xor, but I think technically that would be harder to proof that the source is full entropy according to 800-90c) on top of Windows-PRNG or Linux NativeRandom as the getInstanceStrong() and then use it for explicit key generation (in tools). (It is late, but isn't there some certification requirements in the queue for key generation anyway?)

(And one can only dream of a 8 backport :)

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
From: Weijun Wang <weijun.wang at oracle.com>
Sent: Friday, March 17, 2017 9:53:34 AM
To: Bernd Eckenfels; security-dev at openjdk.java.net
Subject: Re: Generate Keypairs with strong prng provider (SHA1PRNG)

I agree.

JDK 9 merely introduced DRBG as a replacement of SHA1PRNG and everything
else is not touched. (You can see DRBG right before SHA1PRNG in the
preference order with no other in between).

We'll need to find out how to make use of it.

In your previous mail, you mentioned "On Windows the Windows-PRNG and on
Linux the NativePRNGs both look better". I believe they are also DRBGs
initialized with a static strength. Is it also 128?

Thanks
Max

On 03/17/2017 10:28 AM, Bernd Eckenfels wrote:
> Hello,
>
> yes on Java 8 the keytool will use SHA1PRNG (on Windows) and with Java 9
> it will use DRBG(128,reseed_only).
>
> I guess both are not well suited for larger permanent keys (like Keytool
> is supposed to create). But agreed, the Java 9 default is less problematic.
>
> Hmm.. thinking out loud. maybe the concept of a strong PRNG does not
> match well with nonces and personalisation. With the addition of DRBG
> and the wide variety of parameters, is getInstanceStrong() rather
> obsolete in 9 or will it be used by the platform?
>
> Instead of trusting Windows CAPI it would be nice to have a DRBG
> reseeding from it as the default strong secure random. Then it would
> also be fit for use for key generation.
>
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> ------------------------------------------------------------------------
> *From:* Weijun Wang <weijun.wang at oracle.com>
> *Sent:* Friday, March 17, 2017 1:20:29 AM
> *To:* Bernd; security-dev at openjdk.java.net
> *Subject:* Re: Generate Keypairs with strong prng provider (SHA1PRNG)
>
> new SecureRandom() should not return SHA1PRNG on JDK 9. If NativePRNG is
> the preferred provider, it will be returned. Otherwise, DRBG will be
> used. DRBG is preferred to SHA1PRNG on every platform.
>
> Thanks
> Max
>
>
> On 03/17/2017 07:36 AM, Bernd wrote:
>> Hello,
>>
>> as a general precaution I wanted to document key generation best
>> practice. The SHA1PRNG with its small state and single 20 byte seed
>> always is a bit questionable for generating long term keys. 160 bit
>> entropy (as long as the SecureRandom instance is used only once) is not
>> enough for larger RSA Keys or AES192 and 256.
>>
>> So I was looking for a solution which works on 8 and 9 and involves more
>> seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux
>> the NativePRNGs both look better in this regard. The
>> SecureRandom.getInstanceStrong() automatially uses them.
>>
>> So while I think in the long run it might be better to wrap those
>> generators with DRBG some more I think a minimum is to use the strong
>> variant for key generation. I peeked into keytool to see whats best
>> practice and I noticed it does unfortunately NOT use the strong variant
>> or a DRBG configuration:
>>
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150
>>
>> Is it really acceptable for long term keys this way? (I guess no answer
>> means no :)
>>
>> Would it be possible to bump the security level for keytool in 9?
>>
>> Gruss
>> Bernd
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170317/e37eb6d9/attachment.htm>