Reject zero-length Buffer/KeyObject secrets for HS* algorithms, like empty strings #1052

Describe the problem you'd like to have solved

jwt.sign() and jwt.verify() reject an empty string secret (secretOrPrivateKey must have a value / secret or public key must be provided). A zero-length Buffer, or a secret KeyObject created from one, is truthy, so it gets past that check. HS256/HS384/HS512 then sign and verify with an empty HMAC key.

In practice this comes from configuration, not intent. For example, the secret is read from a file that exists but is empty (fs.readFileSync(path)), or it is decoded from an unset variable (Buffer.from(process.env.JWT_SECRET ?? '', 'base64')). The application keeps working, because it signs and verifies its own tokens, but anyone can compute valid tokens for an empty key. With '' the same mistake fails loudly.

This has been visible since auth0/node-jws#51. It is related to #286 and #335, which cover missing or empty string secrets.

Describe the ideal solution

Treat a zero-length symmetric key the same way as an empty string for HS* algorithms. After the key has been converted to a KeyObject, reject symmetricKeySize === 0 in sign and verify, using the existing error messages. algorithm: 'none' behaviour stays the same (#386).

Alternatives and current work-arounds

Applications can check the key length themselves before calling the library.

Additional context

I have a small PR ready with tests and will link it here.