paserk value for k3.secret-wrap.pie-fail-1 is not valid RFC 4648 Base64 #18
Comments
|
It looks like |
bannable
added a commit
to bannable/paseto
that referenced
this issue
Nov 26, 2022
I've modified the test vector for k3.secret-wrap.pie-fail-1 because, in the course of implementing these vectors, I discovered that the paserk value is not valid Base64. Reported here: paseto-standard/paserk#18 In the mean time, I've replaced the badly encoded value with an encoded value that replaces the first byte of the tag with \x00
|
Suggested alternatives: |
bannable
added a commit
to bannable/paseto
that referenced
this issue
Nov 29, 2022
- Versions have been refactored to be classes instead of modules, and things that are versioned are expected to respond to a .protocol method that returns an instance of a Interface::Version class. An instance of such a class is comparable with other instances of the same, and also with any string that matches the associated version, e.g. "v3". - Enabled sorbet final checks and added final sigs to several classes - IncorrectKeyType is gone in favor of LucidityError. A LucidityError is any violation of Algorithm Lucidity properties. - Replaced most string concatenation operations with interpolation for improved performance - Added local-pw and secret-pw support for both v3 and v4 - Made PIE version detection more robust against absense of RbNaCl - PIE::Version3 -> PIE::PieV3, PIE::Version4 -> PIE::PieV4 - Util.secure_compare now uses libsodium primitives when available for significantly improved performance. - Fixed pattern matching order in Token parsing to have the more specific case first I'm not entirely happy with the interface for accessing PBKW at this point, because it requires explicitly initializing with a version, but it works well enough. The tests for PBKW v4 are SLOW as hell due to the test vectors including parameters with very high memlimit and opslimit values. I'm leaving them enabled for now, but if it eats up too much CI time, they'll be changed to run only on demand. The test vectors have been modified as in ef77549 due to more buggy encoding. See: paseto-standard/paserk#18
bannable
added a commit
to bannable/paseto
that referenced
this issue
Dec 3, 2022
I've modified the test vector for k3.secret-wrap.pie-fail-1 because, in the course of implementing these vectors, I discovered that the paserk value is not valid Base64. Reported here: paseto-standard/paserk#18 In the mean time, I've replaced the badly encoded value with an encoded value that replaces the first byte of the tag with \x00
bannable
added a commit
to bannable/paseto
that referenced
this issue
Dec 3, 2022
- Versions have been refactored to be classes instead of modules, and things that are versioned are expected to respond to a .protocol method that returns an instance of a Interface::Version class. An instance of such a class is comparable with other instances of the same, and also with any string that matches the associated version, e.g. "v3". - Enabled sorbet final checks and added final sigs to several classes - IncorrectKeyType is gone in favor of LucidityError. A LucidityError is any violation of Algorithm Lucidity properties. - Replaced most string concatenation operations with interpolation for improved performance - Added local-pw and secret-pw support for both v3 and v4 - Made PIE version detection more robust against absense of RbNaCl - PIE::Version3 -> PIE::PieV3, PIE::Version4 -> PIE::PieV4 - Util.secure_compare now uses libsodium primitives when available for significantly improved performance. - Fixed pattern matching order in Token parsing to have the more specific case first I'm not entirely happy with the interface for accessing PBKW at this point, because it requires explicitly initializing with a version, but it works well enough. The tests for PBKW v4 are SLOW as hell due to the test vectors including parameters with very high memlimit and opslimit values. I'm leaving them enabled for now, but if it eats up too much CI time, they'll be changed to run only on demand. The test vectors have been modified as in ef77549 due to more buggy encoding. See: paseto-standard/paserk#18
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
While the value can be parsed under RFC 2045, it is problematic when using a stricter RFC 4648 coder, such as Ruby's
urlsafe_decode64orstrict_decode64, as the test vector cannot exercise the intended code path for an invalid authentication tag.This appears to be because, when the test vector was written, the value was created simply by modifying the encoded Base64 value instead of modifying the underlying payload and re-encoding.
Even with an RFC 2045 coder, the final 8 bytes are dropped compared to
k3.secret-wrap.pie-2which it appears to be modified from.Reproducer (in ruby)
Expected
Actual
My suggestion is to change the value to a valid RFC 4648 string. For example, this is the value from
k3.secret-wrap.pie-2with the first byte of the tag replaced by\x00, and exercises the intended code path:The text was updated successfully, but these errors were encountered: