Using 7-zip 19.00, on Windows 10 1909, build 18363.592, I encrypted a text file with the contents "hello there" using AES-256 and the password "123". I did this two times, the exact same procedure, but as shown below, the output is different:
Why?
$\begingroup$
$\endgroup$
2
-
4$\begingroup$ It's not a bug, it's a feature called IND-CCA. Moderator note: this comment turns out to be somewhat incorrect; it is kept because the accepted answer's Note 2 refers to it. $\endgroup$– DannyNiuCommented Feb 12, 2020 at 7:58
-
1$\begingroup$ You might want to read up on probabilistic encryption: en.wikipedia.org/wiki/Probabilistic_encryption $\endgroup$– SwashbucklerCommented Feb 12, 2020 at 16:22
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
13
This is expected behavior since 7zip uses Cipher Block Chaining (CBC) mode for encryption. For which you need the Initialization Vector (IV) to be unique and unpredictable.
It was using 64-bit IV but fortunately, that was changed to 128;
Encryption strength for 7z archives was increased: the size of random initialization vector was increased from 64-bit to 128-bit, and the pseudo-random number generator was improved.
If the encryption of the same file results in the same ciphertext then we will be thought that there is a problem with the IV generation. Hopefully, from here we see that there is not.
Note 1: 7zip uses $2^{19}$-times iterated SHA256 to derive the AES-256 key from passwords. This is not safe from massive parallelization. A password with high entropy like diceware is recommended.
Note 2: The first comment under question claims that CBC mode of operations has IND-CCA actually it can't, it has IND-CPA. See the seminal work of Rogaway on modes Evaluation of Some Blockcipher Modes of Operation
answered Feb 11, 2020 at 18:12
-
1$\begingroup$ @fgrieu If we can combine philsmd/7z2hashcat and hashcat examples, 7zip -m is 11600 (hash mode) then it is $2^{19}$ $\endgroup$– kelalakaCommented Feb 11, 2020 at 20:30
-
2$\begingroup$ Hum, I was looking at the wrong part of the source, handling some zip crypto. Indeed, the 7-zip 19.00 password-to-key is CKeyInfo::CalcKey, in CPP/7zip/Crypto/7zAes.cpp and by default (not changeable in the UI) uses $2^{19}$ iterations of something ad-hoc having to do with SHA-256 (but less than a round at each iteration, hence the $2^{18}$ which is an approximation valid for a password of 8 bytes). $\endgroup$– fgrieu ♦Commented Feb 11, 2020 at 21:07
-
$\begingroup$ This answer does not address the question “Why?” but addresses only the how. $\endgroup$– zrajmCommented Feb 14, 2020 at 5:43
-
$\begingroup$ @zrajm Why they choose CBC, maybe we can find in the archives. Why CBC mode gives output different every time because it is designed this way. CBC mode has probabilistic encryption and to achieve that you need to give a random IV for every call. $\endgroup$– kelalakaCommented Feb 14, 2020 at 7:46
-
$\begingroup$ Can you recommend a better alternative to 7z as part of your answer as well? $\endgroup$– jaaqCommented Feb 14, 2020 at 15:02
$\begingroup$
$\endgroup$
3
Encrypting the same input multiple times, normally, is supposed to produce different outputs each time. This is so that an eavesdropper not only cannot tell that the input was hello there, but cannot even tell that the two files were produced from the same input. So for example you could send Mary the first file and Bob the second one, and an eavesdropper wouldn't be able to tell that you've sent them the exact same information.
The mechanics of how it's achieved is by one or both of:
- Deriving a different encryption key each time you reuse the same password, by using not just the password but also a random salt in this process;
- Supplying a different or random initial value (IV) to the encryption algorithm each time you call it.
answered Feb 11, 2020 at 20:11
-
6$\begingroup$ Re: "This is so that an eavesdropper not only cannot tell that the input was
hello there, but cannot even tell that the two files were produced from the same input": More importantly, the use of randomness prevents an eavesdropper who sees the differences between two ciphertexts from computing the differences between the two plaintexts, which can be more useful to an attacker than one might think. (See the second bullet point at en.wikipedia.org/wiki/One-time_pad#Exploits, where use of a one-time pad just twice let some messages be cracked.) $\endgroup$– ruakhCommented Feb 12, 2020 at 8:01 -
$\begingroup$ Am I correct in assuming that the IV must be transported to the recipient of the message as well? If so, is that just done in clear-text/encrypted without an IV? $\endgroup$– user43783Commented Feb 12, 2020 at 15:03
-
5$\begingroup$ @Bananenaffe: Random IVs must be transmitted along with the message, yes, but there's also designs that use or allow counter IVs which can often determined by context. And random IVs are safe to send unencrypted because they're random bits and thus (in theory) don't reveal anything. Counter IVs reveal at most how many messages have been sent so far and their order. $\endgroup$ Commented Feb 12, 2020 at 17:58