Discrepancy between 3DES in OpenSSL and PyDES

Question

I'm trying to encrypt some data using triple DES ECB, but I get a discrepancy between OpenSSL and the pyDES library I'm using.

When trying to get a KCV value, I'm using a file consisting of 8 bytes each with value 0.

I'm using the following OpenSSL command (des-ede3 chosen based on this):

openssl enc -des-ede3 -pass pass:abcdefgh12345678abcdefgh -in empty8.bin -nosalt | xxd

which results in:

00000000: 17f7 b498 bd79 4d55 5e40 aa9c 2907 44bb  .....yMU^@..).D.

I'm using the following Python script, based on this question:

import binascii
import hashlib
import base64
from pyDes import *

key = 'abcdefgh12345678abcdefgh'

fileInput = open("empty8.bin", "rb")
data = fileInput.read()

print('key: ' + str(key))

k = triple_des(key, ECB)
d = k.encrypt(data)

print('KCV: ' + str(binascii.hexlify(d)[0:8]))

which results in:

key: abcdefgh12345678abcdefgh
KCV: b'37c92746'

I've also tried using http://online-domain-tools.com/ for a reference, which gives the same result as the Python code.

Can anyone offer any insights into why OpenSSL produces a different result?

Answer 1

In Python and on that website, you're entering a key. A 3-DES key consists of 24 bytes. You picked a key that's some nice printable text, but a key in general is binary, randomly generated.

With the OpenSSL command line, you're supplying a password (or passphrase, the two words are synonyms). A password is not a key: it's typically not fully random, consists only of printable characters, can have any length, ...

OpenSSL uses a key derivation mechanism to calculate a key from that password. To generate a key from a password, you need to perform stretching and randomize the process with a salt, which OpenSSL does, although not very well.

To get the same result with openssl en, tell it that you're supplying a key, with the -K option.

Generally speaking, the openssl command line is more of a demonstration tool than a tool for serious usage. This is especially true of commands like enc. Don't expect things to be secure unless you have a very precise of what you're doing.

In any case...

triple DES ECB

Hopefully this is for learning purposes, and even then, neither 3DES nor ECB have any advantage for learning. 3DES is an obsolete algorithm with no benefit over the modern standard AES or modern alternatives such as Camellia and ChaCha20. ECB is not really a proper mode, it's “don't bother with a proper mode”, and it isn't secure (so why bother encrypting?). Use a mode such as CTR or CBC for encryption (and learn to use an IV, which is necessary for any mode), or a mode such as GCM or CCM for authenticated encryption.