> 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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
