Gocryptfs: Question: Why AES-GCM instead of AES-CTR + HMAC?

[Xeoncross]

A popular google drive client used AES-CTR + HMAC to avoid a couple issues with Go's GCM implementation not allowing streams causing gocryptfs (and others that use GCM with large files) to have to process smaller blocks (i.e. 4kB chunks) and save them in order signed.

GCM is nice and simple for small blobs but doesn't seem like a good fit here causing extra overhead and resource usage.

[rfjakob]

Pretty sure gcm wipes the floor with ctr+hmac in terms of speed. gocryptfs wants to go fast

[Xeoncross]

Good point. I'm finishing a CTR + HMAC implementation without the extra scrypt key hashing so I'll benchmark it against gocryptfs and report back.

[rfjakob]

The chunking is needed to allow random writes. You have to rewrite the whole chunk even for a 1-byte write, so the 4kiB value for gocryptfs is a compromise between MAC overhead (disk storage size) and small-write penalty (performance of small writes)

[rfjakob]

Great, I'll be interested in the results! As for numbers for comparison, the wiki page at https://github.com/rfjakob/gocryptfs/wiki/CPU-Benchmarks has GCM performance for several CPUs (with and without AES-NI acceleration)

[rfjakob]

I'm gonna close this for now - though I'm still interested in the results!

[Xeoncross]

Here is a basic implementation I put together with a example of streaming over 500MB through the encrypt -> decrypt process. I get about 100MB/sec.

Looks like it's faster than Go GCM on a CPU with no AES-NI - but slower than StupidGCM or a CPU with AES-NI enabled. I could be wrong though and I haven't done any optimization.

[rfjakob]

Nice! It's always better to have actual numbers from an actual implementation.

The problem I see here is that you cannot verify the integrity of anything until the end of the stream. But you have also noticed that.