On Thu, 2013-10-10 at 14:20 -0700, Ray Dillinger wrote: > Wrong on both counts, I think. If you make access private, you > generate metadata because nobody can get at mail other than their > own. If you make access efficient, you generate metadata because > you're avoiding the "wasted" bandwidth that would otherwise prevent > the generation of metadata. Encryption is sufficient privacy, and > efficiency actively works against the purpose of privacy. > > The only bow I'd make to efficiency is to split the message stream > into channels when it gets to be more than, say, 2GB per day. At > that point you would need to know both what channel your recipient > listens to *and* the appropriate encryption key before you could > send mail.
This is starting to sound a lot like Bitmessage, doesn't it? A central message stream that is split into a tree of streams when it gets too busy and everyone tries to decrypt every message in their stream to see if they are the recipient. In the case of BM the stream is distributed in a P2P network, the stream of an address is found by walking the tree, and you need a hash collision proof-of-work in order for other peers to accept your sent messages. The P2P aspect and the proof-of-work (according to the whitepaper[1] it should represent 4 minutes of work on an "average computer") probably makes it less attractive for mobile devices though. [1] https://bitmessage.org/bitmessage.pdf --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography