Simon Josefsson <[email protected]> writes: > [email protected] (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 [email protected] has appeared in headers of some of my emails, and then copied into replies to those. The correct address is [email protected]. > 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
