Spek – Spam and Phishing Email Killer

A great WordPress.com site

Responses to the craphound.com/spamsolutions.txt list

One of the commenters to the original post reproduced the spamsolutions list and marked off which items he thought applied to this idea.

Your post advocates a

(x) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won’t work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

(x) It will stop spam for two weeks and then we’ll be stuck with it
(x) Users of email will not put up with it
(x) Microsoft will not put up with it
(x) The police will not put up with it
(x) Requires too much cooperation from spammers
(x) Requires immediate total cooperation from everybody at once
(x) Many email users cannot afford to lose business or alienate potential employers

Specifically, your plan fails to account for

(x) Lack of centrally controlling authority for email
(x) Open relays in foreign countries
(x) Unpopularity of weird new taxes
(x) Public reluctance to accept weird new forms of money
(x) Huge existing software investment in SMTP
(x) Susceptibility of protocols other than SMTP to attack
(x) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
(x) Eternal arms race involved in all filtering approaches
(x) Extreme profitability of spam

and the following philosophical objections may also apply:

(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
(x) Countermeasures must work if phased in gradually

Furthermore, this is what I think about you:

(x) Sorry dude, but I don’t think it would work.

I’ll address them in turn as best I can.

1) It will stop spam for two weeks and then we’ll be stuck with it

The essence of the idea is that any email sent must contain within it a public key to a bitcoin address (which I called the spek address) that hasn’t been flagged as spammy. That bitcoin address must contain a minimum amount of BTC. I suggested the equivalent of a penny. A spammer would therefore have to maintain a very large number of addresses with a penny in them.

As part of the protocol, everyone must have the private key of their own spek address (so they can make digital signatures), so it is true that once a spek address has been flagged as spammy, that money can then be moved to a new address. Possibly this represents a fatal flaw to the spek idea. I think it depends on the level of fees that the miners charge. Currently (in my experience – I may be wrong) there seems to be a minimum fee of 0.0001BTC, which at the current USD rate is around 5c (it’s a little silly quoting this in a blog because it’s bound to change massively in one direction or the other).

So the question becomes how many emails would get through from one spek address before it was flagged as spam and a new spek address required. If that was 100 then the spammer would be paying 5c for every hundred emails sent. If that is insufficient to make it economically non-viable, then the spek idea won’t work.

2) Users of email will not put up with it

This is certainly possible. However my thought on the matter is that email providers would handle this seamlessly so the user need have very little involvement.

3) Microsoft will not put up with it

I think “Google would not put up with it” might fit better here. In any case, I can’t answer for whether they’d put up with it or not. Obviously I think they would, but that doesn’t constitute an argument on my part.

4) The police will not put up with it

Don’t think this is relevant. Though both Sting and Stewart Copeland have privately indicated they think it’s a great idea.

5)  Requires too much cooperation from spammers

Again, I don’t think this is relevant. They wouldn’t have a choice.

6) Requires immediate total cooperation from everybody at once

This is a good argument. My view on it is that this is something that could be phased in gradually. One possibility would be for people to mention the fact that they’re using spek in their email signatures, to get some viral spread of the idea. “I use spek to get rid of spam and phishing. You should too!”, or something.

In the early days of its usage, one would be wise to accept emails that didn’t follow the protocol. Only as general acceptance arose, (if it did), would one then switch to rejecting emails that didn’t conform, and then probably with some sort of workaround for genuine senders who hadn’t adopted the protocol for whatever reason.

I think this area requires further thought – but only after it’s been agreed that the protocol itself would actually work.

7) Many email users cannot afford to lose business or alienate potential employers

This is similar to the previous point, and I think the same responses apply.

8) Lack of centrally controlling authority for email

Don’t think this is relevant. It’s a protocol that individuals could choose to adopt if they wanted.

9) Open relays in foreign countries

Don’t think this is relevant. Please expand if you disagree.

10) Unpopularity of weird new taxes

I think all new taxes are unpopular, not just the weird ones. I don’t think this classifies as a tax. The money in the spek address belongs to the user, who retains its private key.

11) Public reluctance to accept weird new forms of money

Can’t argue against this.

12) Huge existing software investment in SMTP

Unless I’m missing something, this is not relevant. We’re talking about including some extra data inside email messages. The email protocol being used is surely not relevant?

13) Susceptibility of protocols other than SMTP to attack

I don’t know enough about email protocol to answer this. Perhaps somebody else could chip in. I have to say it sounds irrelevant.

14) Willingness of users to install OS patches received by email

Not relevant. There are no OS patches to install.

15) Armies of worm riddled broadband-connected Windows boxes

Again not relevant, true though it may be as an observation.

16) Eternal arms race involved in all filtering approaches

Nothing’s being filtered.

17) Extreme profitability of spam

See answer 1). This could definitely kill the idea. If spam is more profitable than the miners fees, then unless the protocol is amended, it wouldn’t work.

18) Ideas similar to yours are easy to come up with, yet none have ever been shown practical

I thought it was quite hard to come up with! But I can’t argue against the point.

19) Countermeasures must work if phased in gradually

Can you give any concrete examples of what you mean?

20) Sorry dude, but I don’t think it would work.

You’re probably right. But it might.

SPEK – a killer app for Bitcoin – Spam and Phishing Emails Killer

Summary

By requiring every email sender to maintain a bitcoin address with a small balance in it, spam and phishing could become a thing of the past. The amount (value of, say, 1 cent) is never spent, but must exist for any email address that an email is sent from. Spammers using millions of ‘from’ addresses would have to fund millions of small balances.

This is an outline proposal that needs further work. Please feel free to suggest improvements.

Basic Idea

The basic idea is that the sender of an email maintains a nominal balance in a bitcoin address (the “spek” address) set up for specifically for this purpose. The sender retains the private key to the spek address, and should only have to fund it once.

A separate provably unspendable bitcoin address (the “sentinel” address) created from the sender’s address would allow a recipient of email related to that spek address to flag it as spam.

A spammer would be faced with the problem of his sentinel addresses constantly being flagged and becoming useless. The only way to get spam through would be to set up millions of spek addresses, and funding them. This should prove economically non-viable.

Detailed example

We’ll use the usual suspects, Alice and Bob. (The processes described as being performed by them would in reality be carried out by their email providers or email client.)

Suppose Alice wants to send an email to Bob.

Alice has previously set up a randomly generated bitcoin address (spek address) to which she holds the private key.

She has also previously paid a small amount into the spek address, say the equivalent of a penny. All being well she should only ever have to do this once.

Alice writes her email, and then digitally signs some unique element of the email (eg the subject or the time of sending) using the private key of the spek address. She includes that signature and the public key of her spek address at the end of the text of the email, .

Bob receives Alice’s email.

He first confirms that the signature matches the relevant data (ie the subject or time of sending) in the email, using Alice’s public key. This proves that the sender of the email possesses the private key of the public key.

If this test fails, he deletes the email and ignores it. It was not sent by the person claiming to be the sender.

He then generates Alice’s spek address from the public key, and its sentinel address.

He then checks the sentinel address of Alice’s bitcoin address. The sentinel address is a provably unspendable bitcoin address created from Alice’s bitcoin address (see technical details below).

(See below for a discussion of how the sentinel address might work)

If the sentinel address shows clearly that this is a spammy spek address, the email can be rejected.

Bob then looks up the balance of the spek address, and checks that it’s equal to or greater than the agreed threshold (say a penny).

If the balance is insufficient, he can either ignore the email or place it in a spam folder for later review.

If the email makes it through these checks but Bob determines that it actually is spam or a phishing email, Bob can flag the sender’s sentinel address, possibly using a third party service.

Operation of the sentinel address

This piece needs further thought, although I think I have the basic concept right.

Micropayments, as small as 1 satoshi, to the sentinel address could be used to flag that address as having been used in a spam email.

Individual wishing to flag a spek address as a spammer would make micropayment from their own spek address.

A sentinel address could then be assessed based on the characteristics of the address that had made payments to it.

For example if there were several recent payments from spek addresses whose own sentinel accounts were empty, that would be a strong indication that this sender was indeed a spammer.

Note that payments made to sentinel addresses would be permanently lost. See “Practical considerations” for some thoughts about who should actually bear the cost of these micropayments.

How to derive the sentinel address of a spek address

We use the process described on this page, but we replace the value calculated in step 3 (the 24 byte RIPEMD-160 hash) with the first 24 bytes of the SHA256 hash of the spek address string.

ie using the Javascript at bitaddress.org and Chrome’s console:

If the spek address is 1FyfFouKXHbqg2AknTcSRdDQKE4ujt7vGX

> fakeRIPEMD160 = “00” + Crypto.SHA256(“1FyfFouKXHbqg2AknTcSRdDQKE4ujt7vGX”).substring(0, 48)
> checksum = Crypto.SHA256(Crypto.util.hexToBytes(Crypto.SHA256(Crypto.util.hexToBytes(fakeRIPEMD160)))).substring(0, 8);
> Bitcoin.Base58.encode(Crypto.util.hexToBytes(fakeRIPEMD160 + checksum));

This gives a sentinel address of 1GFpUwdgmQT1bRuXjd9pJb94v3MGPSPR5xVmuLH

This address is provably unspendable since there is no way to find out a private key that points to it.

Practical considerations and further research required

1) Alice could perhaps lodge her private key with her email provider, eg gmail, yahoo. Since there’s only a tiny amount of money in it, this does not consitute a risk.

2) Further thought is required into the details of how the sentinel address would work. Ideally it shouldn’t cost an individual to report a spammy spek address. Possibly some non-profit organisation could manage this. Or maybe an autonomous agent funded via charitable donation could recompense individuals who report spam.

3) A point to consider in the sentinel system is that scurrilously marking an innocent party’s email as spam should have no effect. Ideally a number of reports (ie micropayments) from reputable spek addresses would be required to actually flag an address as a spammer.

4) Whilst a penny is not a large amount of money to most people in the developed world, it is important that the poor should not lose access to free email. To this end perhaps a charitable organisation could be set up to ensure that email did not become the exclusive preserve of the better off. Such a charitable organisation could also take the lead in promoting the spek idea. A public figurehead would be useful – perhaps someone like Bill Gates, Paul Graham, or maybe two of the more obvious beneficiaries of bitcoin’s rise, the Winklevoss twins.

5) Adoption. Initially this could be a voluntary protocol, phased in over a couple of years, with a final switch-on date when all major email providers were already offering it.

Improvements

As stated at the beginning, this is just an outline idea. Please feel free to add suggestions in the comments below.

1SPEKXiV6NF9Xg6Ridw2qUtV83T8TRJZZ (donations, if there are any, will be given to some charity or other at some point – I won’t keep them)