Using CryptoJS 3.1 I noticed that using 3Des, the encrypted message always start with
U2FsdGVkX1
Why is the first part of the encryption always the same?
What information does this hold and how does that information become U2FsdGVkX1?
$\begingroup$
$\endgroup$
2
-
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$– Stephen TousetJun 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 ♦Jun 24, 2013 at 11:24
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
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
-
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$– ThomasJun 19, 2013 at 23:39