Comparing capability systems

[Alan Karp]

I've been asked to write a pros and cons of different types of capability systems.  

The first piece is listing the types.  I have object references, such as endosjs.org, opaque tokens, such as waterken, and certificates, such as zcaps and Macaroons.  Are there other categories?

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

--------------
Alan Karp

[Chris Hibbert]

On 3/5/26 8:05 AM, Alan Karp wrote:
>
> The first piece is listing the types.  I have object references, such as

> endosjs.org <http://endosjs.org>, opaque tokens, such as waterken, and

> certificates, such as zcaps and Macaroons.  Are there other categories?

Do hardware solutions, where the reference is an address count as a
different type?

Chris
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Rob Meijer]

Not an other category but I think there are (at least) four subcategories of opaque tokens that you might possibly want to distinguish between.

* Hierarchical (Derivable) Opaque Tokens
* Non hierarchical cryptographically relevant opaque tokens.
* Content-Addressable (Integrity-Bound) Opaque Tokens
* Random Opaque Tokens

Op donderdag 5 maart 2026 om 17:05:53 UTC+1 schreef alan...@gmail.com:

[Alan Karp]

On Thu, Mar 5, 2026 at 9:46 AM Rob Meijer <pib...@gmail.com> wrote:

Not an other category but I think there are (at least) four subcategories of opaque tokens that you might possibly want to distinguish between.

* Hierarchical (Derivable) Opaque Tokens
* Non hierarchical cryptographically relevant opaque tokens.
* Content-Addressable (Integrity-Bound) Opaque Tokens
* Random Opaque Tokens

I was thinking only of random opaque tokens, such as OAuth authorization tokens or waterken webkeys.  The key factor distinguishing them from others is that the basic attenuated delegation mechanism is token exchange.  (Caretakers are an option for any capability system.)

Can you explain, or give examples, of the other 3?

--------------
Alan Karp\

[Mark S. Miller]

There are (at least) two orthogonal dimensions. The abstract access control model and the implementation substrate.

Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/full-text/ distinguishes 4 main access control models: ACLs as columns, Capabilities as rows, Capabilities as keys, and Object-Capabilities. It differentiates these by 6 criteria. 

I would add Alan's Split Capabilities as a distinct capability-oriented access control model.

Cap Myths Demolished then classifies several actual systems according to these same six criteria

This classification is still orthogonal to the implementation substrate.

The primary implementation substrates, in chronological order of invention, are:

OS (Dennis and Van Horn 1965), Capability OS golden age in the 1970s, KeyKOS, EROS, CapROS, Coyotos, seL4, Capsicum

Hardware or mixed Hardware/OS (Cambridge CAP system 1970), Intel 432 (horror), CHERI and CHERI-like (ARM)

Dynamic Language (Gedanken "Protection in Programming Languages" 1973), Actors, Vulcan, Joule, W7, E, Monte, HardenedJS. (Erlang is close to caps.)

"Static" languages (Emily 2006), Joe-E, Tamed PICT, local-Midori. (Rust without libraries is close to caps.)

Live cryptographic protocols (DCCS 1970s I think), Indra (for Joule), CapTP family (E's CapTP, Midori, Cap'n Proto, ocapn)

Offline cryptographic certificate systems (SPKI/SDSI 1996), CapCert (never implemented)

Alan, there were two generations of Client Utility. The first was split capabilities are the second started with SPKI/SDSI. I'll leave it to you to expand on how it fits.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1s9-D_XnF7wr1toLBPqCDWuQfPDqx2OA-ZkCrYRbOzAA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

A third orthogonal axis is the persistence and upgrade model.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We expect that both forms of upgrade will migrate to Endo, but we do not expect non-consensus use of Endo to support orthogonal persistence. Rather, the durable state of state-based upgrade will also provide persistence.

Mostly separately, Endo supports formula-based persistence and upgrade, already reflected in the Endo cap-oriented UI, the Familiar.

--

  Cheers,
  --MarkM

[Mark S. Miller]

Yes, zcaps definitely falls in the offline cert caps category. Yes, Macaroons is close enough that it is at least adjacent to that category.

Spritely also has an ocap-oriented UI (the Agency) with at least petnames. I don't know about revocability.

Plash is both a dynamic language and a command-line UI, depending on how you want to describe it.

--

  Cheers,
  --MarkM

[Mark S. Miller]

See also Part IV (Related Work) of Robust Composition (2006) https://papers.agoric.com/papers/robust-composition/abstract/

--

  Cheers,
  --MarkM

[Mark S. Miller]

Part V that is.

--

  Cheers,
  --MarkM

[Mark S. Miller]

Much more comprehensive lists at https://github.com/dckc/awesome-ocap

--

  Cheers,
  --MarkM

[Rob Meijer]

Sure.

* Content addressable or integrity bound opaque tokens can be something like a secure hash over the logically immutable (integrity bound) part of what is addressed. The simplest example is using the sha256 hash of a read only file as capabity for reading the file.

* The best example of a non hierarchical cryptographically relevant opaque tokens are I think YURLs. 

* An example of hierarchical opaque tokens is my old pyrumpeltree project. There is a detetministic cryptographic  link between a capability token for some composite or more powerful authority and a capability for a decomposition or attenuation of that authority. 

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0E1PY0XsbhR0PsHo_%3DPRUpYLm4VgxjOpy_iNhZwJvRvg%40mail.gmail.com.

[Mark S. Miller]

In the UI category: Belay https://www.youtube.com/watch?v=2_5p6S2eW8s&t=1s

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Thu, Mar 5, 2026 at 12:14 PM Mark S. Miller <eri...@gmail.com> wrote:

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

A third orthogonal axis is the persistence and upgrade model.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We

Not "relay based". Should be "replay based"

 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYgR%2BGkidv8v6jMSi5%2Bk80DiOEFEGkDhzoL7SiBeEXt%2BDw%40mail.gmail.com.

[Mark S. Miller]

From Robust Composition:

> Object-capability systems differ regarding concurrency control, storage management, equality, typing, and the primitiveness of messages, so we avoid these issues in our model.

Thus, each of these are further dimensions of classification.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD57_zwLRTfQ1fa%3DtaPZJTr04ycShGMtZObNOXJJm9pRpA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

On Thu, Mar 5, 2026 at 8:54 PM Mark S. Miller <eri...@gmail.com> wrote:

From Robust Composition:

> Object-capability systems differ regarding concurrency control, storage management, equality, typing, and the primitiveness of messages, so we avoid these issues in our model.

Thus, each of these are further dimensions of classification.

I also feel like you could perhaps argue that whether messages cross either trust boundaries, or fault boundaries or reliability guarantees could be a dimension of classification.  In the sense that Alice's machines may be within the same trust boundary, yet crash independent of one another, compared with Alice and Bob's machines individually being within different trust boundaries. Others exist only in isolation. *shrug*

[Alan Karp]

The focus of the group is on cross domain delegation to, by, and between AI agents, so I don't know how much interest there is in UI issues.  I've thrown the link in my document just in case.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYj0NvHkoe-zc5SjxZQKEyd_9JphAsmeOci9q5PHRQFbig%40mail.gmail.com.

[Mark S. Miller]

Thanks, I missed that. Where it comes up repeatedly for me is the issue of network partition and endpoint crash/revival. This dimension is somewhat distinct from persistence/upgrade, but obviously the two must be co-designed. E and Waterken are both communicating event-loops with a local ocap language and a distributed live ocap protocol. However, they took opposite stances on distributed error handling:

Waterken masks partition and crash/revival. A network partition is, to the Waterken programmer, just a slow network. Every crashed machine is just a slow machine. Every sent message is still delivered exactly once, independent of these low-level problems. Agoric's use of Endo following the Waterken failure model.

E had live refs vs sturdy refs. You send messages on live refs, until the connection carrying the live ref breaks. Connections are broken when a keep-alive exceeds a timeout. Live refs once broken stay broken.

Sturdy refs are long lived caps that do not depend on connection liveness. But you don't send a message on a live ref. Rather, you use it only to get a new live reference to the object designated by the sturdy ref.

distributed error model is entangled both with persistence and upgrade model and with the distributed deallocation model, such as distributed acyclic gc, which is another dimension of variation.

Also entangled with message ordering, such as FIFO vs E-Order.

 

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFqf0wMY%3D_LNgDyDPGuVPYWOHPAzQfHJpZcD9aXF_VCYsg%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

On Thu, Mar 5, 2026 at 12:34 PM Rob Meijer <pib...@gmail.com> wrote:

* Content addressable or integrity bound opaque tokens can be something like a secure hash over the logically immutable (integrity bound) part of what is addressed. The simplest example is using the sha256 hash of a read only file as capabity for reading the file.

Content addressable is fine for static resources, such as files.  They don't seem to be useful for dynamic resources, such as services like MCP servers.

* The best example of a non hierarchical cryptographically relevant opaque tokens are I think YURLs. 

That's an example of what I've been calling an opaque token.  Other than pointing to the resource, the bits have no structure.

* An example of hierarchical opaque tokens is my old pyrumpeltree project. There is a detetministic cryptographic  link between a capability token for some composite or more powerful authority and a capability for a decomposition or attenuation of that authority. 

Like the relationship between read and write capabilities in Tahoe LAFS?

--------------
Alan Karp

[Bakul Shah]

What is the purpose of this exercise?

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1s9-D_XnF7wr1toLBPqCDWuQfPDqx2OA-ZkCrYRbOzAA%40mail.gmail.com.

[Alan Karp]

On Thu, Mar 5, 2026 at 1:54 PM 'Bakul Shah' via friam <fr...@googlegroups.com> wrote:

What is the purpose of this exercise?

That's the right question, and I should have answered in my original email.  I'm also glad that I didn't because I might not have gotten the wealth of material sent by Mark Miller.

I am participating on the Delegation Subcommittee of the Trusted AI Agent Working Group of the Distributed Identity Foundation.  (Quite a mouthful, that.)  Our goal is to provide a spec for delegating permissions to, by, and between AI agents, which means we're only interested in distributed use cases for general resources.  The group has decided to use capabilities, but the restrictions rule out hardware (CHERI), OS (sel4), purely local ocaps, and resource specific solutions such as Tahoe LAFS.  I expect we'll end up with zcaps, but the group wants a strong justification for that choice.

I provided the group with a list of about a dozen capability or capability-adjacent (e.g., OAuth 2) systems.  At today's meeting, we went through the exercise of seeing how to implement Stiegler's 7 aspects of sharing (his 6 plus revocation) with OAuth 2.  It took most of the meeting.  Since I don't want to spend the next 3 months working through the options, I thought we could do that exercise for each of a few types, opaque tokens (Waterken), digital certificates (zcaps), and distributed object references (E).  

My thinking is that attenuated delegation with opaque tokens can be done with token exchange, independent of the specific system.  Similarly, certificate systems allow for offline delegation, whether they are signed (zcap) or hashed (Macaroons).  My hope is that showing how each of the 3 types can be used to implement the 7 aspects of sharing will suffice.

One solution that always works is caretakers, but there are cost, resource consumption, resilience, and performance concerns.  Also, you don't know ahead of time what caretakers you might need because AI agents develop the solution strategy as they go along.  On the other hand, an AI agent might be able to code any caretaker it needs.

--------------
Alan Karp

[Alan Karp]

On Thu, Mar 5, 2026 at 11:31 AM Mark S. Miller <eri...@gmail.com> wrote:

There are (at least) two orthogonal dimensions. The abstract access control model and the implementation substrate.

 

As I explained in my response to Bakul, that's exactly the split I'm trying to exploit.  The group started by looking at an individual implementation substrate to see how to implement the 7 aspects of sharing.  I'm trying to get them to get the work done faster by using the abstract models.

 

Alan, there were two generations of Client Utility. The first was split capabilities are the second started with SPKI/SDSI. I'll leave it to you to expand on how it fits.

SPKI/SDSI is covered by certificate capabilities.  Split capabilities are closer to a distributed object model but are tied so closely to a particular runtime that I don't think they're worth considering for this project.

--------------
Alan Karp

[Alan Karp]

On Thu, Mar 5, 2026 at 12:14 PM Mark S. Miller <eri...@gmail.com> wrote:

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

Our goal is to define a protocol but not a programming model for whatever capability system we select.  I know you can probably build a system where each vat has its own style of capabilities, but I haven't seen anyone do that for language based capabilities.  We did it with certificates; Zebra Copy was built with J2EE talking to .Net.

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

The group hasn't discussed UI, but we certainly should.

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

That's where I put them, too.

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

Same category as E/Waterken/Joe-E?

A third orthogonal axis is the persistence and upgrade model.

Good point.  I've added that to our list of considerations.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We expect that both forms of upgrade will migrate to Endo, but we do not expect non-consensus use of Endo to support orthogonal persistence. Rather, the durable state of state-based upgrade will also provide persistence.

Mostly separately, Endo supports formula-based persistence and upgrade, already reflected in the Endo cap-oriented UI, the Familiar.

I don't understand very much of the previous 2 paragraphs, but it sounds interesting.  Maybe I'll be able to learn about it when the committee work is done.

 

--------------
Alan Karp

[John Carlson]

I would enjoy a discussion of UI, particularly sharing delegated bearer tokens in a mathematics class giving authority to modify parameters of a spherical equations rendered on all connected web-based clients.

The teacher might share different bearer tokens with different students, such that different tokens give authority to change one or more parameters.

There seems to be 2 tiers, one for granting bearer tokens, or a contacts application that sends bearer tokens to students accounts (email), and then the actual environment where bearer tokens give authority.

John 

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1y51Cv6AH%3DTCs%2BgR_TdLcrMZwLQUMdvH6AK0jW8%3DJYHw%40mail.gmail.com.

[Alan Karp]

One challenge is how you know what permissions you're sharing. Marc Stiegler came up with the concept of WYSIWYSH, What You See Is What You Share.  His editor had tabs at the top for Edit, Read, and Append.  If you're editing a document, and click the Share button, you're sharing read/write permissions; similarly for Read and Append.  The problem we ran into was inadvertently sharing while in Edit mode.  The solution required another click.  When you click Share, you get a mini-menu with the options.  Not terrible, but annoying nevertheless.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3D1yRJMz2%2BzjALBKOFKe9zrYPnDQ9SFHhabbur%3Dq8zRSA%40mail.gmail.com.

[Mark S. Miller]

Alan, I have no idea whether this further distinction is relevant to you. But to further expand the taxonomy, we can divide crypto-cap systems based on whether messages are repudiatable or not. 

All live protocols I'm aware of first negotiate a single-key session keys (one for encryption and one for MAC), and then encode sent messages with those. Such protocols are inherently repudiable. When I receive a message from you, I know it's from you because I know it isn't from me. But I cannot prove that to a 3rd party.

All offline cert-based cap systems I'm aware of use public keys more directly, producing non-repudiable messages.

Neither dominates the other. For some security purposes, you may want repudiability. For other security purposes you may want non-repudiability.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z35TiX0X%3DC%3D2Y2j6%2BEcLLCKLA7k2QxBkQ7ZOuz%2Bfs3Bng%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Rob Meijer]

On Thu, 5 Mar 2026, 22:47 Alan Karp, <alan...@gmail.com> wrote:

On Thu, Mar 5, 2026 at 12:34 PM Rob Meijer <pib...@gmail.com> wrote:

* Content addressable or integrity bound opaque tokens can be something like a secure hash over the logically immutable (integrity bound) part of what is addressed. The simplest example is using the sha256 hash of a read only file as capabity for reading the file.

Content addressable is fine for static resources, such as files.  They don't seem to be useful for dynamic resources, such as services like MCP servers.

Almost. Resources with a logically  static/frozen set of integrity relevant parts. It can be useful for a sparse cap to become invalid if invariants are compromised. 

* The best example of a non hierarchical cryptographically relevant opaque tokens are I think YURLs. 

That's an example of what I've been calling an opaque token.  Other than pointing to the resource, the bits have no structure.

There is a lack of structure in the token itself, but when the token is cryptographicly linked to for example a public key or doubles as a symetric key, it's still different from just random bits. 

* An example of hierarchical opaque tokens is my old pyrumpeltree project. There is a detetministic cryptographic  link between a capability token for some composite or more powerful authority and a capability for a decomposition or attenuation of that authority. 

Like the relationship between read and write capabilities in Tahoe LAFS?

In pyrumpeltree a read-only sparse cap is  a secure hash of the read-write sparse cap, and that read-only sparse-cap doubles as AES key+iv for encryption of a node. Then another secure hash operation creates a storage location handle for the encrypted node data. So that part is attenuation.

The combination of a child node name, a server side secret salt and the patent read only sparse cap is then hashed together to get the read write sparse cap of the child node. 

That means you can do client side attenuation and server side decomposition, and both attenuation and decomposition work without a collection of unrelated random numbers. 

It's one step beyond the YURL example in that the there can be deep hierarchies. 

Hope this makes sense. 

If not, try out playing with rumpelbox from pyrumpeltree. 

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3btia2en5ai0wYzbH2MN4y%2Bn81MWvT8uh9gRu9dX6Skw%40mail.gmail.com.

[John Carlson]

My thought is to have insert (append, for folders, create tables, grant/delegate, put), read (select, query, get), update (edit, set, post), delete (remove, revoke), so not only a GUI for sharing, but also a GUI or actions for stopping sharing.

Aka CRUD.   Attentuate is just meta-CRUD, or CRUD about CRUD.

Personally, I would not do tabs, but checkboxes, probably following after Product Lifecycle Management and MatrixOne, which had many more options I forget.   Maybe that’s the same as a mini-menu.  Each type of object would have their own set of checks, but the labels on the checkboxes were the same.

CRUD operations can be associated with many types of resources to make up capabilities.  Attenuate is just CRUD on capabilities.

This may look like primitive SQL or REST.

What is “join” though?  Query?  Equate?  Compare? What is “sort” and “group by”?  More forms of query?

What I came up for my JSONvirse GUI was a list of petnames for updating of a set of parameters.  My demo had 2 petnames and 6 parameters, so four parameters for each petname.  I could switch between petnames, but I don’t think one could enable more than one petname, except perhaps in a common room or channel.

John

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z35TiX0X%3DC%3D2Y2j6%2BEcLLCKLA7k2QxBkQ7ZOuz%2Bfs3Bng%40mail.gmail.com.

[John Carlson]

I’m trying to grok this.  Basically I can either prove that a capability I invoked was done or not done by me or my agent, or I can prove that you or your deputized agent invoked a capability or no one can prove whether I or my agent invoked the capability?

So responsibility versus irresponsibility?  Some form of logging or absence of logging?  A transaction log?  Or just the presence or absence of signatures, which might be repeated?  Revocation, timestamp, acknowledgements or unique ids might help with replays?  AFAIK, PKI by itself does not by itself prevent replays.  This is very important in payment systems.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjD%3D77k9DFgAx1wNWgjaof8099__8x3754jDh_7b_WJfA%40mail.gmail.com.

[Jonathan S. Shapiro]

I think Spectre and Meltdown may have marked the end of approaches built on in-memory swiss numbers without hardware-assisted protection, and also cryptographic systems that use an in-memory signing or encryption key or secret without hardware protection. Speculative execution exploits (that is: side channel attacks) can extract the bits of these from the address space of a non-cooperating holder. The current best solution is hardware key stores. Once you use a secure store of this kind, it's not so clear why a swiss number is better than a more ordinary data structure.

The KeyKOS approach uses a different solution. In KeyKOS, speculation can be used to exfiltrate the bits of a capability, but there is no operation that transforms those bits into something the kernel will accept or use as a capability; data bits that happen to match a valid capability payload do not convey authority.  Except at the point where objects come in from the store. There is a rights amplification happening there, because the bits on the store are unprotected (unless the store is encrypted). But here again, exfiltrating the bits isn't enough to convey authority.

Memory tag bits that distinguish capabilities from data have the same guarding effect.

The saving grace in all of this is that my side channel attack can read your secrets without your help, but (at least so far) we have not yet seen a side channel attack that can induce security-conscious software to wield its authority or engage in rights amplification or collaborate in sharing guarded authority. Conventional attacks can do that, but not side channel attacks.

Since Meltdown and Spectre, the problem has gotten worse. Processors do more and more aggressive speculation with every passing year, expanding the tools available for attack designers.

Jonathan

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3D2cUZ2jH_Ros5Er6WaRFgz3ejLbOuA5vs95WGgC6GHHA%40mail.gmail.com.

[Alan Karp]

I've always assumed that non-repudiation was something built on top of the messaging layer, but you got me thinking. 

If the certificate is issued to your well-known public key, then I can use that capability only if I can steal your secret key or you share it with me.  Does that meet your requirement for non-repudiation?

I don't like issuing certificates that way for privacy reasons.  I prefer creating a key pair per certificate.  When you delegate to me, you ask me for a public key.  I create a new key pair and send you the public key that you issue the certificate to.  That doesn't satisfy your requirement.  However, I can use my widely known key to create a public commitment to the one-off key.  Does that do the trick?  I think you can use a ZKP to preserve privacy, but I've already got a headache from thinking so hard.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjD%3D77k9DFgAx1wNWgjaof8099__8x3754jDh_7b_WJfA%40mail.gmail.com.

[Alan Karp]

On Thu, Mar 5, 2026 at 4:11 PM Rob Meijer <pib...@gmail.com> wrote:

Content addressable is fine for static resources, such as files.  They don't seem to be useful for dynamic resources, such as services like MCP servers.

Almost. Resources with a logically  static/frozen set of integrity relevant parts. It can be useful for a sparse cap to become invalid if invariants are compromised. 

In the business world, it's more likely that you'd want to allow me to use (and pay for) your service when the invariants change.  That being said, there can be metadata unrelated to the content that can be used for the sparse cap.

There is a lack of structure in the token itself, but when the token is cryptographicly linked to for example a public key or doubles as a symetric key, it's still different from just random bits. 

True, but I'm using the word "opaque" to mean that the holder of the token can't do an offline delegation.   Maybe there's a term that conveys that aspect.

* An example of hierarchical opaque tokens is my old pyrumpeltree project. There is a detetministic cryptographic  link between a capability token for some composite or more powerful authority and a capability for a decomposition or attenuation of that authority. 

Like the relationship between read and write capabilities in Tahoe LAFS?

In pyrumpeltree a read-only sparse cap is  a secure hash of the read-write sparse cap, and that read-only sparse-cap doubles as AES key+iv for encryption of a node. Then another secure hash operation creates a storage location handle for the encrypted node data. So that part is attenuation.

The combination of a child node name, a server side secret salt and the patent read only sparse cap is then hashed together to get the read write sparse cap of the child node. 

That means you can do client side attenuation and server side decomposition, and both attenuation and decomposition work without a collection of unrelated random numbers. 

Does that work if the content changes?  Does it work for more general services?

--------------
Alan Karp

[Alan Karp]

On Thu, Mar 5, 2026 at 6:16 PM John Carlson <yott...@gmail.com> wrote:

My thought is to have insert (append, for folders, create tables, grant/delegate, put), read (select, query, get), update (edit, set, post), delete (remove, revoke), so not only a GUI for sharing, but also a GUI or actions for stopping sharing.

Aka CRUD.   Attentuate is just meta-CRUD, or CRUD about CRUD.

I've never thought about it that way, but it makes sense.

Personally, I would not do tabs, but checkboxes, probably following after Product Lifecycle Management and MatrixOne, which had many more options I forget.   Maybe that’s the same as a mini-menu.  Each type of object would have their own set of checks, but the labels on the checkboxes were the same.

Stiegler's goal was to minimize the number of clicks needed to delegate.  Check boxes imply you need a click per permission.  Tabs allow you to collect permissions that often go together, such as read/write/append. 

--------------
Alan Karp

[Alan Karp]

OAuth is a widely used protocol that relies on bearer tokens represented as bits.  Anyone who learns those bits has what they call an authorization token.  The people designing OAuth were worried about the bits being leaked, but not due to Spectre/Meltdown, so they added something they called the client secret.  Only a service that has pre-registered with the resource provided is allowed to use the token.  That choice has been the source of all kinds of problems.  Still, requests from someone who can steal a token and a client service will be honored.  Since OAuth is used for all kinds of financial transactions, I'm sure we would have heard of successful attacks.

I wonder if the KeyKOS approach is safe if you combine Spectre/Meltdown with RowHammer.  I believe that combination would allow you to learn a set of bits that can then be written to memory in a way that they'd be treated as a capability.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMN3v5-p9Q%2BPOBZKJU23rBUGUn4wmxBL3cUyf5dhXbkMA%40mail.gmail.com.

[Gernot Heiser]

I wasn’t following this discussion, but the following struck my eye:

On 7 Mar 2026, at 05:25, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I think Spectre and Meltdown may have marked the end of approaches built on in-memory swiss numbers without hardware-assisted protection, and also cryptographic systems that use an in-memory signing or encryption key or secret without hardware protection. Speculative execution exploits (that is: side channel attacks) can extract the bits of these from the address space of a non-cooperating holder.

This is technically incorrect.

Spectre is *not* a side-channel attack, despite frequently called such (part of a widespread confusion of side channels vs general covert channels). 

A side channel allows an outsider to observe an innocent program’s state via its normal execution. A general covert channel uses an insider (Trojan) to deliberately leak.

Spectre uses speculative execution to construct a Trojan from code gadgets which get speculatively executed. And the Trojan uses a covert channel to deliberately leak.

And there is a systematic way of preventing this, by ensuring all microarchitectural state is spatially or temporally partitioned – the latter requiring that the state is reset at context-switch time. It’s been demonstrated that this is pretty easy to do (vKgSRDoFTFHir0PqILqA2AG1Faxf0c8wRB1JHbD01Ib3eVmA8i236F04gK3q7mguxYCJ_5k) and there’s a RISC-V task group working on standardising it.

Gernot

[Alan Karp]

Most mechanisms to block these side channel attacks have serious performance impact.  For example, don't you lose your branch predictor state?  What about the cache?  Surely, you're not invalidating it.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/DEE68EFF-B731-4AF3-BADC-4173DE2B5F48%40gmail.com.

[Gernot Heiser]

On 7 Mar 2026, at 10:54, Alan Karp <alan...@gmail.com> wrote:

Most mechanisms to block these side channel attacks have serious performance impact.  For example, don't you lose your branch predictor state?  What about the cache?  Surely, you're not invalidating it.

Cache channels are the easiest to exploit as covert and side channels. L1 caches are virtually indexed and cannot be spatially partitioned, they *must* be invalidated, like it or not.

The cost of this is dominated by the D-cache writeback, but that’s unavoidable. Everything else happens in parallel and doesn’t add to the cost.

Indirect costs are negligible, as, after a round of context switches, there normally isn’t much hot state left in any on-core caches (incl branch predictors etc).

Caches lower in the hierarchy can be spatially partitioned. There’s some performance cost, as the limit of the cache working set is reduced, but in many cases this is actually beneficial and sometimes used to *improve* performance, and in any cases leads to more predictable performance in the case of a contented cache.

Gernot

[Jonathan S. Shapiro]

On Fri, Mar 6, 2026 at 3:03 PM Alan Karp <alan...@gmail.com> wrote:

I wonder if the KeyKOS approach is safe if you combine Spectre/Meltdown with RowHammer.  I believe that combination would allow you to learn a set of bits that can then be written to memory in a way that they'd be treated as a capability.

There are two protections against this:

1. Eric Northup pointed out the other day that because the features are so small, modern DRAMS implement ECC even if they don't bring out the lines needed to expose the ECC. This is intended as a particle hit guard that became needed as the densities got higher and higher. It isn't a complete solution, but it makes RowHammer harder.
2. When Coyotos runs on conventional processors, it is the location of the bits that makes them a capability. All capabilities live in specific "slots" of kernel-protected objects that are only mapped at kernel virtual addresses and have exactly one mapping. Given these constraints, I think RowHammer would have to be operating inside the kernel to flip these bits.
   
   RowHammer is not effective against SRAM, so bits in the cache are also safe; RowHammer can't be applied to them by hammering lines at a cache-aliased address.
3. On a [future] tagged implementation, capabilities in mixed-use pages might be mapped at user mode addresses. I haven't reviewed the details, but repeated capability writes to such addresses might be enough to implement RowHammer. But aside from these mixed-use pages, the other objects that hold capabilities are still guarded as described in [2]. Tags are only needed for mixed-use pages.

So aside from the mixed-use page scenario, which requires non-commodity hardware, I think the KeyKOS approach is fairly safe from RowHammer.

The mixed-use scenario is rare. Adding capability-grain ECC for the mixed pages takes two bytes per capability, so we may not have the DRAM resources on the FPGA/SoC for that. But if I remember my back of the envelope calculations, we might have enough resources for a parity bit next to the tag bit. That wouldn't detect the corruption in DRAM at the moment of occurrence, but it would detect most of them on read (won't catch some multi-bit corrections, which are low likelihood but statistically possible).

Alan: What have I missed here?

[Jonathan S. Shapiro]

On Fri, Mar 6, 2026 at 4:20 PM Gernot Heiser <gernot...@gmail.com> wrote:

...and in any cases leads to more predictable performance in the case of a contented cache.

Contented caches are happy caches, so they put in that extra bit of effort!  :-)

Sorry, Gernot. Couldn't resist.

Jonathan

[Jonathan S. Shapiro]

On Fri, Mar 6, 2026 at 4:20 PM Gernot Heiser <gernot...@gmail.com> wrote:

Cache channels are the easiest to exploit as covert and side channels. L1 caches are virtually indexed and cannot be spatially partitioned, they *must* be invalidated, like it or not.

The cost of this is dominated by the D-cache writeback, but that’s unavoidable. Everything else happens in parallel and doesn’t add to the cost.

For larger applications there doesn't tend to be much useful retained L1 I-cache or D-cache from one process to the next on the same CPU. The notable exception is the microkernel itself. If IPC is synchronous, it seems as if you can sometimes skip the D-cache flush if a long enough string has been transferred, because it has effectively been flushed by the copy operation and the state now in the D-cache is receiver state. I'm not clear how helpful that is in practical terms.

Northup says that most of the hardware people are throwing up their hands at the cost of cache flush and declaring that dedicated secret stores are the answer and us punk-ass software pukes will just have to do more work to protect our secrets. Unfortunately, there are enough applications where that works to make it seem like a viable approach, and it becomes a big game of marketing "chicken" for competitive performance benchmarks. At least for now, the incentives do not favor the more secure approach.

Could a modified cache help guard against this? It seems to me that a cache set is a partition, and maybe a per-set "must be flushed" marker bit would allow the flush to proceed more incrementally? No idea if that actually helps; it would need to be measured, and I wonder if knowing (from the timing) which sets were aliased across the process switch boundary is exploitable.

If it hasn't been done already, I think it would be good for somebody to try hard to do an exploit based on timing observability of which sets held dirty lines. Would be a shame to do cache flush support in hardware that exposed differential timing only to discover a week after tape-out that we needed the flush timing for clean lines to match the timing for dirty lines.

Jonathan

[Gernot Heiser]

On 7 Mar 2026, at 16:27, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

On Fri, Mar 6, 2026 at 4:20 PM Gernot Heiser <gernot...@gmail.com> wrote:

Cache channels are the easiest to exploit as covert and side channels. L1 caches are virtually indexed and cannot be spatially partitioned, they *must* be invalidated, like it or not.

The cost of this is dominated by the D-cache writeback, but that’s unavoidable. Everything else happens in parallel and doesn’t add to the cost.

For larger applications there doesn't tend to be much useful retained L1 I-cache or D-cache from one process to the next on the same CPU. The notable exception is the microkernel itself. If IPC is synchronous, it seems as if you can sometimes skip the D-cache flush if a long enough string has been transferred, because it has effectively been flushed by the copy operation and the state now in the D-cache is receiver state. I'm not clear how helpful that is in practical terms.

Northup says that most of the hardware people are throwing up their hands at the cost of cache flush and declaring that dedicated secret stores are the answer and us punk-ass software pukes will just have to do more work to protect our secrets. Unfortunately, there are enough applications where that works to make it seem like a viable approach, and it becomes a big game of marketing "chicken" for competitive performance benchmarks. At least for now, the incentives do not favor the more secure approach.

A full cache flush is prohibitive. An L1 flush is of the order of a microsecond. You don’t want this on every context switch – no. But if you think in terms of switching security contexts, that tends to be a more coarse-grain operation, typically happening at the ms scale.

Not a totally satisfactory answer, but not as bad as it might look at a first glance.

Could a modified cache help guard against this? It seems to me that a cache set is a partition, and maybe a per-set "must be flushed" marker bit would allow the flush to proceed more incrementally? No idea if that actually helps; it would need to be measured, and I wonder if knowing (from the timing) which sets were aliased across the process switch boundary is exploitable.

Some caches allow you to pin individual lines in the cache.

Locking a complete set is likely to cause issues, as both processes are likely to access the same set. And CPU designs pretty much depend on reading from the L1, so having a hole in there isn’t likely to work.

If it hasn't been done already, I think it would be good for somebody to try hard to do an exploit based on timing observability of which sets held dirty lines. 

This sounds exactly like what the varioys prime&probe (P&P) cache attacks are doing (although they tend to probe for residency, not dirtyness but I can’t see what difference that would make)

Gernot

[Jonathan S. Shapiro]

On Fri, Mar 6, 2026 at 9:58 PM Gernot Heiser <gernot...@gmail.com> wrote:

Could a modified cache help guard against this? It seems to me that a cache set is a partition, and maybe a per-set "must be flushed" marker bit would allow the flush to proceed more incrementally? No idea if that actually helps; it would need to be measured, and I wonder if knowing (from the timing) which sets were aliased across the process switch boundary is exploitable.

Locking a complete set is likely to cause issues, as both processes are likely to access the same set. And CPU designs pretty much depend on reading from the L1, so having a hole in there isn’t likely to work.

I wasn't thinking about locking a set. I was thinking about marking it as needing to be flushed before the current execution context can access it. The thought being that this would allow the writebacks to be handled more incrementally.

This probably isn't helpful if flush is implemented in software.

 

If it hasn't been done already, I think it would be good for somebody to try hard to do an exploit based on timing observability of which sets held dirty lines. 

This sounds exactly like what the varioys prime&probe (P&P) cache attacks are doing (although they tend to probe for residency, not dirtyness but I can’t see what difference that would make).

You mentioned that the flush cost is mainly driven by writeback, which makes sense. It got me wondering if the higher do a write-back vs. an invalidate might be exploitable?

[Gernot Heiser]

On 7 Mar 2026, at 19:33, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

If it hasn't been done already, I think it would be good for somebody to try hard to do an exploit based on timing observability of which sets held dirty lines. 

This sounds exactly like what the varioys prime&probe (P&P) cache attacks are doing (although they tend to probe for residency, not dirtyness but I can’t see what difference that would make).

You mentioned that the flush cost is mainly driven by writeback, which makes sense. It got me wondering if the higher do a write-back vs. an invalidate might be exploitable?

you need to pad to the WCET

Gernot

[Alan Karp]

I attended a talk about Rowhammer a few years back and asked about ECC.  I didn't understand the answer and didn't want to take the audience's time to follow up, but the speaker said that ECC makes Rowhammer easier.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNrfuSc7T%3D%3D1%3DLrhZL9wQ%3DabG6WjDdGarMd1GQeOJM27w%40mail.gmail.com.