[messaging] Unlinkable rendezvous via human-sized keys (was: Re: Human sized keys)

[Daniel Kahn Gillmor]

On 03/23/2014 07:59 PM, Trevor Perrin wrote:
> We're circling around a few ideas for the "physical meeting ->
> introduction secret -> unlinkable online rendezvous" scenario.  Are
> there other approaches we're missing?
> 
> Ways to arrive at an "introduction secret" based on a physical
> meeting, and their downsides:
> 
>  1) Secret exchange
>   - asking people to think up sufficient entropy on the fly seems
> risky and low useability
>   - using non-computer tools to generate entropy seems low useability
> (shuffling cards, rolling dice, tearing "tickets" in half, etc.)
>   - central rendezvous server / DHT needed
> 
>  2) "Human-sized" ECDH key exchange
>   - smallish keys (32 base32 chars = 80 bit security)
>   - low "forward secrecy for linkages" unless you change the key frequently
>   - central rendezvous server / DHT needed
>   - needs user preparation before meeting
> 
>  3) Directory Name + Fingerprint exchange
>   - needs PIR to make "intro-cert" lookups unlinkable
>   - needs user preparation before meeting

I think the proposal i mentioned earlier (one-use strong DH keys that
users print a stack of beforehand) is worth including in this bestiary.
Even if we decide ultimately that it is logisitically too expensive,
it's a useful contrast to the others.

This would be a proposal similar to (2) but would have stronger keys,
automatic forward secrecy, and different user preparation before
meeting.  there are ways to avoid the perforating/stapling/tape parts of
the process, fwiw, which would just leave the user with the job of
printing and carrying an introduction ticket stash and maybe carrying a pen.

This approach would be strongly unlinkable, since each key is only used
once.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140323/8ea125a5/attachment.sig>