E2EE - End-to-end encryption

[elf-pavlik]

From: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$BzKdYmTul7y0FgOCDr44DO5dfx221i6wZ-20Xqnte7I?via=gitter.im&via=matrix.org&via=naamio.chat

More details in https://docs.nextgraph.org/en/encryption/

niko at NextGraph.org
Dear
elf-pavlik (elf Pavlik) your questions are very much to the point.
I could answer for well known encryption systems, and will answer for NextGraph. Each E2EE system is different.
In NextGraph, data is never re-encrypted.
As you rightly say: in a good E2EE system, encryption and authorization are intertwined, and this is what I call "cryptographic capabilities". I can go more in details about how we do that during the call. Basically, the permission system is not based on ACL, and is neither based on classical object-capabilities. Instead, because each bit of data is encrypted (with convergent encryption), we say that a "read capability" is the encryption key itself, plus some additional metadata that details how to fetch the encrypted data.
For write capabilities, it is a bit more complex, as it involves possession of a shared signing key, that all editors have.
When an editor is revoked, we need to generate a new signing key and distribue it to all the other editors, except the one that was revoked. as i said during my last presentation, there is also an individual signature, that lets us know exactly who created the commit/update.
for read access, revocation also involves rotation of some keys that are part of the metadata on how to obtain the ciphertext. This prevents the revoked reader from reading new updates on the document. but it cannot prevent access to older data that the reader has already fetched and for which it used to have read access. This is for 2 reasons: as i said, the symmetric encryption key of each block of data is immutable, so if the reader already got the ciphertext and already got the key, they will be able to continue reading this data. But if they didn't fetch all the data yet, and recently lost their read access, they might have the key, but won't be able to fetch the ciphertext from the broker anymore, so this mechanism will prevent further unauthorized read of old data. even if they have the old keys. this is called "pull control". the second reason is that everything is local first, so what has been already fetched locally and kept in local storage, will also be readable by a former reader.
That's pretty much the outline of NextGraph capability/permission mechanism. Each capability is expressed in the form of a URI, and can be included into another document as RDF, so that permissions become transitive. If i have access to doc A, and doc A includes some permissions for doc B, then I have access to doc B as well.
Permissions are granular at the Resource/Document level (like Solid mandates).
And are assigned to users or agents (bots) and not to devices. Each user has access to all its permissions on all their devices. they can later decide which document should reside on which device, but that's not handled with permissions, but just with a pinning mechanism.
we will now work with ActivityPods on mapping this cryptographic capabilities to WAC and/or ACP. I already studied this task and it is easy for me to do it, by leveraging the SPARQL API that NextGraph offers, and that encodes the capabilities into the named graphs of the request. If the named graph of the doc, including its valid capability, is present in the SPARQL request, then read access will be granted. This will be transparent to the Solid endpoints, that will only deal with WAC or ACP and will not know a SPARQl request is used in the background, with some NextGraph capability URIs included.
SemApps (used by ActivityPods) is already working in a similar way since 4 years (with a simpler permission system), thanks to the plugin for Fuseki I had developed back then. And now we will move forward with NextGraph quadstore replacing Fuseki in SemApps, and WAC being implemented with the help of the capabilities of NG.