Re: [Classpathx-crypto] [patch] Serpent cipher

[Raif S. Naffah]

hello Casey,

my comments are in-lined below.


cheers;
rsn
----- Original Message -----
From: "Casey Marshall" <address@hidden>
To: "Raif S. Naffah" <address@hidden>
Cc: <address@hidden>
Sent: Friday, June 07, 2002 8:45 AM
Subject: Re: [Classpathx-crypto] [patch] Serpent cipher


> On Thu, 6 Jun 2002, Raif S. Naffah wrote:
>
> > btw, do you have (access to) the test vectors for Serpent?  we should
have a
> > junit test case to exercise and produce/compare some of the test vectors
for
> > every algorithm so as to certify correctness (e.g.
> > source/test/cipher/TestOfSquare).
> >
>
> Earlier today I generated some KAT and Monte-Carlo test vectors and
> compared them to those included in the Serpent team's AES submission.
> The implementation appears correct (at least, my faith in it is a bit
> stronger). I'll see about putting together a test case for it, however.

thanks again :-)


> Also, a question: it appears as though the library is working with the
> assumption that all of its ciphers are not stateful, ie something like:
>
> cipher.encryptBlock(pt, 0, ct, 0);
> cipher.decryptBlock(ct, 0, cpt, 0);
>
> will result in pt==cpt (and this is the case, I think, with all the
> current cipher algorithms, as well as most others that I'm familiar with).
> This isn't strictly true...

this is always true with symmetric key block ciphers.

>..., for example, for ARCFOUR, whose s-boxes evolve
> over time. So would stateful ciphers need to be careful about this (e.g.
> keeping s-boxes for encryption and decryption), or could one assume that
> this is not, in practice, the case?

the thing to clarify here is that:

a. both types of ciphers are stateful, yet
b. one type (the symmetric-key block-ciphers eg. aes, rijndael, serpent, and
all gnu.crypto.cipher classes) is invertible, while the other (not yet
implemented in gnu.crypto) is not.


> (Bonus: yes, ARCFOUR is a stream cipher, so would a seperate interface
> (IStreamCipher) be a solution?)

yes! as far as i know, it's the only solution.

for other types of stream ciphers, have a look at some newly designed stream
ciphers, submitted in the NESSIE project --see
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions.html.


>
> Cheers,
>
> --
> Casey Marshall < address@hidden > http://metastatic.org/
>
>
>
> _______________________________________________
> Classpathx-crypto mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpathx-crypto
>