Am Donnerstag, 15. September 2016, 14:26:29 CEST schrieb Herbert Xu: Hi Herbert, > On Thu, Sep 15, 2016 at 08:23:05AM +0200, Stephan Mueller wrote: > > Where shall we draw the line here? Shall that be only for authenc, or > > seqiv? Or shall we also consider rfc4106 too, knowing that there are > > implementations which provide a full rfc4106 GCM combo (x86 for example). > > What about the current pkcspad1 template where we could expect that there > > may be entire HW implementations with that? > > That's something that only you can tell us :) Well, as a baseline we can say that: - with the exception of a few block chaining modes (e.g. xcbc, pcbc, lrw) all templates are allowed in FIPS mode - almost all "non-approved" ciphers (i.e those that should not have a fips_allowed flag) are due to the raw base cipher (i.e. only SHA1/2, AES and TDES is allowed) - all compression algos are allowed > > For such templates we could move that info into the generic > template implementation code and have them declare themselves > as such that for any X if X is FIPS allowed then so is T(X). > > This info can then be used in testmgr. I can see that, but I do not believe it makes our life in the testmgr easier. The reason is that in a lot of cases, the template parts (read: block chaining modes) are moved into implementations. The most notable examples are the x86 Intel and the S390 CPACF implementations. For those, the template handling code is not triggered and thus we still would need testmgr entries with the block chaining modes. Considering that we now have RSA in the kernel and that we could expect RSA implementations in hardware (in fact, we already have them), there is another complication: FIPS only allows RSA according to FIPS 186-4 and not according to FIPS 186-2 (ok, the main difference is in key gen, which we do not have). What I want to say here is that with the more complex style ciphers, it may very well be possible that only the respective implementation knows whether it is FIPS compliant. Thus, I am still thinking that moving the fips_allowed flag into the structs that are evaluated during register time is more helpful. I definitely see that this would imply that all, say, AES implementations need that flag. But IMHO it is a much cleaner solution, because if the register is rejected, the cipher does not show up in /proc/crypto and everybody knows that a particular cipher is not in use. My particular example is that in one test with FIPS mode enabled, seqiv(rfc4106(gcm-base(...))) was successfully loaded and marked as selftest passed in /proc/crypto. Yet, an allocation of the test failed with ENOENT. Rebooting the system without FIPS mode allowed me to allocate the cipher. As there is no test for this particular cipher name in testmgr, I highly suspect that the allocation code did not find it because somehow there was no test. In any case, it is definitely not clear why that particular cipher name cannot be allocated in FIPS mode given the entries in /proc/crypto. Ciao Stephan -- 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
