[messaging] MITM-safe communication w/o authentication possible?

[Jeff Burdges]

On Sun, 2015-11-29 at 13:17 -0800, Adam Langley wrote:
> On Sun, Nov 29, 2015 at 12:32 PM, U.Mutlu <for-gmane at mutluit.com>
> wrote:
> > I wonder if it can be possible, at least theoretically, to have a
> > MITM-secure internet channel without the use of PKI and/or
> > persistent password (ie. w/o authentication, like in the telephone
> > network)?
> > Of course the communication must be encrypted against passive MITM,
> > and must also detect active MITM.
> > Does anybody know of such a protocol, info, papers etc.?
> 
> It's certainly possible if you're willing to have a central authority
> and some way to authentically get private keys from that authority to
> the correct people. In that case search for "identity based
> encryption". (Or just "KDCs" or "Kerberos" if you don't mind the
> authority being online.)

Yes, there needs to be an authority, but why a central authority?  Why
not use people with whom you've already established a secure
connection?

These people could MITM you just like the central authority could in a
typical identity based encryption scheme, but in practice this could be
made hard.  In Pond, people occasionally do this by asking a friend to
forward a PANDA secret.  And I've an open pull request that automates
that.  ;)

If however you had a human readable notion of identity anyways, then
one could improve, or at least distribute, this sort of "friendly
authority" using ideas from identity based encryption.

Jeff

p.s.  I'm working on a mixnet design where only a random contact can do
certain MITM attacks on you, which I'll post about at some point.  I
have *not* been thinking about either identity based encryption or
adding new contacts though. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151130/04d7bfd0/attachment.sig>