[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BriarProject Messaging 1.0 Released

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