2

Java 9 (JSR 379) introduces the NIST DRBG's as specified in JEP 273: DRBG-Based SecureRandom Implementations.

However, the NIST document SP 800-90Ar1 (NIST Special Publication 800-90A Revision 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators) specifies a total of three mechanisms:

Implement the three DRBG mechanisms (Hash_DRBG, HMAC_DRBG, CTR_DRBG) in 800-90Ar1 (on all platforms).

However, although you might expect that we would now have three methods to create such secure random algorithms:

  1. SecureRandom.getInstance("Hash_DRBG")
  2. SecureRandom.getInstance("HMAC_DRBG")
  3. SecureRandom.getInstance("CTR_DRBG")

… possibly with various configuration parameters, we seem to have only one:

  1. SecureRandom.getInstance("DRBG")

So how can the developer configure and detect which one of the algorithms is used?

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • [Temporary Comment] : Dear Maarten, sorry to bother you here. Do you have any experience with chip cards that does not return any ATR? Do you have any idea which type of cards does WaveLight use in its products? – Ebrahim Ghasemi Oct 25 '19 at 20:06
  • 1
    14443 type B cards don't return an ATR or ATS, and work on 13.something MHz. Proximity cards should not be picked up. I think the original MiFare cards also don't use an ATS, but nowadays they generally supply a compatibility layer. No, I don't know what cards or IC's they use. – Maarten Bodewes Oct 25 '19 at 22:55
  • Thank you dear Marteen for the information. BTW the cards are contact. – Ebrahim Ghasemi Oct 26 '19 at 05:22
  • Are you sure that there is no ATR in that case? Because it makes more sense that there are just no *historical bytes* within the ATR. – Maarten Bodewes Oct 26 '19 at 16:41
  • Yes dear Maarten, I'm sure that there is no ATR. I guess I found something related. As soon as I get assured about it, I'll share the data with you. – Ebrahim Ghasemi Nov 02 '19 at 13:02

2 Answers2

4

From the JEP

A new SecureRandomParameters interface so that additional input can be provided to the new SecureRandom methods.

From there we get to DrbgParameters which says

Implementation Note:

The following notes apply to the "DRBG" implementation in the SUN provider of the JDK reference implementation. This implementation supports the Hash_DRBG and HMAC_DRBG mechanisms with DRBG algorithm SHA-224, SHA-512/224, SHA-256, SHA-512/256, SHA-384 and SHA-512, and CTR_DRBG (both using derivation function and not using derivation function) with DRBG algorithm AES-128, AES-192 and AES-256.

The mechanism name and DRBG algorithm name are determined by the security property securerandom.drbg.config. The default choice is Hash_DRBG with SHA-256.

So, implementation dependent and with default impl, switchable only with a property.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • @MaartenBodewes hmm? I would read the same property I guess... – Kayaman Oct 09 '19 at 13:01
  • Yeah, that just dawned on me, and it is probably better than to use `SecureRandom.toString()` which - at least for the OpenJDK implementation - also returns the algorithm in the string. – Maarten Bodewes Oct 09 '19 at 13:11
  • @MaartenBodewes then you might want to just use `SecureRandom.getAlgorithm()`, although it can return `unknown` and probably a lot more. – Kayaman Oct 09 '19 at 13:14
  • Now that one *does not* work, it just returns `"DRBG"` instead of the actual algorithm (as I hoped it would, to be honest). – Maarten Bodewes Oct 09 '19 at 13:41
  • I think the default should be highlighted. – kelalaka Oct 09 '19 at 16:23
4

Use Security.SetProperties before calling SecureRandom:

Security.setProperty("securerandom.drbg.config", "Hash_DRBG");

SecureRandom random = SecureRandom.getInstance("DRBG");

For more information this article provides some in-depth info: https://metebalci.com/blog/everything-about-javas-securerandom/

locus2k
  • 2,802
  • 1
  • 14
  • 21
  • That seems to work fine, thanks. Could you indicate if there are any requirements / access conditions for being able to configure the exact algorithm? I'm flabbergasted that it works (although Java has a lot of these static configuration options that can be set from anywhere in the code). – Maarten Bodewes Oct 09 '19 at 12:56
  • 1
    @MaartenBodewes you can do a lot when there's no `SecurityManager` around, like the old trick of [enabling strong encryption](https://stackoverflow.com/questions/42159690/why-are-the-jce-unlimited-strength-not-included-by-default) with reflection (which seems to be unnecessary these days). – Kayaman Oct 09 '19 at 13:04