Cryptographic Ocap

[Christopher Allen]

(not sure which lists to post this to, and googlegroups will not let me subscribe with my primary email ofChrist...@LifeWithAlacrity.com, so this is coming from my personal account).

When I first met Mark Miller back in the days of Xanadu, pre-internet and before E and subsequent thoughts on ocap, there existed a set of ideas called The Club System, which I felt could be accomplished using relatively pure cryptography rather than through administrative control via code. At first Mark wasn’t sure it was possible, but I think he became more confident that is was feasible over time. However, Mark became less confident in the The Club System architecture itself, feeling it was still essentially an ACL system.

Cryptography has evolved significantly since then, offering new possibilities, and there are still some properties of The Club System that I find particularly useful for distributed systems.

First, what is The Club System? I can’t seem to find much historical that has survived the days of Xanadu to be archived on the Web, but basically you have data objects that have a Read Club that can view that object and a Write Club that edit that object. So in many ways it *is* an ACL.

However, there are three key differences: The first was that both Read Clubs and Write Clubs themselves had Read & Write Clubs. The second was that you had to “knock” to read or write a club, which I always presumed was some form of script — a club might just open, or it might require more information to open. Finally, the “root” of the system was the public club — rather than root being the most private — this meant by default everyone could access, but privacy was a partition from public.

If you wanted to publicly share an object, you could set the Read Club to public, and the Write Club to yourself. If you wanted to restrict editing, you could set the Read Club to be a public, but have the Write Club be a list, with the Read Club for that list being public and the write club being you, so that they could contact you to get added to the write club. You can create fairly elaborate turtles of clubs with many different properties, all the way up and down from public.

So what would an example of a simple cryptographic-based Club System look like? Let me try to give an example.

Presume you are given a content addressable hash (say IPFS) by someone or some service that you desire to resolve (we’ll skip for what purpose for now). The address is the hash of the whole object, and the object itself consists of roughly four parts: a set of encrypted permits, an encrypted payload, a smart signature of both the permits and payload, and optionally a public key of the creator of this object. You can decrypt this object if a) you have the creator’s pubic key (which may not always be embedded in the signature) b) you have a NIKE (non-interactive key exchange, such as DH) key encrypted in one of the permits based on your private key. With these and a nonce you can decrypt a symmetric key allowing the payload to be decrypted. This is very similar to the MiniLock file format: https://45678.github.io/miniLock-file-format/2.html

Thus if you have the public key of the creator and are listed in the permits, you are in the Read Club for this object. There is also a well-known “public” public key and a published private key for that public key. 

So how does the Write Club work? Since content addressable objects can’t really be deleted, you can only update them; instead you rely on the smart signature of the object to be updated.

A smart signature is a predicate script of cryptographic operations that when completed results in either True or False. A very simple  scheme-like smart signature script could offer one example: “(sig_valid <pubkey> (cdr ‘ <msg> <sig>)) (sha256 (car ‘(<msg> <sig>))))”. (see https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/topics-and-advance-readings/DexPredicatesForSmarterSigs.md). Importantly, there can also be AND and OR statements (see https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/final-documents/smarter-signatures.pdf). 

Basically if the smart signature of the original object is valid on the object that says that it is an update to that object, then the update is considered to be valid. Thus if you are able to satisfy the requirements of the smart signature directly, or possibly through an OR script, you are are in the Write club. This update might then change the rules for future smart signatures, adding OR or AND to the smart signature scripts. This is somewhat like how we are doing DIDs (Decentralized Identifiers) in #RebootingWebOfTrust & W3C CCG.

The above could largely have been implemented back in early 90s using RSA when I proposed it to Mark, but with more modern cryptography makes things more interesting. We can use various new cryptographic schemes to add more advanced features to the above.

We can do key aggregation to support validation of a group of people from a single signature (https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html). This allows for a multi-party write club to be to be M of N and still be anonymous as to who signed M. We also can do other forms of key aggregation where were the signers ARE NOT anonymous, which can be useful for other scenarios. We can also combine these. The point is that we can choose fairly elaborate group structures.

We can use scriptless scripts and adaptor signatures, which in a sense treats Schnorr signatures as keys to allow for fairly complex “script” like operations using a single signature. (https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/). This requires you to be able to prove access to one object in order to decrypt another.

We can make it possible for secret keys to be sharded, then redistribute shards to new participants as groups change (https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f).

We  now also create secrets collaboratively, that are only homomorphically available in the fog of a group — the secret never exists on a single machine, and it require the group to cooperate to operate on those secrets, but anyone can validate them. These are available through a variety of computational circuits enabled by crypto. Z-cash uses one that only requires one honest participate to function, and there have been many improvements on this in the last few years. 

We also have available a variety of new zero-knowledge proofs: we can do now a variety of scalar proofs (range proofs), but by using an inverse curve we can also do proofs about keys and signatures. (https://github.com/BlockchainCommons/secp256k1/issues/1#issuecomment-410482607). This allow for a huge number of opportunities, such as non-membership proofs, key derivation proofs, etc. Furthermore, with some mirror curves (secp/secq in particular) you can do a number of proofs recursively, where one curve proves something on the other curve, and back, which can be done in a tree-like fashion for some fairly sophisticated possibilities.

So my call to the ocap community is to consider what it means to do ocap solely through cryptography, rather than through code. I will be hosting the next #RebootingWebOfTrust in Toronto on September 26-28th https://rwot7.eventbrite.com and I know Mark Miller plans to be there. Want to help write up a white paper on these possibilities?

— Christopher Allen

[Ben Laurie]

This all sounds like fun, but:

a) not sure this is really equivalent to capabilities,

b) since part of the point of caps is that you can express arbitrary policy, if you end up with an equivalent cryptographic system, you're still writing code, just using cryptographic stuff instead of CPU instructions (and of course the cryptographic stuff gets translated into CPU instructions anyway...)

Which is not to say this crypto stuff is not useful, just not sure why we'd want to do caps solely through cryptography?

I'd also note that some of the primitives you want to use - e.g. Dex (which looks quite useful and reminds me of objecthash) are not actually crypto, anyway, so not even sure what you mean by "solely through cryptography"/

 

— Christopher Allen

--
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 post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.

[Christopher Allen]

I was particularly hoping for thoughts from Mark Miller, Brian Warner & Chris Webber on this thread.

It is relevant to some early prototypes of Smart Signatures I’m working on in Q1.

— Christopher Allen