Posted by
timothy
on from the to-stem-the-tide dept.
Anon writes: "Although the use of HashCash has been featured before, Adam Back has recently (August 1st) published a paper about it, outlining many other applications for the mechanism. Quite an interesting read. It seems the guys at camram have been working on a standard for use in e-mail too."
More applications?
by
Anonymous Coward
·
· Score: 4, Funny
To prevent spam I ask for the solution of a difficult math problem before I give my e-mail address. I haven't had a date since then.
HashCash software
by
Delta
·
· Score: 2, Insightful
HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.
Does anyone have any good resources on HashCash source code or other things to aid development?
-- Terje Elde
Re:HashCash software
by
Adam+Back
·
· Score: 4, Informative
there is some library and command line tool source available at:
http://www.cypherspace.org/hashcash/source/
also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client).
http://www.cypherspace.org/hashcash/
It can work, and it is actually being used by some newgroups on a trial basis. The reason its not used is because few clients/filters support it. Hopefully this will change with SpamAssassin supporting it, as it is fairly popular. It will create a standard way to get 'around' this filter. See my earliar post on integration into SpamAssassin.
-- I.O.U One Sig.
Anti-Hashcash
by
Animats
·
· Score: 4, Interesting
What a sink for CPU cycles!
The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.
I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with. "When the only tool you have is a market, everything looks like a commodity". Sometimes, the accounting overhead costs more than the thing is worth.
We need a solution to spam, but this isn't it.
There really aren't that many spammers; put fifty people in jail and it will stop.
I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with.
Some of the people from that group are working on the E programming language now if you're interested. Could be used in a similar application as Xanadu.
Sometimes, the accounting overhead costs more than the thing is worth.
Very true. For example, the New York City subway pays as much to pay for the expenses of fare collection as it actually collects in fares. Making the subway free wouldn't hurt the bottom line, except for the fact they'd lose federal matching funds for the fares - so they have to throw money down a hole to get money from the Feds.
Las Vegas local phone calls are free. They probably save money on NOT billing.
Of course, that's all assuming your phone isn't hacked.
-- Just because it CAN be done, doesn't mean it should!
export-a-crypto-system sig
by
abischof
·
· Score: 2
The hashcash proposition is somewhat dangerous
by
hillct
·
· Score: 5, Insightful
I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?
The entire premise seems ridiculous. Granted the system might work in small controlled enviroments where the overall inefficiency it introduces into the network would be limited, but if you read the proposal, you'll see that of course the system wouldn't work at all unless it was adopted on a large scale, so, while it's certainly a novel idea, I don't see how it could possibly succeed.
Re:The hashcash proposition is somewhat dangerous
by
nestler
·
· Score: 4, Insightful
It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?
Yes, because the current system is more dangerous.
Requiring
the solution to a computationally intensive
puzzle is a common technique
in denial-of-service prevention,
especially in protocols where the amount of
computation is already lopsided.
For example, SSL servers are an easily DOSable
target because the server does lots more work
(RSA decryption) during a handshake than
a malicious client does. One solution to this
problem is a protocol modification that requires
the client to answer a "puzzle" of the server's
choosing. This is no problem for a legitimate
client making a few connections, but it keeps
out the guy trying to DOS the server with thousands of connections.
It's the same thing with spam. It's too easy
for a spammer to make mail servers pass around
huge spams to thousands of people on their behalf. But if the mail server required the
spammer to answer a "puzzle" (hashcash) for
each copy of the message sent, that would
make the spammer's life much harder without
making the legitimate mail sender's life that
hard.
Think about mistyping your password at the
telnet prompt. Telnet intentionally waits
for a few seconds before letting you retry
to make it harder to brute force. It doesn't
kill you to wait a few seconds, does it?
It's the same concept.
You are right though that it has to be adopted
on a widespread basis or the spammer just goes
to the relay that doesn't use hashcash.
Re:The hashcash proposition is somewhat dangerous
by
PD
·
· Score: 2
What keyboard has the arrangement of letters so that they spell DVORAK? I've never heard of that keyboard before.
Re:The hashcash proposition is somewhat dangerous
by
sketerpot
·
· Score: 2, Insightful
I don't see the problem, except perhaps on mailing lists. It would take more processing power to send email, so ISPs might have to upgrade some hardware, but in general I think it could work if it were adopted by enough people. And it would prevent mass spamming of gigantic amounts of people. You have a problem with this?
Re:The hashcash proposition is somewhat dangerous
by
Adam+Back
·
· Score: 3, Insightful
The point about introducing inefficiency is to introduce a cost for the sender.
It's like junk faxes: in countries with free local calls, junk faxes are a much bigger problem than they are where local calls cost the caller.
Similarly for being called on cell phones with by marketers. In some countries calling a cell phone is free for the recipient and all costs are on the caller.
So while it is true that hashcash would use some CPU on the client, the amount of CPU used would be small enough to not present a noticeable problem for the sender who sends some sane number of mails per day.
The problem as I see it is deployment, as the first message in the thread "Slow acceptance if ever" puts it. ie If I use a hashcash filter on my received mail then I may lose mail if senders don't follow whatever steps are necessary for them to get their mail to me.
This is what the camram list is about -- making it reasonable for senders to send mail to people using hashcash filters, when sender has no client. For example there is a proposal to require hashcash only on the first mail, subsequent mails would be exempted. There is a simple web page with a java implementation of hashcash.
(The are proposals to deal separately with mailing lists where the recipients wants to receive the mail, and the list has to send lots of mail).
Another approach to reduce the deployment problems is to do it in two phases. In phase 1 hashcash filtering is advisory only (bounce messages on mail having no hashcash if any would just encourage sender to participate but not reject mail; filtering would improve priority of mail, not delete mail without postage); in phase 2 if phase 1 was succesful enough the filters could start bouncing mail without postage.
Will any of these approaches reach sufficient deployment to be useful? I don't know. That's what the camram group are working on.
There are also other applications of hashcash (other than email spam) in combatting DoS which have been succesfully deployed (see the paper).
Re:The hashcash proposition is somewhat dangerous
by
damiangerous
·
· Score: 2
What does is say next to the tab key? QWERTY or DVORAK?
A Dvorak keyboard isn't anamed after its key layout, you know, it's named after a person. Dr August Dvorak. If it were named after its layout you'd have to call it the "quote less than greater than P Y" keyboard.
Re:The hashcash proposition is somewhat dangerous
by
interiot
·
· Score: 2
Indeed. These added inefficiencies are relevant for someone like Amazon.com who sends out thousands of confirmation emails a day, or merely your average mailing list. Sure, there will be ways to explicitely allow specific individuals to send without postage, but yet again, it adds an inconvience to the end user.
Re:The hashcash proposition is somewhat dangerous
by
Nurf
·
· Score: 2
I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?
As an electronic engineer, this concept is very comfortable for me. Though it's more a case of "negative feedback" than inefficiency. Friction-free systems are usually very unstable.
In electronics you usually design a system to respond as fast as possible and then wrap a negative feedback loop around that. The result is a dynamic balance... The system responds well because it is straining to break free, and the feedback holds it to within designed constraints.
Negative feedback is by far the most common element in analog designs - go an look inside any audio amplifier.:-)
Whether this analogy applies to hashcash I don't know. But I do know that I feel nervous when I see a design without some sort of negative feedback in it, to force a dynamic equalibrium.
-- ---
Re:The hashcash proposition is somewhat dangerous
by
shird
·
· Score: 2
You are right though that it has to be adopted on a widespread basis or the spammer just goes to the relay that doesn't use hashcash
Actually, it needn't be adopted on a widespread basis. It can also be used to avoid false positives, as I describe in a later post. The basic idea is, you use it as a way to get around existing filters if you really _need_ to say something 'spammy'. It provides a backdoor which spammers are unable to exploit.
Kind of like a 'password' around the filter, but everyone knows it, and only legitimate users are able to use it. It can also be run on the client end to be used to 'prioitise' mail. If someone like Hotmail were to use it, it would make it possible to 'highlight' messages sent to people with those addresses in a standard way which couldnt be abused.
-- I.O.U One Sig.
Re:The hashcash proposition is somewhat dangerous
by
gorilla
·
· Score: 2
In case anyone cares, the QWERTY layout was designed by Christopher Sholes.
advantages over tarpits?
by
EricHsu
·
· Score: 4, Interesting
Many of the proponents of this idea suggest that the advantage is creating a non-trivial cost for access to resources.
Can someone spell out the advantages this method has over the "tarpit" strategies that some mailers follow? (I.e. each successive access takes longer, so the first access may take 1 sec, the next 2 sec, the next 4 sec, so soon abusers find themselves timing out.)
Is it fair to consider tarpits a special case of hashcash where the non-trivial cost is time waiting applied server-side?
If so, isn't this a less wasteful approach? (Genuine questions on my part.)
Why not just crypt your e-mail?
by
randomErr
·
· Score: 2
In other words your group uses e-mail programs that support the same crypto method(GPG, PGP, BlowFish, ect.).
Anything not crypted, or crypted with a key that is not in your chain goes into a junk basket. The junk basket could then have some rules. That would allow your mum or certain clients, who are still trying figure out how e-mail works, to be fowarded to your In bin.
Adds security and cuts down spam.
-- You say things that offend me and I can deal with it. Can you?
Use useful (SETI?) computations instead?
by
vkg
·
· Score: 2
Why not use a useful computation rather than something useless like hash colissions?
If we're going to have all of this crunch going on to prevent spammers, it ought to achieve something rather than just burn cycles (and energy!) for no good reason.
Why not use a useful computation rather than something useless like hash colissions?
First, SETI's not useful.
But if you DID find something useful, that would defeat the purpose of hashcash entirely! It would mean that there was effectively no cost to producing hashcash, since the creation of it had intrinsic value. So you would be in effect reimbursed for your effort in creating the hashcash, which would remove the cost factor that is supposed to be present.
I'm not a sysadmin, nor an email guru of any sort, so I have to ask the most basic question: Why use SMTP at all? It seems to me, a protocol that is a little more sophistocated, with mandatory digitally signed content (including headers), and rejection of all connections without a certificate, would block all spammers pretty quickly. Generating a certificate is non-trivial and time consuming, and often is a manual process. There's also multiple levels of certificates, from the online-verified only, to the independent 3rd party verified from a trusted certificate authority (human).
However, then you'd need support in servers for the new protocol (probably not too quickly done), and support in clients for the new inbound and outbound protocol. Then users could have the choice of accepting or blocking old SMTP messages, accepting or blocking low-confidence certificates, or blocking specific users, or even blocking users who were authenticated by specific trusted certificate authrities (in case spammers bribed someone for authentication).
I know, this is probably a radical departure from the tried and true SMTP protocol, but servers are the problem, not spammers. Servers should not propagate junk mail, because they shouldn't accept it in the first place. I don't mind receiving mail from a person that I can reply to, but I want to know it's a person, not just an email address they just made up on a free server, or a spoofed reply to.
-- Any connection between your reality and mine is purely coincidental.
Who signs the certificate? I don't want to pay Verisign $200/year just so I can send email. I certainly don't want more spam from Waitrose just because they paid Verisign $200 for a certificate.
Thawte does. For free. As far as I remember, it's an automated system that requires a good deal of info to generate a certificate, and has a higher privilege certificate for people who have been independently stamped, probably like the PGP/GPG web of trust.
The point isn't to make a whitelist, but to exclude anyone who doesn't use a certificate. It would probably then be an ISP service to give you a certificate with every account signup (or let you get your own, or use your previous one if you have one already), so it would be significantly less a barrier to entry for new users. I think it would raise the stakes significantly for spammers, especially since forging a certificate is a legal offense, since signed documents are admissible as evidence, IIRC.
-- Any connection between your reality and mine is purely coincidental.
I can just see it now... spammers hiring script kiddies to write computation mailers to bulk email and DDOS the whole internet, taking over IIS servers and flooding your inbox at the same time.
-- Any connection between your reality and mine is purely coincidental.
I don't think it can do Seti at home, because the server needs to confirm the answer, which would take just as much computation on the server. The question has to be something the server already knows the answer to.
Hash cash? We've had that for years!
by
spacefrog
·
· Score: 2
When I was in school, you could trade hash for most anything.
Oh wait
Integration w/ SpamAssassin
by
shird
·
· Score: 3, Informative
This is also currently being look at being added to SpamAssassin, the idea is;
Its not required, but if you use it, you can avoid being flagged by the filter. In effect it provides a backdoor around the filter, without the potential for abuse by spammers.
I have also being trying to get Microsoft to add this to Hotmail, as a means to 'highlight' messages which have valid tokens to avoid accidental deletion. If anyone has a good contact address for them, please reach me at;
shird:at: dstc.edu.au
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
Re:Webmail is the sore thumb
by
shird
·
· Score: 2
I thought I replied to this already, but anyway. Its also possible to download a client and run it on your machine seperate of the mail 'client', offline and overnight if you wish. Also, if you combine it with a filter, it wouldn't actually be required, just used to bypass filters if your message looks like it will be flagged.
-- I.O.U One Sig.
Re:Webmail is the sore thumb
by
shird
·
· Score: 2
Overnight! How many mails are you sending?!
The tokens can be generated in advance, so you can generate a whole bunch when your computer isn't doing anything, like at night or just in spare CPU cycles, then your client can use this store of tokens whenever it needs.
You are right, after I posted this I realized that it could work if the algorithim is something where the answer can easily be confirmed. For instance factoring a large number, the answer can be easily confirmed but the server did not need to know it ahead of time.
In fact after reading the hashcash docs, it appears that it is actually the client that picks the "question" and also calculates the "answer" at the same time. The server only checks to make sure the same question is not used more than once. So anyway there is no way for the server to know the answer ahead of time, it does not even know the question.
Slashdot Mirror
Isn't that what you take with you to the coffee shops in Amsterdam? :)
Michael Loves Me!
To prevent spam I ask for the solution of a difficult math problem before I give my e-mail address. I haven't had a date since then.
HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.
Does anyone have any good resources on HashCash source code or other things to aid development?
Terje Elde
This was first proposed in 1997. If it can work, where is it?
I looked into the abyss, and the abyss looked into me--and we both winked.
The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.
I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with. "When the only tool you have is a market, everything looks like a commodity". Sometimes, the accounting overhead costs more than the thing is worth.
We need a solution to spam, but this isn't it. There really aren't that many spammers; put fifty people in jail and it will stop.
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]ds
Alex Bischoff
HTML/CSS coder for hire
I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?
The entire premise seems ridiculous. Granted the system might work in small controlled enviroments where the overall inefficiency it introduces into the network would be limited, but if you read the proposal, you'll see that of course the system wouldn't work at all unless it was adopted on a large scale, so, while it's certainly a novel idea, I don't see how it could possibly succeed.
--CTH
--Got Lists? | Top 95 Star Wars Line
Can someone spell out the advantages this method has over the "tarpit" strategies that some mailers follow? (I.e. each successive access takes longer, so the first access may take 1 sec, the next 2 sec, the next 4 sec, so soon abusers find themselves timing out.)
Is it fair to consider tarpits a special case of hashcash where the non-trivial cost is time waiting applied server-side?
If so, isn't this a less wasteful approach? (Genuine questions on my part.)
In other words your group uses e-mail programs that support the same crypto method(GPG, PGP, BlowFish, ect.).
Anything not crypted, or crypted with a key that is not in your chain goes into a junk basket. The junk basket could then have some rules. That would allow your mum or certain clients, who are still trying figure out how e-mail works, to be fowarded to your In bin.
Adds security and cuts down spam.
You say things that offend me and I can deal with it. Can you?
Why not use a useful computation rather than something useless like hash colissions?
If we're going to have all of this crunch going on to prevent spammers, it ought to achieve something rather than just burn cycles (and energy!) for no good reason.
Hexayurt - open source refugee shelter,
I'm not a sysadmin, nor an email guru of any sort, so I have to ask the most basic question: Why use SMTP at all? It seems to me, a protocol that is a little more sophistocated, with mandatory digitally signed content (including headers), and rejection of all connections without a certificate, would block all spammers pretty quickly. Generating a certificate is non-trivial and time consuming, and often is a manual process. There's also multiple levels of certificates, from the online-verified only, to the independent 3rd party verified from a trusted certificate authority (human).
However, then you'd need support in servers for the new protocol (probably not too quickly done), and support in clients for the new inbound and outbound protocol. Then users could have the choice of accepting or blocking old SMTP messages, accepting or blocking low-confidence certificates, or blocking specific users, or even blocking users who were authenticated by specific trusted certificate authrities (in case spammers bribed someone for authentication).
I know, this is probably a radical departure from the tried and true SMTP protocol, but servers are the problem, not spammers. Servers should not propagate junk mail, because they shouldn't accept it in the first place. I don't mind receiving mail from a person that I can reply to, but I want to know it's a person, not just an email address they just made up on a free server, or a spoofed reply to.
Any connection between your reality and mine is purely coincidental.
I can just see it now... spammers hiring script kiddies to write computation mailers to bulk email and DDOS the whole internet, taking over IIS servers and flooding your inbox at the same time.
Any connection between your reality and mine is purely coincidental.
I don't think it can do Seti at home, because the server needs to confirm the answer, which would take just as much computation on the server. The question has to be something the server already knows the answer to.
When I was in school, you could trade hash for most anything.
Oh wait
This is also currently being look at being added to SpamAssassin, the idea is;
:at: dstc.edu.au
Its not required, but if you use it, you can avoid being flagged by the filter. In effect it provides a backdoor around the filter, without the potential for abuse by spammers.
I have also being trying to get Microsoft to add this to Hotmail, as a means to 'highlight' messages which have valid tokens to avoid accidental deletion. If anyone has a good contact address for them, please reach me at;
shird
I.O.U One Sig.
I happen to think the PGP identifiers are sexy.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
I thought I replied to this already, but anyway. Its also possible to download a client and run it on your machine seperate of the mail 'client', offline and overnight if you wish. Also, if you combine it with a filter, it wouldn't actually be required, just used to bypass filters if your message looks like it will be flagged.
I.O.U One Sig.
Overnight! How many mails are you sending?!
The tokens can be generated in advance, so you can generate a whole bunch when your computer isn't doing anything, like at night or just in spare CPU cycles, then your client can use this store of tokens whenever it needs.
I.O.U One Sig.
In fact after reading the hashcash docs, it appears that it is actually the client that picks the "question" and also calculates the "answer" at the same time. The server only checks to make sure the same question is not used more than once. So anyway there is no way for the server to know the answer ahead of time, it does not even know the question.