Re: [MLS] Deniability without pairwise channels.

[Sofía Celi <[e-mail]>]

I forgot to include paper [3]

3. http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf

Thanks!

On 1/23/20 8:42 PM, Sofía Celi wrote:
> Hello!
> 
> Very interesting insight!
> 
>> What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place.
> 
> The "sign & reveal" mechanism is something that can be considered coming
> from OTR, because in it you reveal the MAC keys. But the idea, since the
> first paper of OTR[1] was to use the revelation of keys as an additional
> measure to expand the set of possible message forgers. Message
> unlinkability and deniability was provided in some previous version of
> OTR by using MAC keys instead of long-term keys for signing messages.
> OTR even provides a stronger notion for it by also using malleable
> encryption so anyone can forge a message. So only revealing keys is not
> enough to achieve strong offline deniability. OTR also used an
> authenticated key exchange where conversation partners are able to reuse
> ephemeral keys signed by the other party in forged transcripts, thereby
> providing partial participation repudiation. This insight by Trevor
> Perrin is nice to read[2]
> 
> 
> It depends on what kind of notions of deniability want to be provided.
> 
>> There might be another problem, regarding synchronicity: since MLS is
> completely asynchronous no one should publish a secret key too early
> (i.e. before others have consumed the encrypted messages) otherwise we
> might not be able to trust the authentication any longer.
> 
> This is super interesting and it is problem ;), see section '3.4 Message
> Integrity' of this paper[3].
> 
> 
> I think the notions of deniability in a cryptographic sense have evolved
> and new ways of achieving it have been studied. So many things can be
> done ;)
> 
> 
> 1. https://otr.cypherpunks.ca/otr-wpes.pdf
> 2. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001796.html
> 
> 
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02