Jeff Burdges: > 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 get distributed. 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[1] 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 > viable. I will also think about pairwise encryption with a common server used by all recipients. Azul
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
