TransWikia.com

Are the Serpent Test Vectors incorrect?

Cryptography Asked on November 11, 2021

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.

One Answer

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!

Answered by toothandsticks on November 11, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP