[messaging] Group messaging consistency under resource constraints

[Ximin Luo]

On 10/10/14 21:06, Trevor Perrin wrote:
> On Fri, Oct 10, 2014 at 11:35 AM, Ximin Luo <infinity0 at pwned.gg> wrote:
>> On 10/10/14 17:09, Trevor Perrin wrote:
>>>
>>> In an asynchronous setting you can't assume other parties are online
>>> to retransmit.  With no central server to retransmit, how does your
>>> algorithm work?
>>>
>>
>> It works by having everyone be a potential re-sender, of everyone else's ciphertext. (Only the ciphertext is cached, not e.g. ratchet secrets derived from them.) So yes, it doesn't work if there is one person who is never online at the same time as anyone else.
>>
>> But in such a case, you would need a server to cache the ciphertext *anyway*, for that person to receive *any messages at all*. A non-caching server doesn't help reliability, only performance/efficiency - since the original sender could have just used separate individual transports (without the central server) to deliver to those recipients directly via other routes. And once you build the caching server, it's not much effort to have it attempt retransmits periodically.
> 
> 
> It's true that the asynchronous setting requires a message to be
> stored somewhere, awaiting delivery.
> 
> But I disagree that it's "not much effort" for this somewhere to
> retransmit messages to anyone in a group who asks.  That's not how
> transports like (SMS, Google Cloud Messaging, email, Pond, or mix
> networks) work.
> 

Why do you think it's a lot of effort? Those transports don't try to achieve group consistency; why is it unreasonable to suppose that consistency requires changes to (or, enhancements on top of) how the transport works? I have tried to explain why I think this is necessary in the first post, at least under certain constraints, but no-one is addressing that and instead just denying my claims without backing it up.

> I think your original question was directed at TextSecure.  TextSecure
> already supports a few different transports, and may need to support
> more in the future.  So anything we do with "transcript consistency"
> needs to work within the premise that message delivery is asynchronous
> and unreliable.
> 
> Trevor
> 
> [1] https://moderncrypto.org/mail-archive/messaging/2014/000372.html
> 

This [1] doesn't achieve consistency. I tried to explain why both in its "next message in thread" and in the first post of this thread, but it looks like my warnings are falling on deaf ears; here is a more concrete example:

A: (1) Who wants ice cream? (last-message-seen: 0)
A: (2) Who wants to kill the president? (last-message-seen: 1) (sent to everyone, *except B*)
B: (3) No thanks... (last-message-seen: 2)
C: (4) Me! (last-message-seen: 3)

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141010/d4dd0abb/attachment.sig>