At some point, everyone in the group needs to be able to read the plaintext. If their device is compromised at the time of reading, nothing you do will protect the plaintext.
So, reasoning about "total compromise" is futile. But you can try to reason about less serious types of compromise. For example, what advanced ratchets like Axolotl does, and what the thing I suggested in my last email does, is try to limit the amount of plaintext that a memory compromise *at specific points in time* exposes. But some plaintext will always be exposed, there is no getting away from this. Also, if the attacker can maintain the compromise across time (e.g. getting root), anything you do with a ratchet during this time is irrelevant. Anyway, the protocol is not the right place to solve endpoint security issues. We need to push for verifiably-secure software and hardware in our devices. This might take more effort, but is the root of the problem and where efforts should be addressed. If someone has access to my brain, there's nothing my language can do to protect me. Communications applications should not be expected to cure cancer. X On 28/11/14 14:16, [email protected] wrote: > I see only one problem here: this is totally synchronous. I groups there are > always someone that doesn't use app often, so quorum will take a lot of time. > > 28.11.2014, 14:10, "Stephen" <[email protected]>: >> >> 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" <[email protected] >> <mailto:[email protected]>> 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" <[email protected] >> <mailto:[email protected]>> 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 >> <http://github.com/infinity0/pubkeys.git> >> >> >> _______________________________________________ >> Messaging mailing list >> [email protected] <mailto:[email protected]> >> https://moderncrypto.org/mailman/listinfo/messaging >> >> , >> >> _______________________________________________ >> Messaging mailing list >> [email protected] <mailto:[email protected]> >> https://moderncrypto.org/mailman/listinfo/messaging >> > > > -- > Steve K, > CEO Actor.im > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
