anonymous DH & MITM

Anton Stiglic astiglic at okiok.com
Mon Oct 6 11:43:21 EDT 2003


----- Original Message ----- 
From: "Jerrold Leichter" <jerrold.leichter at smarts.com>
To: "Tim Dierks" <tim at dierks.org>
Cc: "Jerrold Leichter" <jerrold.leichter at smarts.com>; "Cryptography list"
<cryptography at metzdowd.com>
Sent: Friday, October 03, 2003 8:19 PM
Subject: Re: anonymous DH & MITM


> | From: Tim Dierks <tim at dierks.org>
> |
> | I'm lost in a twisty page of MITM passages, all alike.
> |
> | My point was that in an anonymous protocol, for Alice to communicate
with
> | Mallet is equivalent to communicating with Bob, since the protocol is
> | anonymous: there is no distinction. All the concept of MITM is intended
to
> | convey is that in an anonymous protocol, you don't know who you're
talking
> | to, period. Mallet having two conversations with Alice & Bob is
equivalent
> | to Mallet intermediating himself into a conversation between Alice &
Bob.
> |
> | If you have some unintermediated channel to speak with a known someone
> | once, you can exchange a value or values which will allow you to
> | authenticate each other forevermore and detect any intermediations in
the
> | past. But the fundamental truth is that there's no way to bootstrap a
> | secure communication between two authenticated parties if all direct &
> | indirect communications between those parties may be intermediated.
(Call
> | this the 'brain in a jar' hypothesis.)
> OK, let's set up two different scenarios:
>
> 1.  Non-anonymous communication.  Alice talks to Bob.  Alice knows
> Bob is on the other end, Bob knows Alice is on the other
> end.  They share some secret data; Alice wishes it to be
> known only to her and Bob.  Mallet has a bug in Bob's home
> and copies the data.
>
> Can Alice or Bob detect that Mallet is there?  Clearly not if
> Mallet never uses the data in a detectable way.  No matter how
> many times Alice and Bob communicate, whether or not Mallet
> continues to bug Bob, neither Alice nor Bob can never learn of
> Mallet's presence.
>
> 2.  Anonymous communication.  Alice and Bob have a conversation.
> Mallet plays MITM.  Alice and Bob don't know who their
> corresponding partner is, but they each tell the other
> that they will not reveal the secrets they exchange, and
> each believes the other - and indeed neither ever reveals
> those secrets.  They wish to know if anyone else had a
> chance to learn their secret.
>
> On the face of it, there's no difference between these two
> cases.  In each case, someone receives a copy of the secrets
> exchanged between Alice and Bob, but doesn't *do* anything
> with them that either Alice or Bob can see.
>
> However, in this case, unlike 1, if Alice and Bob continue to
> communicate - using private pseudonyms for each other to
> make "continue to communicate" a meaningful phrase - then,
> assuming Mallet cannot *always* interpose himself, they will
> eventually discover that someone has played a MITM game on
> them.

You started by talking about anonymous communication, but ended up
suggesting a scheme for pseudonymous communication.

Anonymous != pseudonymous.

Let us be clear on that!
It is an important difference.

For example, if you take Stefan Brands digital credentials, and issue
a multi-show credential, the showings of the credential can be linked
it is not anonymous but pseudonymous in some sense (even though the
showings cannot be linked to the issuing).  An open problem would be to
have something similar (something as efficient) which allows you to
issue a single credential which can be shown multiple times in an
unlikable way (completely anonymous).

Camenisch and Lysyanskaya came up with a scheme that allows
you to demonstrate possession of a credential multiple times in a way
that these are unlikable, however their solution is far from being efficient
in practice. You are much better off using Brands' credentials and just
have multiple credentials be issued, which when shown will be unlikable.

--Anton

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list