AES-SIV as specified in RFC 5297 places the SIV tag, which plays a dual role as both an initialization vector and MAC, at the beginning of the message (as commonly seen with IVs) as opposed to the end (as commonly seen with MACs).
I hate to reopen what I am sure is an ancient bikeshedding debate, but I think it makes a lot more sense to place the SIV tag at the end of the message. For in-place APIs this means the plaintext aligns to the beginning of the buffer, instead of being 16 bytes into it to leave space for the tag. It also makes it difficult to incorporate these algorithms into libraries which are trying to offer an abstract in-place API which can be used in conjunction with more traditional AEAD algorithms that place the MAC tag at the end of the message.
It's also elicited a number of "WTF the MAC is at the beginning?"-style reactions from a number of people attempting to use or just taking a look at the library, to the point I am getting tired of hearing it.
This would break compatibility with RFC 5297, so if support for placing the tag at the end of the message were added, I would prefer for it to be optional, and for AES-SIV default to RFC 5297 compatibility. On the other hand, as a greenfield construction, perhaps AES-PMAC-SIV could default to placing it at the end.
Aside from having an option to specify where to place the tag, it has no impact on API design except for in-place APIs, but merely changes the message format. The Rust implementation is the only one which presently offers an in-place API. In regard to it, a buffer type (#151) could be used to abstract message slicing so code is capable of working with the tag at either the beginning or the end without other changes.
AES-SIV as specified in RFC 5297 places the SIV tag, which plays a dual role as both an initialization vector and MAC, at the beginning of the message (as commonly seen with IVs) as opposed to the end (as commonly seen with MACs).
I hate to reopen what I am sure is an ancient bikeshedding debate, but I think it makes a lot more sense to place the SIV tag at the end of the message. For in-place APIs this means the plaintext aligns to the beginning of the buffer, instead of being 16 bytes into it to leave space for the tag. It also makes it difficult to incorporate these algorithms into libraries which are trying to offer an abstract in-place API which can be used in conjunction with more traditional AEAD algorithms that place the MAC tag at the end of the message.
It's also elicited a number of "WTF the MAC is at the beginning?"-style reactions from a number of people attempting to use or just taking a look at the library, to the point I am getting tired of hearing it.
This would break compatibility with RFC 5297, so if support for placing the tag at the end of the message were added, I would prefer for it to be optional, and for AES-SIV default to RFC 5297 compatibility. On the other hand, as a greenfield construction, perhaps AES-PMAC-SIV could default to placing it at the end.
Aside from having an option to specify where to place the tag, it has no impact on API design except for in-place APIs, but merely changes the message format. The Rust implementation is the only one which presently offers an in-place API. In regard to it, a buffer type (#151) could be used to abstract message slicing so code is capable of working with the tag at either the beginning or the end without other changes.