[Cryptography] upgrade mechanisms and policies

[Ray Dillinger]

On 04/17/2015 02:39 AM, Michael Kjörling wrote:

> If Mallory can insert himself in the middle, to Alice _appearing_ as
> Bob and to Bob _appearing_ as Alice, then you have no real
> confidentiality, even if the link is encrypted. That's the situation
> you get with encryption without authentication. Incidentally, it's
> also what you have with e-mail opportunistic transport-level
> encryption without certificate validation; it protects against passive
> eavesdropping, which is a step up from everything being in plain text,
> but it does not offer protection against active attackers.

A private chat application that avoids this problem is simple,
really; use Rivest's Interlock Protocol while negotiating keys
with Diffie-Hellman key agreement protocol.  If Mallory
attempts to MITM by doing Diffie-Hellman with Bob on one side
and Alice on the other, Interlock then prevents him from passing
through any messages from Alice to Bob nor from Bob to Alice.

If he can't do that, then it's a simple matter for Bob and
Alice to authenticate each other with a challenge/response
that Mallory will utterly fail at.

Of course, this all seems more complicated than it needs
to be from an engineering perspective; if Bob and Alice have
a shared secret to auth each other, they could just
communicate using symmetric encryption with a shared secret
key.  But that simpler solution ignores the fact that Bob
and Alice are human.  If Bob and Alice were just machines,
that would be fine, but if they're human they need something
different.

Bob and Alice aren't used to thinking of "shared secrets"
as boring high-entropy bit strings.  Bob is perhaps looking
for the same person who knows what wine they had with dinner
on their last date, and Alice is looking for the same person
who knows why her father doesn't get along with her cousin.
If you ask them to "authenticate" using bit strings as a
shared secret key, their eyes will glaze over.  But if you
ask them to "make sure it's the right person by asking
something only they would know" that's something they'll
understand and can do.

My point is that combining Interlock to prevent replays over
a DH-secured private channel, the "human-level" secrets
that they care about and are interested in (and will remember)
can be leveraged to provide the kind of cryptographic
authentication that they care about in that channel.

When doing transactions the way a human would do a transaction
with a *stranger* (at a checkout counter or whatever) use auth
methods (high-entropy bit strings) that machines are good at,
because as far as human perception is concerned one stranger is
the same as another. You fall back on what machines can do
well because humans are no help in that case.

But if people are doing personal interaction of any kind (such
as with a private chat channel) then they can and should use
auth methods that *people* are good at.  A DH/Interlock
private channel will allow them to authenticate using
personal secrets rather than hackable secrets.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150417/b0598d55/attachment.sig>