I was thinking the same thing. In the past, when people have advocated replacing SMTP with something else to combat spam, that idea is always shot down with "too many clients, too much infrastructure" but if you have a new application and real demand (and it seems like there is) then you perhaps you could get enough traction to make that work.
Perhaps. Not sure I like the 'vaporizes in a week' thing. Point to point is good, and clearly something in the middle has to be designed in such a way that traffic analysis of the middle doesn't help. And like Lavabits you have to be careful that if your server infrastructure could be modified to break security, it can be compelled to be modified with an NSL and that is why I expect anything that is solved will only be solved with a server you "own" in your residence (at least in the US) to require the whole warrant process to get access to it.
Yeah, a few people have been looking at how to do things like this too (I've been talking to them); the idea being mix-net vs. onion routing, which is the big win of being async, and sensible defaults. It's a lot easier to do confidentiality/integrity/etc. on messages vs. traffic analysis resistance vs. strong adversaries, though.
Thinking, you register an "address" which can only be registered/announced once... that includes a public key (software generates private key)
When sending a message to someone, the entire envelope of a current email will be encrypted against the recipient's public key. That is the "msg", from there a crc32 of the msg is generated as a "sig" (signature), then a bcrypt of (address + sig) is generated as a "conf" (confirmation of intended recipient). The message is then addressed to a crc32 of the address... this allows for enough uniqueness so that super nodes don't get flooded, but still allow for some routing and query ability.
When you open your client, it connects to the DHT system, and then requests the sig/conf for any messages to crc32(address) then does the calculation locally to determin if a message is actually for said user. It can then request the actual message.
After N days a message should be deleted from the dht systems.
maybe have from:crc32(addr), to:crc32(addr) with two envelopes.. the outer would be encrypted against the recipient's public key.. so that the recipient could get the sender's address and their public key to decode the rest of the content...
As a general point... isnt spam something worth putting up with in order to get secure email? If there is too much spam, obscuring the legit emails, couldn't the client end filter that out?
Frankly, to take and extreme, if I were reliant on secure email for my life, spam would be the very least of my problems.
As a totally random thought, is there no way to use spam to hide and secure legit email?
Well, my initial thought was having the sender's hash could allow for a list of know offenders... but it would be easy enough for spammers to create thousands of address announcements...
If there was a push notification based email server, where the server would have to connect to the sender's server (based on DNS entry) to pull said message, it could allow for better spam filtering... but this would remove the decentralized part.
You are correct in that if I am relying on secure email for my life, then spam would be the least of my problems... but those who feel they must have secure email isn't enough to catalyst a new email system into broad use.
For what it's worth, I'm starting a new project to do just that. The project aims to enable secure mail & file sharing.
There isn't much code ATM, and the protocol hasn't been spec'd out, but I have an idea. If you want to talk more & contribute in the early protocol design phase you can find me on #gourami on freenode.
