On Saturday, April 23, 2016 at 6:13:44 PM UTC-4, jean-pierre.muench wrote: > > Sounds good to me. >
Committed at "Initial cut-in of CRYPTOPP_USE_FIPS_202_SHA3 macro", http://github.com/weidai11/cryptopp/commit/df1c94a38a97119198aa3ae92e82ab9e46d4e9b5. That should get folks beyond the manual merging of patches. I still need to add the test vectors, and they will be coming next. Am 24.04.2016 um 00:11 schrieb Jeffrey Walton: > > On Saturday, April 23, 2016 at 5:34:09 PM UTC-4, jean-pierre.muench wrote: >> >> Comments in-line as usual. >> >> Am 23.04.2016 um 23:23 schrieb Jeffrey Walton: >> >> >> (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). >> >> I think SHA-3 is something not too strongly related to the >> BACKWARDS_COMPATIBILITY macro which controls the availability of old APIs >> and thus hiding the old SHA-3 behind a macro which needs to be explicitly >> enabled by the user sounds like a reasonable plan, so a (deprecated -> >> which will be removed again soon) macro CRYPTOPP_USE_FIPS_202_SHA3 for now >> to enforce the new SHA-3 if the user wants it as a full replacement of the >> old and a CRYPTOPP_USE_PRE_STANDARD_SHA3 for our old one once we pushed the >> default SHA-3 to be standards compliant. >> >> Or, we could tie it to CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY or >> CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY_562. >> >> I'd opt against this because the users may need the older APIs (which is >> what the macros are made for) but don't want to lose the shiny new >> (inter-implementation compatible) SHA-3. >> >> How's this for now? > > If its OK, then I'll add the new test vectors, and add the logic to select > between them. > > Also, config.recommend *will* enable the macro by default. > > $ git diff > diff --git a/chacha.h b/chacha.h > old mode 100755 > new mode 100644 > diff --git a/config.h b/config.h > index 4e2eb68..94cf34d 100644 > --- a/config.h > +++ b/config.h > @@ -43,6 +43,12 @@ > // # define CRYPTOPP_NO_UNALIGNED_DATA_ACCESS > #endif > > +// Define this to select the FIPS 202 version of SHA3, and not the > original > +// version of SHA3. NIST selected Keccak as SHA3 in January 2013. SHA3 was > +// finalized in FIPS 202 in August 2015, and it was a modified version of > +// the selected version. > +//#define CRYPTOPP_USE_FIPS_202_SHA3 ^M > +^M > // ***************** Less Important Settings *************** > > -- -- 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.
