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
The current naming scheme in the AES-SIV uses a different naming scheme for the lengths than rfc5297, naming the algorithm lengths to the number of bits of security provided rather than the key length. This is highly confusing for potential users refering to standards documents and or the IANA registry of AEAD algorithm identifiers.
From my perspective, ideally these aeads should follow the naming convention from the rfc, but if not this should be clearly indicated in the documentation so as to avoid pitfalls for new users.
The text was updated successfully, but these errors were encountered:
Trying to adopt the key-size-not-security-level names would also make the naming inconsistent with the aes-gcm-siv crate. And in general, I think it would make things more confusing for users.
We can add a comment to the type declaration for each of the AEADs which provides the RFC5297 name, however I don't think it makes sense to change the actual type names.
The current naming scheme in the AES-SIV uses a different naming scheme for the lengths than rfc5297, naming the algorithm lengths to the number of bits of security provided rather than the key length. This is highly confusing for potential users refering to standards documents and or the IANA registry of AEAD algorithm identifiers.
From my perspective, ideally these aeads should follow the naming convention from the rfc, but if not this should be clearly indicated in the documentation so as to avoid pitfalls for new users.
The text was updated successfully, but these errors were encountered: