Encryption plugins for gaim

Ian G iang at systemics.com
Tue Mar 15 11:50:54 PST 2005


Ian Goldberg wrote:
>>...Unfortunately
>>the original Jabber developers did not build encryption in from the
>>beginning and the existing methods have not been implemented widely
>>(OpenPGP over Jabber) or are not very Jabberish (RFC 3923), so we need
>>to improve what we have. Contributions welcome. See here for pointers:
>>
>>http://www.saint-andre.com/blog/2005-03.html#2005-03-15T11:23
> 
> 
> OTR works over Jabber today.  Granted, it's not very "Jabberish" (as far
> as I understand the term; I don't know the Jabber protocol very well):
> it just replaces the text of the message with ciphertext.  [gaim, at
> least, doesn't seem to have a way to construct a more "Jabberish"
> message, as far as I could tell.]

My thoughts are similar.  When I first got into the
design, I thought that the privacy aspects of the
protocol would be integral with the messaging system,
but that proved to be not the case.

For several reasons, I think the privacy layer is
going to end up being totally divorced from the messaging
layer.  As a stab at these:

    *  there are many messaging systems, and there are
       efforts at integrating these, so any decent
       privacy layer has to think about hops,
    *  we desperately want to preserve many messaging
       systems in violent competition,
    *  any privacy layer that involves a "decrypt at
       server and then re-encrypt" is not a privacy
       layer, as the threat is 99.9% at the node
       (all three - alice, bob, server) and not on
       the wire,
    *  involving the server in any identity and privacy
       concerns brings up conflicts such as asking the
       server to know who the user is, excrow, liability,...,
    *  messaging systems move at different paces and
       incorporating crypto into them may result in
       yoyo behaviour for safe chat - there today,
       gone tomorrow on the new alpha,
    *  the final authentication - alice of bob and v.v.
       - is something that is best done divorced from the
       lowtech as much as possible, so that means some
       sort of plugin and leveraging off pgp-style WoT.
       Integrating that step into the messaging system
       gives you "S/MIME authentication" which doesn't
       scale.

That was scratched off without pause...

Hence, my own efforts will probably go in these two
parallel directions:

     *  opportunistic key exchange followed by chat
        in SDP1 over SOX.  (Note that SOX is also
        encrypted client-to-server so for much of
        the journey packets will be doubly encrypted,
        but end-to-end is the target).  This method
        will be integrated and fast but lack user
        authentication.  This is uninteresting to
        anyone outside the SOX world.
     *  OpenPGP packets without any interference,
        and a sort of plugin ability to bootstrap
        a fast key exchange, with fingerprint display.
        Key signing to follow later...  Now this is
        much more interesting as conceivably the same
        protocol would (once designed!) work over
        email, Jabber, AIM, etc.  At least, that would
        be the intention.



> I'd be more than happy to help Jabber-ify the OTR protocol.  The reason
> we designed OTR was exactly that the GPG-over-IM solutions have
> semantics that don't match those of a private conversation: you have
> long-term encryption keys, as well as digital signatures on messages.


I'm not sure what this obsession with digital signatures
over messages is.  That probably wants to be unwound.  If
people are "signing a contract" over chat or indeed email,
then they probably need a lot more support in the tech and
a lot more warning, training, and legal support as to the
ramifications.  C.f.,
http://www.financialcryptography.com/mt/archives/000250.html

I agree that encrypting a chat message straight GPG/OpenPGP-
over-IM would probably be clunky.  I was more envisaging
using OpenPGP to handle the clunky key exchange and then
go fast from there.


> You don't *want* Bob to be able to prove to Charlie that Alice said what
> she did.  [Yet you want Bob to be himself assured of Alice's
> authorship.]  And a compromise of Bob's computer tomorrow should not
> expose today's messages.
> 
> OTR also adds a couple of extra features (malleable encryption,
> publishing of the MAC keys, a toolkit for forging transcripts) to help
> Alice claim that someone's putting words in her mouth.


(Note however that my efforts are towards integrating
two separate disparate systems - payments and IM - and
I am less concerned with the privacy aspects as Ian
Goldberg is.  This is one area where I'm adopting a
wait and see attitude because I'm not convinced that
this is an entirely tech issue.  But whichever, when
we get to that stage there is nothing wrong with doing
several possibilities.)

iang (the other other one)
-- 
News and views on what matters in finance+crypto:
         http://financialcryptography.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com





More information about the cypherpunks-legacy mailing list