[Triplesec] HOTP implementation

[Javier Tellez <av...@yahoo.es>]

Hello, 

first of all, thanks to Alex for redirecting me here, and hello to all the members of the group.

My main interest is the development of applications for mobile devices, and lately im working on implementing a 2-factor authentication mechanism for J2ME.

Hotp class implements RFC4226 "HOTP: An HMAC-Based One-Time Password Algorithm".
In that class,

hotp.generate(secret, counter, digits) uses 
int offset = 0; 


but in the RFC4226 that offset is the least significant nibble from the last byte of 
hotp.stepOne() output (the 20 bytes from hmac-sha1(k,c)), that is


int offset = hmac_result[19] & 0xf; 


Is there any reason for that? Alex told me that it could be a bug. 

Thanks, 
best regards, 
Guillermo 

Re: [Triplesec] HOTP implementation

[Alex Karasulu <ak...@apache.org>]

Javier,

Thanks for posting here.  Yes now that I have had some time to think about
this it is a bug.  If you
have the time feel free to file a JIRA issue on this and attach a patch.
We're looking for a few good
committers to get involved with this.

Thanks,
Alex

On 5/21/07, Javier Tellez <av...@yahoo.es> wrote:
>
>  Hello,
>
> first of all, thanks to Alex for redirecting me here, and hello to all the
> members of the group.
>
> My main interest is the development of applications for mobile devices,
> and lately im working on implementing a 2-factor authentication mechanism
> for J2ME.
>
> Hotp class implements RFC4226 "HOTP: An HMAC-Based One-Time Password
> Algorithm".
>
> In that class,
>
> hotp.generate(secret, counter, digits) uses
> int offset = 0;
>
> but in the RFC4226 that offset is the least significant nibble from the
> last byte of
> hotp.stepOne() output (the 20 bytes from hmac-sha1(k,c)), that is
>
> int offset = hmac_result[19] & 0xf;
>
> Is there any reason for that? Alex told me that it could be a bug.
>
> Thanks,
> best regards,
> Guillermo
>