[messaging] pond alike lists (was: Re: pond alike group messaging)
azul at riseup.net
Wed Jun 17 09:57:02 PDT 2015
> On Tue, 2015-06-16 at 16:32 +0000, azul wrote:
>> At a first glance it looks like the distribution mechanism of pond could
>> be generalized to a set of recipients.
> It depends what you mean. In Pond, messages are immediately deleted
> from the server when the user downloads them. In principle, this
> prevents the server from being able to compile statistics about past
> usage of specific mailboxes, which helps protect it from seizure.
I imagine keeping messages on the server for a reasonable time. I think
pond keeps them on the client for two weeks by default. So seizing the
server would reveal the encrypted messages for the last two weeks. I
would be okay with that - maybe there's ways to optimize so the server
knows if all messages have been fetched and can remove them more early.
>> Fetching messages from the server
>> currently requires authenticating to the server with one specific key.
>> This could be extended to multiple recipients with a group
>> authentication scheme similar to the one that pond originally used for
>> authenticating senders.
> It's doable, but it's harder than it first appears. We've discussed
> such things before, especially for multiple devices. I'm unsure if
> you'd want the BBS scheme used in Pond or a newer scheme allowing
> partial revocation.
I was thinking this is similar to multi device scenarios. I have
searched the list archives but i have not found such a discussion - but
maybe i just missed it. Is it archived somewhere?
> Adam is replacing the BBS scheme in Pond with a simpler token based
> system discussed previously on this list because doing the revocations
> has created practical problems.
Yes. So BBS might not be the best choice. I will look into what the
problems were. I'm not sure if token based scheme is applicable. I guess
every message would have to contain the token for fetching the next message.
>> The server could get some information about which connections come from
>> the same user by observing the messages requested.
> Yes, clients must request their own messages back from the server.
> Also, the server can count the number of participants, unless the
> clients rate limit themselves, which makes big lists unusable.
I'm looking at rate limits similar to those pond uses. That would still
allow for receiving a lot of messages per day.
>> There seems to be a rough consensus that pair wise encryption is the way
>> to go for group messaging. However this comes with the condition that
>> participants in a conversation know all other participants keys. In our
>> usecase this may not be easy to achieve.
> Why not? Just introduce them! I've a pull request doing this in Pond
> actually : https://github.com/agl/pond/pull/161
Thanks for the link. The discussion is really interesting. However I
think we are looking at different use cases. I'm looking in the
direction of mailing lists while your pull request sounds more like CC
and BCC mails. I tried to clearify in the subject now.
So my main worry with pair wise pond is sending the message to all the
different recipients. Say you have a list with 100 users and send a
message every 6 minutes on average. So it would take 10 hours for it to
Using pair wise crypto and a common server might be an option though.
> If otoh you're worried about participant anonymity then simply do the
> pairwise key exchange with new anonymous long term private keys.
That sounds feasible. I'm currently not planning to integrate this with
pond - so it would be a matter of not reusing keys between lists. It
would be nice to reuse parts of the crypto and have indistinguishable
messages on the wire though.
>> An interesting option to me seems to be using a proxy reencryption
>> scheme like SELS that reencrypts the messages for a given recipient
>> on the server without leaking the plaintext.
> Am I correct that SELS lacks any forward secrecy, yes? Forward secrecy
> is essential, so that rules out SELS.
I would love forward secrecy. But frankly... on a list with 100
participants message content secrecy is limited. I would like to see
what can be achieved in such a scenario especially regarding metadata.
So even if it was not forward secret it would still be an improvement
over what we currently have.
>> Are there any that also provide perfect forward secrecy?
> Afaik there is no good group ratchet scheme, like Axolotl or even OtR,
> to provide forward secrecy for a group.
Thanks for the list of approaches. I will take a look at them.
> We should imho focus on using pairwise encryption whenever remotely
I will also think about pairwise encryption with a common server used by
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Messaging