otp-sha1 not working?
Status: Beta
Brought to you by:
jkf
Menu
▾
▴
#5 otp-sha1 not working?
While setting up skey on a NetBSD system, I tested
PalmKey, Pilot/OTP, and PilOTP. The NetBSD system,
Pilot/OTP, and PilOTP all agree on a one time
password when using sha1, but I get a different result for
PalmKey.
I double-checked the secret which I entered (it
was entered via pasting for all of the palm apps),
along with the count and seed, so I don't think
there's a problem with misinput on my end.
Have you had any similar reports?
I'm using PalmKey 0.9.0.
Logged In: NO
I should add that all three utilities agree when the
algorithms chosen are md4 or md5.
Logged In: YES
user_id=9083
Is there any way to provide test input that shows the problem?
I haven't received any other bug reports of bogus output.
Logged In: NO
Hello,
I noticed the same problem but in conjunction with OpenBSD
but MD4 and MD5 do their job.
I looked into the source code of sha1.c shipped with PalmKey
0.9.0 and compared it with the original from
http://sea-to-sky.net/~sreid/sha1.c.
There is mentioned that there was a bug concerning 16bit
machines which has been fixed. Maybe this should be
incorporated.
Unfortunately I haven't set up a cross-compiler for the
pilot, because only some int variables have to be changed
into long variables.
Logged In: YES
user_id=9083
Interesting... I'll look into the problem. Guess this is
the motivation I needed to get a cross-compiler setup again
after over a year of not working on palmkey. :)
Logged In: NO
Hi,
i'm very new to palm programming. i'm trying to get the
source code to work using Code Warrior 8. any help in
configuring it so that i can get it to work? i'm also
trying to add a timer to the source in order to see how
fast it is able to process the outcome. any inputs or help
is most welcome :D
Thanks!
Logged In: YES
user_id=9083
I'm afraid I can't help with Code Warrior. I would love to
use it, but $500 is a little steep for hobby programming. I
use a gcc cross-compiler under FreeBSD.
As to the timer, I had a nasty hack of a timer in there for
my own purposes awhile ago. All it consisted of was reading
the clock before and after the call to the hashing
routines. At line 555, put the calls just before and right
after the switch block. Afterwards, subtract start from end
and there is your result. To display it, I used a crude
draw routine to write the time directly to the display. The
slowest I saw it on a Palm Vx, was 62 or 63 seconds for
9999 iterations of SHA1.
Logged In: NO
I've done a bit of debugging on this problem, and I'm a
little stunned: for some reason, the last call to SHA1Update
(in SHA1Final -- line 164 of sha1.c) doesn't seem to be
made. Up to that point, the SHA1 routine matches exactly the
results I see from the public domain sources, but it
diverges at that point.
This is enough to explain the differences in results, but
I'm baffled as to why this might be so. I think I need to
dig a little deeper... I'll keep you posted if/when I manage
to get everything working.
Logged In: YES
user_id=321251
After a lot of stuffing around, I've come to the conclusion
that this one isn't easy. The only firm conclusion I've come
to is that it looks like some of the calls to the
SHA1Update() function aren't going through -- no idea why (I
was the one who posted the earlier comment, btw.) Everything
I'm seeing points to that: the context structure isn't being
updated when it should, with it having the same values
before and after the SHA1Update call.
I'm giving up and installing pilOTP instead. I have other
things to do with my time, especially when there's an
alternative available. Sorry, jkf -- I tried, I got
frustrated, I worked around the problem. :)
Good luck,
Stuart.
Logged In: YES
user_id=287299
It seems that I could fix this. The patch is available.
Please tell me how to upload the patch (context diff format).
Logged In: YES
user_id=287299
Both NetBSD, OpenBSD uses RFC2289 for computing sha1.
On the other hand, PalmKey uses obsolete RFC1938 for sha1.
So is the difference.
Logged In: YES
user_id=9083
To submit a patch, at the bottom, check the box
labeled 'Check to Upload and Attach a File', then click the
browse button, locate the file to attach. You can enter a file
description if you want, but its not necessary. Then submit
and the patch will be uploaded and attached to this report.
Logged In: YES
user_id=9083
I'll have to take at that rfc and the Open/NetBSD code to see
whats going on. The tests I've run between Palmkey and
FreeBSD's opiekey match each other.
Logged In: YES
user_id=287299
Hi,
There is no 'Check to Upload and Attach a File' box.
It seems one can attach file only when submitting new bug
report.
I'll put the patch on `Patches' section.