<div dir="ltr"><div>Speaking as someone very interested in capability systems but only an amateur cryptographer, this paper disappoints me in a few ways:</div><div><br></div><div>1. The proposed approach wants to turn public keys into secret capabilities. This seems inherently risky, since I imagine a lot of crypto systems do not protect public keys as carefully as they protect private keys. It also implies capabilities-as-keys, which is not ideal[0].</div><div><br></div><div>2. The proposed protocol implies that Bob only hosts one capability, or that the capability to which Alice is trying to connect is known before the protocol starts. That's not how capability systems are supposed to work: a "capability" both designates an object and authorizes access to it. One way to "fix" the protocol would be for Alice to send a hash of the public key upfront, but that would mean revealing in cleartext which capability she intends to access. Salting the hash brings us back to a place where Bob has no efficient way of looking up the capability Alice wants since he'd have to test each possibility one-by-one. Practical object-capability systems host large numbers of objects per "vat" (where a "vat" is typically a process, or maybe a machine, but in any case typically has only one physical address). Vat A establishes a secure connection to Vat B, and then only requests a specific capability over that connection after it is set up. Connecting to the vat itself requires no authority, typically, since the vat offers no ambient services.</div><div><br></div><div>3. The paper does not say anything about introductions. Connections in capability systems are usually established via introductions through third parties. The presence of an introducer calls for a completely different kind of handshake, because the introducer can provide information to both parties upfront which allow fewer round trips between the two. Indeed, the protocol proposed in the paper appears to require two round trips, where you ought to need zero when there is an introducer involved.</div><div><br></div><div>-Kenton</div><div><br></div><div>[0] <a href="http://zesty.ca/capmyths/usenix.pdf">http://zesty.ca/capmyths/usenix.pdf</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 3:38 PM, Jonathan Rudenberg <span dir="ltr"><<a href="mailto:jonathan@titanous.com" target="_blank">jonathan@titanous.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m haven’t wrapped my head around the reasons behind embedding “capabilities” into the handshake yet, but this paper includes some references to the old draft of Noise: <a href="https://dominictarr.github.io/secret-handshake-paper/shs.pdf" rel="noreferrer" target="_blank">https://dominictarr.github.io/secret-handshake-paper/shs.pdf</a><br>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div><br></div>