[Cryptography] A simpler group communication scheme...

[Phillip Hallam-Baker]

Alice, Bob and Carol want to hold a group chat, Doug through Zeake might
join in at some point. How do we establish and manage keys for the channel?

The reason for bringing this up is that I am trying to work out if the
ratcheting tree proposed in MLS actually delivers any value.

https://tools.ietf.org/html/draft-ietf-mls-protocol-11

The two types of security we are concerned about are:

1) Forward Secrecy, The conversation remains confidential even if the keys
of Alice, Bob Carol etc. are all compromised after the channel is
established.

2) Post Compromise Security. Alice should be able to have a secure
conversation with Bob even if Bob's key is known to Mallet.

The security issue we are not at all concerned about is what happens if
Mallet is allowed to join the channel. Clearly the channel is
compromised if Mallet learns the channel secret.

MLS describes a complex protocol in which a tree is constructed and the
participants engage in a series of pairwise key exchanges that ultimately
result in a consensus key agreement being reached. This tree interested me
greatly because I could map it onto threshold techniques. But the more I
looked, the more it seems that a much simpler protocol is actually better.

And my experience of using some of the products based on the technique is
that they simply aren't reliable. Whether that is because the peer to peer
crypto isn't really working or the peer to peer comms...


The first issue is that confidentiality is break once run everywhere. A
guarantee that everyone has participated in the generation of a shared
secret is irrelevant when every person who participated can disclose the
secret itself.

This becomes even clearer if we decide that our channel is going to be
encrypted under a randomly chosen session key which is disclosed to the
participants by means of a keywrap function.


So in my simplified protocol, we nominate a subset of the group members to
act as administrators. In the simplest case we have just one admin, Alice.

To join the group, Bob sends his public key plus a newly created ephemeral
to Alice. Alice performs a key exchange on her private key and sends her
public key plus an ephemeral of her own back to Bob.

The Alice/Bob key exchange is KDF ( a.EB || ea.B ) for Alice,  KDF ( eb.A
|| b.EA ) for Bob. Alice uses the result of the KDF to wrap the channel
secret and pass it to Bob.

This key exchange achieves forward secrecy with respect to Alice's private
key and to Bob's private key. Further it has post compromise security
against a passive attack if Alice's private key is compromised OR is Bob's
private key is compromised. It will be breached if both are compromised .

Carol joins the group in the exact same way, by performing a key exchange
against Alice.

Seems to me that the security guarantee here is only slightly less than
that provided in MLS. But why would we expect a communication between Alice
and Bob and Carol to be more secure than just Alice and Bob?


Am I missing something here?

Of course, having established the initial keys, we can rotate the channel
secret at regular intervals so as to support an OTR like limit on the
decryption. And instead of simply rekeying from scratch we will ratchet.
But that is a detail.

I see no reason why Alice can't support a channel of up to a hundred users
by simply staggering the key update process so it is not overly burdensome.
She can also deputize the key agreement to other admins.

In practice, there are no peer to peer communications of more than a few
dozen people simply because you can't have a hundred people yacking at
once. The social constraints on communication scale far less than the
ability to support the necessary crypto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210224/66ccd248/attachment.htm>