Are the Serpent Test Vectors incorrect? 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.
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!