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
On Fri, Feb 11, 2011 at 11:07 AM, Niels Möller nisse@lysator.liu.se wrote:
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.
I'am just repeating myself and might become annoying... but does it really worth the time? Is there anyone using that algorithm, or anyone planning to use it? As it stands now serpent is an academic cipher, it is not used in any protocol.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
As it stands now serpent is an academic cipher, it is not used in any protocol.
It's specified as an optional algorithm in the ssh protocol (see RFC 4253 and RFC 4344).
That said, I think the main use for serpent or any other of the losing aes finalists are as backups in case some serious problem is discovered with aes.
Regards, /Niels
On Fri, Feb 11, 2011 at 12:11 PM, Niels Möller nisse@lysator.liu.se wrote:
As it stands now serpent is an academic cipher, it is not used in any protocol.
It's specified as an optional algorithm in the ssh protocol (see RFC 4253 and RFC 4344).
Ah, I didn't know that.
That said, I think the main use for serpent or any other of the losing aes finalists are as backups in case some serious problem is discovered with aes.
Nowdays this is also camellia for that purpose...
regards, Nikos
On 02/11/2011 05:39 AM, Nikos Mavrogiannopoulos wrote:
I'am just repeating myself and might become annoying... but does it really worth the time? Is there anyone using that algorithm, or anyone planning to use it? As it stands now serpent is an academic cipher, it is not used in any protocol.
I know people who use serpent with Linux's dm-crypt for encrypted block devices. It's not entirely academic. having multiple implementations of serpent would be a Good Thing.
--dkg
nisse@lysator.liu.se (Niels Möller) writes:
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),
I have checked that now. I downloaded and unpacked the submission package http://www.cl.cam.ac.uk/~rja14/Papers/serpent.tar.gz
Test vectors are in the floppy4 directory. In floppy4/ecb_vk.txt, the first test vector is
KEYSIZE=128
PT=00000000000000000000000000000000
I=1 KEY=80000000000000000000000000000000 CT=49afbfad9d5a34052cd8ffa5986bd2dd
and in floppy4/ecb_vt.txt the first text vector is
KEYSIZE=128
KEY=00000000000000000000000000000000
I=1 PT=80000000000000000000000000000000 CT=10b5ffb720b8cb9002a1142b0ba2e94a
These are the first two testvectors in nettle's serpent-test.c.
On the other hand, the file
http://www.cs.technion.ac.il/~biham/Reports/Serpent/Serpent-128-128.verified...
contains the testvector
Set 2, vector# 0: key=00000000000000000000000000000000 plain=80000000000000000000000000000000 cipher=A3B35DE7C358DDD82644678C64B8BCBB decrypted=80000000000000000000000000000000 Iterated 100 times=1DDF9883B4663045753758E0B9B2C09B Iterated 1000 times=BE5AE44A1CF1BB86DD7A3B61CEEA01EC
Same inputs as in ecb_vt.txt, but different output.
What results do you get with libgcrypt for the above two test vectors?
I think I have to mail the authors...
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
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 don't know, I suspect it is serpent-0 but haven't confirmed it.
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?
I see it, maybe there is some caching?
If you have a half-done port of libgrypt's serpent code, maybe you or I could finish it?
Sure! I suspect everything except the key schedule is working in my port. Should I try to make it compatible with libgcrypt, and presumably Serpent-1? Thus modifying serpent-test.c? I'll send a patch later.
/Simon
Simon Josefsson simon@josefsson.org writes:
Should I try to make it compatible with libgcrypt, and presumably Serpent-1?
It ought to be serpent-1, the algorithm proposed for AES. RFC 4344 references the algorithm like this:
[SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998.
Thus modifying serpent-test.c? I'll send a patch later.
I've already checked in a few new test cases in serpent-test.c (taken from http://www.cs.technion.ac.il/~biham/Reports/Serpent/), but #if:ed out for now.
I'd also like to hear what response we get from the serpent people regarding conflicting test vectors, it seems so strange if the test vectors in the aes submission were broken.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
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.
The files defining these testvectors use an input and output format with bytes in the reverse order. At the time (2001-06-17, almost ten years ago), I thought this reversal was part of the cipher operation, rather than a peculiarity with test programs and test vectors in the serpent submission package, and incorrectly added byte reversal to the functions in serpent.c.
I've now reverted this old change, which means that from now on serpent in Nettle ought to agree with other implementations. And this naturally also breaks compatibility for anyone using the serpent implementation of all (or almost all) earlier versions of Nettle.
I've fixed the serpent-test.c to reverse inputs and outputs for the testvectors copied from the serpent submission package, and added a few additional test vectors (from http://www.cs.technion.ac.il/~biham/Reports/Serpent/) using a sane byte order.
Credits go to Eli Biham and Lars Knudsen for finally putting me on the right track.
Regards, /Niels
On 04/15/2011 09:13 PM, Niels Möller wrote:
[...]
I've now reverted this old change, which means that from now on serpent in Nettle ought to agree with other implementations. And this naturally also breaks compatibility for anyone using the serpent implementation of all (or almost all) earlier versions of Nettle.
Would this mean that nettle is now compatible with the libgcrypt version of serpent? In that case would the LGPL libgcrypt code be used instead?
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Would this mean that nettle is now compatible with the libgcrypt version of serpent?
That's the idea.
In that case would the LGPL libgcrypt code be used instead?
Simon said he was working on that. I don't know current status, so I figured it was good to fix the old Nettle code too (it turned out to be easy).
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Would this mean that nettle is now compatible with the libgcrypt version of serpent?
That's the idea.
In that case would the LGPL libgcrypt code be used instead?
Simon said he was working on that. I don't know current status, so I figured it was good to fix the old Nettle code too (it turned out to be easy).
I'll resume my work -- I recall that I got it to a stage where it built and generated ciphertext, however it didn't match the test vectors that were in Nettle back then. Hopefully it will match now, and I can submit the patch shortly.
/Simon
nettle-bugs@lists.lysator.liu.se
-
Daniel Kahn Gillmor -
Nikos Mavrogiannopoulos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se -
Simon Josefsson