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
enough.
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.
iang
[0] http://iang.org/ssl/h2_divide_and_conquer.html#h2.5
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
