[OTR-dev] More on OTR implementation..

[Ian Goldberg]

On Tue, Jun 19, 2007 at 11:43:27PM -0400, Donny Viszneki wrote:
> I mentioned on the list earlier that I'm writing my own implementation
> of OTR. I plan to release the code under an MIT/BSD style license. The
> target platform of my implementation was previously unstated:
> Javascript.
> 
> The goal of my project is to make it possible for people to have
> private IM communications even from public terminals which are only
> equipped with a web-browser (assuming of course that the actual
> terminal is trustworthy and uncompromised.)
> 
> There are several stages of development which will open up the project
> to a wider and wider user-base (for instance, the first version fully
> working version will require the Firefox extension Greasemonkey to
> work.)
> 
> The main web-based IM interfaces I'm interested in targeting are
> Google's GTalk, and Meebo.com. I have some rather crafty plans to
> enable end users to verify the integrity of the code they're running
> from a public terminal, helping to ensure that their conversation is
> safe (barring, again, the possibility that the terminal itself
> represents a security breach.)

Great to hear!  Getting it to work with things like GTalk would be most
excellent.

> Up to this point, I've gotten a bit of the work done. I already have
> written a very flexible and forward-looking multi-precision integer
> arithmetic library for Javascript which overcomes many of the
> limitations that exist in several of the MPI JS libs I've seen out
> there. And I've written some of the groundwork for interfacing with
> Meebo's web interface via Greasemonkey, intercepting messages as they
> go back and forth, etc..
> 
> I'm writing mostly just to get the word out about my project, but also
> to ask for some help identifying exactly which cryptographic
> algorithms I'll need to implement for OTR. I've been reading the OTR
> protocol specification a lot, but I would feel much more comfortable
> getting confirmation from people on the list of exactly how far along
> I am.

Hmm.  AES, SHA1, SHA256, HMAC, CTR mode, modexps, DSA.  I think that
should cover it.  [DH is just modexps.]

> My background is not in math or cryptography (however I've found
> through my research for this project that modular arithmetic and
> number theory share a great deal of overlap with personal math studies
> from my childhood) so you can keep that in mind if you'd like when
> responding.

You'll want to have some really good references at hand (like HAC:
http://www.cacr.math.uwaterloo.ca/hac/ is the free online edition).

> Also, on a slightly different topic, I was wondering where there might
> exist a source of proposed improvements for a new version of the OTR
> protocol? I think I have at least a few useful ideas for one or two
> new OTR capabilities, and I'm curious how they might coincide with
> pre-existing discussion on enhancing OTR.

This list would be appropriate, or directly to the OTR team at
<otr at cypherpunks.ca>.

We just got back from the Privacy Enhancing Technologies conference, and
we hope to make the next release RSN.  The next release will include
support for authenticating your connections *without* having to see the
dreaded word "fingerprint", and hopefully some of the other contributed
patches as well (like i18n), though they'll have to be ported from gaim
to pidgin.  This will not require changes to the OTR wire protocol.

The next task is a new version of the wire protocol that will hopefully
do something sensible in the "logged in more than once" case.

   - Ian