Re: kjabber sha1

[Jim B. <Bla...@yi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 April 2002 01:58 am, dominique devriese wrote:
> Op dinsdag 30 april 2002 10:23, schreef u:
> > OK, now that I have had some time to apply and test your patch, it lo=
oks
> > like there are a couple things we need to fix.  The hash that the jab=
ber
> > server uses is actually computed by concatenating the session ID (sen=
t by
> > the server in the "id" attribute of its <stream> tag) with the passwo=
rd,
> > running this string through the SHA-1 algorithm to generate a 20-byte
> > hash, then converting the hash into a 40-character hex representation=
=2E=20
> > So the code has been changed to grab the session ID, which is working=
,
> > but the other two are not.  First, we need a 40 character hex string.=
=20
> > Write now the code only produces a 32 char string (probably borrowed =
code
> > from MD5). I changed the ksha file and added the extra 4 %02x, but th=
is
> > is still generating bad hashes.  I haven't been able to follow the co=
de
> > very well, so I am still not sure where the problem is. For refrence,=
 the
> > psi client has this working, so here are some of the values.
>
> Hi, i've implemented the code directly from the RFC
> (http://www.ietf.org/rfc/rfc3174.txt?number=3D3174)
> There will prolly be some bug in there somewhere: as i said, i hadn't b=
een
> able to test the code yet...
> Or maybe the RFC and the w3c (which the jabber protocol reference point=
s
> to) are talking about different versions of the hash (?)
> Anyway, i'm willing to fix this for you if you want, but first read
> below...

As far as I know the versions should be the same, although I haven't look=
ed at=20
it much.  I was kind of putting that stuff off :)

>
> > hash string | psi's digest | ksha1's digest
> > 1784195969wrongpass | 81f1efd91575d752e4ad228c56345d60adb60210 |
> > 61b761b114dd10407cb463dfda10aad9cd274fd3
> > 184972892pass | 187d36293171046be561dfc4d6c62cec09c8c70b |
> > 33f34de9f548b1c9f6f3271b6785602912ef463b
> >
> > Also, is it necessary to link to the provided ksha1 file, or can we j=
ust
> > use the kmdcodec files in kdelibs?  Thanks for the info and help,
>
> Well, this is the problem: in the patch i sent you, i had included it a=
s a
> patch to kjabber.  But since then, kjabber seems to have disappeared fr=
om
> cvs (?).

kjabber is a module under kitclient. So just go to the sourceforge kitcli=
ent=20
page and checkout the kjabber module.  A working version with a qsock=20
implementation is availible with the -D "1/21/02 10:00:00 UTC" option, wh=
ile=20
HEAD uses kextsock.=20

> Also since then, i had thought it was best to just put this in
> kmdcodec.h/cpp, which is done (it was in cvs the last time i checked), =
but
> i have been talking with George Staikos, and it prolly won't stay there
> (he's not sure what to do with KMD5 either).
> The problem is that if we start putting all these hash algo's in the
> kdelibs, this can become unnecessarily large, and since most kde apps d=
on't
> require them, it doesn't seem like the right way to go...

Sounds reasonable. I'll just keep using my local version then (with the=20
correction for hexDigest).

>
> In the mean time, i also lost the patch i sent you (i've been doing lot=
s of
> things wrong here :(
>
> Conclusion: it's not clear yet what's going to happen to this code, but=
 if
> you want, and send me your current code, or tell me where to get it, i'=
m
> willing to fix this SHA1 implementation, but it would have to be in you=
r
> source only, i do think it can use the kcodecs class from kmdcodec...

The HEAD branch in cvs contains the original ksha files that you sent me =
with=20
your modifying patch. =20

>
> domi
> PS: what is the deal by the way with KJabber and Psi, i can't find kjab=
ber
> anywhere in cvs, and psi only contains a libpsi...  Why don't psi and
> kjabber merge ?

Psi is using Qt only, kjabber is being designed to work with KDE.  Althou=
gh=20
there is not much of a difference here, it is important.  Specificly, the=
 use=20
of KExtendedSocket instead of QSocket is critical for people behind a=20
firewall or using SOCKS, since kextsock can use global settings and we do=
n't=20
have to implement these protocols ourselves in the client.  Also, psi is=20
using a more C style implementaion (structs) of messages, presnece and=20
packets.  I have tried to develop more robust objects that should be able=
 to=20
be more extendable in the future.  psi aslo parses the xml from the serve=
r=20
without relying as much on Qt, while I have tried to use QDom for almost =
all=20
XML manipulation.  On the other hand, psi has a well working library with=
=20
many features, and very active development.  Kopete also seems to have a=20
jabber plugin springing up, but again it is using qsocket, which confuses=
 me=20
a little since it is a kde program.  I haven't read its code closely at a=
ll,=20
so I don't have much else to say about that.

In any case, I think a working KSHA library would be usefull elsewhere in=
 KDE,=20
so I would be happy to help test this one and I think it would be a good =
idea=20
to continue its development.  kit...@li... is being =
used=20
to discuss kjabber and kit, and you can talk to either me (Blackfoot) or =
Neil=20
on #kde on the openprojects network if you have any general questions. =20
Thanks for your help,

- --=20
Jim Blomo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjzPMh0ACgkQUlS7JsvyVRI+LwCeJWzQRhhpynTJoLOMtuL1AHFq
+v0An2FyhSaoVnIq4cBom06SP2Qs7wh2
=3DiD3D
-----END PGP SIGNATURE-----