1
$\begingroup$

I have recently written an implementation of Serpent and was testing it against known vectors to no avail. Using 256-bit key, I compared my encryption to the test vectors located here:

http://www.cs.technion.ac.il/~biham/Reports/Serpent/Serpent-256-128.verified.test-vectors

For some reason, I match none of these test vectors, and I do not know why. I downloaded the Python implementation found here:

https://www.cl.cam.ac.uk/~fms27/serpent/serpent.py.html

The Python implementation agreed with me and disagreed with the published test vectors. I did, however, find two files in folder Floppy 4 (ecb_tbl.txt) and (ecb_iv.txt) from the full submission package (http://www.cl.cam.ac.uk/~rja14/Papers/serpent.tar.gz) which I completely agree with. If I put in the given 256-bit key and the given plaintexts, I do achieve the correct encrypted ciphertexts.

Are the test vectors published on biham's website incorrect, or is there perhaps something I am missing? If they are wrong, why are they still up and way easier to find than the ones I matched with?

As an example, on Biham's site,

key=8000000000000000000000000000000000000000000000000000000000000000 plain=00000000000000000000000000000000
cipher=A223AA1288463C0E2BE38EBD825616C0

But both my implementation and the Python reference implementation give:

cipher=abed96e766bf28cbc0ebd21a82ef0819

I think it has something to do with this NESSIE format, but so far, I have been unable to determine if that is true and what exactly that means.

Improve this question
$\endgroup$
5
  • $\begingroup$ According to this, there are two versions of Serpent. It seems that your test vectors are for Serpent-1, and it could be that your code is for Serpent-0. The changes are in the key schedule, so that would explain why you get correct results for the all-zero key, but not others. I do not make it an answer, because I'm far from sure. $\endgroup$
    – fgrieu ♦
    Commented Jul 21, 2020 at 18:58
  • $\begingroup$ Thanks for the feedback on this, but I already considered it. My code is not for Serpent-0. I checked this by using the original Python implementation of Serpent-0 and found it gives completely different ciphertext than the Serpent-1 reference, which I am checking my implementation against. The Serpent-0 ciphertext does not match any of the available test vectors I have found, even the ones I noted that I match above using my implementation. $\endgroup$
    – toothandsticks
    Commented Jul 21, 2020 at 21:15
  • 1
    $\begingroup$ probable duplicate of crypto.stackexchange.com/questions/20306/… $\endgroup$
    – Richie Frame
    Commented Jul 23, 2020 at 2:30
  • $\begingroup$ Does above link answer your question, and if it doesn't, can you please indicate what's missing from the answer? I read everything in full, and it does seem to come down to the same thing. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 25, 2020 at 22:11
  • $\begingroup$ Actually, it kind of does. Why the heck does NESSIE have a flipped byte order? I ran the key 0000000000000000000000000000000000000000000000000000000000000080 (flipped byte order) and got the ciphertext above but also in flipped byte order. $\endgroup$
    – toothandsticks
    Commented Jul 26, 2020 at 21:01

1 Answer 1

Reset to default
1
$\begingroup$

Thanks to Richie Frame pointing out this is basically a duplicate of question

Bouncy jdk 1.51 Serpent KAT tests vs Nessie vectors

I discovered the NESSIE writes their key, plaintext, and ciphertext test vectors for Serpent in reversed byte-order (but it's not little endian inside the bytes). So, on Biham's site, https://www.cs.technion.ac.il/~biham/Reports/Serpent/Serpent-256-128.verified.test-vectors , the first test vector,

key=8000000000000000000000000000000000000000000000000000000000000000 plain=00000000000000000000000000000000
cipher=A223AA1288463C0E2BE38EBD825616C0

only works if I use my implementation in reverse byte order; that is, I have to input the key:0000000000000000000000000000000000000000000000000000000000000080,

and I get the above ciphertext in reverse byte order:

cipher: c0165682bd8ee32b0e3c468812aa23a2

Verifying this with set 3, vector 130:

key= 8282828282828282828282828282828282828282828282828282828282828282
plaintext = 82828282828282828282828282828282
ciphertext= AAA92B00896FE228BDF5AA3BA534CA44

Since the key and plaintext are reversible by byte order, I can put this key and plaintext in and expect the ciphertext in reverse byte order. My implementation yields:

44ca34a53baaf5bd28e26f89002ba9aa.

This checks out!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.