[JDEV] Re: Jabber sigs/crypto

["Corbett J. Klempay" <cklempay@acm.jhu.edu>]

>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
>

Question: she will likely have me (in my proposal) outline an intermediary
level of completion which is pretty much for certain achievable within the
semester.  So the question is: if I only have time to implement one or the
other, which is more key: encryption or authentication?

>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 :)

Hmmm...won't that make it difficult for me to do any work, since I'm in the
US?  Or am I allowed to conduct work here, but have the work actually be
taking place on a foreign server (like ssh'ed into some server in Australia
or something)?  Damn US export controls are retarded.

>-->	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
>

One approach that was suggested to me (that is apparently fairly
commonplace; I don't know how it does or doesn't work as far as export
controls go) is to have it so that the encryption framework is set up to
work with 128 bit keys, but all of the key-related stuff "dumbs-down" the
key down from 128 to an effective length of whatever is desired by just
applying 0xFFFF as much as needed to leave as much 'real' key as is desired.

>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.  
>

Hmmm...yeah, I think the encryption can be done without requiring any
server changes, but key distribution requirements for any authentication
work will need server changes...

CJK