Am Montag, 24. April 2017, 09:04:13 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > 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. That is exactly an important question. NIST lately moved away from a pure cipher-only view of cryptography to a more holistic view (i.e. where are ciphers used). That said, for 3DES there is no formal requirement that the 3 keys must be checked. NIST is fine when documentation says how the keys are generated by some logic outside the module. > > 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? Correct. Regarding SP800-131A, it only says that a full 3key 3DES is required. It does not say whether/how the key shall be enforced not being identical. > > 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. Absolutely. If possible, all 3DES implementations should use the same checking functions. The existing checking function regarding the prevention of 1key 3DES should be used by your code too. All I am saying that from a FIPS perspective, there is no need to extent the common function by a 3key 3DES enforcer. > > 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? My personal taste would be: changes that makes sense for all 3DES implementations should go to a common function. Otherwise, 3DES implementation A behaves differently than impl. B. That said, having a check that all three keys are non-identical would certainly be good (see my Ack to the patch from a year ago). But you cannot use the argument that FIPS mandates it to push it through. :-) Ciao Stephan PS: There is currently a new requirement being discussed for FIPS: 3DES operations should not allow more than 4GB of data to be encrypted with one key. This requirement would need technical enforcement. I am looking into this one for some time now.
