classpathx-crypto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Classpathx-crypto] on testing - today and tomorrow


From: Raif S. Naffah
Subject: [Classpathx-crypto] on testing - today and tomorrow
Date: Sun, 30 Jun 2002 00:21:37 +1000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530

A. where we're at
-------------------

earlier i wrote:
> ...
> test.cipher.TestOfSerpent is a model for testing a cipher's correctness...

today's checkin concludes that part which leaves the library in the
following state:

* hash and cipher algorithms have a selfTest() method which is
guarranteed to be called by the respective Factories when asked to
provide a specific implementation.

* the selfTest() method when invoked for the first time, compares the
result of processing a designated input against a knwon pre-computed
output value.  when the two values agree, a "validity" flag is set to true.

* the cached value of the validity flag is re-used in recurrent invocations of the selfTest() methods.

* all the TestOfxxx cipher test-cases now follow a similar pattern which consists of:

   a. test the validity;
   b. test the cloneability;
   c. run 5 tests each of KAT VK, VT, MCT ECB Encryption and
      Decryption for one block size and each key-size in the set
      formed by the intersection of (i) the cipher's supported key
      sizes and (ii) the set of the following 3 values: 128, 192
      and 256.

* in addition, the top-level test harness, runs a general verification test if previously generated test vectors are found in a pre-deisngated location (tv/nist/...). this test assumes the input test vector files follow a naming and have a specific format described by NIST --and hence may have been generated by 3rd parties using other tools than this library.

* the NIST tools, have been changed to allow generation of similar test vector files.


B. where do we go from here
-----------------------------

1. review the hash TestOfxxx and see if a similar pattern can be applied and/or is it worth it.

2. include in the build process the generation, in a separate jar, of the (at least) the NIST test vectors.

3. ensure that all the build tools (ant, top-level make, and preferably automakejar, as well as gcj/make):

   a. run the same tests,
   b. build the same deliverables.

ant's build.xml should be the reference.


once this list is done then we're ready for the first public release.


C. what's next for the near future
------------------------------------

1. do we go for the signed test-vector jars?
2. do we (PGP) sign our distribution?
3. can we get the library integrated with the gcj release --from Olivier's tests it sounded like our JCE adapters fill a missing niche in their distribution?


D. what's next for the medium-term future
-------------------------------------------

1. start the adapters for the javax.security SPIs.
2. what to do with ASN.1 related stuff?
3. work out a process for selecting new algorithms to implement.


comments, suggestions, volunteers are more than welcome ;-)


cheers;
rsn




reply via email to

[Prev in Thread] Current Thread [Next in Thread]