Re: [Classpathx-crypto] on testing (long)

[Raif S. Naffah]

Casey Marshall wrote:
> On Sun, 23 Jun 2002, Raif S. Naffah wrote:
>
>
> > [...]
> >
> > i'd go with (c).
> >
> > * if we go with (b) or (c), how many hard-coded test vectors should we
> > use?  --all of them is out of the question because of size and speed.
> > theoretically one value should be enough, but 3 is more "re-assuring."
> >
> > * should there be any special criteria for selecting the agreed number
> > of test-vectors? or throwing a dice would suffice?
>
>
> I would go with (c), too. As far as the number of test cases to hard-code,
> I would recommend *at least* two of each of the monte-carlo tests, so there
> is at least one change of key. This is because if a test only does the
> first monte-carlo test, a problem with endianess *could* sneak by, since
> the all-zero key looks the same regardless of endianness (this did happen
> early on when I was working on the Serpent implementation, when I only
> checked the all-zero key).

good point!


> For the known-answer tests I would recommend using texts/keys where a bit
> is set somewhere in each byte/nybble/word, to try to cover a range, not
> just the first few.
>
> Other than that I would simply use a Comfortable Round Number.

let's say 5 values for each test, which makes a total of 30 --including 
the KAT ones.  the position of the bits for the latter, should be 
selected at random.


> > * once we have coded those TestOfxxx for our ciphers.  should we still
> > keep the selfTest() method in the API and implementations?
> >
> > in its actual form the setlfTest() for the ciphers only test for
> > symmetry, which may be true even for incorrectly implemented ciphers.
> > in other words it's almost useless!
> >
> > we should change it to either (a) something similar to the selfTest() of
> > hash algorithms, (b) something similar to the TestOfxxx discussed above
> > with some hard-coded test vectors, or (c) get rid of it altogether!
>
> I would go for encrypting a known text, comparing the ciphertext with a
> known answer, then decrypting it to see if it results in the plaintext.

so a symmetry test but with known values.  yup; sounds good.


how do you want to split the work?


cheers;
rsn