[messaging] Recognizing senders of metadata-hidden messages
burdges at gnunet.org
Fri Jul 24 01:09:01 PDT 2015
On Thu, 2015-07-23 at 14:28 -0700, Brian Warner wrote:
> The two agents must keep each other informed about their remaining
> and ask for a refill while they still can. Back in 2004 (in the
> Petmail) I drew up a scheme to do this with Mixminion's SURBs
> (Single-Use Reply Blocks), where the threat of giving someone too many
> was that they could send a big burst of messages to you and use the
> resulting traffic pulse to trace your location. These days, if the
> is merely being used to avoid DoSing the server, then handing out too
> many doesn't matter so much, especially since the agent can cancel
> by talking to the server, and thus limit the total outstanding.
I believe the distinction in Vuvuzela between dialing contacts you
haven't contacted recently, and conversations as bursts of messages
should be relevant to token distribution.
I think Vuvuzela used a unique mailbox for each conversation, making
trial decryption far more viable in that case. I'd imagine one could
evolve the conversation mailbox address with the ratchet state if
In any case, if the transport supports bursts separately from dialing,
like Vuvuzela, then you can be more strict with issuing tokens for your
There are still problematic cases however, like if you want to introduce
two contacts then you must burn two tokens, but you do not know if the
second ever gets used.
p.s. It's maybe worth asking : How should two devices identify when
they come into radio proximity without revealing their identity to
eavesdroppers? There is a more you can do with the proximity based
transport, but maybe something is relevant.
More information about the Messaging