2
$\begingroup$

I would like to use JWT but one thing I'm still thinking is ¿what is the best length for the secret?

If I'm using HS512 as a signing method the secret should have a length of 512 bits as far as I understand and I imagine that 512 bits are 64 characters (of 1 byte) because the secret is a string, as far as I understand.

But what I noticed Is that I could use any length I want for the secret, 1 character, 100 characters... It doesn't seem to affect anything outside the fact that bruteforcing 100 characters is way more difficult than bruteforcing 1 character.

I've been worrying about what are the real implications of using which length... Can a longer secret cause any problem or something?

$\endgroup$

1 Answer 1

1
$\begingroup$

If I'm using HS512 as a signing method the secret should have a length of 512 bits as far as I understand and I imagine that 512 bits are 64 characters (of 1 byte) because the secret is a string, as far as I understand.

Correct. HS512 (terrible name) is using HMAC-512, and HMAC is has been defined to take keys that are the same size as the output size by default.

Yes, the keys are keys in one sense. You can think of secrets as BINARY or OCTET STRING, but not as a text string. Most modern cryptography is designed to work on messages consisting of bits (theoretically) and bytes (practically).

But what I noticed Is that I could use any length I want for the secret, 1 character, 100 characters... It doesn't seem to affect anything outside the fact that bruteforcing 100 characters is way more difficult than bruteforcing 1 character.

As you may now understand, using characters is incorrect. You should be using fully randomized bytes, at least at API level.

Of course, those are hard to read from screen and hard to type using a keyboard, so usually these are represented using e.g. hexadecimals if they need to be displayed. In that case each 2 hex characters represents one byte.

I've been worrying about what are the real implications of using which length... Can a longer secret cause any problem or something?

Only in the sense that it may trigger the secret to be pre-hashed while that is unnecessary. However, a 512 bit key would give you 512 bits of security for HMAC, which is well over the maximum security of 256 that we commonly aim for. .

But more importantly, it would be out of spec, as RFC , section 3.2 reads:

A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. (This requirement is based on Section 5.3.4 (Security Effect of the HMAC Key) of NIST SP 800-117 [NIST.800-107], which states that the effective security strength is the minimum of the security strength of the key and two times the size of the internal hash value.)

The HMAC SHA-256 MAC is generated per RFC 2104, using SHA-256 as the hash algorithm "H", using the JWS Signing Input as the "text" value, and using the shared key. The HMAC output value is the JWS Signature.

Note that the output is specified to be base 64, so the output does get "stringified".

$\endgroup$
2
  • $\begingroup$ Only in the sense that it may trigger the secret to be pre-hashed while that is unnecessary what do you mean by "pre-hashed"? $\endgroup$ Commented Mar 10, 2023 at 20:44
  • $\begingroup$ It's in the definition of HMAC, see RFC 2104 section 3. Note that the pre-hash is specific to the block size rather than the output size. SHA-512 has a block size of 1024 bits / 128 bytes, so there is some headroom. $\endgroup$
    – Maarten Bodewes
    Commented Mar 10, 2023 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.