3 ms·
actually 256-bit key size is not a "big" burden for people. I've seen lots of JWT implementationens which use key sizes > 1024 bits. Consider the Mime64 encoded
by merb 10y ago
actually 256-bit key size is not a "big" burden for people.
I've seen lots of JWT implementationens which use key sizes > 1024 bits.
Consider the Mime64 encoded Bit String:
> 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
- lvh 10y ago> Actually I use HMAC-SHA512 with key sizes between 1024-Bit to 2048-Bit. 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.)