# Discrepancy between 3DES in OpenSSL and PyDES [closed]

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")

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?

## closed as off-topic by fgrieu, Maarten Bodewes♦, e-sushiFeb 19 '18 at 17:54

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm, protocol or side-channel (mitigation) works, you should look into asking on Stack Overflow instead." – fgrieu, Maarten Bodewes, e-sushi
If this question can be reworded to fit the rules in the help center, please edit the question.

• That's off-topic, because it is about idiosyncrasies of two particular pieces of code. That said: 1) you use password-to-24-byte-key derivation in OpenSSL, and 24-(was-8)-byte-key-in-ASCII in python; try using -K rather than -pass; make the key hex in Pyhton; and use the same size (24-or-is-it-16 bytes, twice as many hex chars). 2) the result you get with OpenSSL is 16-byte, twice the blocksize of DES, and it suggests a header or/and padding when none is wanted; perhaps adding -nopad to the openssl options would fix that? – fgrieu Feb 19 '18 at 14:09
• @fgrieu Thank you, apparently -K handles the input differently. The actual C API produces the expected results. – Jaciq Feb 19 '18 at 16:38
• Just got the result you will like using openssl enc -des-ede3-cbc -K 616263646566676831323334353637386162636465666768 -iv 0000000000000000 -in kcvin.dat -out kcvout.dat, except that it is too long by 8 bytes of course. You can use dd to create the 8 byte zero input and of course copy out the 8 bytes required. PS use hexdump instead, that crappy hex output has little endian encoding. – Maarten Bodewes Feb 19 '18 at 17:14
• @fgrieu Per this recent meta discussion, I'm voting to leave this question open. It's a programming question, true, but it's about a cryptographic aspect (as opposed to being a debugging question where cryptography is incidental). – Gilles Feb 19 '18 at 17:30
• @MaartenBodewes: xxd output is default grouped by 2 (-g1 to fix) but never little-endian; it is od -x (or od -tx{otherthan1}) that is platform-endian which is little-endian on x86[-64] and some others. As fgrieu said, enc -nopad avoids the extra block=8bytes. ECB (and not CBC) is correct for a KCV, though not for anything else except possibly keywrap. – dave_thompson_085 Feb 20 '18 at 1:20

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.

• KCV is a hack that isn't really encrypting data and is implemented as ECB, although it's better to use key management that properly protects the key(s) so that KCV isn't needed at all. – dave_thompson_085 Feb 20 '18 at 1:25