[tahoe-dev] Invitation protocol

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian,

Thanks for the links to Hoepman, Payrin and Vaudenay - very useful!

On 02/07/12 03:35, Brian wrote:
> So, I'm looking for some compromise.. something that is generally
> secure enough, but usable enough to actually get used (which, in my
> mind, means a unidirectional channel, and the two computers are not
> connected to each other ahead of time).
> 
> Hm, maybe some of Payrin+Vaudenay's flows could still meet my
> usability criteria, if the reverse channel is expressed as a
> human-assisted validation step at the end of the process. Imagine a
> unidirectional A->B code (sent over an authenticated but
> non-confidential channel), running the protocol I described above,
> but then following it up with Alice and Bob comparing strings (or
> generated images or some other validation step). This might be
> usable enough for local-introduction situations (where you're
> sitting next to someone on the train and want to add them to your
> phone's address book), or the eavesdropper-only cases (where you're
> chatting with someone on IRC, run the protocol, probably connect 
> securely, then both agents tell you a string to paste into IRC and 
> compare against the other's value to confirm the connection).

If we can assume a bidirectional A-but-not-C channel (such as voice)
for exchanging confirmation codes, we could use the following
protocol, which is based on ZRTP's key agreement protocol:

* Alice sends Bob a short invitation code over a unidirectional
neither-A-nor-C channel (a unidirectional A-but-not-C channel, such as
email, is also fine)

* Alice and Bob use the invitation code to establish a bidirectional
neither-A-nor-C channel (such as an IRC conversation on an untrusted
server)

* Alice generates an ephemeral DH or ECDH key pair and sends the hash
of her public key to Bob over the bidirectional neither-A-nor-C channel

* After receiving Alice's hash, Bob generates an ephemeral key pair
and sends the hash of his public key to Alice over the bidirectional
neither-A-nor-C channel

* After receiving Bob's hash, Alice sends her public key to Bob over
the bidirectionalneither-A-nor-C channel

* After receiving Alice's public key and checking that it matches the
previously received hash, Bob sends his public key to Alice over the
bidirectional neither-A-nor-C channel, then uses DH or ECDH to derive
a shared secret from his private key and Alice's public key, then
destroys his ephemeral key pair

* After receiving Bob's public key and checking that it matches the
previously received hash, Alice uses DH or ECDH to derive a shared
secret from her private key and Bob's public key, then destroys her
ephemeral key pair

* Bob derives two short confirmation codes from the shared secret; he
sends the first code to Alice over a bidirectional A-but-not-C channel
(such as voice)

* Alice derives two short confirmation codes from the shared secret;
if the code received from Bob matches her first code, she sends the
second code to Bob over the bidirectional A-but-not-C channel, then
accepts the shared secret

* If the code received from Alice matches his second code, Bob accepts
the shared secret

As with ZRTP, the hash commitments force a MITM attacker to choose her
key pairs before seeing either victim's public key, so the
confirmation codes can be short - they don't need to resist a brute
force attack, they only need to detect an attempted attack with high
probability.

In Briar we're using 19-bit invitation and confirmation codes, which
can be represented as six decimal digits and detect an attempted
attack with probability 1 - 1/2^19 (ie the probability of an
undetected attack is less than one in half a million).

Unlike ZRTP, the use of two confirmation codes - one in each direction
- - prevents either user from skipping the confirmation step. But
there's still a serious usability problem: how do you convince the
users that they must use an authenticated channel, such as voice, to
exchange the confirmation codes? If they use the channel they just
established, or any other unauthenticated channel, the whole thing
falls apart.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJP/bFtAAoJEBEET9GfxSfMuaoH+gPq0GhS/tlMPTqvB2iItLwN
KbA3IJ1vQTPvD/gfSaIBdmT7O0sZe4ocZsDbrx4Z8SLa3TQSFd7DETUVSpnstJ4E
wTBLDP4Sz5NdPZNHQurC1ts4iOBoUoGnDTMG6auPw9mgzcd5W56DFOaB3uGFSiYe
FNIefvdKuScWfCtOV28w16WPfbmHH4zVFOwI7aIx0+YMMlwqK09uPcqTWfcTf8N/
JfU0HiGJxTeNrELvVcv6X7nLfef3BCvf0IMcxXG7xHNgJQO827n8ACXn/MMC+b14
D9hgV9M6INTGn2pEhP2pQm+yOp2jpAobWvpbGtaGavoXLVHnWVOjD76Pi9qJqFI=
=RtPD
-----END PGP SIGNATURE-----