$hmac returns an invalid string when using hash sha384 or sha512 when key length is 65-128 bytes (not characters). The likely cause is treating these hashes as having the same 512-bit chunk/block (not digest length) size as sha224, sha256, sha1, and md5. sha384 and sha512 actually have a 1024-bit (128 bytes) chunk/block size.
Because they use HMAC as one of the steps in calculating their output, this also has a related effect on $hotp and $totp when their key parameter has the same length and they're using either of these 2 hashes.
All other HMAC length/hash combos i've tested are good, and this does not affect the $sha384 and $sha512 identifiers when used separate from HMAC.
2. change digest dropdown to sha512
3. Paste 65-byte clipboard into the 'string' and 'secret key' boxes
4. Compare computed HMAC against the identifier
5. Repeat #3-4 after changing dropdown to sha384
//clipboard $str(z,65) | echo -a sha384 $hmac($cb,$cb,sha384)
current: sha384 32066b46d8b36d0ba060a32c6798256c9e20c812b08bbc3814e1d512353cc01172cfc426d972ca233cf7793aa4d15e9f
website: sha384 02695828d419569796c74efb9e854f345106da0889c19faf31cdab86221cbbc492b480ebf30d8e4cb7f1d734f2980ed1
//clipboard $str(z,65) | echo -a sha512 $hmac($cb,$cb,sha512)
current: sha512 dbddf5022df3b5dcabc94d6dd540f27a069706c6dcd9441de73c781f8941380a2025f7514fa3fd329a354b69d885d2e3d9305ca138b8d3a86737d193f20e162b
website: sha512 c90181b3a36d1bf889954a73a29a1cc86a6ee08e8f4f80e57b066cfcc81a79bcf3c050809c88380802355fad74786c25f42330a9ebb8e275230c519c280e4efa
The issue affecting $hotp and $totp is different than the issue affecting all hashtypes i reported in the thread below, where text passphrases can be interpreted as base32, base32+spaces can be interpreted as hex, etc.
All the test vectors I find for HOTP and TOTP used shorter keys, but I believe that fixing this HMAC chunk size should result in these changed outputs without altering the $hotp or $totp code at all:
//echo 3 -a $hotp($str(!,65),123,sha512,9)
//echo 4 -a $totp($str(!,65),123,sha512,9,30)