1. I think we all agree that we must have the FIPS-202 compliant SHA-3. 2. Since SHA-3 does not provide the same security properties as the original Keccak, I think we must keep Keccak implementation available for those who (for whatever reason) are not satisfied by the properties of SHA-3. Regarding Keccak versions, I agree that in the long term we could/should talk to the Keccak developers (off-hand I don’t know if we want to support multiple versions of Keccak, nor wether it would make sense, nor whether anybody really needs that). For now we can keep whatever we got.
3. HMAC does not make sense for SHA-3 (nor for Keccak). I suggest we table HMAC-SHA-3 until NIST speaks up (and I hope they’d say “use SHA-3 directly instead of trying to push it into HMAC construct”). > On Apr 23, 2016, at 16:13 , Jean-Pierre Münch <[email protected] > <mailto:[email protected]>> wrote: > > 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 >> <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 >> <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] >> <mailto:[email protected]>. >> More information about Crypto++ and this group is available at >> <http://www.cryptopp.com/>http://www.cryptopp.com <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 >> <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] > <mailto:[email protected]>. > More information about Crypto++ and this group is available at > http://www.cryptopp.com <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 > <https://groups.google.com/d/optout>. -- Mobile Mouse [email protected] <mailto:[email protected]> -- -- 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.
