> (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. >
What do you think about tying pre- and post-FIPS 202 to a config.h macro? We could use a new one, like CRYPTOPP_SHA3_FIPS_202 to mean use the finalized FIPS 202 version of SHA3 (August 2015); otherwise use the one called out at selection time (January 2013). Or, we could tie it to CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY or CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY_562. In this question, I'm addressing SHA3 only, and not Keccak. We will still need to figure out what to do with Keccak. 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]. For more options, visit https://groups.google.com/d/optout.
