Email is limited to attachments of a few megabytes, so file drop services are commonly used to send large files. The sender uploads a file and gets a URL. The URL, and sometimes a password, are emailed to the recipient. Unless the file is manually encrypted, this is completely insecure, and is one of many cases of a website being used where a protocol should exist. Here is a protocol I am trying out to solve this problem. It allows sending large files securely to any email address. The sender and recipient don't have to be online at the same time. Servers are required, and the servers can be run by users or by outside service providers. Servers do not contain any secrets. The servers form a distributed hash table using Kademlia, and each server also has its own local storage. Both Kademlia and local storage are hash tables using 20-byte SHA1 hashes. Clients do not participate in the DHT, so the clients only make outbound TCP connections to the servers. Sender wants to send a file to recipient. Sender's client converts recipient's email address to lower case and hashes it with SHA1. Sender's client asks sender's server to look up that hash in the DHT. Sender's server replies with an address-claim record, which contains the fingerprint of a GPG public key. Sender's client asks sender's server to look up that fingerprint in the DHT. Sender's server responds with a key-announcement record (posted to DHT by recipient's client earlier) containing the GPG public key and the address and port number of recipient's server. This additional information is self-signed. If there are multiple keys for a given email address, the fingerprints are displayed and the sender must choose one. Sender's client puts the files into a ZIP archive, signs with sender's public key, encrypts with recipient's public key, and cuts the ciphertext into blocks of some fixed size. Each ciphertext block is hashed with SHA1. Sender connects to recipient's server, as indicated in the key-announcement block, and uploads each data block to recipient server's local storage using each data block hash as its hash key. Sender also generates a message-announcement block containing the list of data blocks and the overall hash of the ciphertext. That block is posted to recipient's server with a hash key generated by prefixing a single digit ("0","1","2" or "3" by default) to recipient's key fingerprint and hashing. When servers receive mutliple message-announcements on the same key value, the announcements are concatenated. Recipient therefore has a small number of hash keys to check for new incoming deliveries. Recipient's client queries recipient's server for its announcement keys as described above. Recipient's client downloads all data blocks addressed to it. When it has all the data blocks for a particular file delivery, recipient's client concatenates the blocks in order and decrypts with its private key. If it does not have sender's public key, recipient's client asks recipient's server to look it up in the DHT. Recipient's client checks the signature on the delivery, and then displays it to recipient. It is also possible to deliver to several recipients on the same server with one set of data blocks and multiple message-announcements. Spamming can be reduced by requiring a proof-of-work from unknown senders. Key-announcements are periodically re-posted by the key owner, so a recipient can move servers without missing any deliveries. What do you think of this protocol as an alternative to using file drop websites? The obvious risk is delivery to the wrong key. Do you see any other vulnerabilities? Mike
