Cyberchef: Bug report: HOTP passcodes not compliant with RFC 4226?

[chudel]

Summary

Hello,

In comparing CyberChef's HOTP with my own (unrelated) implementation, I am getting different results. In troubleshooting my code, I'm not sure how to validate that the HOTP function within CyberChef is working properly.

Example

If I look at RFC 4226 and use the reference test cases in Appendix D, the following secret key should generate the following OTP values (for their corresponding counter value):

````
The following test data uses the ASCII string
"12345678901234567890" for the secret:

Secret = 0x3132333435363738393031323334353637383930

              Truncated

Count Hexadecimal Decimal HOTP
0 4c93cf18 1284755224 755224
1 41397eea 1094287082 287082
2 82fef30 137359152 359152
3 66ef7655 1726969429 969429
4 61c5938a 1640338314 338314
5 33c083d4 868254676 254676
6 7256c032 1918287922 287922
7 4e5b397 82162583 162583
8 2823443f 673399871 399871
9 2679dc69 645520489 520489

````
But the HOTP values in CyberChef are:

| Count | Hexadecimal | Decimal | Reference HOTP | CyberChef HOTP
|--------|-----------------|-----------|-----------|----------------------|
| | | b32 Secret --> | GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ | AEBAGBAFAYDQQCIAAEBAGBAFAYDQQCIA
| 0 | 4c93cf18 | 1284755224 | 755224 |995237
| 1 | 41397eea | 1094287082 | 287082|054065
| 2 | 82fef30 | 137359152 | 359152|197193
| 3 | 66ef7655 | 1726969429 | 969429|216912
| ... | ... | ... | ...|

Of course, I concede that I may not be supplying the input values correctly (in which case I'll gladly take my correction and suggest an enhancement to the documentation for this item).

Please let me know if you agree with this issue and, if an immediate fix is not at hand, I'll volunteer to research and contribute.

[bwhitn]

This looks like it may be something to do with Base64.runTo32 as it takes a bytearray and is being fed a string. Maybe this would be good to employment as a unit test?

[n1474335]

Closed in #214