December 2003 - cypherpunks-legacy

Re: First known purchase of physical goods with cyberbucks
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:39 PM 8/17/95, Marcel van der Peijl wrote: >> Anyway, if anyone knows of an earlier transaction of cyberbucks for physical >> goods than this (at 15:00 GMT 17th August 1995), then please let me know. > >As far as I know, the first transaction took place when I (while >testing) bought a postcard from GlobalX, the first ecash store to >open besides our own (and mine). It is stored in the 'DigiCash >museum' next to early prototypes of all kinds of smartcards, >emulators, wallets etc. > >This must have been around October last year (or August? Can't make >out the postmark). Hundreds of cards were shipped by several shops, >and stickers, lotteries, etc. Check the 'physical objects' section >on http://www.digicash.com/shops/categorical.html > >Maybe you should restrict the 'first known' claim to 'first known >purchase of physical goods with cyberbucks traded at the ECM'. > >Sorry! Also, there are other potential claims for this sort of thing. Based on varying extents to which the "electronic money" is really secure, is cryptographically interesting, etc. For example, more than two years ago on this list (I think it was spring of '93, but it could've been spring of '94) there were a flurry of transactions involving the "MagicMoney" and "TackyTokens" of Pr0ductCypher and others. I recall Black Unicorn and others talking about transactional exchanges involving sixpacks of beer or soft drinks. I could check my archives, but you get the point. And before that, there were "HExmarks" being used on the Extropians list. There was a nominal conversion rate to real dollars, and at the time I left that list, I had more HExmarks than anyone else. And dozens of token-based systems, coupons, LETS systems, etc. Not to mention the various commercial smartcards and "e money" systems. Granted, most of these are not "Chaumian," which is what most of us think of us as digital cash. Claiming credit for being first is a tough issue. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

The Official Cypherpunks Screen Saver?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:11 PM 8/17/95, Jim Gillogly wrote: >I would hazard a guess that 90% of the compute cycles in the world are used >running screen savers... this gives a <lot> of slack for people who would >like to harness them to perform productive work like making points about >the strength of security. It would really be cool to have a screen saver that did useful work while displaying pretty pictures. Imagine a screen saver, maybe with code modules running in "After Dark," that updates the screen with keys tried...could be a nice demonstration of bignums in crypto, etc. Every now and then the user would get lucky and alarms would go off... (Details: getting the modules to automatically divvy-up keyspace...or maybe just let user pick his own key, or from a list, or whatever. A la the "Chinese lottery" keycracking scheme, where set-top cable boxes (containing computers) crunch on keys and try to match to signals sent over the air...Schneier may have something on this in his book.) Just a thought. The "Official Cypherpunks Screen Saver"? I'd rather have this running on my Mac than have a t-shirt. --Tim May (Berkeley Systems, makers of "After Dark" for Macs and Windows, supports third-party modules. Maybe the "Flying Toasters" could swoop down, pick up a "key" laying on the "ground" and proceed to munch on it...the mind boggles.) ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: First known ... (stop this thread please)
by Marcel van der Peijl 17 Dec '03

17 Dec '03

> Also, there are other potential claims for this sort of thing. Based on > varying extents to which the "electronic money" is really secure, is > cryptographically interesting, etc. Sorry, I think we should kill this thread while we're still on top of it. The discussion was CyberBucks, not electronic payments or anything like that. I _KNOW_ what the first transaction was, since I made it, I saw it at the bank, I received the goods, and got an email from the sender saying it was the first transaction. I do not wish to take claim for any of that other stuff, whether it is Chaumian or not. No doubt somebody traded some baseball cards for a few bits somewhere back in the fifties. Let's not dig up any other dead bodies. My claim (which was only to show the incorrectness of the other) is a very restrictive one, and is only for the CyberBucks trading. // Marcel van der Peijl, DigiCash bv, http://www.digicash.com/~bigmac/ // The hottest instruction on a P90? JMP $ @ 2.633A or 52C (with fan)

1 0

Cost to Crack Keys
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Tim May <tcmay(a)got.net> writes: > >Hmm, I don't know about anyone else around here, but my workstation is > >idle 99% of the time. I could almost certainly get access to all the spare > >CPU cycles on 120 workstations for free, and I suspect that a lot of > >people (particularly hackers) could do so as well. There's no need to > >spend $ 10,000 on renting them. > > But, Mark, estimates of the cost to crack a key _must_ be based on market > prices, not on opportunistic access to machines. Such access is good for > occasional, or one-shot, deals, but not for routine use. > > For example, one doesn't say "Hey, I don't see how Hertz can charge $40 a > day to rent a car...my friend lets me use his for free." > [...] > "Standard accounting practices" dictate the way to estimate production costs. Agreed. *But* the real cost to a particular organisation, is subsidised by the amount of idle compute cycles they have. You can't take this into account very easily or accurately for a general figure, where raw $ are probably the best figure. For instance I know someone who works for a large UK newspaper (he's admin for their unix workstations), and he says there are acres of RS6000s just sitting there idling most of the time. They are used for document preparation only (what a waste all that lovely silicon just burning cylces, and being occasionally used as a glorified word processor). Anyway point being to that particular organisation, if they for some reason (I dunno but say a big scoop - they need to nefariously break something to get the low down on a politician - unofficially of course), their real cost is quite a bit lower than the raw $, perhaps 0 cost even if they can wait long enough for their impromptu farm to do the job. This doesn't really affect the raw $ cost as such, people just need to estimate the amount of wasted $ equivalent of idle compute they already have in their personal calculations. It would sound better if various news papers would care to print something along the lines of "with idle compute powers as many typical organisations have in abundance". Papers printing high sounding $ figures is though technically accurate (perhaps not too sure about the accuracy), mis-leading to general public who probably don't realise that there is a few $100 tho of idle compute lying around in the accounts department already! In summary, yes but it doesn't sound as good, and folks don't equate idle CPU to $ intuitively. Adam -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365

1 0

Re: Breaking DES anyone? (was: Breaking RC4-40 for less)
by Hal 17 Dec '03

17 Dec '03

> From: aba(a)dcs.exeter.ac.uk > Another approach is to do lots of keys simultaneously - so you set up > this distributed effort which is continually re-sweeping the 40 bit > keyspace, say every couple of days or whatever. You can sweep for > more than one key at once at very low incremental cost, an extra key > costs close to nothing. So say you are searching for 1000 keys at > once - a dragnet approach - well keys just pop out at random as they > are hit, maybe straight away maybe at worst case the sweeping > roll-over time, but on average a key will fall out every 3 minutes. I don't see how you can sweep for more than one key at once at low cost. Because of the salt, every possible SSL encrypted message has to be swept independently. You can't sweep for two messages' keys at once because the input to the MD5 is different even for the same 40-bit key. If digital cash in micro amounts became practical, people could be paid to let the "idle cycles" on their computers be used for this kind of highly parallel application. (Some people have speculated that graphics rendering would be another suitable choice.) It would be interesting to see what the market price of cycles became in such an environment. That would give a better benchmark for the cost to break keys. Hal

1 0

Re: SSL challenge -- broken !
by Hal 17 Dec '03

17 Dec '03

I can see three ways in which RC4-40 is weaker now than it was when it was approved for "fast track" export approval. First, of course, computers get faster every year. So any fixed cipher becomes relatively weaker as time goes on. Second, until earlier this year RC4 was secret. Then it was posted anonymously to the cypherpunks list and later to sci.crypt. Before that time, only a much smaller number of people would have been in a position to launch an exhaustive search attack. But now that the source is public, virtually anyone can try to crack it. So this is really a very significant loss of security. It also illustrates the difficulty in keeping secrets which will occur due to the kind of technology we advocate. Third, there is much more interest now in actually doing massively parallel encryption attacks. The RSA-129 project got a lot of publicity, and it was followed by the attack on the "Blacknet" 384 bit PGP key by a small private group earlier this year. People are aware now of how easy it is to use parallelism in this kind of work, and with the software Adam Back has worked on this could become even more popular in the future. So all this talk about "6,000 MIPS years" will not be as impressive if any moderately sized hacker group can put that much computing power together in a few days. With these changes, RC4-40 has lost a significant amount of the cryptographic strength it may have had a year or two ago. It is certainly time for the exportable key size to be expanded. Hal

1 0

Strong encryption for credit cards only
by Hal 17 Dec '03

17 Dec '03

In response to the SSL break, Netscape has said they are working on improved encryption specifically for credit card numbers. This would use 56 bit keys, presumably DES. I got this from the SJ Mercury News online, <URL:http://www.sjmercury.com/nav.htm>. While we can applaud any measure to increase user privacy and security, it will be unfortunate if this enhanced encryption, which will apparently be limited strictly to credit card information in order to get export approval, weakens support for efforts to allow expanded export approval of all sorts of encryption. There are many aspects to privacy beyond credit card numbers. The bottom line remains that overseas companies are able to put stronger encryption in their products than American companies can in their export versions. We need to keep offering good arguments for why users will need strong encryption for more than their credit card info. If the message gets out that this new measure solves the security problems on the internet then that will be a big loss for our goals. Hal

1 0

Silly technical question from a non-technical person
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm be piceing together things on this list that I have only a passing understanding of (at a code level). If it costs $10,000 to crack one 40-bit key (putting aside whether we agree on that price or not), could not the software be designed in such a manner that it is able to check, say, 10,000 keys at the same time? Ie, it computes a key, and then checks it against the array of data to see if it fits any of them, and then goes on to the next one. Maybe that would be an interesting test. Randomly compute say 10,000 sessions and they try to crack them all at the same time. Theoretically, it would reduce that $10,000/crack cost dramatically. Of course, I could very well be wrong.... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMDOByjokqlyVGmCFAQHFeAP9Hi9rXt1Ij4+nXISXMdfQL7TglB5T0p5P o80KP3PExZ7BqPVrLK9at831SOOVBIN2qzkFcLo7VTOfsrtc95Oyit6Kkk6+PBQQ 4dmuTjbBtRTFi92a4r5RAIXBlLYaATGSZGI3UUSE4m/PoeOWwAhjl/sweu/g/1Q2 ZsRCz9wefR4= =HlUL -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N++++ o+ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++ e++ h r-- y++** ------END GEEK CODE BLOCK------

1 0

Re: Breaking DES anyone? (was: Breaking RC4-40 for less)
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Hal Finney <hfinney(a)shell.portal.com> writes on cpunks: > > Another approach is to do lots of keys simultaneously - so you set up > > this distributed effort which is continually re-sweeping the 40 bit > > keyspace, say every couple of days or whatever. You can sweep for > > more than one key at once at very low incremental cost, an extra key > > costs close to nothing. So say you are searching for 1000 keys at > > once [...] on average a key will fall out every 3 minutes. > > I don't see how you can sweep for more than one key at once at low cost. > Because of the salt, every possible SSL encrypted message has to be swept > independently. You can't sweep for two messages' keys at once because the > input to the MD5 is different even for the same 40-bit key. Agreed. I was not being clear and mixing various things in one post. I was talking about 3 different systems: 1) export SSL 88 + 40 2) pure RC4-40 (hypothetical - possible microsoft / other apps) 4) DES (56 bits, can it be done) In the part you quote I was talking about pure RC4 40, I'm not sure which applications fall into this category, but it is one thing we have yet to determine. Perhaps Microsoft Access falls in to this category? Other microsoft applications / other vendor applications? someone needs to do the microsoft equivalent of a FOIA to extract this info. Anyone have any Microsoft software with encryption that they could quiz Microsoft tech support about? For export SSL it does not work for the reason you describe, the 88 bit salt effect. For DES I think it does work (attacking many keys at once), but then my understanding of DES is limited, but as a block cipher, presumably you can just brute keys in a straight forward manner? If so you can try multiple keys at once, unless there is some salt effect involved with typical CBC 56 bit DES operation too? Depending on the relative costs of the parts of the block cipher, a) key-setup b) block / stream decrypt pure RC4 is designed so that a) is vastly more expensive than b). How does this pan out for DES? DES (and RC4) are designed for fast encrypt / decrypt, but is there an appreciable key setup phase? I have these figures courtesy of Andy Brown: > Using Eric Young's very fast libdes code, and using the supplied speed > test program I get the following output on a Sparc 20 (1 processor): > > Doing set_key for 10 seconds > 582771 set_key's in 9.83 seconds > Doing des_ecb_encrypt's for 10 seconds > 989184 des_ecb_encrypt's in 9.85 second > Doing des_cbc_encrypt on 8192 byte blocks for 10 seconds > 982 des_cbc_encrypt's of 8192 byte blocks in 9.92 second > Doing crypt for 10 seconds > 37101 crypts in 9.89 second > set_key per sec = 59284.94 ( 16.9uS) > DES ecb bytes per sec = 803398.17 ( 10.0uS) > DES cbc bytes per sec = 810941.94 ( 9.9uS) > crypt per sec = 3751.37 (266.6uS) So what is a brute DES program on multiple keys with CBC mode (is this the most common mode?) going to look like in terms of calls to these various calls? The set_key looks slow compared to the DES cbc bytes per sec, even if you have to cycle a couple of blocks to get to your known plaintext location. Am I on the right tracks? It seems to me that you gain considerably by doing multiple keys even with CBC and random IV due to relatively fast block decrypt as compared to key setup. > If digital cash in micro amounts became practical, people could be paid > to let the "idle cycles" on their computers be used for this kind of > highly parallel application. (Some people have speculated that graphics > rendering would be another suitable choice.) It would be interesting to > see what the market price of cycles became in such an environment. That > would give a better benchmark for the cost to break keys. I think this would be an interesting way to determine the market value of idle cycles, and likely lead to cheaper figures for breaking things than are touted (by newspapers, and people to whose advantage it is to estimate generously the cost). Adam

1 0

Silly technical question from a non-technical person
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

> If it costs $10,000 to crack one 40-bit key (putting aside whether we > agree on that price or not), could not the software be designed in such a > manner that it is able to check, say, 10,000 keys at the same time? Ie, > it computes a key, and then checks it against the array of data to see if > it fits any of them, and then goes on to the next one. Hmm yes and no. - For pure RC4-40 yes. - For export SSL no. It has what is effectively an 88 bit salt (familiar with unix password salts? like that only 88 bits). - For full 128 bit SSL, yes, but 128 bits is a rather large even if you have a few million keys to try at once with speed up gains. 2^128 is a biiig number. - For DES I think so, asked for others opinions, this might be the next one to die, big project but possibly doable with lots of keys at once Adam

1 0