# Design for file transfers to a new party

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
6. Alice sends Bob the UUID out-of-band, somehow.

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.

• UUIDs only aim to be unique, not secret/unpredictable. So they make lousy keys. – CodesInChaos Oct 17 '15 at 12:39
• Aha, what would you suggest to base the key on instead? – dutt Oct 17 '15 at 18:59
• The secure RNG offered by your operating system. For example /dev/urandom on Linux or CryptGenRandom on Windows. Most programming languages include wrappers of these in their standard library. – CodesInChaos Oct 17 '15 at 19:03
• Ah, thanks for the suggestion. Will do it like that instead. – dutt Oct 18 '15 at 8:36
• @CodesInChaos /dev/urandom can produce insecure randomness in an entropy-starvation situation. This is documented at least on Linux (man 4 random dated 2010-08-29). If you want to be certain that the randomness corresponds to available entropy (within system estimations) then read from /dev/random and be aware that the read may block for potentially a long time. – user Oct 19 '15 at 12:56

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.

• Good point/idea regarding P1 and P7. Could you elaborate a little on how the e-mail confirmation would work? not 100% sure I follow. Yep, I was planning on a warning like that, or "This transfer is only as secure as your transfer of the UUID". – dutt Oct 17 '15 at 7:39
• @dutt, it could just be a one-time random token generated by the server and required in the client for the server to allow the download. Alice would tell the server Bob's email address when uploading the file. – otus Oct 17 '15 at 7:44