Simon Josefsson simon@josefsson.org writes:
nisse@lysator.liu.se (Niels Möller) writes:
Maybe you can try adding some of the testvectors at http://www.cs.technion.ac.il/~biham/Reports/Serpent/ to nettle and libgcrypt, and see what happens? (On the nettle side, I'll try to give that a reasonably high priority).
As you noted privately, they fail in nettle but work in libgcrypt.
A while ago, the email masquerading setup was broken on the machine where I write email. Because of this, the invalid adress nettle-bugs@lysator.liu.se has appeared in headers of some of my emails, and then copied into replies to those. The correct address is nettle-bugs@lists.lysator.liu.se.
According to Eli's page and the AES submission paper, there is Serpent-0 and Serpent-1 and the paper discuss (page 22-23) that the key schedule has changed.
Do you think nettle's implementation is serpent-0, or is it just broken? I'm puzzled, because I'm fairly sure I got the test vectors from serpent's submission package (I could try to double check that), which if I understand correctly ought to be serpent-1. I vaguely remember I had some difficulty understanding the organization of the test data, though.
And I'm sorry if you have wasted some time debugging fully correct key scheduling.
I updated the wikipedia article on this: http://en.wikipedia.org/wiki/Serpent_%28cipher%29
Hmm, I can't find any mention of serpent-0 there?
Still, I'm not sure it is worth the time to fix Serpent in Nettle. I suggest to remove it, that will save some code size as well.
It's clearly no use to keep the current broken implementation. But I think it would be nice to have serpent, for a couple of reasons:
* It's generally good to have a couple of ciphers with aes-compatible key and block sizes. Besides aes/rijndael and serpent, there's twofish and camellia.
* I'm not sure what performance one can get out of serpent compared to aes, in particular on 64-bit processors. AES doesn't fit well with 64-bit operations, camellia is better in that respect but includes some awkward operations (current 64-bit code could perhaps be improved abit using larger tables).
* I'd prefer to not remove existing features.
If you have a half-done port of libgrypt's serpent code, maybe you or I could finish it?
I'll start by looking into the test vectors, I'd like to figure out where nettle's came from, and I'd like to have a serpent-test.c including correct test vectors, even if we end up removing all other serpent code.
Regards, /Niels