# What schemes support atomic decryption+reencryption

What encryption schemes support this workflow?

Vendor encrypts and publishes information for the client

1. Client generates public and private key
2. Vendor encrypts private information
3. Vendor publishes that
ENCRYPT(PRIVATE_INFORMATION, CLIENT_PUBLIC_KEY) --> Publish


Client re-encrypts for benefit of a third party

1. Client generates re-encryptor using its own private key and third party's public key
2. Client publishes that
CREATE_REENCRYPTOR(CLIENT_PRIVATE_KEY, THIRD_PARTY_PUBLIC_KEY) --> Publish


Third-party decrypts data

1. The third-party decrypts the data

Other people

1. Nobody can decrypt PRIVATE_INFORMATION unless they have the THIRD_PARTY_PRIVATE_KEY or CLIENT_PUBLIC_KEY.

I know that the asymmetric scheme supports most of this workflow. However, it violates requirement 7. Is there another scheme that fully supports this workflow?

• can the client change the published data or it is trustful? If trustful the answer is easy. The client decrypts the Key Encryption Key and encrypts it for third parties using their public keys. This assumes the Vendor used a KEK to encrypt the message. Oct 15 '20 at 18:54
• I think this is a form of proxy encryption. Why is step 7 a problem? How would somebody without the THIRD_PARTY_PRIVATE_KEY be able to decrypt? Oct 15 '20 at 21:11
• I think William wants the proxy not to be able to decrypt the content. However, someone with CLIENT_PRIVATE_KEYwould be able to obtain it, and presumably the Vendor is not aware that the client is going to reencrypt it. It would be possible to have a reencryptor that is only given the encryption header and changes the encryption from CLIENT_PRIVATE_KEY into THIRD_PARTY_PUBLIC_KEY. The reencryptor would have the simmetric key, but not the contents, while the caller would have the contents but not CLIENT_PRIVATE_KEY. I don't know if this separation of tasks would be acceptable for Will though. Oct 16 '20 at 0:23
• What's the meaning of "atomic" in the title? I don't see that it commonly means 6&7. Also: must it be possible that things occur in the order 1/4/5/2/3/6, which would be harder to achieve? (the 1/2/3/4/5/6 order allows the client to embed the decrypted private information into the decryptor)
– fgrieu
Oct 16 '20 at 7:19