[messaging] Encrypted Group Chats

Stephen kbaegis at gmail.com
Fri Nov 28 02:50:26 PST 2014


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/7b732539/attachment.html>


More information about the Messaging mailing list