[JDEV] Re: Jabber sigs/crypto

[Jeremie <jeremie@jabber.org>]

<heads-up>
Corbett sent this to me directly, and said it was OK if I
just reply directly to the list.
</heads-up>

> Hey there...I think I wrote one comment when the Jabber list first got
> going, saying how we needed digital sigs and/or (preferably an and) crypto
> in Jabber.  Well, this semester I have a crypto class...with a final
> project that's 40% of our grade...and got to thinking...perhaps I might be
> able to make adding one or both of these things into Jabber?  I then wrote
> my professor...she said it sounded pretty cool, and then even wrote
> another response about 10 minutes later, saying she'd been to the Jabber
> site and it looked to be a neat project :)  So, I'm not yet totally for
> sure on it...since she's going to start teaching the class this coming
> week (the TA has been teaching it so far, as it was just classic
> old-school ciphers; kind of background stuff) and will soon be having us
> create project proposals that will have to be turned in to her...but since
> she's already pretty much given a thumbs-up to the concept, I expect I'll
> probably be working on it.  Something extra tasty I noticed while wasting
> time in the library yesterday...I picked up some several-year old (like
> 92-93ish, I think) proceedings from a math and/or crypto conference...and
> just flipping through the contents...she (along with one or two other
> people) had published a paper about some aspect of digital sigs....so I
> think that's a pretty good sign she'll be a good source of expertise on
> what/how I should do things (algorithmicly, at least).  (If you're
> curious, you can see her page...she's a professor in the Math Sci dept,
> but I think she has some CS association, as her page is hosted there (but
> linked off of Math Sci): www.cs.jhu.edu/~cowen).  So, some things I was
> thinking of:

First off, this is WONDERFUL!  It would be GREAT to have someone dedicated
to adding in a decent level of security/encryption!

> 
> 	- What's the best way for me to figure out how I'll plug this
> stuff into the Jabber architecture?  Should I just start sifting through
> the protocol or something?

Well, there are different things that can(need to) be done and each of
them may need to be done differently.  IMHO, here are the needs:
--Identity
	Verifying that the user you received a message from is really them
	(and that the message hasn't been modified)
--Privacy
	Encrypting a message so that only the recipient can decode it
--Authentication
	Validating a login to the server and granting access to resources


> 	- Annoying export bullshit...if I just do digital sigs (which is a
> strong possibility, as sigs aren't export controlled, and she'll probably
> want me to have an intermediary level (i.e. just sigs instead of
> sigs+crypto) deliverable work that can be done by the end of the
> semester), it won't be a problem...but where crypto is concerned...how do
> we handle that?  Make a 40-bit weak version and a 128-bit one (a la the
> browsers)?

IANAL, and I don't follow the crypto stuff, but I'd like to totally avoid
any hairy mess here at all... Luckily, I believe that as it stands Jabber
and the protocol is completely ready to be outfitted with any crypto setup
and not have to modify anything internally to allow this...

Here's my take, since as I understand it we'll get into a mess if we even
think about including crypto stuff or even making special "hooks" for it
in the code:  
-->	Those wanting to work on crypto for jabber set up completely
separate server to host the code(probably best if it's international?) but
are free to use this list to discuss it as long as no code snippets are
sent to the list :)
-->	Jabber.org can point all security/crypto/encryption inquiries and
pages/links to the other server, as a separate project(similar to SSL for
Apache)
-->	All crypto solutions can piggyback ontop of the protocol and
modularization of the server, and provide libs or assist client authors in
including crypto

I might be a little bit "too safe" here, but I'd rather start out as safe
as possible, and relax a little more when we know we can :-)


> 	- Patent issues...I'm starting to look into this...I think the
> strong frontrunner is the El Gamal public key cryptosystem...like RSA, it
> can be used for both authentication _and_ encryption...but unlike RSA,
> it's totally free of patent baggage (it's the first one to have its patent
> expire..I think it's been free since some time in 97).  While RSA gets its
> strength from the difficulty of factoring large primes, El Gamal is based
> on discrete logs.  I forget, but I think that PGP 5.x and up might use El
> Gamal in the free versions (and the commercial version allows you to use
> RSA as well...which also makes it backward-compatible with PGP 2.6.x
> keys).

Like I said, I know little to nothing about this stuff(although I find it
quite interesting), but others feel free to jump in here!

> 	- Architecture changes/extensions?  If a public-key based
> cryptosystem is in place, there will have to be some kind of
> infrastructure to deal with key distribution/management.  This is not
> really too nasty, I think...but the one nasty thing I haven't thought of
> how to handle yet is how to totally avoid (or keep to a BARE minimum) the
> authentication between client and server...I'd like to keep pretty much
> all authentication between client->client (with the server just acting as
> an intermediary)...but I fear that you'll need server-client authetication
> at each step to prevent a man-in-the-middle attack...but the problem is,
> considering how computationally expensive these operations are, server
> scaling would be _severely_ hampered, as too much authentication would
> bring these machines to their knees (and we can't be like: "minimum server
> platform: 21264" :)

The best way to start adding crypto in, is going to be via the <ext>
mechanisms built into the protocol.  For identity, public keys could be
sent in the <ext></ext> tags.  For privacy the actual message content
could be encrypted and the keys again could be in the ext tags to help
decode the message.  But for authentication(since it's client<->server
instead of client<->client like the others) the <user></user><pass></pass>
tags could contain any of the needed char data to validate the incoming
connection, and would be passed on to a special crypto module to actually
handle the authentication for that user.  

I really don't know how the mechanics of the actual encryption/decryption
would work, but I'm pretty sure they can all easily be employed on top of
and independently of the main distro...  If nothing else, Jabber isn't
that complicated, and it wouldn't be difficult to create "secure" clients
and a "secure" server that is completely separate, but can talk to other
"insecure" Jabber servers directly.

> 
> Any thoughts/suggestions?  I'm just starting to try to sift this stuff out
> in my head, as I'll have to have a decent idea of how it will work for
> when I write my project proposal.

I'm really excited about this!  I definately want crypto/mondo-security,
but don't know enough about it so I just tried to make sure Jabber is
extensable enough so that someone who _does_ know can add it easily :)

Thanks!!!

Jer


> 
> ------------------------------------------------------------------------------
> Corbett J. Klempay			         Quote of the Week:
> http://www2.acm.jhu.edu/~cklempay  "Don't judge a man's wealth -- or his
> 				    piety -- by his appearance on Sunday."
> ------------------------------------------------------------------------------
> 
> 
>