Encrypting the chain

[HerbCaudill]

Why?

So far we’ve been treating the chain as if anyone might see it. Any secrets on the chain are encrypted before they go on the chain: For example, any secret keys that are shared on the chain are first encrypted into lockboxes. Everything else is stored and shared in plain text.

However, the chain contains a lot of metadata — personal identifiers, device identifiers, timestamps, etc. Anyone with access to the chain would know exactly who belonged to a group at any point in time, what privileges they have, and so on.

It would be very convenient to be able to use completely untrusted infrastructure for transmitting and storing the chain. If the actual links on the chain were encrypted, we could sync up using untrusted relays, and we could back up the chain onto publicly visible key-value storage, without worrying about leaking this metadata.

How?

Here’s one possible approach:

• We asymmetrically encrypt the body of each link, using the author’s private key and the team’s public key.

  This would eliminate the need for a signature on each link, since the encryption provides authentication.

• If a link rotates the team keys (going from generation i to generation i+1), we encrypt it using the previous team keys (generation i).

  Same thing if a link rotates the author’s keys.

  (Note that this doesn’t prevent us from recovering from a key compromise. Remember, the new team keys themselves are encrypted for each member in lockboxes.)

• When a new member is admitted, in addition to receiving the (encrypted) chain, they would separately receive a lockbox containing the generation 0 all generations of the team keys, as well as the founder's public keys.

[ept]

Another reason for wanting to encrypt the chain: if an attacker can get hold of the public key that is part of a Seitan invitation, and if the space of possible invitation tokens is sufficiently small, the attacker could run an offline attack to brute-force all the possible invitation tokens to find the one that corresponds to the public key on the chain, and hence gain access to the team. Encrypting the public key on the chain prevents this attack without having to resort to excessively long invitation tokens. (An existing member of the team could still try this attack, but that seems like a lower risk than an attacker who is not a team member.)

encryption provides authentication

I'm not sure what you mean with this exactly, but it sets off alarm bells. In the past, encryption and authentication sometimes got conflated, but in modern cryptography they are considered two very different things.

[HerbCaudill]

encryption provides authentication

If I understand correctly, the asymmetric encryption algorithm included in NaCl (Salsa20-Poly1305) guarantees the provenance and integrity of the payload:

https://en.m.wikipedia.org/wiki/ChaCha20-Poly1305#Salsa20-Poly1305_and_XSalsa20-Poly1305

https://en.m.wikipedia.org/wiki/Authenticated_encryption

My intuition, which may be naive, is that if I decrypt a message using Alice's public key and my private key, it can only have been encrypted using Alice's private key, and that it would be infeasible for a third party to have modified the message in transit.

[ept]

Salsa20-Poly1305 is a symmetric cipher, so it has no public keys. If you're using NaCl, the crypto_box API provides asymmetric encryption, but it authenticates only the integrity of the ciphertext; it does not include any signature that tells you who encrypted the message.

if I decrypt a message using Alice's public key and my private key, it can only have been encrypted using Alice's private key

Most asymmetric encryption primitives only allow you to encrypt with a public key and decrypt with a private key; they do not offer encrypting with a private key, nor decrypting with a public key, so I don't understand what you mean here. Authenticating a message with a private key is called a signature, not encryption. (An exception is RSA, where a signature looks a bit like encrypting with a private key, but even here there are subtle differences between encryption and signatures.)

Also, when you say you encrypt "using the author’s private key and the team’s public key", do you mean the same message is encrypted twice, independently, under two different keys? Or first with one key and then with the other? Or encrypted once using a key that is derived from the two keys?

[HerbCaudill]

Using libsodium, the crypto_box_easy function uses the sender's secret key and the recipient's public key to encrypt; then the crypto_box_open_easy function uses sender's public key and the recipient's secret key to decrypt. https://libsodium.gitbook.io/doc/public-key_cryptography/authenticated_encryption

const encrypted = sodium.crypto_box_easy(
  message,
  nonce,
  recipientPublicKey,
  senderSecretKey
)

const decrypted = sodium.crypto_box_open_easy(
  message,
  nonce,
  senderPublicKey,
  recipientSecretKey
)

[ept]

Ah, got it, thanks. So this is plain Diffie-Hellman with static keys on both sides. I think this will work and I agree it should have the authentication property that you want without requiring an additional signature. I will just point out that if a secret key is ever compromised, any message that was encrypted using the corresponding public key will be compromised too, but that's probably an acceptable choice in this context.

[HerbCaudill]

Most of the work to encrypt the chain will take place in the CRDX repo. I've stubbed out a PR there as a container for this work, and I've added some notes on implementation. http://github.com/HerbCaudill/crdx/pull/6