Why do you use EME for file names instead of just GCM?

[lquenti]

What are the advantages of EME? I think that this project is insanely impressive, so I believe that it is the better choice, but for a crypto-noob like me its not obvious:

• According to your thread model it seems to be a potential security issue to not just use GCM, which resulted in you using HKDF just in order to mitigate it
• It seems to be very hard to interact in other languages since EME is more niche, to the point that gocryptfs-inspect gave up on it and "just" uses the socket interface.

Can you give me any hints of what the advantage of EME is?

[danim7]

The main advantage of EME is having *deterministic* names. That would not be possible with GCM mode, which uses *random* initialization vectors. According to the doc, this is necessary to avoid collisions (a folder containing two encrypted names that would decrypt to the same plaintext name): https://nuetzlich.net/gocryptfs/forward_mode_crypto/ Also (and correct me if I'm wrong), having deterministic names is important for performance reasons. This allows to directly identify the encrypted file that corresponds to a given plaintext name. Otherwise, it would be necessary to scan all encrypted names in a folder until we find the one that corresponds to that plain name.

[rfjakob]

Yes, all correct. File name encryption must be deterministic. This rules out AES-GCM.

Then there's the issue that file name length is limited on disk, so you don't want a lot of encryption overhead.

EME is zero-overhead.

At that point in time I expected EME to gain more traction, but it ultimately did not (XTS "won").

I was not aware that gocryptfs-inspect does not implement EME, maybe that can be fixed?

C++-to-Python converter maybe? https://github.com/bailey27/cppcryptfs/blob/master/libcppcryptfs/crypt/eme.cpp

And I guess there's reference implementations in C somewhere.

[lquenti]

thank you both so much!

And for future reference: I later saw that there is a fork that seems to implement it! https://github.com/maxpat78/gocryptfs-inspect/blob/master/aes256eme.py

[rfjakob]

Nice find! I took the opportunity and added a list of implementations here: https://github.com/rfjakob/eme?tab=readme-ov-file#other-implementations

[rfjakob]

I re-read about XTS again, and now I remember the problem it has: It encrypts 16-byte blocks independently. Quoting https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ :

The wide-block-of-narrow-blocks property weakens XTS unnecessarily. As the disk rewrites a given sector, attackers can collect fine-grained (16 byte) ciphertexts. They get to manipulate ciphertexts surgically. It would have been possible to define a “native” wide-block tweakable cipher without that property, but that wouldn’t have been as performant.

For file names, this means that you leak which filenames contain the same 16-byte substrings.

EME encrypts the whole plaintext together as a single block. Changing a single bit changes the whole ciphertext. The price to pay (and probably why XTS won) is performance. EME does two encryption passes. For file names this doesn't matter, it's plenty fast.

[lquenti]

very interesting! Thank you for the insight