[messaging] pond alike group messaging
burdges at gnunet.org
Wed Jun 17 03:08:00 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.
> 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
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 :
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 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 :
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
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
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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging