[messaging] Deniable authenticated group messaging

Michael Rogers michael at briarproject.org
Fri Apr 24 02:31:48 PDT 2015


On 18/04/15 00:09, Trevor Perrin wrote:
> 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.

Ah, got it! Thanks for explaining.

>>>  * 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.

With ephemeral DH keys it would be hard to publish the keys promptly
enough that possession of an unpublished key signed by the other party
couldn't be used as evidence of communication. (In a system like Briar
there isn't even a public place where everyone can publish things - and
that's arguably true for the censored internet too.)

This makes me think that the basic approach of signing DH keys is
flawed. I'm starting to understand the motivation for designing exotic
key agreement protocols. :-)

>>>  * 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).

Agreed about the real-world import. In general it seems like this attack
could be prevented as follows:

1. Exchange ephemeral public DH keys
2. Derive the shared secret, a nonce for each party and a MAC key
3. Each party sends a MAC over their nonce
4. Each party now knows that the other party knows the shared secret
5. Sign the public DH keys and exchange signatures

This still leaves each party in possession of a public key signed by the
other party, however.

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150424/e3f2e53d/attachment.sig>


More information about the Messaging mailing list