Open joelpresence opened 7 years ago
Great question. I actually don't know the complete answer. I'll look into it when I have a chance. Here are some useful clues:
The spec expands RS512
to 'RSASSA-PKCS-v1_5 using SHA-512 hash algorithm'. Most of that work is implemented in the standard library's crypto algorithms. PKCS encoding has room for padding/comments sections. It's possible the tail of the signature is one of those.
In terms of size, I'd assume the above encoding has something to do with it being larger than expected. It's also worth noting that base64 encoded data is ~1.33x the size of the original binary content.
Hi,
Thanks for making this available! I really appreciate your work. :-)
I'm using this in an API server, with an RSA 2048-bit key (public and private) and signing method
jwt.SigningMethodRS512
. The token that gets produced is always something likex.y.z
which is according to the spec format.However, the format of z, the signature, looks odd. For example, it's always 342 bytes long. And it always has 6 parts, as in
z1_z2_z3_z4_z5_z6
. Tampering with any ofz1-z5
will make your jwt signature verification fail. However, tampering withz6
does not cause a signature verification failure. Why?Any tampering with x or y, the header or payload, results in a verification failure. That's good! :-) But how come I can fiddle with the last portion of the signature and have the verification pass? That doesn't make sense to me ... Is this part of the signature redundant?
Also, when using RSA512, shouldn't the signature be 64 bytes long (in binary)? I would expect that when Base64 encoded, the original binary 64 bytes would be shorter than 64. So why is the signature 342 bytes long? I can't relate that back to the RSA512 hash or RSA 2048-bit PK ...
Thanks again for making this awesome library available!