[saag] Re: UPDATED! Re: Errata 5129, 6756, 6702, 765 1 - all HOTP RFC4226

Bleah -

OK - I went back and coded this from the document.   I got the same 
values as are in the test vectors.


What I get is:

5129 - HFDU - Change the complaint to:   Appendix D:  "Table 2 details 
for each count the [DYNAMICALLY] truncated values....". After re-reading 
this and confirming the code, this seems to be the correct fix here.  
The reporter was using a static offset of 0 for all truncations which 
was reasonable unless you read the sample code very closely.   
Clarifying that these were produced using dynamic truncation resolves 
the issue.

6756 - HFDU - this is more correct and matches the sample code (which 
uses hash[hash.length -1] instead of 19).  It also seems to match the 
code in the field.

6702 - Reject - The reporter is mis-reading the code snippet. That 
snippet is how you do a Long to Byte Array - mask and shift to the right 
takes the lower 8 bits and deposits it from the least significant byte 
up to the most significant byte.   The remainder of this suggests that 
the other code has some problems - I'm not going to go any further.

7651 - Reject.  The commentary is interesting and there is a problem 
here with the meaning of "String" or "string", but in this case, String 
is defined as a 20 byte array so changing that to a bit offset would be 
problematic.


I apologize for the confusion - I thought these were valid from 
inspection, but sometimes you just have to write code.

Mike








On 3/9/2025 3:19 PM, Erik Auerswald wrote:
> Hi all,
>
> On Fri, Mar 07, 2025 at 07:09:53PM +0100, Simon Josefsson wrote:
>> Michael StJohns <[email protected]> writes:
>>> https://www.rfc-editor.org/errata/eid5129
>>>
>>>         RFC 4226 <https://www.rfc-editor.org/rfc/rfc4226>, "HOTP: An
>>>         HMAC-Based One-Time Password Algorithm", December 2005
>>>
>>> Recommend:  Hold for Document Update
>>>
>>> At the very least, the referenced section should explain what
>>> parameters it is using to get the results and doesn't.
>>>
>>> I'm not sure whether the values are incorrect or whether the reporter
>>> picked the different parameters from those used by the author. The
>>> fact that this wasn't reported until now suggests either that what's
>>> in the wild is working or that its so lightly deployed that
>>> conflicting versions haven't met in the wild.
>>>
>>> The errata should note that the referenced section is unreliable
>>> without more information.
>> I don't believe this errata is correct.  The values in the RFC seems
>> correct, and I've used the test vectors from the RFC in multiple
>> succesful interops of OATH Toolkit.
> I have implemented HOTP based on RFC 4226 for my RFC 6238-based TOTP
> [implementation][0].  I have used the test data from both RFCs to test
> this implementation.  My implementation is interoperable with at least
> OATH Toolkit, Matt Rubin's Authenticator app, BitWarden client TOTP
> generation, and GitHub TOTP-based MFA.  As such I'd expect the RFC 4226
> test data to be correct.
>
> I would recommend to reject this errata report.
>
> [0]: https://github.com/auerswal/sft/blob/master/thotp.py
>
> Best regards,
> Erik


_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]