4 ms·
One option is an envelope keys. Content is encrypted and published by the owner, but the owner uses a new random key to do the encryption. This new random key
by sounds 7y ago
One option is an envelope keys.
Content is encrypted and published by the owner, but the owner uses a new random key to do the encryption. This new random key is the "envelope key."
The owner then takes the envelope key, encrypts it with the public key of recipient A, and publishes the encrypted message containing the envelope key. (This message with the envelope key should also be signed by the owner using the owner's private key.)
Anyone who obtains the envelope key effectively has read-only access to the content. The owner can publish a separate message with the envelope key, all these messages have recipient B, C, and D's different public keys, so if you are a recipient you will want to know which message is likely to be encrypted by your public key, after which you can decrypt it to get the envelope key.
The owner also needs to sign the content. Signing the content and later verifying the content is done with the owner's public/private keypair, not the envelope key.
A glaring weakness of envelope keys is that the recipient can share the content freely once they have it. There's no content protection after the content and the envelope key are published.
The recipient can easily just share the envelope key if they want to. But they can also just copy the content (once they have decrypted it).
- Spearchucker 7y agoThis gets complex fast. The access control list needs to travel with the data. Revocation can theoretically take forever (until all offline clients get back online). Onwer signing content is great but breaks rule 4 (It should support collaboration). I've been working on my own personal-use app for my twin and I to collaborate on documents from different continents so pretty close to the problem.