[messaging] Partial ordering, dynamic groups and event ordering

[Ximin Luo]

On 15/03/14 03:02, Watson Ladd wrote:
> On Fri, Mar 14, 2014 at 11:37 AM, Jon Callas <jon at callas.org> wrote:
>>> I'm not sure that's a big deal.  But at least in a "pairwise" situation where each message is separately encrypted to each recipient (instead of using a group key and broadcast medium), wouldn't it be easy to omit old hashes to a new member?
>>
>> I agree with Trevor, Ximin.
>>
>> There's an old wry aphorism that any job not worth doing is not worth doing well. I don't think that worrying a lot about those issues is *worth* it.
>>
>> Another relevant aphorism is Dr. Franklin's, that a secret can be kept by three people so long as two of them are dead.
>>
>> Once you get into multiparty communications like an encrypted chat room or IRC channel, the fact that humans *presume* they can blab about things said "in public" is a much bigger threat to communications than any crypto. In a simple case of three people, I bet that the work factor to break things is 2^10, and certainly not 2^20. (Whatever that really means. 2^10 is "one in a thousand" and 2^20 is "one in a million" and my intuition is that the chance someone would blab something juicy is less than one in a million, even if I don't know the direct object of that million.) By the time you have a typical IRC chat, where people come and go, idle, lurk, log, etc., none of the vulnerabilities are in the crypto. So don't over-design it.
> 
> There are several possible failure modes for encrypted chat systems.
> One is Byzantine agreement: I might think our fearless leader said
> that we attack at dawn, but the reinforcements thought we were staying
> put. Confidentiality losses are bad, but it's a bit easier to plan
> around the enemy learning the plan then him making it.
> 

I think Byzantine agreement is an unnecessarily-strong condition; we can get away with solving easier problems, which partial ordering adequately covers.

In Byzantine agreement, you need to do something based on a guarantee on what others will do in the *future*. It's impossible to achieve this with certainty, though spending more effort can get you pretty close (but not 2^-128 close).

However, in a chat system, we have less things to care about. When we say something, it's good to know that the recipients have received our message, but whether they do (or not) doesn't change our original act or decision of saying it.

So, the system should try to guarantee to me that you know about my message (i.e. I have to see your ACK), but it's not necessary for you to know that I know that you know (i.e. for you to know that I saw your ACK).

(If I don't see your ACK in a timely fashion, I can resend the message, but this is rewinding back to the "I sent a message" scenario.)

> Confidential meetings with many participants exist. Yes, breaking
> humans is usually easy. Some humans don't break, or getting access to
> them can be noticed: the tale of Mucius Scaevola comes to mind.
> http://en.wikipedia.org/wiki/Gaius_Mucius_Scaevola.
> 
> Public conversation is easy: broadcast it!
>>
>> We're much better off by having systems that are immune to surveillance by a casual adversary that lurks in the cloud (it could happen), than worrying about the mechanics of the actual chat. They don't *want* to have to go to the trouble of setting up a sock puppet to join the chat, but they will. If the security of the system forces them to have to deign to join the chat, you win. You don't need to do more than that, and as a matter of fact, you're better of spending effort to make it *usable*.
> 
> Why are you having a confidential conversation with people you don't
> know in the room? Plenty of worldwide organizations exist with a need
> to meet in secrecy across large distances. Imagine a team of lawyers
> or auditors involved in a project spanning a few states.
> 

Right, I think the viewpoint of "groups of > $moderate_size are public anyway" is over-simplistic. There are very significant security differences between a group of 7 billion and (even) 1000 people - both in terms of numbers, and in terms of the leakage mechanism (e.g. who the receiver of the leak needs to trust).

However, I do imagine that we will probably need different protocols to deal with small private groups vs moderately-large private groups.

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: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140320/13c0a6b2/attachment.sig>