You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 5, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
The reason for the SIV tag being at the beginning is so messages can be incrementally decrypted before they're fully received. While interesting, no Miscreant implementation currently works this way, and it seems like something of a micro-optimization. The need to do this is also somewhat mitigated by using STREAM
AES-GCM-SIV places the SIV tag at the end of the message
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: