Hey Jeff, Comments are in-line.
Am 23.04.2016 um 22:01 schrieb Jeffrey Walton: > Hi Everyone, > > Our SHA-3 is not really SHA-3 since FIPS 202 was finalized. We can > change it, but then we break folks who began using it in 2013. Also > see "SHA-3 test vector results" > (http://github.com/weidai11/cryptopp/issues/158). > > So I was thinking: > > (1) Update SHA-3 to FIPS 202 > (2) Provide a basic Keccak > > (1) gets us in line with FIPS 202. (2) provides a path for existing users. > > The tricky spot seems to be Keccak, which appears to have at least 11 > revisions (http://keccak.noekeon.org/files.html). Their web page is > kind of messy and lacks dates, so I'm having trouble determining (a) > what version our SHA is, and (b) what version FIPS 202 is. > > So my questions are: > > (1) Is it OK to change SHA-3 to align it with FIPS 202? Sure, but we should do it with the aligned with the usual versioning / warning practices, like we discussed with ECIES. Deprecate the current version if we do a 5.7 and evaluate again if we are doing a direct 6.0 whether it would be too rude to break the existing "SHA-3". > (2) How should we include Keccak so that early adopters don't break? see (1) > (3) What version of Keccak should we include as our Keccak since it > seems to be a moving target? I'd say we *must* have the FIPS-202 version. If you want an additional non-FIPS version of Keccak, then I'd suggest asking the Keccak devs for what they'd recommend and if they have no preferences just go with the most current version. > > For (2), we could do something like: > > class Keccak_ORIG { ... }; If people want to retain our old non-standard Keccak, then sure we can keep it, but I'd prefer to get it out (or at least put it in some deprecated sub-namespace). > > For (3), it can be colorful since we could do something like: > > // Compile time > template <unsigned int Version> > class Keccak { ... }; > > Or: > > // Runtime > class Keccak > { > Keccak(unsigned int version) {...} > }; Or even fancier: // compile-time wrapper for the run-time version template <unsigned int Version> class Keccak { ... }; Like I proposed to do with the ChaCha rounds, e.g. implement it run-time based in case people need to handle different versions at run-time (if the cost of this isn't too high) instead of at compile-time where you don't gain anything but a new template parameter. The only problem is: HMAC requires to know the hash size at compile-time via the CRYPTOPP_CONSTANT and thus a compile-time parameter may be more appealing if we want to make it HMAC compatible (which is actually an unnecessary construction for Keccak) BR JPM > > Jeff > > > -- > -- > 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.
