On Mon, May 14, 2018 at 11:42:14PM -0400, Steve Kinney wrote: > > > On 05/12/2018 02:49 AM, grarpamp wrote: > > > Look to new messaging, fill, PETS and other venues, whatever, etc.. > > search for papers, fidn tbe bibs, see what's out there, or what you > > might create. > > Here's a silly notion: > > First you need a network of servers that can store and forward large > amounts of data in the form of text, and distribute it across enough > nodes to make the stored data deletion-resistant and reasonably > accessible to a large number of users. NNTP will do nicely. > > Then you need privately owned devices capable of downloading gigabytes > of data daily, and applying a decryption test to millions of messages as > they flow by. Today's low end PCs will do nicely. > > Those gigabytes of text? Symmetrically encrypted messages from the > whole Alice, Bob, etc. alphabet soup of users, employing keys obtained > by whatever means from their intended message recipients. > > Everyone participating in this network would download the whole stream, > testing the encrypted subject line of each discrete message with their > personal keys, looking for the flag that says "this one's for you." > Those messages would be decrypted instead of discarded, and presented in > a local inbox. The rest would just zoom on past.
Somewhat like Git - endless stream of messages go past, view the ones your interested in/ can access. Git also provides ready cross-repo sync/ merge algos. With msgs stored separately, no merges needed - the GitSHA of the message/ BLOB ID can be the indexer, and as you say, only those messages you can decrypt get decrypted... > Sending a message? Encrypt it and its subject line with your > recipients' keys, and send it on its way. If your recipient downloads > the stream before your message expires, success. > > 3rd party observers? Out in the cold, unless they penetrate individual > users' machines or otherwise compromise endpoints, one user at a time. > > This protocol presents as an application of the most time honored and > reliable principle of engineering practice: Brute force and total > ignorance. With a side of COTS: We already have all the parts, this > could be done with shell scripts. Nice thoughts. > The only counter attacks I immediately see include flooding past the > breaking point with purely random bits, which may require mitigation via > short cycle message expiration or some kind of registration or proof of > work process for users; or interruption of traffic by a global (or > local) active adversary. > > Call the protocol and associated tools TPC: An acronym for Totally > Protected Communication or, for those in the know, The Perfect Crytocrime. > > Bonus: Quantum cryptanalysis can't touch that, far as we know. > > :o) Free speech tech has a ways to go. After a distribution system, then the end user stack needs to be extremely hardened, and finally auditable libre open hardware...