Designing a secure protocol to replace web-based file drop services

Discussion in 'privacy technology' started by Mike Ingle, Apr 30, 2015.

  1. Mike Ingle

    Mike Ingle Registered Member

    Mar 29, 2015
    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

    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?