On 10/10/14 21:06, Trevor Perrin wrote: > On Fri, Oct 10, 2014 at 11:35 AM, Ximin Luo <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
