[OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals

[Ian Goldberg]

On Mon, Feb 20, 2006 at 03:52:18PM -0500, Evan Schoenberg wrote:
> That hadn't been my understanding, so I did a bit of research.  It  
> turns out I was basically wrong about AOL's official encryption, and  
> I apologize for spreading misinformation. :)
> 
> It turns out what I was thinking of is Trillian's SecureIM which has  
> become a common form of AIM encryption.  SecureIM providese no  
> authentication or signing whatsoever.  As a side note, it uses   
> Blowfish-based encryption.

That's correct.  SecureIM uses unauthenticated Diffie-Hellman for key
agreement, followed by Blowfish for message encryption, and no message
authentication or integrity checking at all.

> joust.kano.net, where Keith Lea has a good description of the  
> protocol and how it works, is down, and but google's cache of the  
> appropriate page [1] isn't.  Brief summary is that it's end-to-end  
> SSL encryption, not only of messages but also of file transfers,  
> direct IM connections, and Get File connections.

Looking at that link, it seems to me that normal IM communication isn't
just "tunnel over SSL"; it's sent by individually wrapping each message
with an RSA encryption and an RSA signature.

> Users of this mechanism need an  
> SSL cert... savvy users can generate their own and self-sign them or  
> pay to have them signed, and AOL offers verisign-signed certificates  
> for a key.  I have no idea what the registration / verification  
> mechanism is for the latter process.

So there's no binding whatsoever between the cert and the screen name?
In what sense is it a cert, then?

> A side note about the AOL encryption: As detailed at [2], there is an  
> aimencrypt.com website which explains to clueless users how to obtain  
> a free signed certificate.  Fantastically, it's free because  
> aimencrypt bought one and gives it to users to download so they can  
> have a cool lock by their name... just wow.

Wow indeed.  So there's definitely *no* binding.  I'm not saying that's
necessarily bad; it just means you need to do the same type of
out-of-band verification of the key that OTR requires.  But from what I
can tell of the UI, there's no indication that you need to do this in
AIM-Encrypt.

And the wiki page would seem to suggest that self-signed certs work just
fine.  So why would aimencrypt.com offer a constant cert to everyone
when they could just offer a little widget to generate a fresh
self-signed one?

I wonder how quickly someone could throw together a patch to the
OSCAR-parsing module of ethereal (or something like that) that
automatically decrypts messages encrypted to this shared aimencrypt.com
cert.  :-)

   - Ian