1

Background / Requirements

  • using a Windows machine
  • hard drives are already (veracrypt) encrypted volumes
  • not relying on any cloud service provider to trust them with their encryption
  • file by file encryption on the local machine

Question

Is there any downside using a program like cryptomator for file by file encryption on a fully encrypted veracrypt volume? Mounting an encrypted drive to access a file which again is used to mount a drive seems weird / I fear the two encryptions may distort each other.

I'm also open for alternative solutions. I also looked into boxcryptor but from what I got my files are unencrypted on my drive and are encrypted/decrypted whilst up and downloading. I would like to see the files encrypted on my drive before uploading.

Simon East
  • 440
  • 5
  • 10
idkfa
  • 113
  • 4

1 Answers1

1

There is absolutely nothing wrong with encrypting files on a volume (hard disk) that is also encrypted. Encryption doesn't "distort" anything; it's a reversible mathematical transformation of the input data. The cipher neither knows nor cares whether the input data is already encrypted; there's no special flag saying "this data is encrypted already!" that might get somehow confused. It's all just data.

  • File contents in plain text: A
  • File gets encrypted using per-file encryption utility: ENCf(A) = B
  • Encrypted file gets stored on an encrypted file system: ENCv(B) = C
  • Encrypted file is read off of the encrypted file system (for example, to upload): DECv(C) = B
  • Encrypted file is uploaded to a cloud service: upload(B)
  • Encrypted file is download from a cloud service to an encrypted volume: ENCv(download(B)) = C
  • Encrypted file is read off the disk and into the per-file decryption utility: DECf(DECv(C)) = DECf(B) = A.

("A", "B", and "C" are placeholder variables for the actual data, not literal values. "ENCf" and "DECf" are the per-file encrypt and decrypt functions, using the key you supply. "ENCv" and "DECv" are the volume-wide (VeraCrypt) encrypt and decrypt functions, using VeraCrypt's key for that volume.)

Now, it is important to not mess up the ordering (some ciphers will tolerate this, but some will not); DECf(C) != B, and DECv(DECf(C)) != A (probably). However, in practice this won't happen. You can't even tell where files begin and end on an encrypted volume unless you decrypt (some of) it first, so you aren't going to do something silly like try to decrypt C using cryptomator* and then try to decrypt the result of that using VeraCrypt. If you can even see the encrypted file is there, it's already passed through VeraCrypt so the data you see if you read it is B, not C, and you can safely pass it to cryptomator or whatever.

I've actually built, with a friend, a simple tool for doing this using the open-source gpg program for the file-level encryption. It worked fine.

*I don't know cryptomator and am not specifically endorsing it.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • I think my fears went into the direction of messing up the ordering. However as you pointed out, I can't really access the cryptomator vault before I I've already decrypted and mounted the VeraCrypt drive. Great explanation! – idkfa Dec 19 '18 at 09:12
  • Like I said, there exist ciphers - stream ciphers, or block ciphers in stream-like modes of operation - that can tolerate being decrypted and encrypted in different sequences. In general, though, it's not something that comes up unless you're trying to do something much more unusual than use encrypted files on an encrypted volume. – CBHacking Dec 19 '18 at 14:11