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. > 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. 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. > 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. > 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 Introductions are an avenue for socially engineered MitM attacks but those exist anyways and the introduction facility can help mitigate them. See : https://moderncrypto.org/mail-archive/messaging/2015/001455.html Also, introductions create an opportunity for later using the socialist millionaire's protocol from OtR. It's far more secure than PAKE systems like PANDA because the adversary only gets one shot. If otoh you're worried about participant anonymity then simply do the pairwise key exchange with new anonymous long term private keys. If you're sending files beyond the size you like transferring pairwise, then simply encrypt them once, upload them wherever, and send the location and hash to each participant. Actually I should look into how my pull request interacts with detachments. > 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. > 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. A naive extensions of Diffie-Hellman to multiple participants require pairwise communication : https://en.wikipedia.org/wiki/Diffie%E2%80% 93Hellman_key_exchange#Operation_with_more_than_two_parties I suppose that provides a TripleDH-like group authentication system, but not sure it helps with forward secrecy. There might for example be an interesting multi-party variant of Axolotl that posses a hierarchy of root keys representing the different states of multi-party Diffie-Hellman operations. Again, it'd requires round trips with all participants though, meaning your forward secrecy degrades as you add participants, so you'd still employ the pairwise ratchets. There is an extension of Diffie-Hellman to three participants that employs a pairing function on elliptic curves. If I understand correctly the existence of that pairing function makes the curve relatively weak cryptographically. It's a "lock that keeps the honest people honest", not anything you'd depend upon for encrypting the actual messages. There are schemes for multi-party Diffie-Hellman beyond than three participants, but the one I saw a talk on two weeks ago seemed rather complex and probabilistic. http://webmath.univ-rennes1.fr/crypto/2014/Jean-SebastienCoron_en.html Now hash iteration ratchets like SCIMP do work for group chats, but they're far weaker than DH ratchets. Imagine for example that IDA-CCR (NSA) found a trick for compromising some proportion x of curve25519 keys. In that case, they could simply retrieve all past communications encrypted with SCIMP from long term storage and decrypt a proportion y of them where y=x^2 or maybe just x or something. Axolotl, and presumably long-term OtR, do not suffer from this since iterating Diffie-Hellman operation gives you the best security of all your private key choices. We should imho focus on using pairwise encryption whenever remotely viable. An Axolotl based messenger like Pond could provide the mutable file component in cloud storage systems, ala Tahoe-LAFS, IPFS, etc. Best, Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
