Re: [JDEV] Re: Jabber sigs/crypto (fwd)

[mskala@csc.UVic.CA]

Hello... Quetzalcoatl Bradley asked me to look at this and comment to the
list, as I'm a crypto geek too.  I'm not *on* the list (probably will join
very soon) so ccing responses to me would be appreciated.  (Ideally,
responses would be cced to the reply-to address above instead of this
school account that gets checked less frequently, but that may be too much
to ask.) 

On Wed, 17 Feb 1999 qbradley@csc.UVic.CA wrote:
> --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

I think authentication in the other direction may be important, too - in
other words, the client has to know that the server they're talking to is
really the server they want to be talking to.  I don't know much about how
Jabber works, but my understanding is that the server, not client, is
responsible for things like knowing who is on my "friends" list and
notifying me when one of them logs on.  Well, my "friends" list (or
whatever you call it) could reveal things about me that I don't want just
anyone to know - e.g. my wife gets a copy and finds my mistress's name on
it.  I'd rather have some assurance that the server I'm giving my personal
data out to is really the server I intend to be giving it out to.

Reading further I see that this is probably something you want to avoid.. 
you want to treat the server as just a dumb insecure message forwarder. 
That makes very good sense as far as protocol design is concerned.. it
does mean, though, that clients have to understand that the server isn't
trusted in the crypto sense.  In other words, my mistress had better be
using a meaningless psuedonym everywhere outside the end-to-end encrypted 
connection between her client and mine.

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

IMHO, it is a *really bad idea* to have a "weak" version, because then
people will use it.  They'll have a false sense of security, and that
seems to me like a bad thing.  With something like crypto that the general
public isn't qualified to make judgements about, I think those of us who
*are* capable of making judgements about it, have a responsibility not to
give the masses enough rope to hang themselves.  I'd prefer to see a
protocol with two options: no security, or meaningful security.

As for export control, if you're in the USA, yes, you have a problem. 
Really, you need an export license (IANAL either, but I'm pretty sure of
this) *even for 40-bit crypto*... it's just that they're much easier to
get, for 40-bit crypto.  One reason is that it's possible to make 40-bit
crypto strong enough to inconvenience the NSA if you, for instance, use a
really time-consuming key setup that makes brute force difficult.

I think digital signatures can be exported, although I heard something
about a 1024-bit limit (which is the minimum length of public-key I'd
consider acceptable).  Or maybe that's just the limit built into DSA.

My opinion on export control:  move.  :-)  Actually, my opinion is that
you should try to make a good protocol, fully document the protocol, and
then either do the print-out-and-scan dance like PGP did, or seek
volunteers outside the USA to implement the protocol.  (You have one here,
subject to my time availability...)  I think it'd be a real shame to allow
the US rules to stop you from building the best possible product.

Incidentally, it's worth asking: why not just use the IETF's version of
SSL (I think it may be called TSA)?  That protocol has the advantage of
being widely peer-reviewed, and also if Jabber built a library for it that
could be used in other things, it'd be a significant contribution to the
community.  OTOH, I don't know how well that protocol would co-exist with
whatever other protocol stuff you're doing.

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

This sounds okay to me, although the desire for "no modifications to the
server" does limit the authentication *of* the server that I mentioned
before.  The system would still be leaps and bounds ahead of any other I
know of, even without server authentication, but it does serve to
underscore the fact that true security is not really something you can add
on as a separate feature - it really has to be built into a system from
the ground up.

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

I think those facts are correct.  El Gamal is also subject to stronger
mathematical proof of its security.  It's been proven that if you can
break El Gamal then you can do discrete logarithms; it is *not* certain
that you must factor to break RSA (in fact, there was an article about
this just now in the latest _Science News_).  So the possibility exists
that RSA could be broken more easily than by factoring; this argues for El
Gamal being stronger. 

El Gamal is the preferred choice of the several supported by GNU Privacy
Guard (to which I contributed code).  My own instinctive reaction still
favors RSA just because it seems simpler to me, and I think any results
against it would then have to be more general, i.e. less likely to happen.
But that's not really a very scientific argument; the engineering
considerations, especially patents, make El Gamal look like the best choice.

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

Not really, if the client-to-client authentication is carried through
*every single communication between clients*... i.e. in your initial
signature/handshake/etc., you agree on a secret MAC (message
authentication check) and you use it on all subsequent messages.  A man in
the middle can't forge the MAC.  The only problem is knowing that the
public key you used for the initial handshake really belonged to the right
person; that requires, as you say, some kind of key authentication
mechanism.  (I don't like the word "infrastructure" because that seems to
imply an hierarchical structure.)

I'd prefer to see some kind of web-of-trust similar to PGP.  Ideally, it
should be easy to transfer trust from existing PGP (and, better, GPG, plug
plug) trust networks.  For instance, you could spit out a Jabber public
key as text, sign it with another product, and send it off to a recipient
who could say, "I trust this signature, so I'll trust that this key is
real".