Open bannable opened 1 year ago
It looks like k4.secret-wrap.pie-fail-1
has this same problem.
k3.secret-pw-fail-2
and k4.secret-pw-fail-2
have this same problem.
Suggested alternatives:
# k3.secret-pw-fail-2
AKjP_XFziwwUW8t0xppL3ecIgaOzfSEx-5-UQG36jJ8AACcQUeD46ydUwIkMOqkXWFvacyf_eaH1BTMlJsdCy6ZhemmaFMZTclOD9LrOwCVnmhlCDQEePilxQEfvPsRM5cL_yxx1bWL0wjS4GAQABQiCvGyQTi_LGlbMnYuiZfxWgpqNJpAI6jx71m6s4f6wZIg68Q
# k4.secret-pw-fail-2
AH54ImYiJUSDhTn7vzBI4QAAAAAQAAAAAAAAAwAAAAFBZythnpR02Zza64_y9DuKHeyZVEP_vZx0Y721aIry1rZc70cR08Jb2rgV4pcqR9in25TvA4pV7L4kT3r-0b-5a8Z7wk35D0zOnPLEJloAHf2XEYGleFReV2-tiV1T79G6OhlATgd-bJbXjRqlEOCsk_-pRdSsCeE
While the value can be parsed under RFC 2045, it is problematic when using a stricter RFC 4648 coder, such as Ruby's
urlsafe_decode64
orstrict_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-2
which 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-2
with the first byte of the tag replaced by\x00
, and exercises the intended code path: