lkml.org 
[lkml]   [2017]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 6/9] staging: ccree: add FIPS support
Date
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.

Ciao
Stephan

\
 
 \ /
  Last update: 2017-04-24 08:17    [W:0.087 / U:1.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site