[lazide]

You can (and folks do) authenticate in ways that don’t make individual blocks bigger.

  And any decent structural validation of the data still makes it reasonably secure even without per-block validation. 

GCM is also opened up to different types of attacks due to it’s structure. Such as if the data is gone, it may be impossible to figure that out without additional signature or metadata.

Without the correct key for AES, it is exceedingly difficult to construct a value that can result in a successful attack after decryption even for the simplest file systems (as compared to a very visible crash or disk corruption issue even without validation), and that blog post way oversimplifies the actual process. It also makes numerous flat out false statements about many encryption modes.

a trivial answer that solves every one of the attacks mentioned in that blog is using ZFS on top of a encrypted block device.

In each of these cases, for a successful attack, you’d need to generate a new block, or identify an existing block to replace a known block with, that would produce the attackers desired outcome. All GCM does is make it more detectable in the encrypted data if that happens.

Some modes mentioned, if watching the actual disk activity and doing chosen plaintext attacks, it could be possible to shorten the time to recover the underlying volume keys, but that is not helped immensely by GCM (necessarily).

It is going to be obvious in the system itself without the right key if someone tries to swap in a bogus block, because it will be gibberish/corrupt, if it is data used by anything or checked by anything.

AES-GCM just means you can tell when you pick something up, vs when you look at it if it’s damaged. And it does it at the trade off of adding a signature on everything. Sometimes that’s worth it, sometimes it’s not.

[loup-vaillant]

> You can (and folks do) authenticate in ways that don’t make individual blocks bigger.

First, name one example.

Second, what do you mean by "individual blocks"?

AES-GCM adds one authentication tag per message. A single message may contain millions of AES blocks, and the total overhead of AES-GCM over it will still be a single authentication tag (16 bytes). That makes it very similar to pretty much any authenticated encryption scheme out there.

[lazide]

Ah, your second question is a good one, and probably gets to the root of the disagreements.

I was specifically referring to the context of things like block devices. There is no single message (in a sane way, anyway) for the device. Each low level block is the message, in the sense you are referring to. That's when inputsize != outputsize is a problem, as that 'message' is also fixed size.

When I am referring to authenticating in a way that doesn't make individual blocks bigger, I'm referring to a HMAC signature in filesystem metadata or similar in this type of scenario. Out of band information. Practically speaking, even a basic CRC of metadata and file contents would make most attacks impractical.

Which you could do with AES-GCM of course, by storing the tag separately. I currently know of no implementations that do so however, but I'm sure there are ones out there. It would require storing the tag per block, which doesn't sound fun or performant.

To answer your second question in that context - everything from SSL to PGP/GPG, S/MIME, etc.

[loup-vaillant]

> Practically speaking, even a basic CRC of metadata and file contents would make most attacks impractical.

If I recall correctly, CRC of plaintext-then-encrypt scheme have been defeated in the past. With practical attacks.

---

> Which you could do with AES-GCM of course, by storing the tag separately. I currently know of no implementations that do so however, but I'm sure there are ones out there. It would require storing the tag per block, which doesn't sound fun or performant.

Here’s an example from possibly the most famous modern cryptographic library: https://doc.libsodium.org/secret-key_cryptography/aead/aes-2...

As for storing the tag "per block", I’m not sure what you mean. Sure you need one tag per block, but with the above API you can store that tag anywhere you want. If for instance you pack them into dedicated blocks, a single 4KiB blocks can store 256 authentication tags. The loss of storage capacity would be a whooping 0.4%.

> When I am referring to authenticating in a way that doesn't make individual blocks bigger, I'm referring to a HMAC signature in filesystem metadata or similar in this type of scenario. Out of band information

Then just store the authentication tag from AES-GCM out of band!! Surely your meta-data can handle a 0.4% size overhead?

---

> To answer your second question in that context - everything from SSL to PGP/GPG, S/MIME, etc.

Thought so. They’re all just like AES-GCM. One of them (TLS 1.3, a.k.a. SSL) can even use AES-GCM for its symmetric crypto.

[lazide]

If you store all your tags (which update every time a block updates) in one location, then you’ll burn it out on a SSD, or thrash your disk with seeks on spinning rust (you’ll multiply your writes 2x, minimum). And unless you are adding some kind of virtualizing layer, you don’t have .4% of blocks to play with. You have 0% of blocks.

I tried to read your pointer, but the link goes no where explaining it. Mind giving a more useful link? It Could be because I’m on mobile.

We weren’t talking about CRC of plaintext anyway - we were talking about block encryption. So it would be CRC (as validation) of on-disk filesystem structures as part of parsing. Aka an actual attack.

Standard AES-GCM appends the tag to the encrypted message directly. None of those I name do it that way. Using AES-GCM as a transport is layering their stuff inside it, which of course is fine as I’m describing it - because they don’t have fixed size structures in their protocols! It doesn’t mean they aren’t doing the additional validation and authentication.

[loup-vaillant]

> And unless you are adding some kind of virtualizing layer, you don’t have .4% of blocks to play with. You have 0% of blocks.

That is a shitty problem to have, there is no perfect solution. If you at all can, change the problem. If that means you need a virtualization layer, use it if possible.

---

> I tried to read your pointer, but the link goes no where explaining it. Mind giving a more useful link? It Could be because I’m on mobile.

The first sentence of the link I gave you reads as follows: "Some applications may need to store the authentication tag and the encrypted message at different locations."

Then it shows you the following function that achieves that separation (with zero performance overhead I might add):

  int crypto_aead_aes256gcm_encrypt_detached(
      unsigned char       *ciphertext,
      unsigned char       *mac,
      unsigned long long  *mac_size_p,
      const unsigned char *message,
      unsigned long long   message_size,
      const unsigned char *additional_data,
      unsigned long long   additional_data_size,
      const unsigned char *always_NULL,
      const unsigned char *nonce,
      const unsigned char *key);

If that does not help you, you need more basic training. I recommend Dan Boneh's standford cryptographic course or crypto1O1. And if you need to understand the severity of various attacks at a gut level, you might want to take a look at the cryptopals challenges as well:

http://openclassroom.stanford.edu/MainFolder/CoursePage.php?...

https://www.crypto101.io/

https://www.cryptopals.com/

[tptacek]

People have been saying stuff like "even a CRC would make attacks impractical" for decades, and what all they've managed to accomplish is an obstacle course for early-career academic cryptographers. Which, by all means, carry on: it produces great papers, and it's a great way to get new people into the field. But if you care about security, your ciphertext needs to be authenticated.

Which brings me back to: all secure encryption expands the size of the ciphertext. If you're using XTS in a new design, you are doing something very wrong.