I read the audit docs on GoCryptFS website (https://nuetzlich.net/gocryptfs/threat_model/). There dragon has full information about the read write done in the gcfs partition, what does this mean and how safe is it to store GoCryptFS encrypted directory on a popular cloud provider?
Add a comment
|
1 Answer
(In the threat model linked, Dragon is an adversary, in the spirit of Eve and Mallory, but it refers to the storage infrastructure provider, which has access to the entirety of the ciphertext across multiple versions.)
I'll assume that encryption is still done client-side and only the ciphertext is sent to Dragon, otherwise, I'd fail to see the point.
In this filesystem, blocks are 4kb and each block (ed: including newer versions of the same block) receives a new IV for AES-GCM. This is probably good, because as the block contents change, if the IV didn't change as well then the XOR of the two plaintext versions of the same block would be leaked (via the XOR of the two ciphertexts MechMK1 '20).
This seems to confirm it, https://nuetzlich.net/gocryptfs/forward_mode_crypto/
All file contents are encrypted using AES-256-GCM (Galois/Counter Mode).
Files are segmented into 4KiB blocks. Each block gets a fresh random 128 bit IV each time it is modified. A 128-bit authentication tag (GHASH) protects each block from modifications.
Each file has a header containing a random 128-bit file ID. The file ID and the block number are concatenated (source code ref) and mixed into the GHASH as additional authenticated data. This prevents blocks from being copied between or within files.
If the IV didn't change, then Dragon would now be in a position to detect the changes and (possibly) take advantage of them.
I don't know if using the software is more or less "safe", however, the use of AES-GCM is relatively a "Good Thing" because each block of ciphertext can't be interferred with due the to authentication properties of this mode - if any aspect of the ciphertext changes, then the tag (ie. the MAC) will change and decryption will fail. But! (There's always a but.) You may wish to consider these criticisms Soatok '20 and decide whether any of them apply to your particular use-case, and if yes, consider another alternative based on a different cryptographic primitives.
