> Depends on what it's used for. It's not clear from the video whether the Yahoo code is also used for multi-device setup, or just backup: You could use it for multi-device setup at the moment: It will result in two devices sharing the same key. It is simply the seed used for a PRG that generates the keys, IIRC. But it won't be supported for this purpose in the long term, and two devices sharing the same key will, eventually, cause an error state (if it can be detected). -- I previously posted to this list about sound methods of handling multiple devices. It might be reasonable to suspect that -- with some refinements suggested by folks on- and off-list -- that might see implementation. :) - David <div class="gmail_quote">On Mon, Apr 13, 2015 at 1:32 PM Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Apr 9, 2015 at 7:14 AM, Tankred Hase <<a href="mailto:tankred@whiteout.io" target="_blank">tankred@whiteout.io</a>> wrote: > >> Thanks for sharing! Could you say more about the use case(s) for >> this? Your blog and spec focus on the "multidevice" case (Alice has a >> laptop and tablet and phone), but you also call the password a "backup >> code" and mention the user losing their device. > > We used to call it "keychain code", but that name didn't really make much sense to users. When we looked at the Yahoo E2E UX we saw that they used to term "backup code", which made more sense. Depends on what it's used for. It's not clear from the video whether the Yahoo code is also used for multi-device setup, or just backup: "Please copy down this backup code in a safe place. You can use it to restore your encryption keys if you ever delete them accidentally." Your explanation states there's a dual role (backup and multidevice): "Your backup code can be used to securely backup and synchronize your encryption key between devices. [...] Please write down your backup code and keep it in a safe place." These explanations are vague about why backup/restore of "your encryption key" is important. I think the answer is to allow decryption of all messages you've received that are stored at the service, so people don't lose access to old messages? I expect some users won't bother to write the backup code down, or will lose it, or will store it someplace hard-to-access, or won't have the code with them when they purchase a new device. If new-device setup requires the backup code, it seems like these users will be inconvenienced. Also, some users might decide they don't *want* a backup code since they prefer forward-secrecy for old messages instead of recoverability. Would they have to sacrifice multi-device support? So I'm still unsure how this fits into an overall key management system, and whether it makes sense to combine multidevice support and key backup. >> For the multidevice case, did you consider device-pairing protocols >> like PAKE (SRP etc), Short-Auth Strings (SAS), or other (QR, NFC)? >> These could allow the user to deal with much shorter strings, or >> dispense with entering / comparing strings altogether. > > Pairing via a PFS scheme would be ideal security wise, but we had to consider the constraints of the web platform. It's not obvious how to get QR codes or NFC to work there. It's certainly possible to display a short text string or QR code from a web app. >> (B) Having to dig out this secret and enter it on phones / tablets is >> not a friendly UI. > > We looked at the workflow of users. It turns out people use password managers like 1password to copy/paste the code. So it's not as bad as one would think UX wise. Good point that password managers tackle a similar problem, so could be leveraged or at least learned from. I believe 1Password allows sync via services like DropBox or iCloud, or device-to-device via Wifi. For the former, security comes from the user-chosen "master password", for the latter one device displays a "secret code" which is entered into the other during the sync process (and appears ~40 bits): <a href="https://guides.agilebits.com/1password-ios/5/en/topic/sync-over-wifi" target="_blank">https://guides.agilebits.com/1password-ios/5/en/topic/sync-over-wifi</a> Is there any data on how many people use different sync approaches (or use *any* sync approach)? I'd also love to know what the protocol is for Wifi sync, anyone know? > Agreed. The option of allowing user-supplied passphrases could be removed from the spec. Agreed, but looking at the example strings from Yahoo and Whiteout I'm not sure that leaves you with good useability: Yahoo: spurrey wanner eligible outgrown diversification hushed adapter hammerer 1 Whiteout: OA9J-IK9J-TZ2W-LEGP-ASWN-K24B > Mozilla made an interesting point in a post about Firefox sync. Basically users were confused by pairing between devices and expected to be able to recover their data even if all devices are lost: > > <a href="https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/" target="_blank">https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/</a> I've seen other people cite Firefox Sync and Brian Warner's "Pairing Problems" blog as arguments against device-pairing. For example, the CONIKS paper: "Unfortunately, device pairing has proved cumbersome and error-prone for users in practice" <a href="https://eprint.iacr.org/2014/1004.pdf" target="_blank">https://eprint.iacr.org/2014/1004.pdf</a> But the UI Firefox tried was too awful to support these conclusions, IMO: <a href="https://blog.mozilla.org/warner/2014/04/02/pairing-problems/" target="_blank">https://blog.mozilla.org/warner/2014/04/02/pairing-problems/</a> Note that users had to register with the Firefox Sync server prior to running the pairing protocol, and choose (and confirm) a password which is then "never entered again" (?!) After this, it's not surprising users would expect that their data was retrievable from this server based on the password, which was a huge breakdown between expectations and what the system actually provided. When you then tried to run the pairing process, you get a short secret code, but are also given a link "I don't have the device with me" which then tells you to enter a "Sync Key" which you've never heard of before and can get from your other device (which you've just said isn't with you), and then if you click "I have lost my other device" it lets you erase all data and generate a new "Recovery Key" which I guess is the same as the "Sync Key"? Anyways, this is UI design by Kafka, I don't think it argues for or against any mechanism... Trevor _______________________________________________ Messaging mailing list <a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a> </blockquote></div>