You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 22, 2021. It is now read-only.
Problem: The share URL contains the decryption key. So if you're sharing files via email, and an email server is compromised before the recipient gets around to downloading things, you essentially send your files to the bad guys.
I don't know how often this happens, but I know I've shared files with people at least a couple times and my recipients respond a few hours later saying, "Uh, that download link has expired." I'm pretty certain we didn't hit the time limit, so the files must have been downloaded by someone somehow.
Solution: Rather than sending a download URL to the recipient, instead allow the recipient to generate an upload URL where people can then go to upload files. All uploaded files would be encrypted with a public key, and only the recipient could decrypt them with their private key. The private key never gets transmitted, so the only way for a bad guy to win is if they compromise the recipient's computer.
Here's how I'd imagine the workflow would look like:
Recipient goes to website to create an upload URL.
JavaScript is used to generate a random public / private key pair in the recipient's browser.
The private key gets saved somewhere:
Perhaps in browser local storage?
Perhaps the key is encrypted in-browser via a password and then the encrypted private key is sent to the server?
Perhaps the user is told to save the URL where they will need to go to download files later, i.e. https://example.com/download/#PRIVATEKEY
The recipient sends an email to the sender, "Upload files to me here! https://example.com/upload/PUBKEY"
The sender visits the URL, JavaScript encrypts files using the public key, then encrypted data is sent to the server.
The server sends an email to the recipient, "You've got new files! Go download them!"
When recipient goes to the download link, the private key is retrieved, files are downloaded and decrypted in browser.
Side note: Thanks for running this service. I look forward to the day when it comes back!
The text was updated successfully, but these errors were encountered:
pcrockett
changed the title
Create upload URLs instead of download URLs
Upload URLs using async crypto
Jul 8, 2020
pcrockett
changed the title
Upload URLs using async crypto
Create upload URLs using async crypto
Jul 8, 2020
Nothing against your idea, but FWIW there can very well be more likely explanations than an evil Mr. X why your recipients got the "Download expired" message. For example, I've experienced some mail systems or even virus scanners actually accessing the website and downloading the file. And I've also experienced some crazy bugs in the past where Send insisted that the link has expired and it turned out to be a port/websocket issue.
Sure, I suspect it's most likely antivirus as well. The point is, though, my files are going through some unknown system somewhere that I don't trust, and the only way for me to get my files into the recipient's hands reliably is to allow multiple downloads. I would like an ephemeral end-to-end encrypted service regardless if the eavesdroppers are good guys or bad guys.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Problem: The share URL contains the decryption key. So if you're sharing files via email, and an email server is compromised before the recipient gets around to downloading things, you essentially send your files to the bad guys.
I don't know how often this happens, but I know I've shared files with people at least a couple times and my recipients respond a few hours later saying, "Uh, that download link has expired." I'm pretty certain we didn't hit the time limit, so the files must have been downloaded by someone somehow.
Solution: Rather than sending a download URL to the recipient, instead allow the recipient to generate an upload URL where people can then go to upload files. All uploaded files would be encrypted with a public key, and only the recipient could decrypt them with their private key. The private key never gets transmitted, so the only way for a bad guy to win is if they compromise the recipient's computer.
Here's how I'd imagine the workflow would look like:
https://example.com/download/#PRIVATEKEY
https://example.com/upload/PUBKEY
"Side note: Thanks for running this service. I look forward to the day when it comes back!
The text was updated successfully, but these errors were encountered: