search

dgrijalva / jwt-go

ARCHIVE - Golang implementation of JSON Web Tokens (JWT). This project is now maintained at:
https://github.com/golang-jwt/jwt
MIT License
10.78k stars 994 forks source link

Token signature length seems odd #211

Open joelpresence opened 7 years ago

joelpresence commented 7 years ago

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 like x.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 of z1-z5 will make your jwt signature verification fail. However, tampering with z6 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!

dgrijalva commented 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.