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
While unsorted context keys are generally tolerated in the ESDK header itself, when using the AES-GCM keyring this is used to canonicalize the encryption context before entering it into the AAD for the AES-GCM keyring. As such, when certain unicode characters (eg Cryllic characters) are used in encryption context keys, the sort order can disagree both with other ESDK languages, and even within the JS ESDK (depending on locale selection). @seebees has more specific examples of keys that can cause this failure mode.
The correct sort order is a binary comparison of the UTF-8 encodings of the encryption context keys (this is what the C ESDK does, at least).
Security implications: Even with the locale sort (which may not be a total ordering), the AAD encoding is unambiguous (keys and values are unambiguously delineated) and therefore it's hard to see a way it could lead to incorrectly accepting ciphertexts that shouldn't. As such I would consider this to be purely a compatibility issue unless proven otherwise.
The text was updated successfully, but these errors were encountered:
The encryption context serialization code incorrectly sorts context keys using a locale-dependent comparator:
aws-encryption-sdk-javascript/modules/serialize/src/serialize_factory.ts
Line 86 in bf15b3a
While unsorted context keys are generally tolerated in the ESDK header itself, when using the AES-GCM keyring this is used to canonicalize the encryption context before entering it into the AAD for the AES-GCM keyring. As such, when certain unicode characters (eg Cryllic characters) are used in encryption context keys, the sort order can disagree both with other ESDK languages, and even within the JS ESDK (depending on locale selection). @seebees has more specific examples of keys that can cause this failure mode.
The correct sort order is a binary comparison of the UTF-8 encodings of the encryption context keys (this is what the C ESDK does, at least).
Security implications: Even with the locale sort (which may not be a total ordering), the AAD encoding is unambiguous (keys and values are unambiguously delineated) and therefore it's hard to see a way it could lead to incorrectly accepting ciphertexts that shouldn't. As such I would consider this to be purely a compatibility issue unless proven otherwise.
The text was updated successfully, but these errors were encountered: