Protocol to facilitate content encryption and sharing

Ecosystem
1

It’s very frequent that some content must be private. This spans from instant messengers to sharing a document with collaborators.

In the case of 1:1 content sharing, normally sender would encrypt with receivers public key and only receiver would be able to decrypt.

In NEAR, each account can have many keys. Also if keys are stored on hardware device or in some other form of custody - it would be extremely hard for receiver to actually decrypt.

There has been a proposal described in Stackoverlow answer: https://stackoverflow.com/a/62291714

There are few more advanced tools like proxy re-encryption that exist as well, which may allow to simplify the interaction flow in expense for more cryptography and computation off chain.

Curious to discuss the proposal and if there are alternatives here. Ideally we should formalize something to the form of implementable milestones.

7 Likes
2

It’s great to see a proposal relating to data encryption / sharing, however I don’t feel it’s the right approach to build this into the blockchain layer.

I’m the founder of Verida that provides an open source library for off-chain data storage and real time messaging.

There is an existing body of work around identity and storage standards:

I recommend the implementation of a NEAR DID method allowing decentralized identities to be native to NEAR.

This is roughly how it would work:

  • User generates a keypair (K1) within their NEAR account (or new user creates implicit account)
  • The private key is used to deterministically generate an additional keypair (K2) and a signing key (K3)
  • A new DID document is created (using the DID-core standard) that publishes the public keys for K2 and K3, signed by K1 to prove the DID document is owned by “did:near:”. (This DID document could be stored on chain, or could be stored off-chain with a URI stored on chain)

Users can then authorize party applications to add new “serviceEndpoint” entries to their DID document effectively publishing what third party / off-chain services are available.

These external services could be Encrypted Data Vaults or Identity Hubs as being developed in the confidential storage spec, it could be DIDComm communication channels, Verida encrypted Vaults etc.

Interestingly, due to NEAR’s unique account system, it could be possible to rotate the on-chain keys then update the DID document which still references the same DID (did:near:) providing a robust key rotation system.

1 Like
3

As a new user I could only put two links in my post, so here’s some more references:

4

Warming up some stale coffee here, please excuse me. Thanks for your suggestions, I have two questions here:

  1. Why do you suggest to deterministically derive K2 and K3? I do not see an advantage compared to just generating two random key pairs.

  2. Why is key rotation only possible with the NEAR account system? I can just replace K2 and K3 with different key pairs and still sign with K1, right?

Thanks!

5

Wow, this is going back a while :slight_smile:

  1. Why do you suggest to deterministically derive K2 and K3? I do not see an advantage compared to just generating two random key pairs.

If you derive a key pair, you need to store both private keys somewhere. This way you only need a single private key and you can unlock any of your apps.

  1. Why is key rotation only possible with the NEAR account system? I can just replace K2 and K3 with different key pairs and still sign with K1, right?

Key rotation of the master key (K1), not the subkeys (K2,K3)

6

What about https://ceramic.network ?

1 Like