Using CryptoJS 3.1 I noticed that using 3Des, the encrypted message always start with


Why is the first part of the encryption always the same?

What information does this hold and how does that information become U2FsdGVkX1?

  • 7
    $\begingroup$ Your question aside, the fact that the default, easiest way of using block ciphers in CryptoJS is ECB mode is an irresponsibly catastrophic API design choice. $\endgroup$ Commented Jun 19, 2013 at 20:31
  • $\begingroup$ @StephenTouset My (by now sizable) experience is that using algorithm defaults in a cryptographic library is always problematic. CBC would have been better, but by now I would recomment an authenticated cipher. It's simply better to have the programmer make concious decissions instead. $\endgroup$
    – Maarten Bodewes
    Commented Jun 24, 2013 at 11:24

1 Answer 1


The answer is:

Why do the encrypted files always start with "Salted__" ("U2FsdGVkX1" in base64)? Isn't giving away information like this insecure?

The encrypted files must always start with "Salted__" to interoperate with OpenSSL. OpenSSL expects this. The 8 bytes that spell "Salted__" are always immediately followed by another random 8 bytes of salt. The encrypted stream starts at the 17th byte. This way, even if you use the same password to encrypt 2 different files, the actual secret keys used to encrypt these 2 files are very different.

It is possible to omit the salt, but this is highly discouraged

source: http://juliusdavies.ca/commons-ssl/pbe.html

  • 4
    $\begingroup$ And just for completeness (since the quote only answers half of the question) starting the files with "Salted__" does not give away information beyond the fact that the file was encrypted with (or at least for) OpenSSL, which is assumed to not be secret. So it isn't insecure. $\endgroup$
    – Thomas
    Commented Jun 19, 2013 at 23:39

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