Hacker News Reader

Comment by IncRnd | Hacker News Reader

from https://www.cryfs.org/howitworks: > The current version protects the encrypted blocks from being modified by an attacker, since it uses an authenticated encryption scheme like aes-256-gcm. However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block.

GCM only retains its security properties when nonce/IV & Key combinations are never repeated. If these repeat under a specific key, the algebraic ability to completely break the scheme is drastically heightened. Therefore, this implementation appears to be broken. Is there an expectation for when this will be fixed? It's very serious, and the scheme seems somewhat well-planned in other ways.

Also, with this implementation of GCM, what is the practical limit before reuse happens, given the blob/block difference and nonce size? I call this out, as this is disk encryption not file encryption.

View on HN

As far as I can tell, the IV is randomly chosen, as you would expect: https://github.com/cryfs/cryfs/blob/master/src/cpp-utils/cry.... Did you see something different?

Assuming the 128-bit IV is indeed randomly chosen, after encrypting a trillion blocks, you would have roughly a 1.5E-15 (on the order of a quadrillionth) chance of hitting a collision.

Unless I'm mistaken, even if you hit that one-in-a-quadrillion lottery, the result is that the two blocks encrypted with the same IV are more crackable (because you can XOR them together), not that the key itself is easier to obtain, right? (My understanding is that AES is resistant to known-plaintext attacks.)

The text you quote says nothing about what values are used for IV.

To me it looks like each block has a static name, probably based on its offset in the address space of the virtual block device, and that there's nothing telling the block pointing at a block which version of the block to use. So you can replace block N with any known good version of that block.

To point at specific versions of a block you'd have to point at something like hash(encrypted_block) or hash(block_offset || block_version) instead, but then you'd have to update pointers all the way up to the root for every edit made anywhere in the FS.

"However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block."

All cryptographic filesystems have that limitation. The attacker cannot modify or tamper data or create new data (thanks to authenticated encryption), but they can always return the raw disk back to an earlier version if they have a copy of it.

The fact that the filesystem can be rolled back, does not automatically imply GCM IV reuse as you suggest. In fact, it should increase confidence on the basis that the authors are aware of the possibility of rollback.

Reply on news.ycombinator.com