[OTR-users] multi-party OTR communications? (and other OTR details)

Gregory Maxwell gmaxwell at gmail.com
Mon Sep 22 11:42:04 EDT 2008


On Mon, Sep 22, 2008 at 11:06 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
>> Indeed, with the current version of OTR, if Bob keeps a copy of his
>> secrets, he can prove that someone he's in cahoots with at some
>> point in the past started an OTR session with Alice's client.
>> (Because Alice signs a MAC over Bob's ephemeral DH key.)  But anyone
>> can start an OTR conversation with anyone else (quite
>> intentionally).  On the drawing board is a variation that will
>> remove even this.
>
> This is very interesting.  Can you give a summary of how something
> like this might be possible without removing the ability to be sure
> that your conversation partner is who they claim to be?

I can't speak for whatever Ian is doing, but if you look a few weeks
back in the development archive you'll see a proposed exchange of mine
for another project I'm working on.  After I was corrected with
respect the identity rebinding attack, I proposed an exchange which
achieved that property. (Basically by not including any private data
in the commitment): Anyone who knew (from passive observation, for
example) the public keys of two parties could create a forged
transcript between them.

> While the deniability features are pretty cool from a crypto
> perspective, it doesn't seem to me like they offer any *more*
> deniability than the deniability you have with unencrypted/unsigned
> material (e.g. the contents of a web server logs, or a traffic dump
> From a router).

The biggest concern is to not to do better than unencrypted/unsigned
but not to do worse.  The possibility of providing more really depends
on the level of imagination and technical sophistication of the
audience that you're trying to convince.  An unencrypted log shouldn't
be considered good evidence since anyone who touched it could have
untraceably, and even accidentally, altered it.   But such things are
often considered to be proof, and to someone who does no OTR system
would likely be considered less proof.  But at least it can be made no
moreso.

[snip]
>Given that unencrypted/unsigned digital material is
> regularly respected as powerful evidence in legal disputes, contract
> negotiations, and journalism already
[snip]

At least today even laymen can easily understand that one party or
another could have simply edited the log.  The accuracy of evidence is
understood to ultimately depend on many factors.   You can't get some
crypto-expert to come in and say that the log is irrefutable proof.
But with a signed encrypted message system the number of possible
explanations is substantially reduced (someone had to steal your
private key and passphrase).

[snip]
> I guess what i'm saying is that the deniability feature of OTR is not
> as high a priority for me as the other features (such as IM-layer
> protocol independence, remote-party authentication (including SMP),
> and a clear, simple UI).

As developers we owe it to our users make a best effort to avoid
creating new vulnerabilities for them which they may not understand
but which may still bite them. Turning on encryption should never make
you *more* vulnerable,  but without denyability it very well may.
Educating users about the risks of non-deniable encryption so that
they could make good choices would be really hard, it's better to just
fix the problem. (Sometimes users do want non-repudiation, but they
*know* when they want it. They usually do not know when they want
deniable encryption).

Achieving denyability is, for the most part, a one time R&D cost.
Sure, there are computation and message exchange costs too... but they
are infinitesimal.  Because of this it should be a default behavior
wherever it can be reasonably provided.



More information about the OTR-users mailing list