[tahoe-dev] Idea for a Publish/Subscribe Message System on Tahoe-LAFS

[Jeffrey Burdges]

Hello,

I'm not terribly familiar with the Tahoe codebase yet, only just lurked here thus far, but I'd be interested in contributing to an append-caps project as well.


> It'll take the spammers at most an hour before every subject line is "Help I've been mugged and lost my wallet", or "Hi sweetie", or "Important your account has been suspended", and the recipient has to download every message (or ignore them and suffer false-positives).

There isn't quite such an enormous problem with spammers on instant messagers or social network sites as with email because they make users establish a connection first.

I'd naively assumed that a Tahoe based messaging system would be implemented similarly, with each user creating a directory to receive a public "hello"  messages that adhere to a moderately strict XML format, i.e. no conventional HTML entities. 

An initial hello message might contain a text only message and an append/write-cap for a newly created MDMF directory that represents your "friendship".  You'd find a read-cap that identifies the sender in this directory, like a read-cap containing a name and photo.  You'd confirm the "friendship" by replying into this friendship directory with a similar identifying read-cap.  You both then communicate additional URIs by adding them into this directory. 

You could add an additional proof-of-work into this exchange of course, but maybe you should instead add a proof-of-work into the search tool used to obtain the initial hello append-cap for their friends.  In fact, a search based proof-of-work lets you more easily justify using write-caps for hello messages instead of implementing append-caps.

I'm now straying away from Tahoe LAFS itself but ..

There aren't afaik any directory services that offer a weak security guarantee that the searcher searched for an exact phrase and perhaps did additional work.  I expect this might useful for distributing stuff like hello append-caps, GPG keys, etc.  I suppose spammers aren't reduced to scrapping GPG key servers for email addresses, but one could imagine this being an issue. 

Our search server's records might contain a key computed as SHA512( exact search string ), a user selected seed, an AES512( search result, SHA512( seeded exact search string ) ), and a user created public key for revocation.  If I query the search server with the key, after hashing my search, then it'll tell me the seed, and I can decrypt the search results. 

One could add a proof-of-work by giving an inexact seed and an error correcting code for the search result.  I suppose you'd implement this inexact seed by specifying a mask of bits that the searcher should try flipping.  And the searcher's software would simply refuse to return any results if the popcount was too large. 

There is an enormous risk of a rainbow table attack on the key space by a malicious server, but maybe you could move the proof-of-work to the key space side to reduce this.  An independent source picks a new key seed every n months, thus forcing the searcher to hash their searches using all previous seeds, but preventing the server from using rainbow tables as effectively. 

I would also be interested in working on such a weakly secure search infrastructure project.  I'm rather surprised that nobody has built this or similar yet actually, it's trivial conceptually and not too hard to implement. 

Jeff Burdges