<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>Hi Trevor,</div><div><br></div><div>You bring up some valid points. Indeed, a SafeSlinger key exchange is as usable as the medium over which it is used. I list below an un-scientific estimate of the availability of a handful of communication channels for all smartphone users (considering current market distribution of all versions of iOS, Android, Windows Phone, and Blackberry) to run the protocol which drove choosing the use of a server for our first implementation. It's true an additional out of band "low number" adds another step, thus lowering usability. However, usability is a broad category, not being able to install the application for hardware restrictions, OS version, or not having the right communication channel available after installation also lowers the usability.</div><div><br></div><div><div>TCP/IP: 100% available, 100% cross-platform, requires an additional out of band grouping number, adds network overhead.</div></div><div>Bluetooth: 100% available, 0% cross-platform (Thanks Apple!), adds some discovery time.</div><div><div>LE Bluetooth: 25% available, 100% cross-platform, adds some discovery time.</div></div><div><div>NFC: 25% available, 100% cross-platform, adds some discovery time.</div></div><div><div>WiFi Direct: 25% available, 100% cross-platform, adds minimal discovery time.</div></div><div><br></div><div>To your point about local wireless, it would be great to run the protocol over a local network channel like WiFiDirect or LE Bluetooth, since some countries block our servers outright. Of course we need to design some good usability features to help users decide which channel to use. A simple ping of the server could provide this for 2 mainland China users to determine that BT should be used since our server is blocked, however it doesn't help the case where one user is in mainland China and the other is in the US attempting the exchange. It'll take some UX planning, but could be done.</div><div><br></div><div>After consulting with Adrian (I finally remembered to cc him on this DL) about using DH trees, he offers this:</div><div><br></div><div>"This paper shows that if communication is slow, then the STR DH tree we are using is very efficient:</div><div><a href="https://sparrow.ece.cmu.edu/group/pub/old-pubs/str-toc.pdf">https://sparrow.ece.cmu.edu/group/pub/old-pubs/str-toc.pdf</a></div><div><br></div><div>But to scale to larger groups, we should use TGDH:</div><div><a href="https://sparrow.ece.cmu.edu/group/pub/old-pubs/ccs2000.pdf">https://sparrow.ece.cmu.edu/group/pub/old-pubs/ccs2000.pdf</a></div><div><br></div><div>TGDH should be more efficient than the other options, AFAIK."</div></div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div><div>Cheers,</div><div>Mike</div><div><br></div><div>Michael W. Farb</div><div>Research Programmer, Carnegie Mellon University CyLab</div><div>M 412-965-4725 - <a href="http://www.cylab.cmu.edu/safeslinger">www.cylab.cmu.edu/safeslinger</a></div></div></div></div></div>
</div>
<br><div><div>On Jun 30, 2014, at 2:53 AM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Jun 26, 2014 at 2:35 PM, Michael Farb <<a href="mailto:mwfarb@cmu.edu">mwfarb@cmu.edu</a>> wrote:<br><blockquote type="cite"><br>One approach we took with SafeSlinger was to reduce the set of 2-10 public<br>keys of all users who are trying to simultaneously exchange keys to 24-bits<br>through a real-time combined in-band and out-of-band protocol. The advantage<br>is 2-10 people attesting to the same 24-bit ephemeral fingerprint goes<br>pretty quickly.<br></blockquote><br>Hi Michael,<br><br>Thanks for sending that!<br><br>We had earlier discussion on nearby people exchanging public keys and<br>other contact info by using their phones to execute a "pairing"<br>protocol, which users authenticate with a "Short Auth String".<br><br>SafeSlinger looks like a well-designed generalization of that for<br>small groups. Everyone in the group verifies the same SAS, instead of<br>having each pair of users compare.<br><br>At the moment it looks like communications are through a server, with<br>a "compare amongst yourselves and enter lowest ID" step so the users<br>can form into groups while preserving client anonymity.<br><br>But that's a useability inconvenience, and the server contact still<br>seems like a risk for relationship info (you could contact it over<br>Tor, but Tor's not perfect). I wonder what the prospects are for<br>making this work over Bluetooth or other short-range comms. The<br>paper's analysis of message rounds and bandwidth is a little vague, it<br>would be nice to see more detail.<br><br>I'm also curious what led you to choose a tree-based group key<br>agreement rather than either<br> (A) a ring-based GKA (like Burmester-Desmedt or Kim-Lee-Lee [1], e.g.<br>do DH with parties to left and right of you, publish the XOR), or<br> (B) pairwise encryption to each user's public DH value (at <= 10<br>users, it seems like that could be a single message of a few hundred<br>bytes).<br><br>Trevor<br><br>[1] <a href="https://www.iacr.org/archive/asiacrypt2004/33290243/33290243.pdf">https://www.iacr.org/archive/asiacrypt2004/33290243/33290243.pdf</a><br></blockquote></div><br></body></html>