2

Given:

  • A file (assume 1 GB in size) is encrypted along with filenames using 7zip into a 7z archive using AES-256
  • The file is uploaded to a cloud storage service such as those offered by Google, Amazon, or Microsoft
  • The file is downloaded by a peer on a separate network and the peer is offered the password in a secure manner

Acknowledgements:

  • I realize that if someone got the password then their job would be easy
  • I also realize that the security is only as great as the developer who created 7z made it
  • I went through as many similar topics as I could find on here and elsewhere about this and while similar questions have been asked, I don't believe the exact concerns here have been addressed so I hope this is not a duplicate.

Questions:

  • Does using a linux based operation to create such files offer more security than doing so with 7zip on Windows?
  • How susceptible would this kind of operation be to an attacker, government agency, etc... seeking to know what the contents of the archive are? Would that middle man need to intercept the entire file in order to potentially gain access to the contents?
  • What other flaws may have been overlooked in this approach?
  • Are there better alternatives that offer comparably equal ease of implementation?
Rob
  • 68
  • 1
  • 6
  • The MITM attack would have to be done over whatever channel the key is exchanged through. You say it's a "secure manner", so whether or not MITM is a risk depends on how secure it exactly is. – forest Feb 24 '18 at 03:36

3 Answers3

3

Context

What we have here is a symmetric encryption scheme implemented using 7z for encryption. Since I trust that, as you stated, the password is shared in a secure manner, we can consider it a pre-shared secret (at least pre-shared by the time of decryption). This means that the security of the scheme is dependent on the 7zip implementation of AES, etc.

Also, due to the nature of symmetric encryption with pre-shared secrets, an active attack (e.g. a man-in-the-middle attack) is no more useful than a passive eavesdropper.

Does using a linux based operation to create such files offer more security than doing so with 7zip on Windows?

As long as your system is not compromised, either system would be equally fine. Which one is less likely to be compromised, etc, is a different question

How susceptible would this kind of operation be to an attacker, government agency, etc... seeking to know what the contents of the archive are? Would that middle man need to intercept the entire file in order to potentially gain access to the contents?

As mentioned above, "intercepting" the file would be no better/worse than passively observing it, so a gov't agency would be no better off than your cloud provider, etc.

Whether they could (physically) compromise your devices, install keyloggers, use a $5 wrench to extract the password, etc, is a different question. How worrisome these threats are is up to you.

Cryptography-wise, the security is 100% dependent on the security of the encryption and the password. Since AES is pretty strong, I'd only worry about the password. (edit, thx @SteffenUllrich:) Since the password is being securely communicated, the only thing that you need to worry about is its strength. I recommend using a password manager to store and generate your password for the time between its creation and when it is sent to your friend/coworker/etc.

What other flaws may have been overlooked in this approach?

(edited in later:) As mentioned in the comments, you might want to look into how 7zip hashes passwords, etc.

Are there better alternatives that offer comparably equal ease of implementation?

Overall, I'd say that your current setup passes with flying colors. It's simple and uses established algorithms (i.e. AES).

Alexander O'Mara
  • 8,774
  • 6
  • 34
  • 38
user196499
  • 1,121
  • 6
  • 11
  • It appears that 7zip [does not use a salt](https://crypto.stackexchange.com/q/30468/54184), and most likely does not have any form of integrity such as an HMAC. Those are the main flaws in the setup that I can see. – forest Feb 24 '18 at 03:40
  • Actually I'm not sure if that's still true, since https://github.com/philsmd/7z2hashcat mentions a salt. I guess I'll have to check the actual source code. – forest Feb 24 '18 at 04:35
  • *"I'd only worry about the password, which, as you said, is securely communicated and is therefore not a worry either."* - one can also communicate a weak password in a secure way. The security not only depends on the secure sharing of the password but also on the strength of the password itself. AES and KDF will not help much against brute-forcing if a weak password was used. – Steffen Ullrich Feb 24 '18 at 07:43
  • @SteffenUllrich oops, nice catch :) I didn't mean to phrase it that way, but after rereading my answer I now realize that I mistakenly assume that the password he is using is secure. I'll edit my post with better wording – user196499 Feb 24 '18 at 08:24
  • Thanks for the input. I should have added the assumption that the password is strong and secure. Thanks for mentioning passive easvesdropping as well. That is really more of a concern than a man in the middle. Ultimately I think this set up is sufficient as well as I am not expecting an attack and am just seeking privacy. – Rob Feb 24 '18 at 16:26
0

While the answer provided by @user196499 is spot on the one thing i think should be discussed is time.

Since your cryptographically secure archive has been created and placed online what is the allowable time it may remain secure?

Key lifetimes should be implemented due to the fact that on a long enough timeline every keys security drops to 0.

Factorization of a key (brute force), cryptanalysis of the algorithms output, side channel attacks in the cipher mode, iv weakness etc all play a part in the time of which the archive can be considered secure.

As mentioned, set a max on the key lifetime and if needed when implementing a new key reevaluate the mode of encryption being used; I.E. CBC, CTR , GCM etc

jas-
  • 931
  • 5
  • 9
  • While key expiration is great for public keys where you don't want people to send you messages encrypted with a compromised key, etc, it still doesn't solve the problem of stuff already encrypted using the key (i.e. the files encrypted w/ 7zip) – user196499 Feb 24 '18 at 07:30
  • NIST SP 800-57 Pt. 1 Rev. 4 recommends a lifetime associated with the key. Asymmetric or symmetric keys are still keys and over time are indeed susceptible to attacks. Rotating a key would require a decryption, re encryption but further protects the resulting cipher text. – jas- Feb 24 '18 at 07:45
0

The underlying cipher is secure. However, a specific practical MITM attack on encrypted archives has been proposed: https://link.springer.com/article/10.1007%2Fs10207-006-0086-3

The attack consists of intercepting the archive and editing the header to change indicated compression mode, so that the archive decrypts correctly, but decompresses incorrectly. The recipient is then expected to send back the garbled file, which the attacker intercepts again, fixes the header, and gets the data.

Of course, this isn't an attack on archives so much as it is an attack on unathenticated encryption in general. It also relies on highly reckless user behavior - but, if there are hundreds of recipients, it's conceivable that someone might do that, particularly if the MITM can also forge communications between the parties.

This scheme can be improved with encrypt-then-MAC authentication and ensuring the recipients verify the file before opening.

ZOMVID-21
  • 2,450
  • 11
  • 17