# Is the DES algorithm in OPENSSL random?

Look at the hex dumps of encrypted1.bin and encrypted2.bin . They both have same password A which was used to encrypt sampletext

[achilles:~/Arena/crypto] $openssl enc -e -des -in plaintext -out encrypted1.bin enter des-cbc encryption password: Verifying - enter des-cbc encryption password: [achilles:~/Arena/crypto]$ openssl enc -e -des -in plaintext -out encrypted2.bin
Verifying - enter des-cbc encryption password:


So both are encrypting the same text with the same password. Now when I hexdump them I get

[achilles:~/Arena/crypto] $hd encrypted1.bin 00000000 53 61 6c 74 65 64 5f 5f 50 cc a6 a8 6f 52 cf 53 |Salted__P...oR.S| 00000010 c7 8e 71 ea 98 4b 2a 8c a1 4d bd 0f d0 90 62 cb |..q..K*..M....b.| 00000020 b1 a0 7a ef b5 a8 c1 14 |..z.....| 00000028 [achilles:~/Arena/crypto]$ hd encrypted2.bin
00000000  53 61 6c 74 65 64 5f 5f  0c c2 44 d0 19 bb a9 5e  |Salted__..D....^|
00000010  af 56 24 ce b3 b4 30 4f  61 1c f4 ba bd fc 1d a7  |.V\$...0Oa.......|
00000020  b4 99 77 b9 1c 15 8a 42                           |..w....B|
00000028


How is this possible? How can the hexdump completely vary for the encryption of the same plain text with the same password and same algo (DES). And when encrypted1 and encrypted2 are decrypted they give me back the SAME plain text?

-
If you're just asking out of curiosity, great. But you should never, ever, ever use DES for any practical application. It is absolutely 100% broken. Use AES if this is for anything other than toying around. – Stephen Touset May 10 '13 at 17:21
@StephenTouset I wouldn't say "absolutely 100% broken", just "can be bruteforced in a reasonable time by attackers with some recources". And this is mainly because of the small effective key size of 56 bits. It would be broken when there were much faster attacks than that. Or did I miss some new developments in cryptanalysis of DES? (But still, don't use DES nowadays.) – Paŭlo Ebermann May 10 '13 at 17:40
You're correct that it isn't broken in a cryptanalytic sense. It's just that 56 bits is well within brute force range of even rank amateurs, which for all practical purposes is totally broken. A 56 bit key was brute forced in 1998 on a single desktop computer in a little over two days. Given the advances in hardware, I can't imagine a DES key would last more than a few hours at most against an average modern laptop. – Stephen Touset May 10 '13 at 17:44

Using the -k option, you can specify a password. Passwords are not really encryption keys, so OpenSSL uses a key derivation process to turn the password into an encryption key. It turns out by default OpenSSL uses a salt in that derivation process (which is why you see Salted__ in the output, which is a magic to indicate that the next 8 bytes are the randomly generated salt). The ciphertext only starts from byte 16 onwards.

If the salt changes, the encryption key changes. If the encryption key changes, the ciphertext changes. By default OpenSSL generates a new random salt every execution. That is why you are seeing the changing ciphertext.

To turn this off you can add -nosalt. This is fine for testing purposes. As stated in the OpenSSL docs "This option SHOULD NOT be used except for test purposes or compatibility with ancient versions of OpenSSL and SSLeay". Otherwise your ciphertext is deterministic which can lead to cryptanalysis and a broken (i.e., insecure) system.

Alternatively -K lets you directly specify a key value in hexadecimals, skipping the (OpenSSL specific) password key derivation - and therefore the salt generation - entirely. You also need to specify the IV using -iv in that case. The IV should be random to achieve security in CBC mode if the key is reused, but the generation of the IV is left to the user.

-
Cleaned up some comments from a previous version of answer. Thanks @StephenTouset for pointing out my flaw. – mikeazo May 10 '13 at 17:46
If there is such a RANDOM salt added then how is possible to revert the whole cipher. Does the cipher have info about that RANDOM salt ??? – vikkyhacks May 10 '13 at 18:06
@vikkyhacks, I haven't looked at the code, but I imagine that the first few bytes immediately after SALTED_ in the ciphertext is the salt. – mikeazo May 10 '13 at 18:09
Well what is the point of adding the salt in such way which can be easily identified. I mean if I have to bruteforce can I not copy the salt and the key to get that SAME ciphertext. What's the point in adding such salt ??? – vikkyhacks May 10 '13 at 18:31
@vikkyhacks,Depending on your application, hiding the salt (much like hiding an IV or nonce) is unnecessary. The salt ensures the key is different from execution to execution making it such that the ciphertext is different even for the same plaintext/password. See also. – mikeazo May 10 '13 at 18:35