[Cryptography] multi-key encryption of "meta" data

[Natanael]

Den 20 jul 2014 22:59 skrev "John Kelsey" <crypto.jmk at gmail.com>:
>
> 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.
>
> The two ways I can imagine making that work without a trusted mail server
are either:
>
> 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.)
>
> 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.

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.

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.

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).
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.

The main problem is performance, you have to test ECDH let exchange on all
messages you see.

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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140721/c687840d/attachment.html>