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 > <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) > <http://www.cryptopp.com/docs/ref/pubkey_8h_source.html%29>). > > (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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
