SP800-90 Random Number Generators

[Jeffrey Walton]

The ANSI X9.17 (3-key Triple DES) and X9.31 (AES) based generators cannot be used after December 2015. From SP800-131A (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf):

    The ANSI generators are in DEPRECATED status.
    You can use them from 2010 through 2015. After
    2015, you MUST use an SP800-90 generator.

That means Crypto++ will lack an approved generator in 2016.

SP800-90 specifies 3 replacement generators. The generators have some polices attached to them. Policy includes:

  * How to utilize user supplied seeds
  * Reseed interval based on bytes provided

So the questions are:

 1. Do we provide an interface that provides a policy interface and have the 800-90 generators inherit from them (in addition to RandomNumberGenerator)?
 2. Forgo policy objects, just inherit from RandomNumberGenerator, and hard code the requirements into each implementation?
 3. Make the reseed limit a template parameter so its a compile time constant?

(1) seems like its better design, and it follows current practices (for example, see the comments pubhey.h (http://www.cryptopp.com/docs/ref/pubkey_8h_source.html)).

(2) is a quicker path to a new generator at the expense of design and extensibility.

(3) does not seem useful since the limits are not moving targets. That is, they are fixed and we can get the same result with `static const unsigned int RESEED_INTERVAL = 4 * 1024 * 1024;`.

Are there other alternatives that I missed?

Which would be better suited for the library?

[Jean-Pierre Münch]

Hey Jeffrey,

I've to say you that (for me) the link is a dead end.

1) Can't we just derive a special drbg class from randomnumbergenerator, so people would have the choice which interface style to use? (and use the new NIST class to derive the NIST DRBGs).

2) What would be the differences by these new policies? It's still up to the generator on how to interpret seeds and we could simple construct a middle class that does the job as NIST wants it (and encorage use of Fortuna?)

3) I've had the same design problem with my Fortuna code and solved it using the approach you described in your "answer" to (3). If you look into my code you'll find a compile-time constant (CRYPTOPP_CONSTANT) named NUMBER_MILLISECONDS_BETWEEN_RESEEDS (very functional name isn't it?) and I think we can solve it in a similar way, maybe again with a middleware class.

BR

JPM

[Jeffrey Walton]

On Monday, April 13, 2015 at 11:02:18 AM UTC-4, Jean-Pierre Münch wrote:

Hey Jeffrey,

I've to say you that (for me) the link is a dead end.

The link is good. I think the HTML markup included the closing paren in it. You should be able to trim it from the address bar and get to the page. Or, you can visit it locally from the sources.
 

1) Can't we just derive a special drbg class from randomnumbergenerator, so people would have the choice which interface style to use? (and use the new NIST class to derive the NIST DRBGs).

Yes, RandomNumberGenerator will be a base class.

What I am wondering about if/how the policy related objects should fit in.
 

2) What would be the differences by these new policies? It's still up to the generator on how to interpret seeds and we could simple construct a middle class that does the job as NIST wants it (and encorage use of Fortuna?)

Folks in US Federal and US DoD need to use an approved generator. They can't use other generators, like RandomPool or Fortuna.
 

3) I've had the same design problem with my Fortuna code and solved it using the approach you described in your "answer" to (3). If you look into my code you'll find a compile-time constant (CRYPTOPP_CONSTANT) named NUMBER_MILLISECONDS_BETWEEN_RESEEDS (very functional name isn't it?) and I think we can solve it in a similar way, maybe again with a middleware class.

OK, thanks.

Jeff

[Jean-Pierre Münch]

Am 13.04.2015 um 17:58 schrieb Jeffrey Walton:

On Monday, April 13, 2015 at 11:02:18 AM UTC-4, Jean-Pierre Münch wrote:

Hey Jeffrey,

I've to say you that (for me) the link is a dead end.

The link is good. I think the HTML markup included the closing paren in it. You should be able to trim it from the address bar and get to the page. Or, you can visit it locally from the sources.

Checked again. Works now.

 

1) Can't we just derive a special drbg class from randomnumbergenerator, so people would have the choice which interface style to use? (and use the new NIST class to derive the NIST DRBGs).

Yes, RandomNumberGenerator will be a base class.

What I am wondering about if/how the policy related objects should fit in.

Could you please state the requirements an approved generator has to fulfill?
(Reseed every X seconds,...)
I think most can be mitigated by adding new functions that generalize old ones with good defaults. (Like I did with tweakable blockciphers, so that processdata() is a special case of processdatawithtweak().

 

2) What would be the differences by these new policies? It's still up to the generator on how to interpret seeds and we could simple construct a middle class that does the job as NIST wants it (and encorage use of Fortuna?)

Folks in US Federal and US DoD need to use an approved generator. They can't use other generators, like RandomPool or Fortuna.
 

3) I've had the same design problem with my Fortuna code and solved it using the approach you described in your "answer" to (3). If you look into my code you'll find a compile-time constant (CRYPTOPP_CONSTANT) named NUMBER_MILLISECONDS_BETWEEN_RESEEDS (very functional name isn't it?) and I think we can solve it in a similar way, maybe again with a middleware class.

OK, thanks.

Jeff

BR

JPM

Am Montag, 13. April 2015 03:54:20 UTC+2 schrieb Jeffrey Walton:

The ANSI X9.17 (3-key Triple DES) and X9.31 (AES) based generators cannot be used after December 2015. From SP800-131A (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf):

    The ANSI generators are in DEPRECATED status.
    You can use them from 2010 through 2015. After
    2015, you MUST use an SP800-90 generator.

That means Crypto++ will lack an approved generator in 2016.

SP800-90 specifies 3 replacement generators. The generators have some polices attached to them. Policy includes:

  * How to utilize user supplied seeds
  * Reseed interval based on bytes provided

So the questions are:

 1. Do we provide an interface that provides a policy interface and have the 800-90 generators inherit from them (in addition to RandomNumberGenerator)?
 2. Forgo policy objects, just inherit from RandomNumberGenerator, and hard code the requirements into each implementation?
 3. Make the reseed limit a template parameter so its a compile time constant?

(1) seems like its better design, and it follows current practices (for example, see the comments pubhey.h (http://www.cryptopp.com/docs/ref/pubkey_8h_source.html)).

(2) is a quicker path to a new generator at the expense of design and extensibility.

(3) does not seem useful since the limits are not moving targets. That is, they are fixed and we can get the same result with `static const unsigned int RESEED_INTERVAL = 4 * 1024 * 1024;`.

Are there other alternatives that I missed?

Which would be better suited for the library?

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Walton]

1) Can't we just derive a special drbg class from randomnumbergenerator, so people would have the choice which interface style to use? (and use the new NIST class to derive the NIST DRBGs).

Yes, RandomNumberGenerator will be a base class.

What I am wondering about if/how the policy related objects should fit in.

Could you please state the requirements an approved generator has to fulfill?
(Reseed every X seconds,...)

The requirements for the NIST generators can be found in [1,2].

I don't know what your Fortuna generator requires because I don't use it. You should probably review the paper that introduced it to the world.

There's also VM playback hardening [3,4]. To help harden against some of these attacks, you add entropy immediately prior to providing bytes.

Maybe the way to proceed is to add a couple of overloaded constructors and NamedValuePairs that the generator understands (http://www.cryptopp.com/wiki/NameValuePairs). There could be a ReseedInterval of type "unsigned int", an AddEntropyOnOutput of type "boolean", etc. AddEntropyOnOutput is partially the Hedging implementation proposed by Ristenpart and Yilek.

[1] Recommendation for Random Number Generation Using Deterministic Random Bit Generators, http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
[2] Recommendation for Random Bit Generator (RBG) Constructions, SP800-90C, http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90c.pdf
[3] When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments, https://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf
[4] When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography, http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf