[messaging] Deniable authenticated group messaging
Michael Rogers
michael at briarproject.org
Fri Apr 24 02:51:05 PDT 2015
On 18/04/15 13:13, Ximin Luo wrote:
> On 18/04/15 00:00, Michael Rogers wrote:
>> I'm not sure how much of Ximin's message applies, as he's talking
>> about ciphertext transcripts whereas I'm talking about plaintext.
>>
>
> Deniability is a property that the ciphertext may have. (I use the
> term loosely to refer to the public output of any protocol, so e.g.
> plaintext+signature would count in this definition and fail
> deniability.)
Ah, sorry, I misunderstood.
> Plaintext is intrinsically deniable with no further effort - anyone
> can fake any amount of plaintext, and there's nothing
> cryptographically associated with this to prove anything to anyone.
> Whether it's plausibly convincing that Bob could have faked 3GB worth
> of Alice talking, is another matter outside of the scope of
> "deniability". In fact, as Trevor points out here and elsewhere, it
> is this intrinsic property of the plaintext that we also want the
> ciphertext to have (but also be able to authenticate it). My previous
> email was outlining ways you can try to achieve this, and limits to
> what you can achieve.
Thanks, I'm slowly working my way through the paper you pointed out.
The definition of deniability there seems quite strong. What I'm
primarily interested in is proof that a given person wrote a given
message. Secondarily, it would be nice to avoid producing proof that a
given person communicated with a specific person or group. I'm not very
concerned about producing proof that a given person communicated with
some unspecified person or group.
For all of the above, I use "proof" to mean "stronger proof than a
plaintext log of the conversation would provide". I understand that this
distinction is probably irrelevant for legal purposes, but I feel that
it might be relevant in less formal social settings, where it's
reasonable to believe that someone might lie about what someone else
said (i.e. forge a plaintext transcript).
> Is the property you're thinking of any different from the
> "deniability" that OTR refers to? Because that's what I thought you
> meant, and what my previous and current emails are talking about.
I don't know exactly what OTR means by deniability, but hopefully what
I've said above will give you an idea of the properties I'm interested
in. Like I said before, I'm happy to call it "zorgability" or any other
name if it will avoid confusion.
> I have not explored this area in much more depth that what I already
> said, but if I was going to solve your problem myself right now, I
> would start by looking at the "Composability and On-Line Deniability
> of Authentication" paper mentioned previously. (I haven't yet done
> this myself, but it looks good at a first glance.)
>
> I also found [1] useful in defining the security properties and
> threat models more precisely in terms of security games. It's quite
> accessible, requires little background, and the proofs are relatively
> easy to follow.
>
> [1] Deniable Authentication and Key Exchange
> https://www.dmi.unict.it/diraimondo/web/wp-content/uploads/papers/deniability-ake.pdf
Thanks, I'll give that a look too! At first glance it seems like their
"partial deniability" property may match what I've described above: "a
party may not be able to deny that it was 'alive' at some point in time
but can fully deny the contents of its communications and the identity
of its interlocutors".
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/f4d91ade/attachment.sig>
More information about the Messaging
mailing list