It would be great if $hmac supported syntax which allowed binary keys instead of requiring the key be seen as a UTF8 text string. HMAC is usually used either without a key at all, as being a better quality hash than the $sha*() functions, or is used with binary keys.

By enabling binary keys, there are several test vectors in RFC 2104 and 4868 whose keys are not UTF8 text, which could then be matched.

The subroutine used by $hmac can handle non-UTF8 binary keys, such as when it receives them from $totp inside a base32 key, or when a too-long HMAC key is replaced by the binary hash digest of it, but it doesn't currently have an interface that lets the user feed the binary key directly to $hmac.


2 ways this can be given syntax that doesn't affect backwards compatibility:

* extend the current N parameter so that it can recognize that the $2 key parameter contains the hex encoding of a binary string
* a 5th parameter to contol how $2 is seen, similar to how the 5th parm controls $1.

To combine this into the 4th N parameter, the interior logic could change to:

Message format = $and($4,3) -> values 0/1/2
Key Format = $iif($and($4,4) == 4,Hex,UTF8 Text)

That wouldn't affect existing syntax, but would let N=1+4=5 be Message=&binvar Key=Hex, or N=4 be 0+4 for Message=Text Key=Hex.

Having a separate parameter would let the same syntax be used for both $4 $5, except for the addition of another numeric that means 'hex'.

Hex could either be the next number '3', or could be the more intuitive 4 from 2^4=base16.