RS384: RSASSA-PKCS1-v1_5 with SHA-384 in a JWT
RS384 is the same RSA signing scheme as RS256 with SHA-384 as the digest. The stronger hash changes the signing input, not the signature length, which is fixed by the key size.
At a glance
- Algorithm
- RS384, RSASSA-PKCS1-v1_5 using SHA-384
- Registered in
- RFC 7518 section 3.3
- Implementation requirement
- Optional
- Key
- RSA key pair, 2048 bits or larger, the same requirement as RS256
- Signature size
- Equal to the key size, so identical to RS256 with the same key
- Verified in the decoder
- Yes, in your browser, with a PEM public key, the same as the other RSA options.
In detail
Only the hash differs from RS256. The token is hashed with SHA-384, the digest is wrapped in the PKCS#1 v1.5 structure with the matching digest identifier, and the result is signed with the RSA private key. Because RSA output is the size of the modulus, the token is exactly as long as it would be with RS256 using the same key, which surprises people who expect a bigger hash to mean a bigger token.
That makes the choice cheaper than it looks and less useful than it sounds. There is no size penalty and only a marginal cost in hashing, but SHA-256 is not a practical weakness in this construction, so the upgrade buys headroom rather than fixing anything. Deployments that use RS384 have usually inherited it from a profile or a certificate policy that specifies SHA-384 across the board.
It is worth separating the hash from the padding. PKCS#1 v1.5 is the older signature padding and it is the part modern guidance prefers to move away from, in favour of the probabilistic scheme used by PS256 and its siblings. Moving from RS256 to RS384 changes the digest while keeping the same padding, so it does not address that concern at all.
The decoder verifies RS384 in the browser given a PEM public key, exactly as it does RS256. Since RS384 is optional in RFC 7518 and less widely implemented, being able to confirm a signature locally is often the quickest way to establish whether a token is genuinely invalid or simply not supported by whatever rejected it.
Examples
// RS256 and RS384 with one 2048 bit key
{ "alg": "RS256" } // signature: 256 bytes, 342 base64url characters
{ "alg": "RS384" } // signature: 256 bytes, 342 base64url characters
// Only the hash inside the PKCS#1 v1.5 structure changes.Things that catch people out
- Expecting a longer token. RSA signature length follows the key, so the third part does not change size when you move from RS256 to RS384.
- Treating RS384 as a fix for PKCS#1 v1.5 padding concerns. If the padding is the worry, PS384 is the change to make, not a longer hash.
- Assuming every verifier accepts it. RS384 is optional in RFC 7518, and plenty of deployments only enable RS256.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →RS256: RSASSA-PKCS1-v1_5 with SHA-256 in a JWT
RS256 signs a JWT with an RSA private key and verifies with the public key. Key sizes, the RS256 to HS256 confusion attack, and verifying in your browser.
RS512: RSASSA-PKCS1-v1_5 with SHA-512 in a JWT
RS512 signs a JWT with RSA and SHA-512. Why the signature length follows the key rather than the hash, and what the decoder needs to verify one.
PS384: RSASSA-PSS with SHA-384 in a JWT
PS384 signs a JWT using RSA-PSS with SHA-384 and a 48 byte salt. What changes against PS256, and how the decoder verifies one in your browser.
PS256: RSASSA-PSS with SHA-256 in a JWT
PS256 signs a JWT using RSA-PSS with SHA-256 and MGF1. How it differs from RS256, why two signatures differ, and verifying with a public key.
PS512: RSASSA-PSS with SHA-512 in a JWT
PS512 signs a JWT using RSA-PSS with SHA-512 and a 64 byte salt. Why very small keys cannot carry it, and how verification works in the decoder.
ES256: ECDSA with P-256 and SHA-256 in a JWT
ES256 signs a JWT with ECDSA on curve P-256 using SHA-256. Signature format, why raw R and S beats DER here, and verifying with a public key.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server