[PATCH] crypto: prevent 112bit key for 3DES

[PATCH] crypto: prevent 112bit key for 3DES

[Roman Drahtmueller]

56 bit keys are already prevented from being used, which conforms to rfc2451.
As of 2016, 112 bit 3DES should be prevented, too, if the expectation
is that the algorithm uses 168 bit.

Signed-off-by: Roman Drahtmueller <draht@schaltsekun.de>
---
 crypto/des_generic.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index a717205..5810643 100644
--- a/crypto/des_generic.c
+++ b/crypto/des_generic.c
@@ -854,9 +854,25 @@ static void des_decrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
  *   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
+ *   equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the
  *   same as DES.  Implementers MUST reject keys that exhibit this
  *   property.
+ *   -- end of RFC quote --
+ *
+ *
+ *   Keying options are:
+ *   1) 168 bit 3DES: All three 64bit keys are different.
+ *   2) 112 bit 3DES: k1 != k2, but k3 == k1.
+ *   3)  56 bit 3DES (single DES): If two successive operations use the
+ *      same key, they cancel out, leaving only one effective operation.
+ *      Having three identical keys is only a special case.
+ *      k1 == k2 or k2 == k3 (or even k1 == k2 == k3)
+ *
+ *   Option 3) MUST be rejected, this is mandated by RFC2451.
+ *   Option 2) is a bad choice as of 2016, too. The expectation is
+ *   that if 168 bit key material is provided, the implementation should
+ *   guarantee that the algorithm behaves as strongly as expected,
+ *   intercepting weak keys.
  *
  */
 int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key,
@@ -865,7 +881,8 @@ int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key,
 	const u32 *K = (const u32 *)key;
 
 	if (unlikely(!((K[0] ^ K[2]) | (K[1] ^ K[3])) ||
-		     !((K[2] ^ K[4]) | (K[3] ^ K[5]))) &&
+		     !((K[2] ^ K[4]) | (K[3] ^ K[5])) ||
+		     !((K[0] ^ K[4]) | (K[1] ^ K[5]))) &&
 		     (*flags & CRYPTO_TFM_REQ_WEAK_KEY)) {
 		*flags |= CRYPTO_TFM_RES_WEAK_KEY;
 		return -EINVAL;
-- 
1.7.3.4

Re: [PATCH] crypto: prevent 112bit key for 3DES

[Stephan Mueller]

Am Freitag, 12. Februar 2016, 17:45:24 schrieb Roman Drahtmueller:

Hi Roman,

>56 bit keys are already prevented from being used, which conforms to rfc2451.
>As of 2016, 112 bit 3DES should be prevented, too, if the expectation is
>that the algorithm uses 168 bit.
>
>Signed-off-by: Roman Drahtmueller <draht@schaltsekun.de>

This code is at least needed in FIPS 140-2 mode. As a caller would manually 
need to create a 2-key TDES key which would violate the newly added check ( 
which is very unlikely) I would think this patch is also appropriate for all 
users.

Acked-by: Stephan Mueller <smueller@chronox.de>

Re: [PATCH] crypto: prevent 112bit key for 3DES

[Theodore Ts'o]

On Fri, Feb 12, 2016 at 05:45:24PM +0100, Roman Drahtmueller wrote:
> 
> 56 bit keys are already prevented from being used, which conforms to rfc2451.
> As of 2016, 112 bit 3DES should be prevented, too, if the expectation
> is that the algorithm uses 168 bit.

I'm not sure this is a place to be making policy statements.  3DES
supports two key lengths: 112 and 168 bits, just as AES supports three
key lengths: 128, 192, and 256.

NIST recommends that you use 128 bits if you need data to be kept
confidential after 2030, but if you only need data to be kept safe
until 2030, 112 bits is still OK.  But that's just NIST, and even NIST
SP800-131A (Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Lengths) disallows, for US Federal
Government users, use of 112 bit TDES for _encryption_ after December
31, 2015.  However, 112 bit TDES is still allowed for _decryption_ for
legacy use (e.g., maybe you want to decrypt a document that was
encrypted using 112 bits).

So if you're making a product where you are selling to the US Federal
Government, and compliance to SP800-131A is required, prohibiting 2
key TDES for encryption might be somethign you want to do.  But
disalowig it in the setkey function means that you also aren't
allowing decryption of legacy data.  How much does this matter for the
kernel crypto layer?  Meh.  But I'm also not so sure this is the right
place to be making policy pronouncements.  After all, it's not like we
are enforcing key length restrictions in crypto/arc4.c, so a caller
can use 40-bit RC4 keys.  That seems rather inconsistent with making
restrictions about TDES's key size.

Cheers,

					- Ted