Description
Taylor Hornby of defuse.ca has release a security audit of gocryptfs: https://defuse.ca/audits/gocryptfs.htm
This ticket tracks and discusses the findings (section 2 in the audit)
> 2.1 File-Level Ciphertext Malleability
Get rid of allow_other? Still, defending about root-level access is not really feasible.
> 2.2 File ID Poisoning / PoC 5
Defense for PoC 5 is in the works. Empty files that contain nothing but the header will be overwritten (destroying the poisoned file ID)
Done in 14038a1 .
> 2.3 Directory IV Poisoning / PoC 7
Create gocryptfs.diriv when the first file is created? Not sure if the extra complexity of doing that is worth it, as the impact is low.
> 2.4 Same Key Used for Both GCM and EME Modes
gocryptfs v1.3 will derive separate key using HKDF (developed in the hkdf branch)
Done, the hkdf branch has been merged to master.
> 2.5 No Integrity Protection for File Permissions
Works as designed but should be documented.
> 2.6 Pushing the Limits of GCM
The audit agrees with my calculations that the 128-bit IVs that are used by gocryptfs are safe up to petabytes of data.
Users who expect to be writing
more than, say, a petabyte of data to a gocryptfs repository in its lifetime should
repeat the calculations in [2] to make sure they don’t hit these limits.
Still, we may switch to AES-GCM-SIV once it is available and fast.