<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 6:52 PM, Maxwell Krohn <span dir="ltr"><<a href="mailto:themax@gmail.com" target="_blank">themax@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I mentioned to David off-list that we considered but didn't pursue another multi-device option for signatures.  It would be to use a protocol such as 2-Schnorr [1]. </div></blockquote><div><br></div><div>This is a nice protocol but it's solving a different problem being discussed initially in this thread. I think it's worth starting from the high-level user experience we want here before diving into the crypto, because people are already discussing crypto protocols which provide a pretty different UX. Ignoring setup/pairing, which is a pain in almost any protocol, there are three possible versions of the "multi device UI" which have already been proposed in this thread:</div><div><br></div><div>*A user has multiple devices, any one of which can read messages if it is online (Trevor's #2/3/4 all fit here as do all of David's proposals)</div><div>*A user has multiple devices, one "master" (or "home server") of which must be online for the user to be able to read messages at any other device (this was Trevor's #1)</div><div>*A user has multiple devices, two of which must be online to sign something and set up a channel (2-Schnorr?) </div><div><br></div><div>There are many other combos when you get in to issuing/revoking/changing keys. For example, you might also use the 2-Schnorr protoocl only to protect some meta-key to sign other device keys, and not for routine messages.</div><div><br></div><div>In any case, I would advocate that any system needs to be flexible for different users to choose multiple options based on their security preferences. I suspect most users will want a simple baseline UI along the lines of iMessage (or almost any other chat app) today, which is that you can enroll any new device instantaneously with a username/password only and no pairing protocol. I think if you want to design a mass-market system, anything involving an explicit device pairing-protocol needs to be an opt-in feature.</div></div></div></div>