One library checks for key lengths [1] and throws exceptions, another one doesn't [2] -- in fact it uses a quickstart example that should obviously fail.
[1] https://github.com/latchset/jwcrypto/ [2] https://github.com/mpdavis/python-jose
> 8Jbr+vX5JpFZOW7P1RLs7/ArYy1Az7hrimMfcI3qqBI=
This "small" Key is already 256-Bit.
if decoded to an Array in Java: > java.util.Base64.getDecoder.decode("8Jbr+vX5JpFZOW7P1RLs7/ArYy1Az7hrimMfcI3qqBI=").length * 8
> res7: Int = 256
if you try to decode a jwt with it, it takes forever. (Actually I guess you also need to raise the length of the progam but it's akward since you probably don't know the correct length.Actually I use HMAC-SHA512 with key sizes between 1024-Bit to 2048-Bit.
Edit: Typo
This is utterly pointless security theater. You don't just get more security by rubbing bigger key sizes on it. The key goes through the hash function (twice, in HMAC; once via ipad, once via opad); the HMAC standard defines keys larger than the hash function's block size to go through the hash function first. With good reason, HMAC recommends key sizes to be equal to the hash function's output length; that's 16 bytes (128 bits) for MD5, and 20 bytes (160 bits) for SHA-1.
Relatedly: GCM supports large nonces, but I don't understand why you would ever use anything other than a 96 bit one. (Larger nonces go through GHASH.)
The example provided has a private key length of 32 bits which is far too short to be secure. Based on the JSON Web Algorithms (RFC 7518) the key length must be at least the length of the output hash (256 bits) to be used in accordance with the standard.
> A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm.
https://tools.ietf.org/html/rfc7518