[messaging] Encrypted Group Chats

[Stephen]

So rather than have keys to the kingdom stored on every device, would it be
possible to have a group message store which required a quorum of
participants based on Shamir's secret sharing?  No individual phone/device
could access the group messages without central sign off.  Once a quorum
has been established, any participant in the central server's list could
access the communications.  This could be relatively simple.  A server
could generate a keypair and publish the public portion to each
participant.  The private key could then be locked down with SSS.  The
constituent keys are distributed to the endpoints.  They send the server
only ciphertext, and the server signs the messages with the group keypair.
Without a quorum, no communications can be read.  Rather than getting
weaker with every participant, this would actually become stronger.  Would
this be a superior method?
On Nov 28, 2014 2:50 AM, "Stephen" <kbaegis at gmail.com> wrote:

> Would it be possible to require sign off from a central authority which
> contains no message data before the message store could be accessed? Could
> a group chat protocol leverage SSS to allow specific access to a message
> store?
> On Nov 27, 2014 9:01 PM, "Ximin Luo" <infinity0 at pwned.gg> wrote:
>
>> On 28/11/14 04:24, Stephen wrote:
>> > This all side steps the core contention. The more interlocutors, the
>> larger profile for endpoint based attacks, and therefore the less security.
>> If I can break one device then all communications are compromised for the
>> entire group.
>> >
>> > How is this supposed to be dealt with? Is this an intrinsic constraint?
>> If so, this needs to be communicated appropriately.
>> >
>>
>> If you break one device, then the communications are compromised for that
>> session, since the device has all the secret material needed to participate
>> in the session. As you point out this risk increases with the size of the
>> group.
>>
>> However, one can devise a key agreement where the long-term keys are
>> needed only at the start. Then, in principle, one can remove long-term keys
>> from the device *during a session*, such that if the device is compromised,
>> only the active sessions are compromised and no other existing sessions (on
>> different devices) are affected, and no new sessions can be started
>> (without compromising the long-term key).
>>
>> I can't remember if Axolotl has this property. If any future messages in
>> the ratchet need the long-term key to derive more messages/secrets, then it
>> doesn't. I remember we were playing with other ratchets and trying to add
>> this property in there, at last year's RWC though - it is definitely
>> possible in principle.
>>
>> However, this property is somewhat secondary if you have a weak endpoint
>> like the current generation of mobile phones. To solve this problem
>> effectively, we need to push for verifiably-secure software and hardware at
>> the endpoints. I don't think it's something that can be fixed on the
>> protocol layer.
>>
>> X
>>
>> --
>> GPG: 4096R/1318EFAC5FBBDBCE
>> git://github.com/infinity0/pubkeys.git
>>
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141128/63e50f55/attachment.html>