December 2003 - cypherpunks-legacy

Hardware RNG
by Jack Mott 17 Dec '03

17 Dec '03

I just recently built a hardware RNG, I just wanted to see what you guys think of it, here is how it works: Got a geiger counter plugged into the game port Weak radioactive source next to it (dont worry wont fry you) Use a PRNG string to do create an RC4 S-box Cycle through the S-box in a tight loop, each time checking to see if the geiger counter got a hit, if it did, record that number in the S-box as our first byte, do this 100 times, and we have 100 random numbers. With my radioactive source and geiger settings, you can grab 100 random numbers in about 8 seconds, and the S-box will make a complete cycle between 1000 and 350,000 times between geiger hits, depending on how long between hits. any thoughts? It seems to work well, no basic stat analysis reveals any pattern, and physicists have backed me up on radioactive decay being 'the great randomizer'. seeya -- thecrow(a)iconn.net "It can't rain all the time" RSA ENCRYPTION IN 3 LINES OF PERL --------------------------------------------------------- #!/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*',/((..)*)$/)

1 0

Re: Cookies anyone?
by Alan Olsen 17 Dec '03

17 Dec '03

At 04:34 PM 6/29/96 -0700, vanished(a)alpha.c2.org wondered what happens if he tosses his cookies: >While rummaging around in my cookie jar, I found this message--along with some >cookies. > >:Netscape HTTP Cookie File >:# http://www.netscape.com/newsref/std/cookie_spec.html >:# This is a generated file! Do not edit. > >Rather than bring down my system by experimenting, I thought I'd ask the list, >"What happens if I delete this file?" and "What happens if I delete (edit) the >cookies?" If you edit the file, Netscape may no longer be able to read the file correctly. (Bookmarks are similar in this respect. Netscape code is pretty picky about things like line termination and the like.) If you toss your cookies, Netscape will probibly bring you more cookies, but they will be different cookies than the last batch. Beware of burned cookies, fortune cookies (espicially ones with "Good Times" written on them), raisin cookies (especially if the raisins move), Brownies under the age of consent, and the cookies from dusty vending machines (Especially the hairy green ones). > >This may have been discussed before, but until now I never checked for cookies. You might also read the cookie recipie at http://www.netscape.com/newsref/std/cookie_spec.html . I hear it was written by a disgruntled Mrs. Fields employee. >Thanks for your consideration of this matter. You are welcome. Have a nice day. --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0

Re: Crack for DOS
by frantz＠netcom.com 17 Dec '03

17 Dec '03

Bill Stewart wrote: > Blowfish is new, so perhaps there are flaws that 10-20 years of analysis > will find. But it's pretty good - it's small, fast in software, > and has an annoyingly slow key-schedule which makes it difficult to > use brute-force crackers on. It's got variable key lengths. This comment about "annoyingly slow" key setup made me think of pipeline hardware to set up the keys. Now with blowfish, key setup requires running the Blowfish algorithm 521 times in setting up the key, so the pipeline will require 521 stages if you want a new key for every "real" decryption. Ignoring chip size restrictions, this pipeline will increase the chip real estate by 521 which will have approximately the same economic effect on the cost of cracks as extending the key by 9 bits. For CBC cypher systems, brute force attacks will require at least two decryptions (one for the initialization vector, and one for the first block of the message). however, these decryptions can take place in parallel (for the first block of the message) so they do not change the above argument. However if the design calls for more than the first block, then the pipeline can run slower and becomes a smaller portion of the cost of the system. Of course if you are using Blowfish with anywhere near its full 448 bit key, brute force attacks are simply not practical. ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz(a)netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA

1 0

New&Improved MiddleMan
by MiddleMan Remailer 17 Dec '03

17 Dec '03

Hello Everyone, Due to several requests, I have been working on an improved middleman remailer. Actually it's quite simple. I was able to improve the reliability and robustness of the remailer dramatically by changing $config{"numshuf"} = 3; to $config{"numshuf"} = 2; in the .premailrc file for the middleman remailer. Exhaustive testing demonstrated that no code changes to middleman itself were required. The only variable that demonstrated the most profound performance difference is shown above. I invite others to test the remailer for reliability and report back to me. If it works, I'll go public with it once again. Here is the public key for middleman. Please note the slight name change from middle-man to middleman. One less keystroke if you know what I mean. I invite your comments. middleman middleman(a)nym.jpunix.com d020c2e68f1861098812ffaadd6e8a7d 2.0.3 -----Begin Mix Key----- d020c2e68f1861098812ffaadd6e8a7d 258 AAS/9+NieAH945N1PYtLzSxnhUxVrfPR/OIAcQDM 61v5WGfpgXAltjMRQ0PHaBibeuER2/JhF5uDh4tu nypppGDshlrajeX/RuXMN38UPRMZPDKwNzP2oddB l/nTy6rxcdRUclBfzzoERUUay9RSiScbpnfvcm3g R2Qgv3taGiAf+wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAB -----End Mix Key----- middleman-admin(a)nym.jpunix.com

1 0

Re: anonymous mailing lists
by Alex de Joode 17 Dec '03

17 Dec '03

Hal sez: : Wei Dai did some nice statistical analysis of this type of attack : sometime a year or two ago. Even with countermeasures such as you : suggest, if they are not perfect, so some information leaks correlating : incoming and outgoing messages, Wei showed that it was possible to : deduce the owners of the nyms surprisingly quickly. : The countermeasures do work - if you get and send exactly 50 pieces of : 4K byte email every day, no matter what, then correlations don't exist : - but they are expensive to do perfectly. For now we have much worse : weaknesses; none of the current return-address systems are really safe, : other than posting encrypted mail to newsgroups (and even that may be a : problem if they suspect who you are and are monitoring your computer : link to see if you download certain messages). Use ssh or any other link encryptor, or fetch the whole newsgroup using uucp. -- -AJ-

1 0

In From the Cold
by jya＠pipeline.com 17 Dec '03

17 Dec '03

June 28 the NYT and Wash Post reported on a new report on intelligence: In From the Cold: The Report of the Twentieth Century Fund Task Force on the Future of U.S. Intelligence. This report supplements and differs somewhat from the three released earlier this year by the Brown Commission, Representative Combest's Committee and the Council on Foreign Relations. It recommends greater emphasis on economic intelligence and less on military support as well as reduction of covert operations. Here's an excerpt from the Foreword: The Task Force discerned basic problems that merit far greater attention. Foremost among them is the intelligence community's increasing preoccupation with military priorities since the Soviet Union's collapse, which has coincided with a decline in the usefulness of intelligence to civilian policymakers. To help strike a more equitable balance between the military and civilian needs of the government, the Task Force proposes specific recommendations for strengthening what it perceives to be four pervasive shortcomings: 1) the atrophying analytic capabilities of the intelligence community and U.S. foreign policy agencies; 2) the lack of productive and effective interactions between the intelligence community and civilian officials who make foreign policy decisions; 3) a clandestine service whose costs have too often exceeded its benefits; and 4) poorly organized, unfocused, and often mediocre economic intelligence efforts. The full volume is 275 pages, composed of introductions, the main 21-page report and three extensive and detailed background papers of 248 pages. The introductions and main report are at: http://pwp.usa.pipeline.com/~jya/infrom.txt (60 kb) INF_rom ---------- In From The Cold: The Report of the Twentieth Century Fund Task Force on the Future of U.S. Intelligence. With Background papers by Allan E. Goodman, Gregory F. Treverton and Philip Zelikow The Twentieth Century Fund Press, New York, 1996. $5.95 ISBN 0-87078-392-0 To order by telephone: 1-800-552-5450

1 0

Re: rsync and md4
by Andrew Tridgell 17 Dec '03

17 Dec '03

> The odds of a certain file having a certain hash are one in 2^128. But, > the odds of any two files having the same hash (the "Birthday Attack") is > just one in 2^64. The birthday paradox doesn't apply in my case I believe. Its not an all-to-all comparison. One file is "given" by the user. I'm definately not a crypto-expert, however, so I could be wrong. > That's good, because MD4 collisions can be produced in a matter of > minutes. But if you're not concerned about attacks, then MD4 is probably > more than you need. I'd like to know more about this. > You could, but why bother? If you've got a 14.4 or faster modem, you can > send a lot of hashes in a short time. The real load won't come until you > try to download an altered file. You'd have to read the tech report on rsync. It does not download the whole file when a checksum mismatch is found, that would be next to useless. It effectively creates binary diffs of the two files, without direct (local) access to both files. As far as I know this is a new type of algorithm. In practice the hashes and checksums dominate the data that is sent over the link. They total about 1/30 of the total file size for the default settings. > MD4 is not strong- people can deliberately produce files with the same > hash in a matter of minutes. MD5 is secure for now, but it seems to be > gradually falling to cryptanalysis, and should be phased out of use before > it breaks. IMO the best hash algorithm is SHA1 (which is an updated > version of the original SHA). Do a web search for "FIPS PUB 180-1" for the > specs. Do you have references to the md4 collision stuff? The situation I have is a bit unusual so its just possible some of the results may apply. > For what you're doing it sounds like you don't need a cryptographically > secure hash function. If you're not concerned about people deliberately > trying to defeat the system, then just use a 32-bit CRC. It already uses a 16 bit hash as a first level filter and a 32 bit "rolling checksum" as the 2nd level. The 2nd level fails about 25 times on a 25MB test file I've been using. The failure rate goes as the square of the file length. When the 2nd level fails it is detected by the md4 hash which has to be much stronger. Cheers, Andrew

2 1

(no subject)
by Paul Rahe 17 Dec '03

17 Dec '03

1 0

arcfour
by Steve Reid 17 Dec '03

17 Dec '03

A few questions about RC4... I understand that RC4 is like a one-time-pad, in that a key can not be used more than once. What about adding a different salt to the key for each encryption? Would that be sufficent, even if the salt (but not the rest of the key) were known to an attacker? Is there any way to identify and weed out weak keys? Does anyone have any sample data I can use to test an RC4 implementation? A key and the first few bytes of the stream should be sufficent. Thanks... ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve(a)edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:)

2 1

Re: Hardware RNG
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:26 AM 6/30/96, Jack Mott wrote: >I just recently built a hardware RNG, I just wanted to see what you guys >think of it, here is how it works: > > Got a geiger counter plugged into the game port >any thoughts? It seems to work well, no basic stat analysis reveals any >pattern, and physicists have backed me up on radioactive decay being >'the great randomizer'. First, have fun playing with it. Second, watch out for subtle statistical biases. While radioactive decay is unpredictable (so are a lot of things, by the way), there are all kinds of biases that reduce the apparent entropy. Detector "dead time" is a classic one (basically, the detector can't detect counts during a post-pulse recovery time...probably not a problem at low count rates, but an example of how subtle things can sneak in). --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0