[messaging] Partial ordering, dynamic groups and event ordering

[Ximin Luo]

On 14/03/14 18:37, Jon Callas 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.
> 
> 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*.
> 

Human and technical issues are non-conflicting topics in security, and both should be solved. What you are talking about is *per-instance-cost*, the cost to achieve strong security *in each instance* of a situation. Of course, we do not want high per-instance-cost solutions.

The effort I am putting in here is *research-cost*. Once a solution is found and the software written, the cost to achieve security becomes very very low. Also, we are on a mailing list called messaging at moderncrypto.org, so excuse me for talking about very technical issues.

Just because there has historically been a lack of focus on UX, and many people are rightly focusing on it more, does not mean technical research is "not worth" the effort. In fact, I started another thread in parallel, that focused more on UX issues - perhaps you have something more constructive to add to that one? You are welcome to ignore this thread if you don't feel it's worth your personal effort to think about - but I do.

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/20140314/48d2c606/attachment.sig>