On Sun, Jan 4, 2015 at 2:11 AM, Michael Rogers <[email protected]> wrote: > > On 03/01/15 20:13, Trevor Perrin wrote: >> >> In asynchronous scenarios (like email or text messaging), this >> seems a disadvantage of your approach compared to the (1)-(4) >> proposals. What do you see as the advantages? > > In brief: forward secrecy and peer-to-peer. > > If we want forward secrecy then the information Bob publishes (on his > business card or wherever) can't be a long-term encryption key. > Assuming Bob doesn't have a way of remotely updating old business > cards, it can't be a short-term encryption key either. It has to be an > authentication key for authenticating a key exchange or a short-term > encryption key. > > So how do we perform that key exchange or obtain that short-term > encryption key in an asynchronous setting? > > In TextSecure (if I understand right) the answer is to use a server to > hold prekeys.
Yes, but short-lived prekeys/subkeys for forward-secrecy could be delivered from a server, or directly from one of the recipient's devices. So this approach is flexible to interactive or third-party-assisted (asynchronous) cases. I was thinking a multidevice approach should have the same flexibility, and should allow fingerprint authentication. This is possible provided you use signatures from a master key over device keys, or synchronize the master private key to devices. If you require interaction with one device to learn about others, you lose "asynchronousness", and I'm not sure what you gain. If you're using different device keys not signed by a single key, you lose fingerprint-ability. > If we want to do things peer-to-peer, we can either (a) require the > key exchange (though not the subsequent messaging) to be synchronous, > or (b) do an asynchronous key exchange via someone with whom Alice and > Bob have already set up asynchronous messaging channels. If you can lookup signed devices keys and short-lived forward-secrecy keys from any party (including Bob himself), and authenticate them with a fingerprint, I think that would also be sufficient? To me, it seems like such an approach is flexible to the cases you want to support, and others, so I'm unsure of the value of doing more limited things (like a). Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
