Re: [messaging] KCI in X3DH

Thanks for the explanation Katriel! That all makes sense to me. X Katriel Cohn-Gordon: > Hi all, > > I'm one of the authors of the Signal and ART papers. We have pushed a > small update to the paper to help clarify its wording. If you spot any > other places where we can improve things, please

Re: [messaging] KCI in X3DH

Trevor Perrin: > On Wed, Jan 17, 2018 at 5:40 PM, Ximin Luo <infini...@pwned.gg> wrote: >> >> On the ART paper near the end it mentions: "we use the X3DH paper [..] >> extended to include the static-static DH key in order to prevent UKS and KCI >> atta

Re: [messaging] Asynchronous Ratcheting Tree

; merge support. I also haven't really considered whether this would > compromise any security properties, which would be important to look into! > > Hope that makes some sense, > Jon > > > On 9 January 2018 at 12:34, Ximin Luo <infini...@pwned.gg> wrote: > >> I was

[messaging] Asynchronous Ratcheting Tree

I was just forwarded this: https://eprint.iacr.org/2017/666 On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees, by Katriel Cohn-Gordon and Cas Cremers and Luke Garratt and Jon Millican and Kevin Milner It looks very nice. However, on a quick glance through

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > >>> If my understanding is correct, the answer is No. No we cannot prevent >>> longterm intersection attacks by using decoy traffic in the >>> katzenpost/loopix system because users will go offline and come back >>> online later which changes the anonymity set size and thus leaks >>>

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > >> I wonder, in general can we have nice things? Can we finally have a >> cryptographic messaging system that protects against intersection >> attacks? To that end I've been putting together a reading list so that > > If my understanding is correct, the answer is No. No we cannot

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Michael Rogers: > On 10/11/17 14:31, Ximin Luo wrote: >>> So if we're asking whether a system may be vulnerable to the attack, and >>> it has the properties above, then we need to ask whether the system is >>> doing something to produce that counterva

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

Michael Rogers: > On 01/11/17 01:40, Ximin Luo wrote: >> After a quick web search on "epistemic attacks", the main paper I can find >> [1] has the result that attacks are very strong if each node only knows >> about a small fraction (n nodes) of the whole ne

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > [..] >> >> Indeed no, but I understand now and the comparison was useful, thanks. I >> think I was originally thrown off because the term "PKI" brought to my head >> X509 and WoT mapping of real-identities-to-keys. >> >> If I understand correctly, what you mean here instead is a

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > No, it will scale as Loopix intended. The constraint that each Operator > will run an equal size set of mixes is a deployment constraint that may > not be adhered to strictly. We shall see, for now we haven't even finished our > implementation so we are a ways away from discovering what

Re: [messaging] Panoramix decryption mixnet messaging spec and design documents

dawuud: > > https://github.com/Katzenpost/docs/blob/master/drafts/mixdesign.txt > > [..] Hi David, it's been a while since I read through this topic, and I only briefly scanned the Loopix paper, so forgive me if the following questions are ignorant: 1. The Loopix paper mentions "Furthermore,

Re: [messaging] Ronion anonymous routing protocol framework

Nazar Mokrynskyi: > Hi folks, > > Recently I've being exploring anonymous routing protocols (Tor, mixed > networks) because I need such for one of my projects. > > Each project seemed to design the whole thing from the ground up and they are > protocols are quite complex as a whole. > > I

Re: [messaging] IETF standardization of a next-gen e2e encryption component

Tony Arcieri: > On Sun, Oct 2, 2016 at 2:23 AM, Hanno Böck wrote: > >> * I assume your intention is to standardize an encryption layer only >> and not a new messaging protocol, right? > > Yes > In that case, can we please rename this thread to something that's less

Re: [messaging] IETF standardization of a next-gen messaging protocol

Ben Laurie: > On 2 October 2016 at 13:39, Ximin Luo <infini...@pwned.gg> wrote: >> >> I can see the benefits in agreeing to standardise a cryptographic component >> including the packet flows and algorithms, but standardising the exact wire >> representation is

Re: [messaging] IETF standardization of a next-gen messaging protocol

Tobias Markmann: > On Sun, Oct 2, 2016 at 1:48 PM, Ximin Luo <infini...@pwned.gg> wrote: > >> For sure, but then it should be called a common encryption component and >> *not* "standardisation of a next-gen messaging protocol" (the subject of >> this threa

Re: [messaging] IETF standardization of a next-gen messaging protocol

Tobias Markmann: > Hi, > > On Sun, Oct 2, 2016 at 11:23 AM, Hanno Böck wrote: > >> * I assume your intention is to standardize an encryption layer only >> and not a new messaging protocol, right? (That's the way the thing >> that's commonly called the signal protocol is

Re: [messaging] RFC: (n+1)sec secure group chat - security properties and UX design

Ruud Koolen: > [..] > security without sacrificing too much usability, and thus to avoid designing > a beautiful system that nobody will use because of its complexity. > [..] I think these types of remarks are logical fallacies that harm security research and the internet freedom community.

Re: [messaging] Partial order group chat with partial history visibility

Ximin Luo: > However, for the longest time I couldn't construct any examples that actually > concretely indicate this problem, to be able to study it further. Now finally > I've proved that this is actually false, and the more counter-intuitive > result holds, i.e.: > Scratch t

Re: [messaging] Partial order group chat with partial history visibility

Jeff Burdges: > On Wed, 2016-05-25 at 12:25 +0200, Ximin Luo wrote: >> Ximin Luo: >>> Jeff Burdges: >>>> Is there even a global partial order G for typical DVCs for example? >>>> It's just the local ones that actually exist on disk, right? >>&g

Re: [messaging] Partial order group chat with partial history visibility

Ximin Luo: > Jeff Burdges: >> >> Is there even a global partial order G for typical DVCs for example? >> It's just the local ones that actually exist on disk, right? >> > > Yes, that is G the "full history". > One thing to note here is that I don

Re: [messaging] Partial order group chat with partial history visibility

Jeff Burdges: > > In other words, there is no globally consistent view, but if the event > membership data U[v] was magically globally consistent, then the general > merge algorithm can be pairwise consistent by running it again only > messages known to both parties. > The data U[v] is embedded

[messaging] Partial order group chat with partial history visibility

I've been exploring representing group chat history in terms of a partial order (directed acyclic graph) just like how modern version control systems represent history, in order to support asynchronous group chat (where it's better not to have a "captain"). Two years ago, way back in [1] I

Re: [messaging] MITM-safe communication w/o authentication possible?

On 30/11/15 03:09, Karl wrote: > On 11/29/15, Ximin Luo <infini...@pwned.gg> wrote: >> On 30/11/15 00:53, Ethan Heilman wrote: >>>> No human user thinks in terms of contacting cryptographic identities. >>>> [..] >>> >>> Am I correc

Re: [messaging] MITM-safe communication w/o authentication possible?

On 30/11/15 01:36, Ethan Heilman wrote: >> In other words, your way of interpreting the question basically ignores the >> hard problem. Of course, if you ignore the hard problem, then it's >> "possible". > > I agree with that, the hard problem is aliasing real world identities > with

Re: [messaging] MITM-safe communication w/o authentication possible?

On 29/11/15 23:53, Ethan Heilman wrote: > It is possible If your identity in a system is directly tied to your > public key or some provable secret. > No, this is a common fallacy of "identity-based encryption". No human user thinks in terms of contacting cryptographic identities. There is some

Re: [messaging] MITM-safe communication w/o authentication possible?

On 29/11/15 21:32, U.Mutlu wrote: > I wonder if it can be possible, at least theoretically, to have a > MITM-secure internet channel without the use of PKI and/or > persistent password If by "without the use of X" you mean "without any further human input", this is impossible. (That is the

Re: [messaging] Security arguments for read receipts

On 03/11/15 18:53, Jeff Burdges wrote: > There are not many systems that satisfy both M0/M1 and R0 from : > > http://www.lothar.com/blog/53-petmail-delivery/ > All that I know fit into two categories : > > > Category 1. Group signature schemes require pairing-based cryptography > > [..]

[messaging] Security arguments for read receipts

I hear that OpenWhisperSystems don't want to implement "read receipts" because they consider this to be a security issue, and have closed several user tickets requesting this feature as "wont fix". I don't think it's a security issue, at least not in a significant sense, and in fact I think *not*

Re: [messaging] Security arguments for read receipts

On 03/11/15 16:49, Jeff Burdges wrote: > As stated, there is no need for timely auto-acks to get these > properties since implicit manual acks do them just fine. > > [..] > > Is this a security issue really? It sounds beneficial of course, but > not seeing the security implications. At

Re: [messaging] Security arguments for read receipts

Hi Nataneal, It sounds like you have a specific proposal in mind, for a system that has auto-acks. It would be good if you wrote this up in a separate document. My post was about why auto-acks are desireable in the first place. I specifically tried to ignore how one might implement this,

[messaging] Forward secrecy in the EFF messaging scorecard

Hi, I just saw that in the EFF messaging scorecard [1], the column for forward secrecy gives a tick even if the application does not actually have forward secrecy: "Note: For this phase of the campaign, we accept [..] forward secrecy on the transport layer [..] and non-forward-secret

Re: [messaging] Hold the Axolotl ratchet

On 22/09/15 23:57, Sebastian Verschoor wrote: > Even though it seems like a useless attack, the fact that you have to rely on > the honesty of the other party to forward the ratchet seems like an unwanted > property... > Intuitively, something is "an attack" if it allows the executor to do

Re: [messaging] Naming and classifying a security property

On 16/09/15 08:36, Jeff Burdges wrote: > I think typical capability terminology breaks down once you start > talking about the internals of a protocol and memory compromises as > opposed to the full protocol. > > There are folks miss-reading Dominic Tarr's paper on wildcard attacks in >

Re: [messaging] Naming and classifying a security property

On 14/09/15 22:44, Trevor Perrin wrote: > On Sun, Sep 13, 2015 at 8:50 AM, Ximin Luo <infini...@pwned.gg> wrote: >> While I was doing an exercise on classifying and enumerating security >> properties, I came up with the following one: >> >> - (in: w encrypts

Re: [messaging] Naming and classifying a security property

On 14/09/15 12:47, Katriel Cohn-Gordon wrote: > - (in: w encrypts m to r) if attacker "a" passively compromises w, they > are able/unable to decrypt current (in-transit) and/or future ciphertext > (i.e. "act as r") > - (in: w authenticates m to r) if attacker "a" passively compromises r,

Re: [messaging] Naming and classifying a security property

On 13/09/15 17:50, Ximin Luo wrote: > - chain-based ratcheting has this property - as the sender, you encrypt m[i] > using k, then hash it and delete the original for m[i+1]. the recipient will > need to keep extra state around if they want to handle out-of-order messages. Whoops, this

Re: [messaging] libforwardsec: forward secure encryption for email and asynchronous messaging

Thanks for the explanation previously. Let me put it into different terms, which might make it clearer for others. Your scheme decouples these two things: 1. the ability to prevent decryption of messages sent in the past (that were not received) 2. the abliity to prevent re-decryption of

Re: [messaging] libforwardsec: forward secure encryption for email and asynchronous messaging

Hey, thanks for the post. It's always nice to hear about new work on ratchets. +1 for writing new applications/libraries in Rust and ditching C/C++. On 04/09/15 21:42, Ian Miers wrote: > * Performance: depends on message distribution. Assuming a poisson process > for initial messages (you

Re: [messaging] libforwardsec: forward secure encryption for email and asynchronous messaging

On 05/09/15 12:27, Ximin Luo wrote: > Do you have a paper that describes this in more detail? > I just found the paper and skimmed through it. To answer my own questions, the differences between this and e.g. a typical ratchet is that: - the encrypted messages are not ordered,

Re: [messaging] Deniable authenticated group messaging

On 18/04/15 00:00, Michael Rogers wrote: On 17/04/15 22:35, Ben Laurie wrote: It's not a fantasy requirement, it's a standard property of MACs. If Alice and Bob share a MAC key and Alice uses it to create a MAC, Bob knows that since he didn't create the MAC, Alice must have done.

Re: [messaging] Deniable authenticated group messaging

On 17/04/15 19:37, Ben Laurie wrote: On 17 April 2015 at 11:54, Michael Rogers mich...@briarproject.org mailto:mich...@briarproject.org wrote: Members should be able to send messages to the group, such that any member of the group can verify that a message was written by the owner

[messaging] Merging in partially-ordered private group chats; was: Re: Matrix.org: Decentralized group chat

(should have re-titled the thread a while ago) On 11/03/15 19:59, Jeff Burdges wrote: On 11 Mar 2015, at 14:55, Ximin Luo infini...@pwned.gg wrote: In summary: with merge algorithms that don't need to think about partial history, b and d .. **must** have the same view of the membership

Re: [messaging] Matrix.org: Decentralized group chat

On 10/03/15 15:13, Natanael wrote: Den 10 mar 2015 14:52 skrev Ximin Luo infini...@pwned.gg mailto:infini...@pwned.gg: On 10/03/15 14:42, Natanael wrote: Den 10 mar 2015 09:49 skrev Ximin Luo infini...@pwned.gg mailto:infini...@pwned.gg mailto:infini...@pwned.gg mailto:infini

Re: [messaging] Matrix.org: Decentralized group chat

On 11/03/15 00:51, Matthew Hodgson wrote: On Tue, 10 Mar 2015, Ximin Luo wrote: On 10/03/15 21:39, Matthew Hodgson wrote: So in terms of state merge resolution: yes, this is obviously a hard problem to get right. Hopefully we haven't underestimated it. The WIP draft documentation

Re: [messaging] Matrix.org: Decentralized group chat

On 10/03/15 19:36, Jeff Burdges wrote: On 10 Mar 2015, at 17:08, Ximin Luo infini...@pwned.gg wrote: Merge the unordered set of members. In the following diagrams, the node labels (e.g. bd) represent the set of members (b, d) at a given message/node/event. Someone wants to merge the blue

Re: [messaging] Matrix.org: Decentralized group chat

On 10/03/15 21:39, Matthew Hodgson wrote: So in terms of state merge resolution: yes, this is obviously a hard problem to get right. Hopefully we haven't underestimated it. The WIP draft documentation for it is at

Re: [messaging] Matrix.org: Decentralized group chat

On 07/03/15 19:31, Ben Laurie wrote: On 7 March 2015 at 18:18, Mike Hearn m...@plan99.net wrote: It might eventually turn into Wave, then? Federated merge resolution with signatures sounds very Wave like. Yeah, it does. I worked with Wave for a while, which is why I have reservations about

Re: [messaging] Value of deniability

On 12/12/14 15:53, Daniel Kahn Gillmor wrote: On 12/12/2014 09:12 AM, Bruce Leidl wrote: It seems rather unfair (maybe even hostile) to users to sell them on purported 'secure' communication protocols which are in some ways inferior and actually less secure than not using them because an

Re: [messaging] Value of deniability

On 12/12/14 16:30, Eleanor Saitta wrote: On 2014.12.12 10.06, Ximin Luo wrote: Can we all talk about something more productive now, please? There are lots more problems to be solved in group chat, and getting stuck on deniability hinders progress. AFAIK, everyone still actively working

Re: [messaging] Value of deniability

On 10/12/14 22:00, Eleanor Saitta wrote: On 2014.12.10 15.52, Ximin Luo wrote: Yes, deniability won't prove the lack of authorship in legal settings, because in current systems there's lots of other evidence that suggests (or proves-in-court) authorship. However, once we have systems

Re: [messaging] Value of deniability

On 10/12/14 22:24, Eleanor Saitta wrote: On 2014.12.10 16.12, Ximin Luo wrote: There are a bunch of reasons why deniability doesn't work in the field. Once we neutralise those reasons, it would work in the field. For example, metadata leaks and bad endpoint security. So blaming it doesn't

Re: [messaging] Encrypted Group Chats

On 28/11/14 02:28, st...@actor.im wrote: It doesn't feel to be secure to share one common key across all members of group. One of main plus of group is that we can easily check encryption key for group. [..] Any ideas? I'm going to attempt a summary of everything that's been discussed

Re: [messaging] Encrypted Group Chats

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

Re: [messaging] Tahoe-Lafs + miniLock: A device agnostic user friendly zero knowledge file system?

On 04/11/14 16:53, toti...@riseup.net wrote: Currently, there is no zero knowledge file system that is user friendly and fully open source. Hi, I haven't yet read through the rest of it, but my first comment is that zero-knowledge file system sounds like mystical marketing terminology. I

Re: [messaging] EFF Secure Messaging Scorecard

On 04/11/14 19:50, Robert Obryk wrote: On Tue, Nov 4, 2014 at 5:43 PM, Joseph Bonneau jbonn...@gmail.com wrote: First version launched today: https://www.eff.org/secure-messaging-scorecard This was a collaboration between tech advisers (primarily Peter Eckersley and myself) and a good team of

Re: [messaging] Forward secrecy and multiple devices

devices. I was hoping this list would be aware of some kind of breakthrough I've missed out on, but that doesn't seem to be the case. Hope you're doing well. :-) NK -- Original Message -- From: Ximin Luo infini...@pwned.gg To: messaging messaging@moderncrypto.org Sent: 2014-10

Re: [messaging] Group messaging consistency under resource constraints

On 10/10/14 23:09, Trevor Perrin wrote: On Fri, Oct 10, 2014 at 1:21 PM, Ximin Luo infini...@pwned.gg wrote: On 10/10/14 21:06, Trevor Perrin wrote: [1] https://moderncrypto.org/mail-archive/messaging/2014/000372.html This [1] doesn't achieve consistency. I tried to explain why both in its

Re: [messaging] Group messaging consistency under resource constraints

On 20/10/14 18:10, Trevor Perrin wrote: On Mon, Oct 20, 2014 at 8:11 AM, Ximin Luo infini...@pwned.gg wrote: On 10/10/14 23:09, Trevor Perrin wrote: On Fri, Oct 10, 2014 at 1:21 PM, Ximin Luo infini...@pwned.gg wrote: On 10/10/14 21:06, Trevor Perrin wrote: [1] https://moderncrypto.org/mail

Re: [messaging] Group messaging consistency under resource constraints

On 20/10/14 22:19, Natanael wrote: Den 20 okt 2014 19:22 skrev Ximin Luo infini...@pwned.gg mailto:infini...@pwned.gg: On 20/10/14 18:10, Trevor Perrin wrote: On Mon, Oct 20, 2014 at 8:11 AM, Ximin Luo infini...@pwned.gg mailto:infini...@pwned.gg wrote: On 10/10/14 23:09, Trevor

Re: [messaging] Group messaging consistency under resource constraints

On 20/10/14 23:23, David Leon Gil wrote: On Mon, Oct 20, 2014 at 6:13 PM, Ximin Luo infini...@pwned.gg wrote: So, we are working in the context that some messages might be dropped. Say there were 20 messages and Alice only received 15 of them. She builds up a root hash from these 15 messages

Re: [messaging] Group messaging consistency under resource constraints

On 12/10/14 04:57, David Leon Gil wrote: In short: I agree with Ximin; group messaging should be consistent. Ximin's proposal: a sequentially consistent log. This is likely to cause excessive message delays, as Trevor rightly worries about, even with a pure reorder channel. Yes, I do

Re: [messaging] Group messaging consistency under resource constraints

On 16/10/14 18:37, Trevor Perrin wrote: On Thu, Oct 16, 2014 at 9:53 AM, Ximin Luo infini...@pwned.gg wrote: There have been arguments that typical transports don't work like this and I gave TCP as a counterexample. Trevor also mentioned Pond, but actually this is an example in my favour

Re: [messaging] Group messaging consistency under resource constraints

On 16/10/14 19:51, Trevor Perrin wrote: I don't think you've internalized the asynchronous messaging use case (email, text messages, Pond, TextSecure). It means messages can be sent and received regardless of whether correspondents are online. Alice to Bob, Charlie: Krakens are coming!

Re: [messaging] Group messaging consistency under resource constraints

On 10/10/14 10:24, Trevor Perrin wrote: On Mon, Oct 6, 2014 at 10:53 AM, Ximin Luo infini...@pwned.gg wrote: Committing to delivering messages in causal order has been controversial for those with resource constraints [2], because it involves queueing some messages from being displayed

Re: [messaging] Group messaging consistency under resource constraints

On 10/10/14 21:06, Trevor Perrin wrote: On Fri, Oct 10, 2014 at 11:35 AM, Ximin Luo infini...@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

Re: [messaging] Group messaging consistency under resource constraints

On 10/10/14 23:09, Trevor Perrin wrote: On Fri, Oct 10, 2014 at 1:21 PM, Ximin Luo infini...@pwned.gg wrote: On 10/10/14 21:06, Trevor Perrin wrote: 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

[messaging] Group messaging consistency under resource constraints

Some of us have been working on group secure messaging, and there is an outstanding issue within the broader topic of how to achieve consistency. Those who have followed this topic can Ctrl-F to Tradeoffs with causal ordering. Model of consistency We have pairwise

Re: [messaging] Group messaging consistency under resource constraints

On 06/10/14 22:29, Trevor Perrin wrote: So you're arguing it's a desirable UX if out-of-order messages are not displayed until their ancestors have been displayed, and that this is generally achievable since clients can use a retransmit mechanism to get any lost messages. I note that in

Re: [messaging] Group messaging consistency under resource constraints

On 07/10/14 00:37, Andy Isaacson wrote: On Mon, Oct 06, 2014 at 11:07:13PM +0100, Ximin Luo wrote: If one doesn't care about consistency of history, it's fine to just display messages immediately as they arrive. If one does care about it, then you can't. Or at least, I believe not - and nobody

Re: [messaging] Thoughts on keyservers

On 19/08/14 00:02, elijah wrote: On 08/18/2014 12:09 AM, Trevor Perrin wrote: Keyservers could also support transparency similar to CT... On 08/18/2014 02:35 PM, Tony Arcieri wrote: I think whatever the solution is, it needs a CT-like scheme to help detect spoofed IDs. I would like

Re: [messaging] Tor Hidden Services in (Cables, SMTorP, Pond)

On 18/06/14 15:20, Daniel Kahn Gillmor wrote: On 06/18/2014 07:21 AM, Eleanor Saitta wrote: On 2014.06.18 00.31, Daniel Kahn Gillmor wrote: I was surprised by this claim as well -- my current expectation is that i have *no idea* when my mail reaches the receiver's mailpile (and i'm fine with

Re: [messaging] Message order in group chat (attempt at summary)

On 30/04/14 22:59, Michael Rogers wrote: I have a hunch that for linear conversations, something like the CAP theorem holds: if there's a partition, either the conversation has to pause or you have to give up consistency. Threaded conversations can be partition tolerant because they can

Re: [messaging] Message order in group chat (attempt at summary)

On 30/04/14 23:58, Ximin Luo wrote: - for any given user, if they refer to parents P in one event E, their future event E' = E must refer to parents P' all of whose elements are = all elements of P. Or equivalently, ancestors(E) is a subset of ancestors(E'). Scratch that, the or equivalently

Re: [messaging] Message order in group chat (attempt at summary)

On 29/04/14 09:15, Michael Rogers wrote: On 27/04/14 18:45, Ben Laurie wrote: If it is delayed for all recipients, then causality cannot be violated :-) Here's a crazy idea. Each client maintains a list of messages it knows each other client has seen (because that client has told it so).

Re: [messaging] Merging partially-ordered membership operations was Re: Message order in group chat (attempt at summary)

On 21/04/14 16:22, Trevor Perrin wrote: On Mon, Apr 21, 2014 at 6:24 AM, Ximin Luo infini...@pwned.gg wrote: Suppose a simpler policy: a member-delete message takes priority over member-add even if they're siblings. Since siblings only arise in the simultaneous send case, where it's sort

Re: [messaging] Message order in group chat (attempt at summary)

On 26/04/14 16:39, Moxie Marlinspike wrote: 3) Each message is displayed with a small icon or color which indicates that you've seen the message it is responding to. 4) If you long-click the message, it'll display In reply to... That way when Alice says I do! in reply to what she thought

Re: [messaging] Message order in group chat (attempt at summary)

On 27/04/14 13:45, Ben Laurie wrote: On 27 April 2014 18:40, Moxie Marlinspike mo...@thoughtcrime.org wrote: On 04/27/2014 07:39 AM, Ximin Luo wrote: I'm not so sure about displaying messages where you haven't yet seen their parents yet. This violates causality, and the principle

[messaging] Necessary considerations of a linear order based on server-receive time

During the mpCAT summit we discussed the following idea: - The server dictates the ordering of messages. - For any message M sent by a given user, the server may validly insert others' messages before M. - Everyone attests to the order, and checks others' attestations. This is a simple way to

Re: [messaging] Merging partially-ordered membership operations was Re: Message order in group chat (attempt at summary)

On 21/04/14 04:31, Trevor Perrin wrote: On Sun, Apr 20, 2014 at 5:20 PM, Ximin Luo infini...@pwned.gg wrote: I'm unsure what you're trying to achieve with M, D. I'd like to understand the algorithms for tracking causal order and group membership. There's different membership policies

Re: [messaging] Merging partially-ordered membership operations was Re: Message order in group chat (attempt at summary)

On 21/04/14 16:22, Trevor Perrin wrote: On Mon, Apr 21, 2014 at 6:24 AM, Ximin Luo infini...@pwned.gg wrote: I think this does work, but I see a few issues. It leaks some information about previous members in the session - I don't think the garbage-collection would be enough to hide

Re: [messaging] Message order in group chat (attempt at summary)

On 19/04/14 00:54, Trevor Perrin wrote: On Fri, Apr 18, 2014 at 2:32 PM, Alexandre Carmel-Veilleux a...@miniguru.ca wrote: On Fri, Apr 18, 2014 at 5:07 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Apr 18, 2014 at 1:42 PM, Trevor Perrin tr...@trevp.net wrote: (1) It seems feasible to

Re: [messaging] Message order in group chat (attempt at summary)

On 19/04/14 16:45, Trevor Perrin wrote: On Sat, Apr 19, 2014 at 6:53 AM, Ximin Luo infini...@pwned.gg wrote: On 19/04/14 00:54, Trevor Perrin wrote: To handle join and part events, I think we can assume these actions are represented as messages which operate on the member-set each

Re: [messaging] Minimal requirements for group chat

On 16/04/14 19:34, Michael Rogers wrote: On 16/04/14 16:36, Michael Rogers wrote: If a member receives a message with the same sequence number as a staged message, she sends a nack to every other member and discards both messages. Anyone who receives a nack for a staged message discards the

Re: [messaging] Message delivery and revocation in Pond etc

On 01/04/14 23:17, Trevor Perrin wrote: On Mon, Mar 31, 2014 at 12:11 PM, Ximin Luo infini...@pwned.gg wrote: On 30/03/14 17:31, Trevor Perrin wrote: * The server's storage of used values is unlimited over time, but grows at a small rate, and could possibly be scoped by introducing more

Re: [messaging] Message delivery and revocation in Pond etc

On 03/04/14 21:06, Trevor Perrin wrote: On Thu, Apr 3, 2014 at 12:50 PM, Michael Rogers mich...@briarproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/04/14 19:02, Trevor Perrin wrote: I think you want signatures for garbage messages which fail end-to-end

Re: [messaging] Separation of concerns, usability, and partial verification

On 12/03/14 15:18, Ximin Luo wrote: This is a brief outline on the architecture of an independent/central verification program. This could be part of a keyring, or a contact manager, or even a combined contacts/keys manager that some UX folks were suggesting at the CTS IV. It would let

Re: [messaging] Pseudoword base32 fingerprints

On 06/02/14 01:08, Tony Arcieri wrote: On Wed, Feb 5, 2014 at 4:47 PM, Moritz Bartl mor...@headstrong.de mailto:mor...@headstrong.de wrote: Hm. Sorry, stupid question, but why can't you simply map 4-tuples to a 65k wordlist? Fantasy names, English, something more pronounceable?