[cryptography] Keyspace: client-side encryption for key/value stores

ianG iang at iang.org
Thu Mar 21 03:59:38 EDT 2013

On 21/03/13 09:52 AM, Tony Arcieri wrote:
> https://github.com/livingsocial/keyspace
> tl;dr: Keyspace provides "least authority" client-side encryption for
> key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and
> Ed25519 as part of a capability-based security model.
> A question about crypto-capabilities is: how do you share them securely?

Using a crypto-capability for secure sharing.  Which leads to a 
boot-strapping problem, of course, but that's part of the fun.

A partial answer from capabilities is found in YURLs which are URLs that 
can't be futzed with by an attacker.  But this still doesn't solve the 
issue of who you send them too...

The high-level helicopter answer is that you bootstrap relationships 
into key exchanges [0], and the hidden assumption here is that you have 
relationships of some form, which means you are now in application space 
-- the market area -- not in systems space.

> Fortunately I think a system like Keyspace can bootstrap itself,
> providing a "vault" per user which stores the capabilities they have
> access to. NaCl's Crypto::Box can be used to allow users to publish
> public keys they can give to a system administrator who can then give
> them an encrypted capability to their user-specific capability vault.

In terms of server -> user path, the authentication & finding mechanism 
is generally interrelated.  You typically need to start from some well 
known and self-authenticating mechanism which is sometimes called a 
root.  Some examples:  websites are found by the DNS system which root 
is built into the net stack, secure websites are authenticated by a root 
inside the browser that overlays the DNS system.  In my Ricardo system, 
the root is a financial instrument that you've found from some trading 
partner which points to the managing server.  For S/MIME it is necessary 
to use a corporate server of some form to keep keys fresh.

What is happening here is that you are leaving the strong crypto area 
and entering into the weak/vague/untethered world of user marketing.  In 
this area you have to look at your chosen market space and leverage the 
relationships that already exist.  For this reason, in order to do this 
successfully, you must already have chosen a market space.

Systems like PGP try to do it without choosing their market space (and 
going user -> user with no servers).  Hence, to use PGP, they have a 
particular thing called a PGP key signing party which is a generic 
one-size-suits-all way to create those paths.  It works, but it is not 
patterned after any particular trading patterns, so it doesn't work well 

Reflections of this are found in Zooko's Triangle:  There is no way to 
create a cryptographically secure, global and human-memorable 
identifier.  To square the triangle, you need to be in application 
space, so that you can bootstrap relationships into key exchanges.


[0] http://iang.org/ssl/h2_divide_and_conquer.html#h2.5

More information about the cryptography mailing list