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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to