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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
