Partial tag comparison

[Flakebi]

Hi,
I’m trying to use the eax crate to decrypt data with decrypt_in_place_detached but I only have the first 8 byte of the tag available as the network protocol I implement cuts off the other 8 byte of the 16 byte tag.
All aead functions expect the whole tag, so I can’t find a way to decrypt the data.

[tarcieri]

The Eax type accepts a tag size when you instantiate it (2nd generic parameter). If you’re using an 8-byte tag, you need to specify U8 for this parameter.

Edit: whoops, just realized I was thinking of the CCM crate, sorry, too many crates 😅. If we can’t customize this it should be made generic if possible

[newpavlov]

We would have to make a method which uses partial tag a fundamental one and implement a fixed sized version in terms of it. An alternative approach would be to introduce a fundamental "hazmat" method which would decrypt ciphertext and return a computed tag without performing authentication by itself, on top of which will be implemented fixed and variable sized methods.

Currently I like the second variant a bit more.

[tarcieri]

@newpavlov it seems like this problem could be solved with no API changes or additional methods by making the tag size a generic parameter?

[newpavlov]

Hm, polymorphic trait is certainly another option to choose from and luckily they allow default parameters, so ergonomics should not suffer. But we would have to encode "less or equal" bounds, which unfortunately can not be expressed by const generics (I think it's worth to keep APIs relatively simple, to make future transition easier).

If you instead meant making type generic, I don't like this option, since I think we should implement this abstraction on the trait level.

One advantage of the "hazmat" approach is that it will allow us to remove some code duplication. Currently all AEAD implementors do the tag equality check themselves, while with this approach it will be done in the blanket method implementation. We also could even add decrypted data erasure in the case if the equality check has failed.

[Flakebi]

I tried to implement the “hazmat” approach by introducing decrypt_in_place_detached_no_tag_check, which returns the computed tag, and have a default implementation of decrypt_in_place_detached on top of that but I encountered a problem.
Eax has independent tag computation and decryption, so we want to

1. Compute and check the tag
2. Only decrypt if the tag is correct

This does not really fit these function signatures.
GCM on the other hand would fit this model nicely because it decrypts and computes the tag in one go.

A solution would be to introduce decrypt_in_place_custom_tag_check<F: FnOnce(Tag<Self::TagSize>) -> Result<(), Error>>(…, check_tag: F), so the aead scheme can put the tag check wherever it fits best. Also, it gets harder to forget checking the tag.

[tarcieri]

I'll just state again I think we should solve this by explicitly supporting truncated tags the exact same way the ccm crate does - as a generic parameter with an explicit list of valid lengths:

https://github.com/RustCrypto/AEADs/blob/master/ccm/src/lib.rs#L64-L65

EAX is more or less designed as a CCM replacement. Perhaps we should consider supporting the same set of truncated MACs that we do in CCM.

I don't think it makes any sense to further complexify the traits to support the truncated tag use case. They're already quite complicated and I think there's still some design work we need to do to refine what we have before adding further complexity. Done incorrectly, it could introduce sharp edges/security vulnerabilities that don't exist today, such as checking too short a tag length, or an empty tag length.

Using a generic parameter also makes usage of truncated tags type safe. It means we can restrict the set of tag truncations that are valid and actually make sense, and also means if two parts of the code don't agree on what the truncated tag length should be, a type error occurs.

[newpavlov]

@Flakebi

Eax has independent tag computation and decryption, so we want to: 1) Compute and check the tag 2) Only decrypt if the tag is correct

Note that if we want to be efficient in the "happy" path, decryption has to be done in one pass for EAX as well. I think it's acceptable for our decryption methods to start ciphertext decryption before authentication tag was verified. I understand the security concerns, but I think a better approach to satisfy them will be to simply zeroize the input buffer in case of tag mismatch.

@tarcieri
Note that CCM does not simply truncate the tag, resulting "full" tag is different for different output lengths. In that sense it has a certain similarity to the variable length hashes (such as BLAKE2). So I don't think we should mix simple truncation and explicitly specified algorithm variations with different output lengths.

we can restrict the set of tag truncations that are valid and actually make sense

What exact values do make sense though? For example in #231 "valid" values include 1 and 2 byte tags, which are obviously trivially breakable.

[tarcieri]

Note: see RustCrypto/traits#347 for further discussion on this topic