[noise] Designing a Secret Handshake: Authenticated Key Exchange as a Capability System

[Kenton Varda]

Speaking as someone very interested in capability systems but only an
amateur cryptographer, this paper disappoints me in a few ways:

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].

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.

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.

-Kenton

[0] http://zesty.ca/capmyths/usenix.pdf

On Sat, Jul 25, 2015 at 3:38 PM, Jonathan Rudenberg <jonathan at titanous.com>
wrote:

> 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:
> https://dominictarr.github.io/secret-handshake-paper/shs.pdf
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150725/e8baedb2/attachment.html>