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:

  1. User1 encrypts a file with an AES-256 key and uploads the encrypted file somewhere.
  2. Anyone who wants access to the file can ask User1, and hand them their public key.
  3. 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?

  1. Step 1 the same as above
  2. Step 2 the same as above
  3. 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.
  4. 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....

  • 1
    Alternative step 4: The user shares the k̶e̶y̶ actual file. What exactly are you trying to achieve? Aug 16 '18 at 13:54
  • Right, well using that method both users would need to be online to do the transfer. The idea here is that you have a central (public) server that stores the files until the recipient is ready to go and get them. Or - the user's dont know each other in person... So assuming that use case, how can someone create a user sepcific decrytion key?
    – amlwwalker
    Aug 21 '18 at 12:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.