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 [email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
