On Sun, Apr 23, 2017 at 12:48 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > Hi, > > Thank you for the review. > > On Thu, Apr 20, 2017 at 4:39 PM, Stephan Müller <smueller@xxxxxxxxxx> wrote: > >>> +/* The function verifies that tdes keys are not weak.*/ >>> +static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen) >>> +{ >>> +#ifdef CCREE_FIPS_SUPPORT >>> + tdes_keys_t *tdes_key = (tdes_keys_t*)key; >>> + >>> + /* verify key1 != key2 and key3 != key2*/ >> >> I do not think that this check is necessary. There is no FIPS requirement or >> IG that mandates this (unlike the XTS key check). >> >> If there would be such requirement, we would need a common service function >> for all TDES implementations Well, it turns out there is and we do :-) This is from crypto/des_generic.c: /* * RFC2451: * * For DES-EDE3, there is no known need to reject weak or * complementation keys. Any weakness is obviated by the use of * multiple keys. * * However, if the first two or last two independent 64-bit keys are * equal (k1 == k2 or k2 == k3), then the DES3 operation is simply the * same as DES. Implementers MUST reject keys that exhibit this * property. * */ int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, unsigned int keylen) However, this does not check that k1 == k3. In this case DES3 becomes 2DES (2-keys TDEA), the use of which was dropped post 2015 by NIST Special Publication 800-131A*. Would it be acceptable if I offer a patch adding this check to __des3_ede_setkey() and use that in the ccree driver? * http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf Many thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html