On Mon, Apr 24, 2017 at 9:16 AM, Stephan Müller <smueller@xxxxxxxxxx> wrote: > Am Montag, 24. April 2017, 08:06:09 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, >> >> 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*. > > It is correct that the RFC wants at least a 2key 3DES. And it is correct that > SP800-131A mandates 3key 3DES post 2015. All I am saying is that FIPS 140-2 > does *not* require a technical verification of the 3 keys being not identical. > > Note, formally, FIPS 140-2 requires that the 3 keys (i.e. all 192 bits) must > be obtained from *one* call to a DRBG or KDF (separate independent calls to, > say, obtain one key at a time is *not* permitted). Of course, fixing the > parity bits is allowed after obtaining the random number. >> >> Would it be acceptable if I offer a patch adding this check to >> __des3_ede_setkey() >> and use that in the ccree driver? > > I am not sure it makes sense as the core requirement is the *one* invocation > of the DRBG. Thanks you for the clarification. As I think is obvious by now I am not a FIPS expert by any stretch. Isn't the requirements on DRBG or KDF invocations pertain to key generation only? What happens if you don't derive the keys on the system, but wish to use keys derived elsewhere? I assumed the limitations on weak keys etc. were meant to protect against that scenario and are therefore independent from key generation requirements, but I may have misunderstood that. Anyway, if I understand you correctly, what you are saying is that these checks might make an implementation RFC 2451 and SP800-131A compliant respectively but they are not required for FIPS 140-2 compliance? did I understand that correctly? If so, since two 3DES implementation in the kernel already do the RFC 2451 compliant check I assume you would not object to the ccree driver using the same function, disconnect from FIPS being set or not, just as is being done with the other 3DES implementation. In addition, would it be OK if we did an extra check in the ccree driver for SP800-131A key compliance and disable encryption (but allow decryption) if the key fails the check? again, this would be independent from FIPS mode? Thanks again, 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
