Design for file transfers to a new party

Question

I'm pondering a problem of how to enable transfers of files from clients to people that does not yet have an application/account/keys yet.

Here's my current thought for Alice wanting to send Bob FancyPants.png through my tool:

1. Generate random UUID
2. Generate encryption keys from that UUID
3. Encrypt FancyPants with the key
4. Upload to server
5. Ask Alice for Bobs e-mail and send "You have a file waiting, click here to download client and retrieve file securely"
6. Alice sends Bob the UUID out-of-band, somehow.
7. Bob clicks the link, enters the UUID on a page and receives a client prepared to start downloading FancyPants.png from the server.

However this method has a couple of problems, step 1, 6 and step 7.

Point 1 since I figure some form of user input would be good, otherwise it's basically just a random key and doesn't require any previous knowledge so anyone can generate it.

Point 6 since it's an out-of-bounds method which likely means they'll likely e-mail or sms in cleartext potentially defeating the whole encryption.

Point 7 since at that point my server will know the unencrypted file, which I'd like to avoid.

Are there any ways around these? I'm looking into if something might be usable like private set intersection or oblivious transfer but people here seem really knowledgeable and might know a better way.

This might be too vague but let me know and I'll edit it. I also don't know how this should be tagged, suggestions highly welcome.

Answer 1

Point 1 since I figure some form of user input would be good, otherwise it's basically just a random key and doesn't require any previous knowledge so anyone can generate it.

Nothing wrong with that. A long random value is the best kind of key there is, much better than anything dependent on user input.

However, as mentioned in the comments, the key material must be from a secure RNG. If you generate the UUID as e.g. a 128 or 256-bit random number using OS randomness, you should be fine.

Point 6 since it's an out-of-bounds method which likely means they'll likely e-mail or sms in cleartext potentially defeating the whole encryption.

You cannot avoid this. The recipient must know everything needed to request the file, so anyone who finds out what they know will also be able to do the same. By making download links work only once you can at least prevent silent compromise.

(Some sort of email confirmation could also require a compromise of the email specifically, rather than just any random out-of-band channel used. Coupled with warning "do not use email for sending UUID" you have a light 2FA-like system.)

Point 7 since at that point my server will know the unencrypted file, which I'd like to avoid.

The server does not necessarily need to know it, only the client program. I.e. you can make the user download a generic client that asks for the UUID and identify the file using some derived information. E.g. derive encryption key from the UUID $u$ using $H(u, \text{e})$ and file identifier using $H(u, \text{i})$, then send the latter to the server with the encrypted file. The server will be unable to find $u$ or the encryption key.

Of course, you can always offer a malicious client program anyway, so the server must be trusted.