Tony Arcieri

> Next, we should provide extension traits which implement prepending and appending modes of operation. In other words, even if an algorithm specification states that tag should be prepended, we...

Using prefix constructions in a postfix mode would again create non-standard variants of algorithms which aren't compatible with any other implementation. I think we should implement the algorithms as specified...

> But everything breaks down when tags are prepended in-place because the plaintext and ciphertext (i.e. in-buffer and out-buffer) necessarily overlap at an offset. Supporting this properly would need support...

> That is to say -- would there be any fundamental problem in adding an `offset: isize,` field to `InOutBuf` (or its internals) that affects which region of the in-place...

> Honestly, I am not sure about importance of prefix/postfix mode specified by an AEAD algorithm in practice. In my experience, tag/nonce handling is usually defined by a file format...

> Also, I wouldn't say it's universal, e.g. [MGM](https://www.rfc-editor.org/rfc/rfc9058.txt) returns a tuple with ciphertext and tag without specifying whether tag should be appended or prepended. MGM is definitely the odd...

I think what might make the most sense is a `pub trait PostfixTag(ged)` marker trait which we can gate the blanket impls on. Algorithms which are specified with a non-postfix...

Might be worth updating #551 and see if the issues have resolved themselves in the interim

As a meta comment: I would once again suggest making newtypes, rather than `CoreWrapper` type aliases, for each of the digest algorithms we support, possibly using a macro to write...

Would suggest closing this for now. > instead it should be an alias for `Blake2b`. @newpavlov that seems fine to me. Curious with `hybrid-array` if we could even make that...