Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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
enter des-cbc encryption password:
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?

share|improve this question
    
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
1  
@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
add comment

1 Answer 1

up vote 7 down vote accepted

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.

share|improve this answer
1  
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
1  
@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
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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