0
$\begingroup$

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.

online-domain-tools result

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

Improve this question
$\endgroup$
5
  • 5
    $\begingroup$ 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? $\endgroup$
    – fgrieu ♦
    Commented Feb 19, 2018 at 14:09
  • $\begingroup$ @fgrieu Thank you, apparently -K handles the input differently. The actual C API produces the expected results. $\endgroup$
    – Jaciq
    Commented Feb 19, 2018 at 16:38
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 19, 2018 at 17:14
  • $\begingroup$ @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). $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Feb 19, 2018 at 17:30
  • $\begingroup$ @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. $\endgroup$
    – dave_thompson_085
    Commented Feb 20, 2018 at 1:20

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – dave_thompson_085
    Commented Feb 20, 2018 at 1:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.