# Bouncy jdk 1.51 Serpent KAT tests vs Nessie vectors

Having a little trouble getting Nessie vectors working with the Bouncy Castle SerpentEngine. Do the Nessie vectors require a mode or some pre-processing? Nessie Serpent 128, set 1, vector 0 reads:

key=80000000000000000000000000000000

plain=00000000000000000000000000000000

cipher=264E5481EFF42A4606ABDA06C0BFDA3D

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

Bouncy Castle SerpentTest.js, vector 10 reads:

key=80000000000000000000000000000000

plain=00000000000000000000000000000000

http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk15on/1.51/org/bouncycastle/crypto/test/SerpentTest.java#SerpentTest.0tests

Why the different expected output?

• Serpent-0 and Serpent-1? Nov 18 '14 at 1:15
• I thought it might be versioning, maybe changes made during AES.. but these are the vectors posted on the serpent homepage. I'll investigate tomorrow, compare to final submission.
– JGU
Nov 18 '14 at 1:33
• @owlstead Do you know where the Bouncy Castle vectors came from? Looks like the discrepancy may be due to a difference in s-box implementations.
– JGU
Nov 18 '14 at 1:55
• it could be that bouncy castle is using the AES submission bit ordering. the only reason the s-boxes would be different is if it is serpent-0, which uses DES s-boxes Nov 18 '14 at 5:08
• @John I couldn't find any other test vectors either, but I guess it is solved now... Nov 18 '14 at 8:41

Bouncy Castle seems to be using a reversed byte order for inputs and outputs when compared to NESSIE test vectors.

In order to replicate the NESSIE vector in Bouncy Castle, the order of all inputs and outputs needs to be flipped at the byte level, therefore the following results are given from a NESSIE compliant implementation (Set 1, Vector 120):

key =    00000000000000000000000000000080
plain =  00000000000000000000000000000000


Note the first key byte is now in the final position, and the ciphertext when reversed matches BC vector 10. Additionally if we perform a Monte Carlo test, the results should be similar:

Serpent Encryption, ECB Mode, 128-bit key

COUNT =      0
KEY =        d692af3ea36f5ef30de8c5eb79a8fb31
PLAINTEXT =  14f63ff537a39296008945f7125ea070
CIPHERTEXT = 2d74412f3d89016083c93b4d0fa553fc


These results match vector 14 in reverse byte order, using a 100 block loop test, the BC test does not seem to perform an outer key loop like other Monte Carlo test implementations, such as NIST CAVP. The CAVP MCT performs 100 outer key loops with 1000 inner block loops for testing AES implementations. If continued, next iteration in the key loop would be as follows:

COUNT =      1
KEY =        fbe6ee119ee65f938e21fea6760da8cd
PLAINTEXT =  2d74412f3d89016083c93b4d0fa553fc
CIPHERTEXT = 4597017beb21a4c6c75acb85ac4645f7

• Send a mail to one of the BC maintainers... Nov 18 '14 at 8:40
• as per user13484's answer, it want matter. however, if you look at their code, their counters go in reverse, and they use word to byte conversions which reverse the byte order. NESSIE implementations count foreward, and can treat byte arrays as word arrays, leading to better performance and less potential leakage. Nov 18 '14 at 10:42
• I added the Array.Reverse step to key, plain and ciphertext, and now results are aligning.. thanks for the insight
– JGU
Nov 18 '14 at 17:55
• how can I reverse using CBC encoding? Aug 14 '15 at 23:32

Important Change, 23rd November 2015