Description of problem: For fips compliance, we need self-tests for all crypto components we're certifying. We're attempting to get the rfc4309 variant off ccm using aes, aka rfc4309(ccm(aes)) certified, but there is currently no self-test for it in tcrypt. Version-Release number of selected component (if applicable): kernel-2.6.18-124.el5 How reproducible: Attempt a crypto operation using rfc4309(ccm(aes)), and observe the notice in dmesg: alg: No test for rfc4309(ccm(aes)) (rfc4309(ccm_base(ctr(aes-x86_64),aes-x86_64))) Note: I'm working on obtaining some test vectors with known answers, which we could use to implement this self-test.
FYI, I think we can just use the test vectors from here: http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf
Note to self. Looking at the docs above I believe the nist nomenclature to linux crypto lib nomenclature in testmgr is as follows: NIST | linux cryptolib K | key Klen | klen A | assoc Alen | alen N | iv Nlen | N/A (iv is null terminated) P | input Plen | ilen C | result Clen | rlen I'm a bit concerned about the null termination of iv, as I think its possible for the initial vector to have embedded \00 values in it, which would screw up the computation here, so I'll need to check on that. Beyond that however, I think we can use any of the examples in the above document using that mapping
Updating PM score.
(In reply to comment #1) > FYI, I think we can just use the test vectors from here: > http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf Unfortunately, none of the test vectors there can be used, as we've got a strict implementation limitation of an 11-byte nonce. The examples us 8, 9, 12 and 13. D'oh. I do have some vectors and known-good answers from the test lab, but it'd certainly be nicer if we could point to an authoritative location where we got test vectors. For the time being, I'll just toss some of those in and focus on the code to exercise them.
Ugh. This is turning out to be a bit more difficult than anticipated... The self-tests for rfc4309 currently can't run -- the self-test manages to get itself into a circular dependency lock-up, stalling out in crypto_larval_wait(). Still trying to debug.
So the self-tests run correctly on 2.6.30-rc1 + cryptodev-2.6 tree + a one-line fix to the try_then_request_module macro now, and the full self-tests patch has been submitted upstream. Now its on to some git bisection to try to figure out what change it was that got things working so we can back-port that to rhel5.
Need to submit an updated patch upstream still, based on some additional testing done locally. Good news is that I've finally actually got this working on a RHEL5 kernel too. Patches coming Real Soon Now(tm).
Upstream submission: http://lkml.org/lkml/2009/4/13/308
in kernel-2.6.18-144.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1243.html