Currently knowing a share's address grants read/write access. The consequences:
Accidental leaking of the share address ends the useful life of a share.
It is impossible to let someone read the contents of a share without also granting them access to modify it.
Hosting of a share's data replication can only be done by people trusted enough to have write access.
Interfaces must be carefully written so that share addresses are partially obscured to prevent accidental disclosure.
What solution are you recommending?
This PR makes it so that share addresses become public keys with an associated secret. Read access is granted by knowledge of the public key (+gardening.bxxxxxxxxxxx), and write access granted by the private key.
When new documents are written, they use the share keypair to create a shareSignature property on a document, which is verified by other peers upon ingestion.
Generation of a new share can be done using Crypto.generateShareKeypair.
There's one drawback to this: an extra signature on documents means signing and verifying each document takes twice as long. I feel like this is an acceptable trade-off.
What's the problem you solved?
Currently knowing a share's address grants read/write access. The consequences:
What solution are you recommending?
This PR makes it so that share addresses become public keys with an associated secret. Read access is granted by knowledge of the public key (
+gardening.bxxxxxxxxxxx), and write access granted by the private key.When new documents are written, they use the share keypair to create a
shareSignatureproperty on a document, which is verified by other peers upon ingestion.Generation of a new share can be done using
Crypto.generateShareKeypair.There's one drawback to this: an extra signature on documents means signing and verifying each document takes twice as long. I feel like this is an acceptable trade-off.