Re: [JDEV] Re: Jabber sigs/crypto

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

[Two messages compiled to one reply]


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

This would make the most sense, because if we block enabled clients from
sending encrypted messages to unenabled buddies, we wouldn't have to worry
about catching the encrypted string at the other end or making part of it
readable to the unenabled user.  Enabled Jabbers would check for the tag
before displaying a string, and ~walla~ red text if it came encrypted or
black if not (or something like that).  But we must ensure that enabled
clients have the facilities to tag buddies as to whether or not they can
recieve encrypted messages.

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


I'm sorry, I'm still relatively new to programming, and especially new to
cross platform stuff, so I do not really have much of a clue about that (I
don't think Borland C++ ever made me worry about endians during college
projects!).  Disregard.  I just thought if using high level math we may wish
to remember cross platform stuff.  Maybe someone, someday, can email me with
info on endians to set me straight.  That would be very appreciated.  :)

>>        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
>>:)
>
>Perhaps key distribution could work sort of like this:
>
>- when the user originally registers, the server that registered them
>stores their public key.  None of the other servers have it.
>- when you add someone to your 'buddy' list (or if you explicitly request
>it, I guess), your client contacts its current server to retrieve the key.
>If the server does not have it, then it radiates out in a DNS kind of
>manner...contacting another to see if he has it, and so forth.
[...cut...]

This seems to me that it would complicate things in the server severly.
IMOHO - If a person wanted anyone to get their public key, they could
register it with a central "yellow pages" or the like (best if jabber.org
had that for user ease).  The keys could be available for retrieval by the
client program or at the client's account at the server.  The other way to
access someone's public key would be to have them send it to you while
chatting in non secure mode, directly without the servers involved (IP to
IP).  That would allow more discreet persons to control (somewhat) who gets
their public keys.  This could be incorporated with the file transfer mode
(I assume Jabber will eventually get that, like ICQ?!?!?)

What I meant by "hamper roaming" was the private key and use at both home
and work.  I for one would not want my private key stored on a server
machine!

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


Conceed and agree.  I only meant that just chatting with a buddy and not
wanting to be sniffed would only need 40bit.  I also did mention that I
would love to go higher for business purposes.  To quote:  "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."  I think
if we went a very secure route, Jabber _could_ become the business
transaction program of choice (at least for transactions where two PEOPLE
were actually engaged in conversation).

>[...cut...] I'm wondering if the 'dumbed-down key' approach is workable
here.


You would most likely know more than I would, like I said before, I'm pretty
much starting on all of this.  :)

>>[...cut...] (although I think I read somewhere that it is "relatively
easy" to break [...]

>? Are you sure about this one, or perhaps you have it crossed in your mind
>with another one?  If you have seen evidence of this and remember where,
>can you point me there?  All of the reading I've done so far has made no
>mention of known major flaws in El Gamal; it is still regarded as being
>secure (unless some new developments to indicate otherwise have gone on
>more recently than my literature)


Sorry, I must have read it wrong.  It was Applied Cryptography 2/e - B
Schneier pg 477.  Please confirm my misconceptions for me.  I looked up
ElGamal to get an idea what you were on to (I'm only up to about pg 100 in
my reading of it), and caught this:

If Eve ever gets two messages signed or encrypted using the same k, even if
she doesn't know what it is, she can recover x.

But it is talking about signatures, and, as I'm not that far, I'm not sure
what this really means.  By all means, set me straight or flat out ignore my
comments on that.

But, I hope that I have shown at least some knowledge of what you're doing,
and not insulted you.  I'm starting, I'm trying, and I'm very interested.
Thank you for putting up with me!  :)

Deej