Gocryptfs: defuse.ca Security Audit Results

[rfjakob]

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 https://github.com/rfjakob/gocryptfs/commit/14038a1644f17f50b113a05d09a2a0a3b3e973b2 .

> 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.

[rfjakob]

Threat model published at https://nuetzlich.net/gocryptfs/threat_model/

[defuse]

Looks good!

[rfjakob]

Oh, thanks for looking!!

[arpitchauhan]

@rfjakob Thanks for your work and taking the audit report seriously. I just wanted to know whether 2.1 and 2.3 above are being dealt with or are considered acceptable? 😄

[rfjakob]

Not working on these, no. I consider them as acceptable limitations.

[arpitchauhan]

Ok, thank you!