Subject: [Classpathx-crypto] TestOfSerpent

From: Casey Marshall <[email-masked]>
Date: Sat, 8 Jun 2002 16:36:49 -0700 (PDT)

As promised, attached is a pared-down version of a test suite for
Serpent. It runs all the variable-key and variable-text known-answer
tests, and the first ten of each of the monte carlo tests provided in
the Serpent team's submission. It also runs the BaseCipher's default
symmetry test.

This version comes from a test suite that tests all known-answer and all
monte carlo tests -- which seemed a bit excessive. It is available at:

	http://www.metastatic.org/src/serpent-test-full.tar.gz

It is 117 kilobytes compressed, and is slow.

I figured that this version provided a good enough compromise, and can be
trimmed even further by simply deleting answers from the bottoms of the
test arrays.

If GNU's mailing lists (or you) do not like attachments, the trimmed
version can also be found at:

	http://www.metastatic.org/src/serpent-test.tar.gz

Cheers,

-- 
Casey Marshall < [email-masked] > http://metastatic.org/
Also: regular expressions are fun.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 09 Jun 2002 10:18:21 +1000

hello Casey,

> the Serpent team's submission. It also runs the BaseCipher's default

that's simply beautiful.  i think all cipher test cases should follow 
this model.

> It is 117 kilobytes compressed, and is slow.

is this the inverse of the NistKAT and NistMCT (in gnu.crypto.tools) tools?

since we will be using code from these tools for the test cases, should 
we look into re-factoring that code to improve code re-usability across 
the library?

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 09 Jun 2002 10:34:44 +1000

i've committed to the cvs in the last few days the following:

1. Casey Marshall's contribution of Serpent and its test case;

2. a new package gnu.crypto.mac that includes:

* HMAC implementation that allows constructing the HMAC over all 
implemented (now and in the future) hash algorithms (in gnu.crypto.hash),

* UMac32 and UHash32 as described in Krovetz & al. submission to the 
NESSIE --which is also an IETF draft,

3. OFB block cipher mode of operations as described in NIST's 
recommendations;

4. a new UMacGenerator pseudo-random number generator, described in 
Krovetz & al. paper using the AES;

5. updated the home page to reflect the new additions;

6. added Casey to the list of AUTHORS;

7. updated the GNU build-related files in the top level as well as in 
gcj/ and gcj/source --i finally was able to run aclocal, autoconf and 
automake using the cygwin distribution.  pls note that automake (on my 
cygwin installation is 1.6.1 which required me to change some of the 
files that were failing cause were relying on version 1.6a.  if this 
causes others build envs to break, then raise your hand.

8. removed some NIST MCT test cases for Anubis with key sizes > 256.

9. removed superfluous characters from some source files that were 
causing some interpreters to barf.

things remaining for the first public release are:

* an implementation of the UST (David McGrew's IETF draft),
* re-visiting of the test hierarchy and -may be- re-factoring of some 
gnu.crypto.tool classes,
* consensus on the effectiveness of both ANT and GNU build-related tools.

cheers;
rsn

---

From: Nic Ferrier <[email-masked]>
Date: 09 Jun 2002 15:05:36 +0100

> causes others build envs to break, then raise your hand. 

Did you look at the automakejar stuff? It has been recieved with
enthusiasm on other GNU java projects and hopefully will become
something of a standard for us.

I put an example tar in the classpathx ftp dir.

Nic

---

From: Casey Marshall <[email-masked]>
Date: Sun, 9 Jun 2002 12:42:10 -0700 (PDT)

> is this the inverse of the NistKAT and NistMCT (in gnu.crypto.tools) tools?

After a fashion, yes.

> we look into re-factoring that code to improve code re-usability across

It did not even occur to me to use that code; I like this idea, however
--- one could envision a point where writing a full-conformance test for
a particular algorithm would amount to simply including the appropriate
test vectors and pointing the program at them. It seems smarter than
keeping large, static String arrays.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Mon, 10 Jun 2002 12:24:46 +1000

hello Nic,

trying to use this failed last time i tried it --see my previous post 
dated 25/4.

cheers;
rsn

Nic Ferrier wrote:
> _______________________________________________
> Classpathx-crypto mailing list
> [email-masked]
> http://mail.gnu.org/mailman/listinfo/classpathx-crypto
> 
> .
>

---

From: "Raif S. Naffah" <[email-masked]>
Date: Mon, 10 Jun 2002 12:36:49 +1000

Casey Marshall wrote:
> [...]

absolutely.  Nistxxx tools _emit_ the test vectors, but they also 
include the code to verify the inverse operation of what they generate.

re-factoring that code and re-using your patterns (from TestOfSerpent) 
would allow:

a. ending up with new tools (or added functionality to the existing 
ones) that _read_ the conformance test vectors and verify them, this 
time instead of _writing_ them out.

b. exposing some methods in these tools, or have'em all use common 
Helper(s) to do their job and making writing TestOf<block-ciphers> as 
simple as feeding the test-case a collection of files (or a directory 
where those files would be found).

does this make sense?

cheers;
rsn