JWT signature [non-]malleability #2256
Replies: 1 comment
-
Yup you're totally right 👍 When we implemented low-s signature checks, we just threw it everywhere that we were checking signatures. However, when we added in the additional check for signature malleability after your report (#1839), we added a flag to the verification logic around whether we allow malleable signatures. So for anything content addressed (repo commits, plc ops, etc), we do not allow malleable signatures. But with JWTs, we do allow them. As you pointed out, there's no particular need for non-malleable signatures on JWTs and enforcing non-malleability could clash with some existing JWT libraries. We do need to update the specs around this to note that it's not required for JWTs. |
Beta Was this translation helpful? Give feedback.
-
At some point in the past, when I was writing picopds, the sandbox AppView seemed to want low-S signatures in JWT bearer tokens, and so I jumped through some hoops to generate low-S signatures, and everything worked.
I tried again today, and it seems like the sandbox AppView is now also accepting high-S signatures, which would be nice because it means I could drop my hacky workarounds - I don't think there's a particular need for JWT signatures to be non-malleable?
It's possible I was mistaken, either back then or now, but it looks like the behavior has changed at over time. Which version is correct?
The docs at https://atproto.com/specs/cryptography#ecdsa-signature-malleability talk about signature [non-]malleability in general, but don't make specific reference to JWT.
Beta Was this translation helpful? Give feedback.
All reactions