[messaging] Partial ordering, dynamic groups and event ordering

[Jon Callas]

> 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*.

	Jon