Home > Archive > Java Security > January 2006 > Help: SHA-1 problem, requires some expert advice.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help: SHA-1 problem, requires some expert advice.
|
|
|
| I'd be very grateful if someone could help me out with this
problem regarding the internals of SHA-1 and Java. I maintain
an Open Source (GPL) project which implements the Yahoo Instant
Messenger protocol (YMSG) as a Java package...
http://jymsg9.sourceforge.net/
As I'm sure you know, Yahoo occasionally tweaks its login
protocol to lock out third party code. So far I've been able
to match them by updating my own code, based upon changes made
to other third party projects like libyahoo2 and gaim (see
http://libyahoo2.sf.net/ and http://gaim.sf.net/ ). But the
most recent change has caused me some headaches. It's a small
alteration regarding SHA-1, but I'm not sure if I can easily
replicate it in Java.
I'm hoping some knowledgable soul here will throw some light on
the matter - if I cannot solve this problem, then the whole jYMSG
project is at threat!
Below is a fragment of C source (taken from libyahoo2, via Gaim)
showing the two new lines apparently required to fix the login
process. As you can see, it involves an assignment to a variable
'sizeLo'... My problem is, how can I replicate this using the
standard SHA-1 code which comes with java.security.MessageDigest ?
shaUpdate(&ctx1, crypt_hash_xor1, 64);
/* Start of additions */
if(j>=3)
ctx1.sizeLo = 0x1ff;
/* End of additions */
shaUpdate(&ctx1, magic_key_char, 4);
shaFinal(&ctx1, digest1);
My knowledge of message digests and the like is limited. I took
a look at some SHA-1 C source on-line, and it appears that sizeLo
is manipulated when updating the digest, then used when padding
the data(?). But there is a further update following the setting
of sizeLo, so I can't just replicate the behaviour by manually
padding the digest with the correct bytes myself (can I?)
So, I guess my problem amounts to....
1) Can I reproduce the effect of setting sizeLo mid-way through
a digest update, as in the source above, using
java.security.MessageDigest ?
2) If not, can anyone recommend a good, GPL-friendly, SHA-1
implementation in Java, which would facilitate such a thing?
Any help or suggestions gratefully received! :-)
Some links... The SHA-1 C source I studied was here...
http://www.openaether.org/jabberd2/source/util/sha1.c
http://www.openaether.org/jabberd2/source/util/sha1.h
And the web CVS page for the complete source file from which
the sample C fragement was taken is here...
http://cvs.sourceforge.net/viewcvs.py/libyahoo2/libyahoo2/src/libyahoo2.c
-FISH- ><>
| |
| Roedy Green 2004-06-27, 3:57 pm |
| On 27 Jun 2004 06:38:09 -0700, joeking@merseymail.com (FISH) wrote or
quoted :
>Any help or suggestions gratefully received! :-)
Is Yahoo attempting to block others from accessing its IM service
other than with their clients?
Surely they have the legal right to do that, even though it will
inconvenience many.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Michael Amling 2004-06-27, 3:57 pm |
| FISH wrote:
>
> Below is a fragment of C source (taken from libyahoo2, via Gaim)
> showing the two new lines apparently required to fix the login
> process. As you can see, it involves an assignment to a variable
> 'sizeLo'... My problem is, how can I replicate this using the
> standard SHA-1 code which comes with java.security.MessageDigest ?
>
> shaUpdate(&ctx1, crypt_hash_xor1, 64);
> /* Start of additions */
> if(j>=3)
> ctx1.sizeLo = 0x1ff;
> /* End of additions */
> shaUpdate(&ctx1, magic_key_char, 4);
> shaFinal(&ctx1, digest1);
>
> My knowledge of message digests and the like is limited. I took
> a look at some SHA-1 C source on-line, and it appears that sizeLo
> is manipulated when updating the digest, then used when padding
> the data(?).
Yes, the last thing in a padded SHA-1 message is the 64-bit length of
the message in bits. If the ctxl.sizeLo=0x1FF assignment changes the
value of sizeLo, then you won't be able to duplicate the output of the
modified hash using a standard SHA-1 implementation. Luckily this is not
a big problem, as you can implement SHA-1 yourself rather than using new
MessaageDigest("SHA1").
> But there is a further update following the setting
> of sizeLo, so I can't just replicate the behaviour by manually
> padding the digest with the correct bytes myself (can I?)
>
> So, I guess my problem amounts to....
>
> 1) Can I reproduce the effect of setting sizeLo mid-way through
> a digest update, as in the source above, using
> java.security.MessageDigest ?
> 2) If not, can anyone recommend a good, GPL-friendly, SHA-1
> implementation in Java, which would facilitate such a thing?
If you have a little time, you can implement it from scratch. The
specs are in FIPS 180-1 (or FIPS 180-2 at
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf).
Test it with the test vectors from
http://csrc.nist.gov/cryptval/shs/sha1-vectors.zip.
>
> Any help or suggestions gratefully received! :-)
>
> Some links... The SHA-1 C source I studied was here...
> http://www.openaether.org/jabberd2/source/util/sha1.c
Converting this Mozilla Public License C code would appear to be
straightforward. The 32-bit C long becomes a Java int. The 8-bit C char
becomes a Java byte. Just watch out for unwanted sign extension.
> http://www.openaether.org/jabberd2/source/util/sha1.h
> And the web CVS page for the complete source file from which
> the sample C fragement was taken is here...
> http://cvs.sourceforge.net/viewcvs.py/libyahoo2/libyahoo2/src/libyahoo2.c
--Mike Amling
| |
| nobody 2004-06-27, 8:57 pm |
|
> 1) Can I reproduce the effect of setting sizeLo mid-way through
> a digest update, as in the source above, using
> java.security.MessageDigest ?
Unlikely.
> 2) If not, can anyone recommend a good, GPL-friendly, SHA-1
> implementation in Java, which would facilitate such a thing?
>
BouncyCastle (http://www.bouncycastle.org) is good, and has a fairly
liberal license compatible with the GPL. The GNU Crypto project
(http://www.gnu.org/software/gnu-crypto) is also GPL-friendly.
| |
|
| joeking@merseymail.com (FISH) wrote in message news:<dbc5020.0406270538.6fe1a2ab@posting.google.com>...
> I'd be very grateful if someone could help me out with this
> problem regarding the internals of SHA-1 and Java. I maintain
> an Open Source (GPL) project which implements the Yahoo Instant
> Messenger protocol (YMSG) as a Java package...
>
> http://jymsg9.sourceforge.net/
[snipped...]
A big thanks to those who posted and emailed solutions to this problem.
As it turned out, one of the project's users had already crafted a
SHA1 implementation which was capable of being manipulated in the way
needed - so jYMSG is back in business once more! Even so, I'm going
to look into the links you people provided, as I doubt this will be
the last time Yahoo screw about with their login code.
Thanks,
-FISH- ><>
| |
|
|
|
|
|