[OTR-users] Re: [OTR-announce] Flaw in OTR Protocol (with workaround!)

[Gregory Maxwell]

On 7/24/05, The OTR Dev Team <otr at cypherpunks.ca> wrote:
> As a side effect, if anyone's got other enhancements to OTR in the wings
> that would require wire protocol changes, now's the time to speak up.  :-)

Oh!

1. Automatic message splitting
2. Compression

AIM is annoying enough without the overhead of OTR, especially if you
paste in HTML things, but with OTR it is quite painful.

Support for compression would help this quite a bit, but I understand
the desire to avoid compression to make it more trivial to demonstrate
a modification attack.  ... Since it would still take a lot of work to
find an AES key that produced the 'right' keystream output given the
logged traffic. (i.e. in the very likely case that some 'trustable'
logging device has been installed in the network).

In any case, message splitting really should be implemented and it
would be nice if the protocol had support so that there needed to be
only 1x OTR overhead for a N way split message.

It would be nice if the splitting mechanism supported joining messages
of varying length, so that message breaks could be placed randomly to
frustrate traffic analysis and it would be nice if the maximum message
length could be controlled based on some feedback from GAIM about what
it guesses the IM services' rate limit might be.

I also have an idea about compression that I've been stewing on for a
while, which I will discuss in a separate post.