I may be falling into a classic encryption-problem trap here... I've been developing applications using AES and public/private key encryption for some time so I have a good understanding of straight forward usage, however I wouldn't claim to be a cryptographer.
Situation I understand:
- User1 encrypts a file with an AES-256 key and uploads the encrypted file somewhere.
- Anyone who wants access to the file can ask User1, and hand them their public key.
- User1 encrypts the AES-256 key with their public key and uploads that. All auth'd users, can then decrypt the key, and in turn decrypt the file.
What if User1 wants to have some control over who can access the file after the event?
- Step 1 the same as above
- Step 2 the same as above
- When someone requests access to a file User1 generates a new AES-256 key, encrypts the file again with that, uploads it. Then encrypts the new, user specific key with their public key. Now only that user has that key. When the file is requested, the requester can sign the request with their private key, and the user knows who requested it.
- If the user ever shares the key, then the signature of the request would come from somewhere else, and User1 could delete the version of the file that can be accessed with that key, in effect blocking that user (and anyone they shared the key with)
This would work, however a) requires interaction from User1 for each new user, and b) is inefficient as there are multiple copies of the same file.
Goal: End to end encrypted file sharing with a per user access key.
Is there such thing as retroactive encryption? Or what if there was something else (such as an asset on the blockchain) that could be proven to be owned by the requester and therefore give them access?
I was thinking about when something is encryted with multiple people's public keys, it requires all of them to decrypt it to view the file, that doesn't help, but was a train of thought
I was also thinking that if the user held an asset on the blockchain (ERC721) the file owner could require that the request for file access came from there, or atleast verified by that asset. Similar to signing the request I suppose, but would be tied to a specific user's wallet and sharing that wallet could mean the initial user loses access to the file (someone they share it with moves owner ship of the asset).
In other words, I don't necessarily need the solution to be "lots of AES keys", but some way to control decryption access on a per user basis, even if they have the key.
P.S I would like to do this with as little server side logic as possible. Smart contracts work, if they can be used, or client side apps....