[OTR-dev] Achieving non-non-repudiation in another protocol.

[Gregory Maxwell]

On Thu, Aug 28, 2008 at 11:45 AM, Paul Wouters <paul at cypherpunks.ca> wrote:
> Doesn't the new libotr 4 specification for arranging symmetric keys via
> OTR solve your problem?

It may, but I did not think the functionality was implemented yet.

I haven't seen the implementation yet so I can't say.  It would need
to preserve the repudiation property for the symmetric keys. Schemes
which sign symmetric keying material (as in Ian's quick reply to me)
wouldn't get the repudiation property I'm looking for.

I'm trying to figure out how I could use OTR: Common libraries are
good for many reasons, including security, but I'm looking for
properties that OTR doesn't provide naively which go beyond needing
simple symmetric keys.

I have a hard realtime audio data channel which simply needs symmetric
keys that change every once in a while. Sounds like libotr4 could do
that for me.

I also have a control channel which provides reliable and known-order
delivery of control messages.

I need all of it to be robust against eavesdropping,  MTIM, and
'traffic interference'. Traffic interference in this context is any
activity other than simple packet dropping which damages or degrades
the flow of traffic (think: sending forged RST packets to kill TCP
sessions).

Right now I'm accomplishing this via a yet un-released fork of airhook
(http://airhook.ofb.net/) which I've extended to provide some OTR like
properties as well as being able to provide symmetric keys for the
hard-realtime audio channel (which I multiplex on the same UDP port by
reserving one of the audio channel sequence numbers to indicate
control).  Think of it is as reliable-packet-OTR for IPv4/UDP and
IPv6/UDP , perhaps. :)

In order to use libotr I'd need to implement a basic reliable
transport for OTR, then implement another reliable transport inside of
OTR (or otherwise keyed by OTR)... and I'd need to make sure the outer
transport for OTR is itself not vulnerable to traffic interference.

I'd also have tolerate or work around some of OTR's existing chat
channels (like the wasteful plain text encoding) which don't apply to
this application.  I *think* that since OTR can run inside the 500
byte limit of IRC I should be fine with the 532 byte MTU I'm imposing
for keying operations.

An interesting idea.