[messaging] Message delivery and revocation in Pond etc

Michael Rogers michael at briarproject.org
Thu Apr 3 15:36:12 PDT 2014

Hash: SHA256

On 03/04/14 21:06, Trevor Perrin wrote:
> In Pond, at least, the mailbox/recipient bandwidth is kept to a
> low, roughly constant level over time, to resist traffic analysis.
> Thus the recipient can be temporarily DoS'd by a fairly low volume
> of messages.  I'm not sure it's feasible to keep the # of
> outstanding tokens so low as to prevent this.

If anything that makes it easier. There's already a limit on how many
messages each contact can send per day, so the mailbox can be
provisioned to accommodate that many messages.

Thus the mailbox can never be flooded. Only three things can happen:
(1) a contact can use some of her daily allowance to send junk,
without affecting communication with other senders; (2) the server can
drop some or all of the received messages and replace them with junk,
without knowing which contacts they come from; (3) the server can drop
some or all of the received messages and not replace them, without
knowing which contacts they come from.

>>> With signatures a recipient can attribute a garbage message to
>>> a particular sender, or to the server (if the message can't be 
>>> attributed to a sender, e.g. bad signature).
>> Hmm, good point. How about this: the recipient gives random
>> tokens to authorised senders, and the hashes of the tokens to the
>> server. Now the server can only send a message by dropping a
>> submitted message and stealing its token. If the recipient
>> receives a junk message with a valid token then either the sender
>> sent a junk message, or the server dropped a submitted message
>> and stole its token.
> Sure, but you can't distinguish those cases.

In the long term you can, because the server can't see which senders'
messages it's replacing (or dropping). Eventually it will become clear
that either all of your contacts are spamming you (or claiming to have
sent messages they didn't send), or the server's misbehaving.

If you didn't trust any of your contacts to be honest you could send
yourself messages anonymously to audit the server.

> My original proposal was for distributing one-time signing keys
> which would work similarly to your tokens, but with the added
> property that the signature would be bound to a particular
> message.

Yup, I don't see any problem with your original proposal - I'm just
curious about whether we can do something simpler.


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the Messaging mailing list