Mailing List Archive

On Mon, 8 Jun 2009 13:00, bradh@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?
Libgcrypt 1.4.4 actually passed the entire test suite (hash, cipher
pubkey random). If you look at the NIST database you will find an entry
for 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 .

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.

BTW, I'd like to avoid yet another script language because we already
have AWK (which is POSIX) and Perl.


Shalom-Salam,

Werner



--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Tuesday 09 June 2009 03:30:02 am Werner Koch wrote:
> On Mon, 8 Jun 2009 13:00, bradh@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?
No.

> 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.

Brad

Brad

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel