Consider adding tag size of 4 and 8 to AES GCM

[d3lm]

I have noticed that AesGcm only accepts tag sizes >= 12 and <= 16. However, Node.js for example also allows tag sizes of 4 and 8 (see here). Could we implement SealedTagSize for consts::U4 and consts::U8 as well?

[tarcieri]

NIST SP 800-38D Appendix C provides guidelines for the use of short tags, noting the following potential attack up front:

Absent the requirements and guidelines in this appendix, it may be practical for the attack to produce the hash subkey, H, after which the authentication assurance is completely lost.

While we could potentially support them, using them securely comes with a whole host of caveats described in that section which makes their usage fall into more of a "hazmat" category which requires short lived, frequently-rotated keys with bounds on how many times they can safely be used for decryption without being vulnerable to a targeted forgery attack:

For any implementation that supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2,
respectively, shall be enforced. In particular, the supported lengths for the plaintext/ciphertext
and the AAD shall ensure that every valid packet satisfies the length restriction in the row, and
the controlling protocol/system shall ensure that the key is changed before the authenticated
decryption function is invoked more than the maximum that is given in the row. A smaller
maximum may also be enforced.

[d3lm]

Oh ok, I wasn't actually aware of that - thanks for pointing that out. I guess it'd be more effort than to support short tags. It might be ok for us to restrict the tag size and ignore short tags. I also don't know if there's applications that really use short tags and it's just something I noticed while I was implementing AES-GCM that complies to Node.js using aes_gcm.

[tarcieri]

It sounds like they are buffering and perhaps incrementally encrypting/authenticating the data.

We only have one-shot APIs at the moment, though you could largely achieve the same effect by buffering the data into a Vec<u8> and then encrypting it with the one-shot API.

[d3lm]

Yes, that's what I am doing for encryption and it works, but I have issues with incrementally decrypt data. Because parts of the encrypted data will throw an aead::Error likely because the tag isn't correct and corresponds to the tag for the entire data. Any idea what I can do?

[tarcieri]

It's not possible to safely decrypt individual AEAD messages incrementally. At the very least, the tag needs to be checked before decryption can begin.

[d3lm]

I wonder how Node.js does that then 🤔

[tarcieri]

My guess would be: unsafely

[d3lm]

Oh my, I just realized, with every call to update(<partial_aead_message>) they don't even check the tag only once you call final and have all the "chunks".

[d3lm]

But that is prolly not a good idea is it?

[d3lm]

Hm I guess maybe it is because only after calling final() the entire decryption process is finished and I would expect that you can not expect it to be fully checked before calling final().

[tarcieri]

Operating on unauthenticated data can be a source of chosen ciphertext attacks which completely undermine AEAD security.

These sorts of streaming decryption APIs are "hazmat" which is difficult to use correctly with high misuse potential.

[d3lm]

Thanks a lot for your input on this 🙏 I am not a crypto expert myself so appreciate it.

[d3lm]

Maybe you can still consider adding short tags, that would be really nice. But for now it's fine and I can work around it and only support 128 bit tags.

[tarcieri]

We could add an API for it, but it would require a special decryptor object which caps the max message size and number of decryptions allowed under a given key

[d3lm]

I think that sounds reasonable as long as those numbers are decently high or maybe configurable?