Re: [JDEV] Re: Jabber sigs/crypto

["Nicholas M. Kirsch" <nkirsch@olaf.nick.org>]

> Hmmm...I'm not sure of an obvious way around this right now, but this seems
> to be an unacceptable (to me at least) requirement...if I were a user of a
> problem like this and was told 'yeah, type your message here, but whatever
> you do, don't start with this particular string'...it just would give me
> the impression that the system was somehow shoddy.  There must be one way
> or another around it...

I agree with this. The jabber protocol is specified by xml tags, it would
be relatively easy to simply add it as an option to a <message
encrypted="yes"> tag. 

> I would have assumed the code would be designed such that it could run on
> either big or little endian, depending on compilation constants.

Most definitly should be. I'm not sure how the sources are now, but
anything that is sent over the network should first be put into big-endian
format if we are going to look for true cross-platform compatibility. This
should be relatively easy to add to the existing code base, since we now
have a good build environment (with autoconf/automake). 

> Yeah, so this is what I was talking about earlier...if the Jabber server
> needs to verify a digital sig for every user as they log on, will this
> place an unacceptable processing burden on the server's CPU?  (or in other
> words will server scalability suck because of this processing overhead)  I
> think I need to do some investigation into how fast verification is with a
> variety of algorithms.

We currently verify a user based on a login name and password. Surely the
digital signature can be incorporated into some type of password scheme.
Verifying the digital signature shouldn't be any more computationally
intensive than verifying a password, ideally anyway.


> >>> 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.
> 
> Yeah, _you_ might feel that it's adequate, but lots of people would
> disagree.  I mean, don't get me wrong: I myself am one of those people who
> doesn't bother getting the 128-bit versions of Netscape to do my online
> purchases; I figure if someone feels like taking the effort to get my
> credit card number, they almost deserve it (then again, it would be
> Mastercard who'd be taking the hit, I think).  I think especially if people
> would want to use Jabber in a business environment, they'd be looking for >
> 40 bit.  This appears to have already been an issue with ICQ; I guess
> several businesses complained to Mirabilis when they realized how easy it
> was to sniff and spoof with ICQ, and how they couldn't talk about
> business-related matters with confidence when using it.  (to which
> Mirabilis responded that ICQ was never intended for use in a business
> environment, blah blah)  Applied Crypto recommends:
> tactical military info (minutes/hours) 56-64 bits
> product announcements, mergers, interest rates (days/weeks) 64 bits
> long-term business plans (years) 64 bits
> trade secrets (decades) 112 bits

I don't think it would be difficult to setup parameters in the CVS
tree to check the hostname of the user attempting to download the source
and replace it with 40 bit versions instead of 128. US export laws are
strict, and we have to do our best to be sure not to violate them. 


> Well, no.  El Gamal is a public key (asymmetric) system; Blowfish is
> symmetric (like DES).  There is no way to use Blowfish for authentication.
> It might be possible to use a hybrid approach (like PGP) and use an
> asymmetric algorithm for signing and authentication, and key management,
> but while still using a symmetric (and thus MUCH faster...on the order of
> 1000x faster) algorithm to do the encryption of the bulk data.
> 
> CJK
> 

This is really the only option. To use a public-key system for all the
data encryption would be _extremely_ CPU intensive. SSH uses a hybrid
approach, using a public-key system to negotiation a session key, which is
then a symmetric algorithm.

Nick