4 ms·

This has been a problem with disk encryption since the dawn of time: there is no (at least AFAIK) scheme that allows efficiently hosting the MAC for an encrypte

by _wmd 11y ago

This has been a problem with disk encryption since the dawn of time: there is no (at least AFAIK) scheme that allows efficiently hosting the MAC for an encrypted block in a way that meets various efficiency and robustness requirements. Emulating an unencrypted disk means allowing updates at (traditionally) 512-byte sector granularity. Assuming we store a SHA256 MAC for the sector's ciphertext, for a 1TiB drive that means storing 64GiB of hashes. In order to preserve alignment (required by various layers of the hardware and software stack), it's not possible to locate these hashes inline with the sectors they represent. In traditional media that meant adding an extra seek to every read or flush, or in other words at least halving the throughput of your drive. This situation doesn't magically disappear with SSDs, the same performance problem just exhibits in a different way. There's a bunch of other reasons full disk encryption isn't authenticated, but the above is a good starting point edit: I have no idea how hardware disk encryption (e.g. TCG OPAL) functions, I guess it's at least vendor-dependent, but at least there is a possibility within traditional spinning rust drives to interleave authentication data more efficiently. In any case at that point, the attacker would need to physically disassemble the drive in order to perform an attack, so OPAL is probably a step up from plain software encryption if you're paranoid enough, yet somehow still trust your drive firmware

qrmn 11y ago
But this isn't disk encryption! Filesystems have metadata: which is where a MAC can go, next to the filename. There's just no way this should be unauthenticated XTS, this is simply the wrong mode to use, you should use an AEAD. ChaCha20_Poly1305 - RFC7539: https://datatracker.ietf.org/doc/rfc7539/ https://datatracker.ietf.org/doc/rfc7539/ - makes much more sense. Faster, too, on the target mobile devices which have poor crypt performance. I don't think this should be merged early or as-is. Unauthenticated encryption is against good advice and a bad idea. Standardising that is an even worse idea. Edit: I do see that they're intending this as a minimum viable patch for Android 'M' and they intend to add GCM support later (again, I'd point to CC20 as a newer, better alternative), they're just waiting on a transactional update first. I do question whether shipping it broadly with this design as-is should happen in the vanilla kernel, however: Android uses its own patches anyway. Maybe let this one mature a bit first before merging upstream?
- fulafel 11y ago
  > Filesystems have metadata: which is where a MAC can go, next to the filename. File-level MACs would require reading/writing the entire file in one go, andpreclude efficient in-place modification of files. The alternative, lots of per-block MACs stored in extended attributes, wouldn't work for ext4 because of the 4 kb extended attribute size limitation, and would also have problems that the grandparent listed (lots of seeks).
  - qrmn 11y ago
    A fair point. btrfs would have a much easier time of it. We then have the interesting consequence that we can observe times and sizes of COW updates, but in truth SSDs have that anyway.
- caf 11y ago
  ChaCha20 may be better in the abstract, but as a practical matter AES-GCM can take advantage of AESNI. I don't think a patch adding support for ChaCha20 would be particularly controversial anyway.

by _wmd 11y ago

qrmn 11y ago

But this isn't disk encryption! Filesystems have metadata: which is where a MAC can go, next to the filename. There's just no way this should be unauthenticated XTS, this is simply the wrong mode to use, you should use an AEAD. ChaCha20_Poly1305 - RFC7539: https://datatracker.ietf.org/doc/rfc7539/ https://datatracker.ietf.org/doc/rfc7539/ - makes much more sense. Faster, too, on the target mobile devices which have poor crypt performance. I don't think this should be merged early or as-is. Unauthenticated encryption is against good advice and a bad idea. Standardising that is an even worse idea. Edit: I do see that they're intending this as a minimum viable patch for Android 'M' and they intend to add GCM support later (again, I'd point to CC20 as a newer, better alternative), they're just waiting on a transactional update first. I do question whether shipping it broadly with this design as-is should happen in the vanilla kernel, however: Android uses its own patches anyway. Maybe let this one mature a bit first before merging upstream?

fulafel 11y ago
> Filesystems have metadata: which is where a MAC can go, next to the filename. File-level MACs would require reading/writing the entire file in one go, andpreclude efficient in-place modification of files. The alternative, lots of per-block MACs stored in extended attributes, wouldn't work for ext4 because of the 4 kb extended attribute size limitation, and would also have problems that the grandparent listed (lots of seeks).
- qrmn 11y ago
  A fair point. btrfs would have a much easier time of it. We then have the interesting consequence that we can observe times and sizes of COW updates, but in truth SSDs have that anyway.
caf 11y ago
ChaCha20 may be better in the abstract, but as a practical matter AES-GCM can take advantage of AESNI. I don't think a patch adding support for ChaCha20 would be particularly controversial anyway.