On 10/10/14 21:21, Ximin Luo wrote: > 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*)
correction, editing made things inconsistent. This should say, sent to everyone *except C*. > 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
