0
$\begingroup$

I do the following via the Linux CLI:

printf '\xff\xff\xff\xff\xff\xff\xff\xff' > plaintext.txt
openssl enc -bf-ecb -e -in plaintext.txt -out ciphertext.txt -nosalt -K FFFFFFFFFFFFFFFF -p

I then read the contents of ciphertext.txt with <?= bin2hex(file_get_contents('ciphertext.txt')); ?> and I get this:

5aacfb5a8dc0155dd0269124c9e81789

According to https://www.schneier.com/code/vectors.txt, however, the result is this:

51866fd5b85ecb8a

That ciphertext.txt is twice as long as the test vector result makes sense because of padding. But shouldn't the first eight bytes of ciphertext.txt match the test vector?

Doing the above with des-ecb (same plaintext and same key) gives the same output that https://www.cosic.esat.kuleuven.be/nessie/testvectors/bc/des/Des-64-64.test-vectors mentions (Set 3, vector#255) so it seems like my test methodology is correct.

Any ideas?

$\endgroup$

1 Answer 1

2
$\begingroup$

The -bf-ecb cipher is expanding the key to 128 bits by zero extending it.

The output from -p is the telltale here:

$ openssl enc -bf-ecb -e -in plaintext.txt -out ciphertext.txt -nosalt -K FFFFFFFFFFFFFFFF -p
key=FFFFFFFFFFFFFFFF0000000000000000

Blowfish is defined for 32-448 bit keys, and it appears the OpenSSL implementation chose 128 bits as the size to use, and added zero-extension of shorter keys as a 'convenience'.

Compare this with -des-ecb, where DES is only defined for 64 bit keys:

$ openssl enc -des-ecb -e -in plaintext.txt -out ciphertext-des.txt -nosalt -K FFFFFFFFFFFFFFFF -p
key=FFFFFFFFFFFFFFFF
$\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.