[patch] Add tests for NIST CAVP hash tests
bradh at frogmouth.net
Tue Jun 9 11:45:39 CEST 2009
On Tuesday 09 June 2009 03:30:02 am Werner Koch wrote:
> On Mon, 8 Jun 2009 13:00, bradh at frogmouth.net said:
> > The attached patch adds a test generator (in python) that uses the NIST
> > CAVP Secure Hash Standard (SHA1, SHA2) test cases. The tests are 2.7M
> > (zipped) and
> Hmmm, did you missed that we have a full CAVS test suite in Libgcrypt?
> The driver script tests/cavs_test.sh has instructions on how to run the
> test. As input you need the REQ files and it will generate and zip the
> RSP files. The interface between the script and libgcrypt is
> tests/fipsdrv.c .
I see these activities as complementary. The tests/cavs_test.sh (and
associated driver code) are for running a CAVS test (i.e. producing a .resp
from a .req). The python code I submitted is when you don't have such a .req.
It checks the samples provided by NIST.
> A script to generate the input data and another one to check
> the response might be useful, however we can also use a fixed set of
> files and put them on ftp.gnupg.org. I can check whether the set I use
> can be made public. What is missing is the code to check the response.
I agree, except you don't need to provide them on ftp.gnupg.org - they are
already available from NIST. The generator script makes an application that
creates a set of requests and responses - I just encode them in C structures
rather than have to write them out and parse them back in.
> BTW, I'd like to avoid yet another script language because we already
> have AWK (which is POSIX) and Perl.
I can appreciate that. Unfortunately I don't know either :-(
If I had a set of test vectors to use (e.g. if you could share the test
vectors from NIST CST that you got, even if they aren't made totally public)
perhaps I could rewrite the test driver. That could also eliminate the need
for unpacking the tests in the correct directory structure, and also the need
for the zip utility.
Note that the goal here isn't really hashing. That was just something I did to
de-risk a possible future implementation (where I don't have tests or
implementation) - GCM.
More information about the Gcrypt-devel