This references fixing problems with $hotp/$totp key handling described in:
https://forums.mirc.com/ubbthreads.php/topics/263037Because of the high chance of several types of ambiguous keys (hex vs base32 vs literal text), and to preserve backwards compatibility with existing keys which may not be parsed correctly by $hotp or $totp, a solution to fixing the key handling while preserving backwards compatibility. It would create an additional parameter for $hotp and $totp, and possibly for $hmac too. It would contain $encode-style switch letters, to allow users to make sure their keys are being handled correctly, and to offer a wider variety of valid keys not currently possible.
For example, currently it's impossible to encode a key as a base32 string of length 40/64/128 if the encoded string contains only characters 0-9a-f, because those are instead matched as valid hex strings. It's also impossible to use a case-sensitive passphrase of space-separated words having total sentence length of 20/24/32 because those are instead matched as case-insensitive Base32 strings.
The change would allow compatibility with applications expecting Base16 hex strings of length 40/64/128 to be the binary 20/32/64 byte binary keys of the sha1/sha256/sha512 hashes, as well as enabling other hash lengths to be used as binary keys, such as 96 hex digits for sha384. It would also allow support for Google Authenticator 128-bit keys that are encoded as base32 strings of length 26 without being forced to insert 6 spaces to make the string length be 32.
With an additional parameter containing a switch modeled after $encode switches, the user could exercise more control over keys which could match 2 or more of the current rules for handling keys, and prevent literal text keys being handled as if they're case-insensitive encodings.
--
Current syntax: $hotp(key, count, hash, digits)
Replace syntax: $hotp(key, count, hash, digits, switches)
0 or $null = default = the current method, possibly after fixing rules #1 and/or #3.
1 or b = key is name of a &binvar containing literal binary key
t = Case-sensitive literal text even if it could match base32 or base16 strings.
u = key is uuencoded string
m = key is mime encoded string
a = key is base32 encoded string
h = key is binary decoding of hexadecimal text with an even number of digits. Binary key length is half the length of the hex string.
Unline the default parsing of the key parameter, u/m/a would allow padding characters at the end of the string.
--
Old: $totp(key, time, hash, digits, timestep)
New: $totp(key, time, hash, digits, timestep ,switches)
Switches would be the same group of letters, as $totp appears to be the equivalent of an alias that sub-contracts its work to $hotp:
//var %key password , %ctime $ctime , %timestep 30 , %digits 9 , %hash sha256 , %interval $int($calc($ctime / %timestep)) | echo -a interval %interval ctime %ctime / $totp(%key,%ctime,%hash,%digits,%timestep) same as $hotp(%key,%interval,%hash,%digits)
--
Old: $hmac(text|&binvar|filename, key, hash, N)
New: $hmac(text|&binvar|filename, key, hash, N + new message switches, N+key switches)
$hmac currently has the ability to use binary keys when called from $hotp or $totp, but doesn't have parameters/switches to use them directly. Defaults for the new switches would also be 0 to preserve backwards compatibility.
