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 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 [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.
