On 21/03/14 01:19, Trevor Perrin wrote: > > On Thu, Mar 20, 2014 at 8:44 AM, Daniel Kahn Gillmor <[email protected] > <mailto:[email protected]>> wrote: > > On 03/20/2014 03:11 AM, Trevor Perrin wrote: > > You'd have users exchange ~160-bit ECDH keys directly. I'd have users > > exchange (introduction server name, ~128-bit fingerprint) and use these > to > > lookup an "introduction cert" where the fingerprinted long-term key > signs a > > short-term ECDH key. > > > > Your approach eliminates the need to mask the intro-cert lookup via PIR > or > > dummy traffic. But it lowers the security of your long-term key from > ~128 > > bits to ~80 bits, and reduces "forward-secrecy of linkages", since > > compromise of the long-term ECDH key (which you've printed on your > business > > card, so you're not going to rotate it frequently) allows going through > > published rendezvous messages and linking correspondents for the key's > > lifetime. > > Watson's scheme is also doable with ephemeral keys, you just wouldn't > have them on your business card -- each user could have their machinery > generate a stash of ephemeral keys and print out one card per key. each > card would have the public key of a single ephemeral key written on one > half of the card (the "peer" half), and a short tag on the other half > that identifies the private key in your client's ephemeral stash (the > "self" half) > > you meet someone who also plays this game, and the two of you take the > top card from each of your stacks, tear it in half, give the peer half > to the other person, and staple or tape or otherwise pair up the two > pieces for use later when you're online. > > > Yeah, I think that loses the main benefit of a DH rendezvous though, which is > that each party has a single static value which they can print on biz cards, > publish widely for corroboration, or exchange via 3rd parties. > > Your process requires: > - printing and carrying around a stack of perforated tickets > - tearing and exchanging them > - attaching them with staples or tape > > I think a lot fewer people would be willing / able to do that. > > > Trevor >
I think the point is that, this is something that can be added onto any long-term identity system. You could even mix the two - Alice can generate one-use identities and Bob can use his long-term identity. This comes at some extra cost to Alice (she has to remember which id she gave to Bob) but I don't think Bob has any extra cost. In other words, we have a generic construction that lets us build ephemeral identities *on top of* a system based on long-term identities. As you say it's pretty costly, but we could think of ways to lower this cost (e.g. specify a reusable standard way of doing this), if we wanted to support it better. (Of course, it's also probably possible to do the reverse construction, i.e. build long-term identities *on top of* a system based on ephemeral identities.) X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
