4

I know keeping an active encrypted volume (like a VeraCrypt drive or a simple zip folder encrypted with AES256) on Dropbox/OneDrive/Gdrive/etc. is risky; data can be corrupted and the pattern of modifications can be a clue to an adversary, as is well explained in this thread. But what if it is never modified or shared, is it still risky?

Dark Lotus
  • 41
  • 2
  • Well, no, without modifications there are no patterns. Data can still be corrupted, always. – deviantfan Oct 29 '18 at 17:39
  • 1
    Even if you never modify the version you have stored online you might modify it offline. If an adversary gets hold of a media where you are storing one of your offline copies the adversary may then have two different versions of your encrypted image (assuming they also got the version you stored online). Most storage encryptions aren't designed to provide security when the adversary has two copies of your encrypted container from different points in time. – kasperd Oct 29 '18 at 23:31

2 Answers2

2

If it is never modified, and is always at rest, then the confidentiality of the contents will be as strong as the encryption key. In other words, an attacker would need to know the encryption key (or the password it is derived from) in order to decrypt the contents. However, know that VeraCrypt uses XTS mode, which is not authenticated. An unauthenticated mode means that it may be possible for an attacker to make predictable modifications to the plaintext just by modifying the ciphertext, without even knowing the key. For XTS, an attacker can randomize any 16 byte sector. If integrity is not part of your threat model (for example, if you digitally sign the volume), then this is not an issue.

forest
  • 64,616
  • 20
  • 206
  • 257
  • I looked at a diagram of XTS, and it does not look like it does much to ensure security against an adversary who has acquired copies of the container from two different points in time. So it will be important that there are no modifications. – kasperd Oct 29 '18 at 23:33
  • @kasperd You are correct. That is why I specified that it is fine only if it is never modified. – forest Oct 29 '18 at 23:35
  • I took a look at the article you linked to. It looks like a good introduction to the subject and highlights several of the drawbacks. – kasperd Oct 29 '18 at 23:51
1

There's many different types of "risk".

Risk of accessability - The cloud service abruptly goes out of business. The drive(s) storing your data may crash.

Risk of confidentiality - Is the passphrase you're using strong, and not reused multiple places.

Risk of integrity - Are you signing the file, or just encrypting the archive?

Then there's always the small risk that there was a bug or error in the code which implemented the encryption algorithms, which could result in a vulnerability being found in the future.

Daisetsu
  • 5,110
  • 1
  • 14
  • 24
  • Small risk? That's a bit of an understatement. – Nobody Oct 29 '18 at 19:30
  • @Nobody there's no perfect way to quantify risk in such a broad question. For some threat models this might be an unacceptably high risk, where hardware encryption is needed, for others it could he incredibly irrelevant. While I don't want to exaggerate the risk, I don't want to give the impression any implementation is 100% secure. Defense in depth (layers) exists for a reason. – Daisetsu Oct 29 '18 at 20:07
  • 1
    @Nobody It _is_ a small risk. You can verify that, say, VeraCrypt correctly implements the crypto primitives it claims to use. I have verified this myself, actually. Anyway, why was this downvoted? It gives a proper overview of the CIA triad, even if it is a little brief. – forest Oct 29 '18 at 23:00
  • Risk of integrity is what I'm more worried about. If, say, I upload a veracrypt volume to OneDrive, forget about it (but keep using OneDrive for other tasks), and download it 5 years for now, will it be the same file I uploaded 5 years before, same checksum? – Dark Lotus Oct 30 '18 at 13:06
  • 1
    @Dark Lotus if you're concerned about integrity then you want to sign the file using public key crypto. To a lesser extent you could use a checksum to look at file integrity, but if you is something like md5 that could be compromised (hash collision) – Daisetsu Oct 30 '18 at 15:09
  • 1
    @Daisetsu I think you might be meaning the "likelihood" part of risk in your "small risk" comment. The risk is quantifiably massive due to the impact, but the likelihood is very low. I have a feeling that this distinction might resolve all the subsequent comments. – schroeder Nov 01 '18 at 15:04
  • @schroeder Yes, that's what I meant. – Daisetsu Nov 01 '18 at 15:11