Broken encryption when direct dialing about peerbit HOT 2 OPEN

Thanks for creating this issue.

As of now, you can query nodes for unencypted version of data, which means that you necessarily does not have to be able to decrypt the payloads to receive decrypted copies of the documents.

If you include canRead fn in your open fn

 async open(): Promise<void> {
        await this.posts.open({
            type: Post,
            index: { key: "id" },
            canAppend: async (entry) => {
                await entry.verifySignatures();
                const payload = await entry.getPayloadValue();
                console.log('GOT PAYLOAD')
                if (payload instanceof PutOperation) {
                    const post: Post = payload.getValue(
                        this.posts.index.valueEncoding
                    );
                    console.log('PUT POST', post)
                    return true;
                } else if (payload instanceof DeleteOperation) {
                    return false;
                }
                return true
            },
            canRead: async (publicKey) => {
                return publicKey?.equals(client3.identity.publicKey) || false;
            }
        });
    }

you can control what publickeys can search for documents, and one who sits on the documents will decrypt them if the canRead check will pass. (canRead by default is () => true which means everyone can read, even though the payloads are encrypted). The reason for why there is a separate way for peers to retrieve documents outside the "encryption at rest" which is what you define during .put is that there are scenarios where you want to protect the data at rest, but leak things when certain conditions are met.

In your example, I also modified the print lines to this

console.log('Store1:')
await printPosts(store)
console.log('Store2:')
await printPosts(store2)
console.log('Store3:')
await printPosts(store3)

so that the prints are in order.

With the changes above the results will be:

Store1 will receive results because, it created them, which means it has an unencrypted local copy.
Store2 will receive no results
Store3 will receive results because it can decrypt the payload.

Though:

Issues/Bugs I have identified with Peerbit codebase when looking into this, which I ASAP look into.

• When using the canRead, and a node gets rejected. The node will wait until timeout for responses (that will never come). This is why the response times are so long if you make the change above. #128
• The documentation is lacking regarding canRead and that documents can leak by default if you are not modifying the canRead function. #129
  * canRead, should perhaps be mandatory to define.
• canRead should also be a callback that not only takes the publicKey of the query, but also the query itself, or some other information, so that more advanced behaviour could be created. Perhaps there should be to be a filter of what queries are performed, but then also a filter for controller what documents are returned. Perhaps there should be a canSearch (before querying) and canRead (after results has been obtained, but before returning them) #130
• By default, you open stores are as a replicator, but if peers put documents in them that you can not decrypt, should you reject in the canAppend (?). The search index duties are not conditioned on what documents you can encrypt/decrypt but the hash of the commit. #131

from peerbit.

All problems have now more or less been solved with the latest release

https://peerbit.org/#/modules/encryption/?id=encrypted-document-store

Only one issue left that I have not fully settled on:

• What should the default behaviour of canRead and canSearch be? False? Throw a Type error if not provided?

Sorry for the long delay of fixing these issues.

from peerbit.