Slashdot Mirror

http://www.cypherspace.org/ada...

So you've never seen Python code I take it, because there's no similarity between the languages. Effectively none.

One needs braces and semicolons, the other uses space, one allows in-line regex, the other doesn't, the one can have RSA implemented like this:

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

The other looks like this:
#!/usr/bin/python
from sys import*
from string import*
a=argv;[s,p,q]=filter(lambda x:x[:1]!='-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x>8*i&255),range(o-1,-1,-1)))

Even super-short highly optimized Python with semicolons for whitespace removal looks nothing like perl.

All due credit to http://www.cypherspace.org/rsa... for sources.

You miss the point. Nobody who wants a good gun wants a 3D-printed gun in 2016 (check back in a decade). The issue is always the government oppression that arises from such happenings. Free Speech still falls under 'stuff that matters'. Maybe you weren't around for CryptoWar I when we illegally wore T-shirts with the RSA algorithm on it to trade shows.

http://www.cypherspace.org/ada...

We've seen this kind of thing before, but it was even more ridiculous when the U.S. government tried to claim that it was illegal to export code that implemented the RSA algorithm.

Those not familiar might be interested in this link...

RSA in 3 lines of perl

Give me "unsophisticated" and/or heavily commented code, thank you.

http://www.cypherspace.org/ada...

I'll just leave this here.

I found this lying around on the internet. It looks like at least some of the people at the NSA know damned well that what they're doing is wrong, but don't seem to care (or didn't understand that what is described in 1984 is bad): I'm making the assumption that this is true.

for those gen-Y and gen-Z people, this is what he is talking about.

http://www.cypherspace.org/adam/uk-shirt.html

BTW: people did go to jail for wearing these things!

that no matter how hard they try to 'break' someones ability to do something, those someones will quickly circumvent that 'break' in the system, if they wish to. Makes me flash back to the days of the T-shirts with the DeCSS code written right upon it, and all the controversy about them. Also the tshirts that printed with the PGP (probably also gpg)code that were considered munitions by the US government. Makes me chuckle, makes me sad. It's a mad world, to quote Tears for Fears (though I think I adore Jules version more). There are plenty of other examples, from recording a videotape to another, using analog methods (which to me seems one of the easiest and first methods to break most digital methods of 'breakage', though the quality does suffer, in many peoples opinions.)
I really don't forsee a day when people will quite hacking the 'breaks' in systems. Isn't that what they are there for in the first place? Why not spend all those research dollars into the improvement of the platform itself? Or finding new exciting artists? Etc...

Emacs has had a spook function since at least the 80s.

You could get T-shirts with an encryption program that were technically classed as munitions. Being perl, it looked like it had been run on its own source.

Shame I can't find it now, there was also picture going round teh tubes of it written on a chick's butt.

RSA in five lines of perl. (Well, it also uses dc..)

The next stage is to flood the internet with random data.

Some of us have been doing that for years.

And don't forget my favorite Perl export here.

That's a pretty good idea. The source code it self is ludicrously short (about 9 printed pages), so it would amount to something more like a pamphlet than a book -- but it proves the point nicely.

I wonder whether it could be reduced even further in size through a concerted effort like the Export-a-crypto perl script that ended up printed on t-shirts. It would be sweet if we could get Cafe Press a DMCA takedown notice on crypto grounds...

I don't know enough to say who's right, but here's Phil Zimmermann's acount of PGP history. Also check out Adam Back's PGP timeline, which he warns is probably inaccurate. Microtimes columnist's recollections of PGP history.

Ross Anderson of the Computer Security Group at Cambridge University wrote a paper called the Eternity Service. It has had a few different attempts at implementation, as well as some reworks in terms of design. The primary difference is in the Eternity Service - you had no idea what data you had, nor did you have access to the keys. This new concept/design seems to provide more control/granualirity for the user. Given the new proposed encryption laws in the UK, I'm not sure this is a good idea.

Exactly. No matter how vigorously any software company may deny it, without access to the full and complete source code, one cannot verify the integrity of the system. The threat is real, and more pervasive than you may think, especially post-9/11 -- people I know personally have been approached to put backdoors into their companies' applications, a la Lotus Notes. And the NSA was not above using both rewards and threats to make it happen.

The frightening thing is that in the past, the NSA has apparently been interested only in export versions of software (spying on other governments, I would suspect); after 9/11 they are also interested in spying on us.

PGP was available to protect sensitive text since at least 1991. I have no doubt that some variant of it, or perhaps an entirely new encryption scheme, will be developed for VoIP phones in response to this.

If nothing else, the business world will probably demand it.

Keep the peace(es).

I was under the impression that PGP was pretty widely excepted and closed source. I know there is an OpenPGP, but it's not the original. I may be wrong, but I though PGP was pretty popular. Here is a page describing the history of PGP and the controversy. As to longer encryption algorithms, I think the NSA will have quantum computers before the general public. They may have them now or it could still be 10 years away. That would eat through current encryption pretty fast. I wish I could get my email contacts to trade keys...I'm still trying to get them to stop sending me stories via the "send to a friend" box on web sites.

More than likely, they route all communications and scan them, flagging suspicious words like "bomb" or "Al Qaeda"

Sure they can. Check your congress' budget book and try to look for those 'missing' numbers. NSA is known to try to implant backdoors inside commercial algorithms or prodcuts, with certain '3rd party' experts coming to your office and asking to help you 'strenghten' your algorithm. For a real life example of Cryto AG surrendering: Look here or Lotus notes . It just makes it harder, not impossible. Remember, PGP/SSL/GnuPG is part of the solution to a secure communication channel. If your Private key is compromised (by any reason), you are toast.

That would be the modern version of the emacs spook mode. Except the idea is to add a little spookiness to ALL conversations, making global keyword matching useless.

Contrary to another reply, the FBI doesn't need to prove squat to a judge anymore. The patriot act, and other related below-the-radar legislation, has things to the point where they pretty much just write a note to themselves saying, "this is terrorist related" -- but if they feel like being more official they can take it to a FISA judge, who have rubberstamped every single wiretap request ever made of them. Plus, if they aren't planning on using the info in court - you know a little COINTELPRO type action or worse, then they don't even have to go through any charade at all.

I've posted it once and I'll keep posting it until people actually listen.

The right way to make email "cost" something to mass mailers but not cost end-users anything is HashCash.

See http://www.cypherspace.org/~adam/hashcash/ for more info.

Next, please. That technology involving random numbers+statistics looked far more promising....

Do you mean Hashcash? Keep in mind it does not provide any monetary or reusable value to those that accept Hashcash, it only proves that a "purchaser" has spent an amount of time doing CPU work. The purpose is to artificially increase scarcity of a service, not to compensate service providers. Useful, but a completely different purpose than BitPass.

There is a perfectly good technical solution to the spam problem: HashCash. Can you please stop advocating that the government stick its finger up my ass even farther? I mean, if you like that, more power to you, but as for me...

Pay per e-mail sucks because it can't account for foreign exchange disparities. $1 to send 100 e-mails is a whole lot cheaper for an average income earner in the US than R7 is here (ZA). The countries that will be the worst affected are the poorest 3rd world countries, that most need the benefit of cheap Internet access to improve their economic condition.

Pay per email has promise, but if it is limited to actual currencies, it is destined to fail (for all the reasons you've enumerated.) The other way to force the sender to pay to send the message is to force them to expend a certain amount of CPU cycles before sending the message. It's a negligible cost (in time) to someone sending a few messages, but to someone sending millions of SPAM messages, it would bring the cost of sending those messages above the profits they can generate from sending those messages.

What's needed is an extension to SMTP which uses HashCash or something like it to ensure that the sender has to do a certain amount of work to send the message. If all the large MTAs began to support such an extension and the larger ISPs (err...largest ISP...*cough*AOL*cough*) began to require it to send messages to their users and through their servers, SPAM would end up being almost non-existant and the anonymous nature of email would be preserved.

This idea is way too much work and won't even solve the spam problem. A better approach would be widespread deployment of something like HashCash that makes sending large amounts of unexpected E-mail prohibitively expensive, but doesn't do the same to mailing lists or to individual unexpected messages.

I'm suprised noone has brought up Hash Cash yet as a technical means to stop spam:

"Hash cash is payment in burnt CPU cycles by calculating n-bit partial hash collisions on chosen texts.

The idea of using partial hashes is that they can be made arbitrarily expensive to compute (by choosing the desired number of bits of collision), and yet can be verified instantly. This can be used as the basis for an ecash system measured in burnt CPU cycles. Such cash systems can be used to throttle systematic abuses of un-metered internet resources."

Now we just need a decent RFC for mail transfer!

But after the message is recieved, and the connection dropped, have another mechanism connect to the senders server (from the MX in DNS), asking if it sent this MD5SUM(message)

Hmm, now you might be onto something...

How about a built-in Razor-like/DNSBL-like check?

Prior to sending the message, the sender calculates a md5sum (or maybe something like Hash Cash) of the message body. This is sent prior to the DATA phase (eg, MD5SUM: blah, 250 OK, DATA, etc), and is the md5sum of the message. If the message doesn't match the md5sum provided, reject the message. But we can also do a Razor-like check (or DNSBL-like check) on the md5sum to see if it is a known, blacklisted message sum. This way, if you know you don't want the message, you reject the connection before the sender has a chance to send you the entire body and headers of the message. Hopefully, this will add a slight cost to the sender as well (but it could adversely affect a server receiving many messages as well).

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received.

Maybe I'm just a bit daft, but I think people are seriously overthinking the whole SPAM prevention issue. SPAM could be virtually eliminated with one simple measure implemented by mail servers...sleep.

Yep, that's right, the sleep function. At some point in the SMTP process (after mail from, or before data), the mail server should sleep for 2-3 seconds. To the average user, this is just a 2 or 3 second wait while their message is being sent (no big deal). But to a SPAMer sending 1,000,000 messages, this adds 2-3 million seconds to the send time (approx 3 weeks). If we make sending 1,000,000 message a non-starter for any individual user (Big ISPs could white list each other), SPAM would virtually disappear.

Oh, and if you need a whiz-bang techie solution, you could use HashCash instead of sleep (though it would have to be part of a new protocol).

It looks like the problem is increasingly one of messages that are not spam, but get blocked by filters or by trigger-happy pressing of the 'D' key. Since no filter and no human can ever be entirely accurate at detecting what is spam given only a few seconds to look at each message, and the spam being sent is evolving to look more like genuine messages at a quick glance, this problem will only get worse.

What's needed is some way to mark messages as 'definitely not spam' so that filters can ignore them. Some have used PGP signatures for this in the past, but I'm getting an increasing amount of PGP-signed spam. The trouble is that generating a PGP signature is not costly for the spammer.

However a system like Hash Cash could work, because it costs a few seconds of CPU time per message to mark it, making the system unusable by spammers who need to send hundreds of thousands of messages to break even. A message with the right amount of postage attached could be let through by filters; in the long run it would be better for mail user agents to do the filtering themselves based on a postage rate set by the user, but right now it would have to be done on the server with a fixed postage rate (perhaps equivalent to 5 seconds of CPU time on a current low-end PC).

I'm reminded of when some in the government wanted to prohibit public-key crypto, and Paul Zimmerman (1) created PGP in order to free the information/ability.

Does anyone know how to go about recreating some of this work for public use?

Let's let the cat out of the bag before the government ties it shut.

(1) See http://www.cypherspace.org/~adam/timeline/ for details.

They could have a dual system: send challenges normally, but if a message has enough Hash Cash postage paid then no challenge is needed. This would let automated mailings get through if the sender was prepared to spend some amount of CPU time. Presumably the company with whom you have a business relationship would be willing to spend ten seconds of their server's CPU time to send you a message, but a spammer would not.

Of course it is no good if the spammers can set up automated systems to respond to the challenge. There are only two ways around this:

- Make the challenge 'AI-complete', that is, to give a correct answer you must be a thinking human being and not a computer. But then how can the other end check that the answer is correct? Having humans generate a fixed number of questions and provide sample answers also isn't going to work, since spammers will learn the correct answers. You need a way to generate an unlimited number of questions and to mark the answers automatically, and clearly this can't be done if the questions are intended to be too hard for a computer.

- Make the response computationally burdensome, so a computer can do it but only at the cost of some CPU power (so large bulk mailings would be impractical). This is what Hash Cash and similar systems suggest.

It looks like Earthlink's system will rely on sending pictures you have to look at. Apart from the practical problems of clogging the wires with image files, I worry about OCR potential. The examples of this stuff I've seen on Yahoo, where you have to type in a number shown in a partially 'obscured' image, wouldn't have been difficult to develop OCR software for if you were so minded.

There's also the question of the spammer taking the challenge and sending it out to some other user. That user, by now used to replying to challenges from Earthlink and other addresses, will respond to the question and send the correct answer back to the spammer. D'oh!

Why not use HashCash or some other proof-of-work-based system? At least then I wouldn't be forking more of my money over to Uncle Sam for some transaction he has absolutely nothing to do with.

SMTP spam can be fixed with something called Hash Cash. Is that idea going anywhere at all? Has anyone written an RFC and submitted it to the IETF? I think that this can be rolled out in a way that doesn't break the existing mail system during the migration of the world to the new system.

Yes they will, they just won't pay with money. People will be more than happy to pay with a resource that they are pretty much wasting already...CPU cycles. Ask them to pay with CPU cycles and I don't think anyone will object. I've posted this link a few times, so one more won't hurt. HashCash is a scheme that allows a computer to easily and quickly force another computer to burn a certain amount of CPU cycles before continuing.

Take the case of SPAM. For most of us, a HashCash solution would result in our computers pausing for a second or two before sending out the message. For a SPAMer sending out 1,000,000 emails, the process would take 1,000,000 seconds (extremely ineffective) or requiring the SPAMer to purchase a machine with much more processing power (bringing the cost of sending SPAM above the threshold at which it is profitable).

I'm not sure why this type of solution has been almost completely ignored as a means of fighting SPAM. If integrated properly into SMTP and the major MTA/MUAs, it would be seamless to the end user and pretty much end SPAM as we know it.

http://www.cypherspace.org/~adam/hashcash/

The real problem with spam is the economics: it costs next to nothing to send a message, the only real cost (time) is borne by the recipient. Fix that problem and spam will go away. It doesn't need legislation, which in any case could apply in just one jurisdiction.

A system like Hash Cash could solve the problem. The most popular free mail clients could start including hash-cash postage with each sent message, and then in a couple of years' time start to drop incoming messages that don't have postage paid. AOL could include hash cash in their mail client easily. *Easily*. That spam-detection centre they run is not cheap. Even Microsoft would add hash cash to Outlook, Outlook Express and Hotmail, since it's another encouragement to upgrade to a new Outlook release (which of course requires a new Windows version).

Getting the whole world to upgrade its mail clients is a hard task, but getting every government in the world to pass anti-spam laws and enforce them is much harder. Goodness knows it's bad enough trying to get _one_ legislature to take a sane view on anything technology-related.

I think HashCash does a much better job of moving the onus to the sender. It requires that the mail server sending the message burns a certain amount of CPU cycles. For messages sent to one or two recipients, the computations necessary to send the message are small and unobtrusive. For SPAM messages sent to a couple of hundred thousand people, the necessary CPU power to complete the calculations would be more costly than the revenue that the SPAM would generate.

It also has the advantage that it can be implemented into the SMTP protocol in such a way that individual admins could decide whether they only want to accept HashCashed messages. ISPs could decide to whitelist the servers they know are not open relays and have effective AUPs (other ISPs) so that they don't have to burn CPU cycles on their mail servers unnecessarily.

See for example hashcash and camram

On the same note, if the payment is made between the sending and receiving ISPs, as well as the traditional mail sender and sending ISP, then the whole "hey, we don't charge anything" argument is gone, as the ISP will have no alternative but to pay the ISP they are sending mail to. I mean they wouldn't have to charge the mail sender, but if it was going to strain the sending ISP's hardware, then it all works out.

The whole idea of HashCash (I assume there's plenty of other alternatives, I just saw this one listed here not long ago) is that the work of the CPU makes it economically unviable to send that number of emails. I mean even if it "costs" just 1 second to send an email, that limits you to 86400 emails every 24 hours. A lot less than the millions we hear the spammers bragging about.

Also, as the receiver gets to set the "cost" of the email, as the processing power of the sender gets larger, the sender can just up the "cost".

Even if the original sender doesn't have to negotiate a "cost" with their ISP, this sees a lot of advantage, as the economies of scale of the bulk mailing are lost when it takes you (well, the ISP) weeks to send out the same number of emails you could do before in a day. Your market is significantly reduced.

The beauty of all of this, I suppose, is that ISPs could integrate this system without the end user having to change anything on their side. All they would "notice" is that it took another couple of seconds for the mail to get to whoever they sent it to. And if an ISP's mail system refuses to "pay" for sending the mail on, then the receiver could just bail down to only accepting one or two a minute. Even that shouldn't affect the user that much. If you're e-mailing to all your friends, it might take a few hours for them all to get it, but only if they're all on the same mail server.

Through my own travails with SPAM to my personal account, I've come to the basic conclusion that filtering out SPAM is a sisyphean task. No matter how good we make our filters, determined SPAMers will find a way through those filters. Blacklisting of open relays helps, really only punishes careless sysadmins, not the SPAMers who victimize them.

I see much more promise in technologies like HashCash which force sending machines to burn CPU cycles in order to send their message. My question to you is, are you aware of this type of technology? Do you think it would be effective? And what do you think it would take to get such a technology deployed (standardization, ISP acceptance, MTA/MUA integration, etc)?

You can play around with HashCash. I think many free MUAs support it (including Gnus).

The idea of using CPU cycles as payment is not new, check out Hash Cash.

google hashcash. I think it's a great idea.

You're thinking of HashCash.

The one that I've heard talked about that seems most promising is to embed work requests into the SMTP protocol.

Lots of server protocols prevent attacks by requesting a cookie before they do anything difficult or resource-consuming. Besides security, that's useful for basic reliability - it makes sure the IP routes are all working, the client can reach the server, the server's working, and the server can reach the client, before either side does any real work. Most exceptions to this are simple protocols like DNS that don't require any state or much work and would do more work building the connection than sending the real data, and things like NFS which have some reason for the client to trust the server's availability before sending big packets and which make sure that retries with the same data are ok.

Some of the crypto protocols, such as Photuris, do a cookie handshake first, because the first "real" step of the protocol comsumes lots of server CPU, and they'd be vulnerable to denial-of-service attacks otherwise. In this case, the attack is a forged-request attack on an unsuspecting client, but the server is still the only one that can provide any protection. Either way, the client firsts requests a cookie from the server, and the requests for real work need to include the cookie, or the cookie modified in a way that clearly indicates it was received.

A variation on cookies is to make the client perform non-trivial amounts of work using the cookie, which the server can verify quickly - this lets the server limit the rate of requests, and means an successful attacker needs lots more resources than the server. Hashcash is the canonical one - the client has to use brute-force search to find a string containing the cookie that has a hash value starting with a specified N bits, and the server can verify the hash quickly. This defense can be made stronger by including the sender's identification and a timestamp in the cookie string, making it harder to replay. While it's not possible to tune hashcash CPU consumption precisely (since different machines are different speeds, and the attacker may have a Beowulf cluster of Crays or a bunch of zombies to do calculations), the server can adjust the rate of requests by adjusting the hash length as needed. In addition to fullscale cookie-based hashcash, it's sometimes adequate to do a simple userid-and-timestamp version, or userid-and-counter, so the attacker has to do some work, e.g. burn a second of CPU time for every 2KB of response for a modem user, or 10KB for an online user, to prevent swamping.

In this environment, though, anything that requires client upgrades won't fly; you're stuck with upgrades to servers (tough enough) and handshakes that use the existing user interface.
Modifying the server to limit the number of responses per second for a given client (or of big responses) is probably a good start - it doesn't solve all the problems, and the attacker may be able to forge a stream of requests that prevents the victim from doing legitimate queries, but it protects the network connections. Another approach would be to do something password-like - the user queries for a password, or chooses a password, and has to use it to get any big queries, or more than N big queries.