Re: [JDEV] Re: Jabber sigs/crypto

["Donovan Schulteis" <sculdheizo@mindless.com>]

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

    I would think that having the client programs implement this in full,
without the knowledge of the server programs (with the exception of doing a
user authentication thing) would be relatively simple to implement without
disrupting the current protocols.  You could just have the client program
grab the string (actual message) prior to transmiting and encrypt it,
throwing a begin encrypt/ end encrypt string at the ends, and send the
entire phrase as the string (message).  When the recieving client program
sees the proper begin phrase, it will decrypt the message and display that
message to the screen (probably with some code to indicate that the message
was sent encrypted, ie, red text or the words: secure message, or the like).
A "lock/unlock" button on the client program could toggle secure and
non-secure modes.
    Backlashes:
        A user would have to be careful not to use the exact same phrase at
the beginning of an instant message that the encryption function places to
denote encrypted text (ie, ---begin encrypted text here --- ; or whatever)
or else the recieving client program will try to decipher the plain text.
        Users would have to have the same client program, or compatible
programs (which could be easily accomplished by releasing the lib and code
to developers.  Users without client programs would be unable to decrypt
secure messages, and should have a intercepting routine that would stop the
message from appearing, and send a return message stating so.  This would
have to be included in all clients to ensure there is no confusion.  Another
thing for the enabled clients would be to not allow encryption to
Jabber-only "buddies", I don't think ICQ or AIM would work   :)    And
remember to code for the least common denominator machine, the PC's little
endian, to ensure platform portability.
        As with any uses of keys, this could seriously hamper "roaming"
capabilities of the user (for secure modes, that is).  Unless the keys were
stored on the server, which would kinda disrupt the whole idea of the thing
:)

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


    Digital signatures attached automatically to the end of message strings
that are not displayed to the users (or displayed in some subtle form - like
the word "Authenticated").  These could easily be added in the same way to
the end of a message string (using ---begin sig here ---  ; or the like).
Once again, not displayed to the unenabled user.
    Better yet, make an "aware" client program disable the encryption and
sigs for "buddies" that are not tagged with "encryption aware" options (like
a check-box within a "buddy config" menu).  This would allow unaware clients
to not be "readied" for encryption tags.  Aware clients would just alert
"their own user" that they cannot send sigs or encrypted text to that
particular buddy.

>--Privacy
> Encrypting a message so that only the recipient can decode it


    As above (my first paragraph of babble).

>--Authentication
> Validating a login to the server and granting access to resources


    This would require changes to the Jabber server program, to accept and
verify users as they log on, but the program would have to be flexible
enough to allow non-enabled clients to logon without.  But if implemented,
could be done by just verifying the digital signature.

>> Make a 40-bit weak version and a 128-bit one (a la the browsers)?

I would think that 40-bit would be quite suffencient for just one or two
line messages between friends.  To go the 128-bit route, is to open a whole
can of legal worms in distribution and all that.  Although, I think it would
be cool if we went one step further, to say 512-bit, and became the de-facto
standard for transmitting credit card numbers and the like through the
internet, but then again, that's just dreaming.

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


Should be planned for in the code, but not tailored for it.  I think that,
with the exception of authentication, it should be a client to client thing,
that the Jabber servers and transports would pass without knowledge of, or
even being able to tell, the encryption.

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

As soon as my server comes up (should be a month or so, life, you know), I
would be glad to host it, if no other host is found by then.

>--> All crypto solutions can piggyback ontop of the protocol and
>modularization of the server, and provide libs or assist client authors in
>including crypto


Yes, exactly.

>> - Patent issues...I'm starting to look into this...I think the
>> strong frontrunner is the El Gamal public key cryptosystem...
>> [...] I think it's been free since some time in 97). [...]

It has been freed up since Apr 97.  El Gamal sounds good (although I think I
read somewhere that it is "relatively easy" to break, ie, the NSA would have
no problems at all).  The only other non-patented system I can think of
off-hand would be the Blowfish algorithm, by Bruce Schneier, which he
distributes freely.  It can handle up to, I think, 448-bit encryption, but
has a larger memory footprint.  Either would work, I would guess.

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

That would do it.  And key distribution could be done on a special server
somewhere, or done through file transfers with buddies.  Say you're talking
with someone and decide to go secure for one reason or another, do a public
key transfer via the client program, and get his public key by doing an IP
to IP transfer (hey, you trust the guy enough to talk secure with him, so
you can trust him with your IP).  The key management should be part of the
same interface as everything else.  After the keys have been transferred,
then secure talking can begin.

>> ...but I fear that you'll need server-client authetication
>> at each step to prevent a man-in-the-middle attack...

Not necessarily, because you'll be going client to client, and your digital
sig will be at the end of each message to verify it's you.  And as far as
sniffing your key transfers - they're PUBLIC keys, so anyone can have them
anyways.  The only way someone is going to attack is to spoof as you by
logging on to a your server with your digital sig, and then talking securely
with your private keys.  If they have gotten all this, the game is done
already.

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


That sounds really good, I think that this is a do-able plan, and should be
implemented as such.

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


I am too!!!  I don't think that any of the other IM's offer encryption
options, and we could go so far as to include functions to encrypt files for
transfer as well.  I really don't think it would be too hard to implement at
all, with the way Jabber is already set up, so it just becomes an issue of
choosing how and doing it.  If any help is needed, I would gladly TRY to be
of some assistance.

Deej