[messaging] Deniable authenticated group messaging

[Trevor Perrin]

On Fri, Apr 17, 2015 at 2:38 PM, Michael Rogers
<michael at briarproject.org> wrote:
> On 17/04/15 20:08, Trevor Perrin wrote:
>> The lack of ephemeral keys here means you don't have properties like
>> "forward secrecy" or "key compromise impersonation resistance", but I
>> guess that's not what you're asking about.
>
> Right. Forward secrecy is handled at another layer, and I'm happy to
> accept that if someone's private key is compromised it can be used to
> impersonate them.

Key-compromise impersonation = someone's long-term private key is
compromised, enabling the attacker to impersonate other parties *to*
them.

Can be resisted in DH-based protocols if you authenticate other
parties by challenging them with an ephemeral public key, instead of
your long-term public key.


>>  * Are the signed ECDH keys published so anyone can retrieve them?  If
>> not, then possession of Alice's signature by Bob would provide
>> evidence that they communicated, perhaps even violating the "useful"
>> form of deniability.
>
> They can be published, yes. But even if they're not published, each
> person has one signed DH key that they use for all their deniable
> conversations, so everyone Alice has communicated with has her signed DH
> key and could potentially have given it to Bob without Alice and Bob
> ever having communicated.

Yeah, but that's still evidence that Bob communicated with Alice or
someone who did, so probably best to have this signature published if
you care about deniability.


>>  * Suppose Bob signs a bogus ECDH public key that's made of digits of
>> pi or something, so it's obvious that Bob doesn't know the private key
>> for his own public key.  Bob won't be able to decrypt Alice's message,
>> but he could give it to some judge.  If the judge can compromise
>> Alice's private key, the judge can confirm this message came from
>> Alice and was intended for Bob (thanks to Matt Green, who once pointed
>> this out to me).
>
> Interesting. Wouldn't this also work for OTR, or any other system that
> relies on MACs derived from DH being deniable?

There's ways to prevent this (e.g. signature or some
proof-of-possession for Bob's public key; Alice destroying her
ephemeral private key immediately on sending the message).

Dunno about OTR, I think the DH values in handshake don't get deleted
immediately so this may be slightly applicable, but since OTR signs
values from the peer it's not an ideal "deniable AKE" in any case
(though as I said before I think that's an academic notion without
much real-world import).

Trevor