<p dir="ltr">Den 20 jul 2014 22:59 skrev "John Kelsey" <<a href="mailto:crypto.jmk@gmail.com">crypto.jmk@gmail.com</a>>:<br>
><br>
> Imagine a completely trusted mail server used by everyone.  If you had such a thing, you could get what you want by having a protocol wherein each user connected once every day to the mail server over an encrypted channel (TLS), sent up a fixed amount of information, and pulled down a fixed amount of information.  No outsider would be able to determine whether you were sending/receiving any email--all they'd know would be that you *could* have sent/received email.<br>

><br>
> The two ways I can imagine making that work without a trusted mail server are either:<br>
><br>
> a.  Come up with a protocol so that the mail server doesn't know who got what.  (This looks hard to me--it's related to searching on encrypted data, but looks harder than that to me.)<br>
><br>
> b.  Replace the single mail server with some kind of network of nodes controlled by different entities.  What we know how to do right now is build a remailer network with some kind of longish delay, along with some kind of service that lets users drop information and chaff into/out of the system.</p>

<p dir="ltr">Bote mail in I2P uses method B already. Emails are encrypted using your public key, delivered inside I2P (a traffic anonymization network similar to Tor) using your public key as address and DHT as delivery and searching method, it allows for using relay with time delays within chosen ranges, and you can easily switch addresses often, and your van always use several addresses at once. </p>

<p dir="ltr">It like to see the Bitcoin stealth address proposal adapted for it so that you can keep a single address, yet have incoming mail tagged with public keys derived from yours which nobody but you and the sender can know is for you. </p>

<p dir="ltr">It works like this: The sender performs an ECDH key exchange with his keypair and that of the recipient. The resulting number is used to do EC multiply on the public key of the recipient. To make sure it isn't the same every time, you can XOR in the hash of a counter. You use that new derived public key as the receiving addresses (and encrypts the message to it) and tag it with the sending public key (if you also want to keep yourself anonymous, use different tagging keypairs each time).<br>

Now to the really clever part, the receiver can perform the same ECDH key exchange to generate that same number, use it with the sending keypair and his own to perform EC multiply on his PRIVATE key, and thus generate a valid new keypair matching what the sender generated which can decrypt the incoming message. </p>

<p dir="ltr">The main problem is performance, you have to test ECDH let exchange on all messages you see. </p>
<p dir="ltr">Does anybody know of a more efficient method of tagging messages meant for the owner of some secret value / private key, that don't reveal who it is for or where it is from, but lets the recipient see it is for him? My idea is that headers would be propagated first to everybody so that you can determine which messages to fetch (anonymously within I2P). </p>

<p dir="ltr">Other than Bote, I do like the idea of pond, but they seem to be too fixated at needing servers. I like for servers to be optional. In my method above, you could let servers gather your messages for you, but they couldn't decrypt them, just see the ciphertext blobs with their anonymous headers. So you reveal some Metadata to them such as approximately when and how much mail you get of what size, but not more than that. </p>