encryption of "metadata->metadataKeys" in case of multiple users

[kud202]

Ref: https://github.com/nextcloud/end_to_end_encryption_rfc/blob/master/RFC.md#create-metadata-file

The metadata is a JSON document with the following structure. The metadata->metadataKeys elements are encrypted to the recipients public keys and the values are used to encrypt the single file metadata elements.

If a folder is shared with multiple users, there will be multiple recipients. Encrypting metadata->metadataKeys with each recipient's public key would result in a different ciphertext for every recipient.

How are these multiple ciphertexts stored in the encrypted json structure ?

In the given example file "ia7OEEEyXMoRa1QWQk8r" is shared by 2 people "[email protected]" and "[email protected]". This file can be decrypted by using metadataKey[1].

Whose public key will be be used to encrypt metadataKey[1] ?

[rullzer]

Sharing will not be supported in the first round. But when we do we will rpobably need to us envelopes.

For sake of simplicity. It will be encrypted to all metadatakeys. So any of the private keys that have acces will be able to decrypt the metadatakey.

[purdieb]

I ran into this when I got impatient and decided to dive into the nextcloud desktop client code to implement end to end encrypted folder sharing myself. I was following the whitepaper/RFC and hoping I could write my own code to comply with it, and then realized that the RFC is really going to have to be modified in order to implement sharing.

The solution of encapsulating the metadata keys into an envelope seems like it introduces unnecessary steps. You would have an asymmetrically encrypted symmetrical key, which is used to decrypt a set of symmetrical keys, which would be used to decrypt the encrypted portion of the file metadata to retrieve the file key.

It feels like the encrypted file metadata might as well also be encapsulated within the envelope, skipping the metadata keys entirely.