[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.