December 2003 - cypherpunks-legacy

Re: QED_jak
by dmandl＠bear.com 17 Dec '03

17 Dec '03

"Perry E. Metzger" <perry(a)imsi.com> says: > John Young writes: > > "U.S. Tells How It Found Soviets Sought A-Bomb: Discloses > > Clues That Led to Code-Breaking." > > > The reports claimed the spys were using one time pads in some flawed > manner, but did not explain very well what the problem was. Does > anyone out there know? > > .pm It wasn't completely random. They reused some code material: But Mr. Gardner and his colleagues found patterns in unrelated messages. They were proof that exhausted Soviet code-makers had repeated themselves ... Still, it's pretty impressive that the NSA was able to find this. --Dave. -- ******************************************************************************* Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *******************************************************************************

1 0

LOU_nex
by John Young 17 Dec '03

17 Dec '03

7-13-95. NYPaper Page Oner: "Senior F.B.I. Agent Suspended in Probe Of a Deadly Siege." The Federal Bureau of Investigation has suspended a senior career agent as a result of a Justice Department inquiry into whether officials destroyed important documents about the agency's bloody 1992 standoff with a white separatist in Idaho, law-enforcement officials said today. The suspension of the agent, E. Michael Kahoe, who was an official at F.B.I. headquarters during the Idaho siege, sent a shock wave through the agency's upper ranks. LOU_nex

2 1

Re: QED_jak
by John Young 17 Dec '03

17 Dec '03

Responding to msg by perry(a)imsi.com ("Perry E. Metzger") on Wed, 12 Jul 10:45 AM >The reports claimed the spys were using one time pads >in some flawed manner, but did not explain very well >what the problem was. Does anyone out there know? The NYT-reported ceremony was on C-SPAN (1 or 2) last night; I saw only a snippet of Moynihan mumbling. Maybe there will be a replay sometime today that may provide clues to the sharp ear. Held at the CIA, the clip showed lots of backs of heads of creme de les zipped-lipped crypto-slaves. Unctous Freeh, Deutch, the spy-brass were all there, lipping the New Yarper -- an ouvert HERF-zap would have spattered their sucrets.

1 0

NSA, Random Number Generation, Soviet Codes, Prohibition of Crypto
by Black Unicorn 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ** How a conservative learned to like NPR - Listening to Public Radio this morning I caught a story about the NSA's recent release, or pending release of some 2000 - 2200 documents bearing decoded Soviet communications. These were the result of a long running communications and signals intelligence program conducted by the U.S., and thus, by the NSA and it's predecessors. Some of the documents to be released include communications quite damaging to the Rosenbergs, who were executed for espionage and selling U.S. atomic "secrets" to the Soviets. This is, in fact, the key attraction in the documents. More interesting than all this was the discussion with the deputy director of the NSA in which he described the communications collections program which continued from the 1950's all the way into the 1980's. What interested me most, aside the fact that the NSA was speaking so candidly, and in my opinion foolishly so, about the program (even given their new public relations awareness) was a brief discussion of what methods were used in cracking the Soviet code. While it was not defined specifically, it was suggested that the majority of the messages were communications between the embassies and Moscow. As a result, the procedural and cryptologic algorithm was likely very entrenched as a method, and lacked variation because of the massive coordination required to switch methods in embassy to home country secure communications. While I do not know how much was puffing, I suspect that it is safe to say that the basic method the Soviets were using looked something like this. Plaintext -> Codebook number substitution pass -> One time pad pass. The most difficult, and in the words of the deputy director, "remarkable" task was, of course, attacking the last layer in the encryption, and the first layer in the decryption process, the random series on the one time pad, which, in the words of the public spook, "was not so random after all." The fixed codebook substitution perhaps had a high overhead in the initial computation, but once analyzed the first time the entire cipher is a wash until a new codebook or random number generation method is used. ** "Captain, the energy is structured in a pattern I have never before encountered." - So what does this little disclosure tell us about NSA capabilities? Most obviously that they have extremely sophisticated "random" number analysis abilities. 1950-1980 is a long time to practice, and develop specialized hardware for this purpose. The discussion of the value of specialized hardware gains having been applied on this list to RC4 analysis, its value is still somewhat of a mystery to me with reference to random number analysis. In any event, it is safe to assume that the NSA has a very large section dedicated to this entire pursuit, and moreover, that the Soviets probably were not "petty" random number generators. Perhaps laziness got the best of them, but I am inclined to think they conducted this program, at least at first, like any other massive communist "for the glory of the state" program-- i.e., with crippling dedication. To me this prompts the questions: How random is random, and how random is "cryptographically random?" I don't know much about the mechanics of cryptographically strong random number generation, but considering the enormous effort the NSA has put into the analysis of same, I suspect it is in everyone's best interest to know more. Consider: Now that the NSA has gone public with the program one must believe this prima facie evidence that the program is no longer of use against the Soviets. I suspect that a lot of dedicated hardware, already paid for, is probably sitting about looking for a use. "Hey Louie Freeh, any idea what we can do with all this idle equipment?" So for the cypherpunks, my first suggestion is a long look at exactly how strong the "cryptographically strong" random numbers might be. Certainly we are not random number ignorant, but how random number savvy are we? Perhaps someone with the equipment and the computer time might conduct a bit of an experiment. Maybe lifting the random number generators from common cryptographic applications like CryptDisk Curve Encrypt, PGP, Secure Device, and taking a massive sample to identify trends in the "random" data might be a good idea. Even those processes that employ some physical component might have some trends that could fall into patterns. Even with hard hashes of random seeds, could seed patterns create patterns in the actual random data? I must suspect so. Perhaps a piece of code which could be distributed far and wide to 'punks and others which might generate random data on different machines with different hardware and different users and generate an export file to be submitted to a Web Page or something. We've seen the tremendous value Web Pages have in bringing users together to contribute processor time for the RC4 project, what about random number generation time? One of the first attacks on short-wave radio "number stations" (for the uninitiated, most are based in South America and read off long sets of code numbers, usually in Spanish) was with the assumption that a one time pad had been used. The result? An analyst determined that the "random" numbers for several stations were one time padded with "random" poundings on an old typewriter. Even if not broken, this immediately identified several stations as related by the use of the same one time pad generation method (which is sensitive enough that unrelated stations are quite unlikely to have been privy to the method) and thus provided tremendous traffic analysis information. What does our random data tell the world about us? Could not the bits in PGP keystroke timing subroutines fall into a subtle pattern? Enough of one to make someone's job a lot easier? When you whirl that mouse around the screen to generate random numbers for CryptDisk, do you start with a counter clockwise circle? If you're right handed you're likely to. In the scheme of things, these might be pretty good clues to someone who does nothing but random analysis all day long in a cubical with a frighteningly quick piece of specialized hardware in the next room. ** "He's in a tough position. If he announces he's running, everything becomes a political move, if he announces he isn't, his administration becomes a lame duck effort. Perhaps he should say nothing" - My estimation of the NSA's new public image, which amazed me at first, prompted me to suggest that the bulk of the hyper-sensitive work done there has already been moved to another outfit. To go from "No Such Agency" to a politicized and highly public organization with a public relations department and press releases in just under 30 years is a dramatic change for a secret agency. In many ways it is not a poor move. The agency has grown quite large, and it has become impossible to hide. In addition, the public is much more likely to be receptive to an agency which appears-- in public-- to have some worth. Cryptography is a complex concept, enigmatic at best for the general public. The public relates much better to the capture of spies and the foiling of the Soviet Union than to an agency which is too secret to acknowledge. Public opinion tilting to the NSA might be a bad thing for Cypherpunks. When the NSA says key forfeiture is required, the public is much more likely to swallow the pill from an agency that uncovers traitors, protects our national interest, and has a cool museum that you can visit to boot. Mr. Young rightly pointed out on this list that part of the coin the intelligence community sells, the demand for which moves novels by the millions, is the feeling of inclusion in a select group, a shared secret. How elegant the way the National Cryptological museum was opened. No fanfare, no publicity, no invitations, just there to be discovered at first, like a little secret. Stuck in an old motel, barely visible from Route 32, dwarfed by the massive NSA complex. Talk about public relations coup. Classic intelligence, release what is worthless or nearly worthless, create the impression it is rare, make cursory efforts to obscure it- efforts you know will eventually fail, and you have created something coveted. Wait a while, and then when it has been discovered, uncovered, publicized, put out a brown and white sign: "National Cryptologic Museum." What does DeBeers do any differently? So the NSA has become a political tool. A mouthpiece, and in a subtle way, a propaganda machine. (Just keep the lead counsel out of the public eye guys. He keeps screwing things up. Do a Stephenopolis or Hillary Clinton on him. Time for him to go behind the scenes). We've long been predicting the clash between crypto and government, I doubt government sees it much differently, though perhaps through the foggy lenses of a entity used to getting its way through coercion. I suspect they are likely to do themselves major damage with simple hubris. Still, the signs are out there. They are more and more public every day. I think cryptography scares the administration. It certainly scares the FBI. So I ask some of the same questions I asked here a few months ago. Where are the stealth PGP hacks? Where are the more subtle stego programs? Why aren't there totally transparent strong crypto programs which don't advertise the recipient right in the header? Why isn't crypto prepared to weather the storm of a outright ban? Sure, fight on the side of keeping crypto legal, but prepare for the worst. The fact that everyone and their mother drank didn't keep prohibition from being initially passed. How is it people think it will be the sure fire crypto ban deterrent? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMAOxEi1onm9OaF05AQEi6Qf/ZW3qZln5SwPonJnf00OZM7DiPrjg/0+R qzsgolAAnZIr/xFnNP99kzfLf393B5i/8CYO3V0m43VWI4T51b+sBs90Jkiin5hi dals2aa/hCnMKvGfX1RjBo6OmiPmBhiwtvIOkn+tTda37YSWjYuBJ5DOZhXiuW6S CUBxoDoE7yQmNy2BVZU9AKibpF3+Mv2k0yR9PlO0Yc0g8Z+juKR5xxUuMgqpy4HJ qERDYZ6Cd+ADBt/YZGpoESBdishkKfZJeA+J9XApKbR8GiFgeT487ax1/P+Ph+eo 3kMcDEW4O87QbuXa3zewnNrxO306TO04jOeQp6GdJ00IQkRKeru0uw== =6iZQ -----END PGP SIGNATURE----- 00B9289C28DC0E55 nemo repente fuit turpissimus - potestas scientiae in usu est E16D5378B81E1C96 quaere verum ad infinitum, loquitur sub rosa - wichtig! *New Key Information* - Finger for key revocation and latest key update.

4 3

Privtool 0.84a
by Rev. Mark Grant 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ok, version 0.84 didn't work properly on Linux, so I'm now releasing a version 0.84a with fixes to make it compile. US users can get the sources from from ftp.c2.org:/pub/privtool/privtool-0.84a.tar.gz, or in Europe at ftp.ox.ac.uk:/pub/crypto/pgp/utils/privtool-0.84a.tar.gz. It will also be available soon on ftp.dsi.unimi.it. US ITAR laws may make it a crime to export Privtool, so if (like me) you're not in the US then get it from the European sites. In addition the documentation is available on the WWW at http://www.c2.org/~mark/privtool/privtool.html. Mark Privtool Beta Release @(#)README.1ST 1.16 7/12/95 ----------------------------------------------------- Privtool ("Privacy Tool") is intended to be a PGP-aware replacement for the standard Sun Workstation mailtool program, with a similar user interface and automagick support for PGP-signing and PGP-encryption. Just to make things clear, I have written this program from scratch, it is *not* a modified mailtool (and I'd hope that the Sun program code is much cleaner than mine 8-) !). When the program starts up, it displays a list of messages in your mailbox, along with flags to indicate whether messages are signed or encrypted, and if they have had their signatures verified or have been decrypted. When you double click on a message, it will be decrypted (requesting your passphrase if neccesary), and/or will have the signature checked, and the decrypted message will be displayed in the top part of the display window, with signature information in the bottom part. The mail header is not displayed, but can be read by pressing the 'Header' button to display the header window. In addition, the program has support for encrypted mailing list feeds, and if the decrypted message includes another standard-format message it will replace the original message and be fed back into the display processing chain. When composing a message or replying to one, the compose window has several check-boxes, including one for signature, and one for encryption. If these are selected, then the message will be automatically encrypted and/or signed (requesting your passphrase when neccesary) before it is sent. You may also select a 'Remail' box, which will use the Mixmaster anonymous remailer client program to send the message through one or more remailers. Being an Beta release, there are a number of bugs and nonfeatures : Known Bugs : Message list scrollbar often set to stupid position when loading a mail file. When you save changes to the mail file, it throws away the signature verification and decrypted messages, so that the next time you view a message it has to be verified or decrypted again. 'New mail' indicator in icon does not go away if you open the window and close it again without reading any messages. Known Nonfeatures : Currently if you send encrypted mail to multiple recipients, all must have valid encrpytion keys otherwise you will have to send the message decrypted. Also, the message will be sent encrypted to all users, not just the one who is receiving each copy. 'Add Key' button is enabled and disabled as appropriate, but does not do anything ! A number of other buttons and menu items do not work either. Passphrase is stored in ASCII rather than MD5 form, making it easier for hackers to find if you're on a multi-user machine (of course, you shouldn't be, but many of us are). Kill-by-subject does not work. Ignores Reply-To: lines, and could probably do with an improved mail-reading algorithm. Only one display window, and only one compose window. Code should be more modular to assist with ports to Xt, Motif, Mac, Windows, etc. Not very well documented ! Encrypted messages are saved to mail files in encrypted form. There is currently no option to save messages in decrypted form. No support for anonymous return addresses. Not very well tested on Solaris 2.x, or Linux. Major changes for 0.84: Added 'Forward' option to 'Compose' button. Support for Mixmaster and multiple pseudonyms. Due to a bug in the current version of Mixmaster, note that messages have to be saved to a temporary file for mailing. Fixed file descriptor leak in pgplib.c which could make the program hang occasionally when saving changes. Added support for 'smallring.pgp' to speed up access to commonly used public keys. This version is thought to work on Linux, however I haven't been able to test that myself. Changes supplied by David Summers (david(a)actsn.fay.ar.us) Changes for 0.84a: Linux testing showed up some problems with 0.84. This has been solved by using Rich Salz's parsedate() function to parse the dates on mail messages. This is now supplied in a linux subdirectory, and appropriate changes made to the Makfile to allow it to compile correctly on Linux. Changes supplied by David Summers (david(a)actsn.fay.ar.us) Fixed another hang by deleting the lock file if we failed to open the mail file while saving a message. Privtool can be compiled to either use PGPTools, or to fork off a copy of PGP whenever it is needed. There are also a number of different security level options for the passphrase, varying from 'read it from PGPPASS and keep it in memory' to 'request it every time and delete it as soon as possible', via 'request it when neccesary and delete it if it's not used for a while'. See the README file for information on compiling the code, and the user.doc file for user documentation (the little that currently exists). You should also ensure that you read the security concerns section in user.doc before using the program. Mark Grant (mark(a)unicorn.com) -----BEGIN PGP SIGNATURE----- Version: 2.6 iQEVAgUBMAPq5lVvaTo9kEQVAQG48gf9EXXCBm42agXpfJP1ePuI5zbDujtaWhGb khAPRrlPJJ5QeZp3wz0DMDjhvSJjz2dlyxYj5u61kgbfybhxr2lAzwYL4k89A/B+ aHSggEMpKYwosd9FZEZ30pG1ufYeEI0eJw0hHuZzIIbGzTy3x+IfVY9h41F+ewkV fbAtw5jwZKI43cil0cds3DFLHYOhiuWUU72KUCHABgvQfLPBYCJ4F3nW64GduxtA idjHrcfe3ZJNLJEQ1VsHbqbAgND2jzB/8C84kw9Nb9wgd+zTdgnnJPWidpqHZqe2 ymBX1JD675WrKORnZlTI28haIcajPnLp5nXy2Ycs+/5RMuW/AVlYhg== =4M+l -----END PGP SIGNATURE-----

1 0

Your Beta Signup Confirmation
by Mother Jones HTTP Daemon 17 Dec '03

17 Dec '03

You're now a confirmed MoJo Wire Beta Tester Username: cypherpunks Password: cypherpunks For now, look at <http://www.mojones.com:8040/> Thanks for participating!

1 0

Re: Num Rat
by terrell＠sam.neosoft.com 17 Dec '03

17 Dec '03

> > >I just looked @ the front of a M.O. computer catalog & the numerals in the >prices are anything but random. A very heavy concentration of eights (8) & >nines (9), apparently this company is more into $508.98 (color inkjet printer) >& $38.98 (well known game s/w) than the old late night TV standby of >"JUST $19.99!". Of course, this is because of excessively documented >ad nauseum human psychological tendencies that salescritters, who set at >least the lsd's of price, have been aware of for millenia. I'd bet, that >5(five), 8(eight), & 9(nine) are significantly more represented across >the board in prices (& thus in amounts for checks & tax write offs) than >than their random distribution by Benford's Law or more well known tests >for randomness would suggest. Has Mr. Negrini factored this into his program? >I guess the lesson is do a few pgp make__random's & convert a few of the >hex numbers to dec digits for the lsd's the next time one does creative expense >reporting. > >tjh > Just an aside -- J C Penney invented the $n.95 pricing scheme so that his clerks would have to make change. That way they had to use their registers, recording the sale and the cash didn't just go into their pockets. Even at that early date, proper security of automated systems depended largely on human factors. Buford C. Terrell 1303 San Jacinto Street Professor of Law Houston, TX 77002 South Texas College of Law voice (713)646-1857 terrell(a)sam.neosoft.com fax (713)646-1766

1 0

Re: general RC4 key searcher: optimisations anyone?
by Jonathan Shekter 17 Dec '03

17 Dec '03

>/* RC4 Brute Force Key Searcher, by Andy Brown 1995 > >This part of the package is meant to be portable between most systems >so that Unix users can take part in the searching. After all, the >kind of really high powered systems that can make a large dent in the >key space are not running Windows NT. You will, however, require Umm... ever hear of an Alpha? Besides which, this will compile on NT, and just about every other OS known to man, so it's a moot point. >#define SwapByte(a,b) ((a)^=(b),(b)^=(a),(a)^=(b)) If the two values are in memory (which they are as you swap state vector elements) then this xor trick requires three read-modify-write cyles -- slow on any architecture. Use a temp variable instead. >/* prepare the key */ > >for(counter=0;counter<256;counter++) >state[counter]=(unsigned char)counter; This is bad. Use either a) memcpy as in bruterc4 or b) an unsigned long, starting at either 0x00010203 or 0x03020100 depending on endianness, adding 0x04040404 at each iteration to generate four bytes per shot. Remember, on most machines a 32-bit store is the same speed as an 8-bit store. The fastes I have been able to do on this section was obtained by unrolling the loop manually, and using *two* long variables, alternating, to remove instruction dependancies. >for(counter=0;counter<256;counter++) > >index2=(key[index1]+state[counter]+index2) & 0xFF; >SwapByte(state[counter],state[index2]); > >if(++index1==keybytes) >index1=0; 1) This loop needs to be unrolled! Using direct array offsets instead of incrementing the counter is a speedup on many machines. Also, experiment with the unroll size. Making it larger increases performance until you get too big to fit in the cache, at which point it slows down. My experiments on a few different types of machines showed that unrolling the inner loop 16 or 32 times was usually about right. See the inner loop of bruterc4. Use macros to do the unrolling. 2) You can avoid the if statement for checking for key wrap around as follows: in your initialization, construct an array as follows: for (i=0; i<keysize-1; i++) transtbl[i] = i+1; transtbl[i] = 0; Then, after each iteration: index1 = transtbl[index]; Viola, no if statements, no divides or mods. On many architectures this is worth the trouble as branches are expensive. Obviously, though, test this >/* do two RC4 operations as a preliminary test. If this fails then test >the next one, then the rest. This should result in a lot of rejections >before the rest of the loop is entered */ I like the early-out test. >x=(x+1) & 0xFF; >y=(state[x]+y) & 0xFF; >SwapByte(state[x],state[y]); Again, swapping with xor probably hurts you here. Use a register temp variable. My personal keycracker accepts general length keys and is not too much slower than bruterc4. So it can be done. - Jonathan -- ____________________________________________________ / Jonathan Shekter / / / Graphics Hack / "Probability alone / / Alias/Wavefront / dictates that I exist" / /______________________/____________________________/

3 2

Re: Why they can be sued... (Was: freedom of speech)
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

> >Last thursday there was a report in the news. They started a new >lawsuit against a Nazi, who was already earlier sentenced for other >Nazi crimes. He was sued because he distributed a video. In the video Just to sidetrack the issue, a bit. Are there any ex-Nazis who participated in the Holocaust who would dispute this guy? > >I wanted to know in detail why he can be sued. Therefore I had a look >into my book commenting the criminal law. I try to translate as good >as I can. > >In the german criminal law there is a chapter about slander, libel and >such things. > >Slander is seen in Germany not as a crime, but as an offence. It >differs from other offences in the detail, that the prosecuting attorney >can't sue it himself. It needs the request of a 'victim'. > >If the victim dies, the right to request is transferred to the >wife/husband and the children. If there aren't any, to the parents. If >there aren't any, to the brothes/sisters and grandchildren. > > Par. 189: Wer das Andenken eines Verstorbenen verunglimpft, > wird mit Freiheitsstrafe bis zu zwei Jahren oder mit > Geldstrafe bestraft. > > Who decries the memory to a dead person, is punished with jail up > to two years or fine. > This is a little different from the US. I've never heard of anybody being jailed or fined for libel/slander, just sued for it. > >This applies under certain circumstances to saying that the holocaust >never happened. > >Do you have a law like this in America? > > No. You can't libel the dead. Most historians would get their socks sued off if you could. I remember reading about a case once in which two sons wanted to sue the man who had libelled their dead father. They couldnt do it through normal channels, father being dead and all, so they publicly called the libeller a liar, repeatedly, eventually provoking _him_ to sue _them_ thereby allowing the truth of the original liber to be tested in court. The sons won; a moral victory at least. > >This is the reason why someone can be sued if he claims that the >holocaust never happened. It is not the idea itself. The reason is >that it can be a form of violence against dead people in the eyes of >german law. > So in other words, the Holocaust-Denial crime is a creative extension of existing libel laws. >BTW: I have a collection of the most important german laws on my >webserver. You can find the list at > >http://iaks-www.ira.uka.de/ta/Diverses/Gesetze/ > Useful to know that. Aachen is just down the road from here. -- Thank you VERY much! You'll be getting a Handsome Simulfax Copy of your OWN words in the mail soon (and My Reply). <Andrew.Spring(a)ping.be> PGP Print: 0529 C9AF 613E 9E49 378E 54CD E232 DF96 Thank you for question, exit left to Funway.

1 0

Free Directory Pinpoints E-Mail Addresses
by Phiberflea＠aol.com 17 Dec '03

17 Dec '03

Hi Team, Received this little blurb in my e-mail. >Free Directory Pinpoints E-Mail Addresses >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Palo Alto, Calif. -- .... Well, SLED Corp. has stepped up to answer the call of all the Internet >users who have ever screamed "How can I find someone's e-mail address?" >..... > The Palo Alto-based company recently released its Four11 Online User >Directory as a free service for Internet users. The directory is easily >searched by e-mail, through the use of e-mail forms, or the Web, by using >browsers such as Mosaic or Lynx. Search parameters include name, location, >old e-mail address, Group Connection and wildcards. >...Membership also includes PGP encryption certification and storage >services. Members who provide proper identification can have their PGP >public key signed with the SLED Silver Signature. Signed keys are added >to the key owner's directory listing and can be quickly retrieved by other >Internet users through either e-mail or the Web. These keys, actually >small data files, are used to send private messages and verify digital >signatures. The combination of an Internet wide directory with a PGP key >server makes it possible to quickly find someone, obtain their key, and >send them a secure message. Things that make you go hmmmm.... Ginger Shei shuo zhong-guo hua?

1 0

My only words on "Electromagnetic Pulse" Damage
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

Much discussion this morning about EMP, electromagnetic pulse weapons, HERF guns, Winn Schwartau's "Information Warfare" scenarios, TEMPEST, etc. Not closely related to Cypherpunks themes, but lots of speculation is continuing. I happen to know a fair amount about chip vulnerability to various kinds of radiation and electrostatic discharge, and have had contacts with folks who know Schwartau. (I was also interviewed for a Schwartau-oriented BBC television program called "The I-Bomb.") Here's what I know: * EMP can of course zap devices. High electric field gradients can induce voltage drops that blow inputs, burn out circuits, etc. Lots of mechanisms for this, of course. Latch-up in CMOS circuits, field oxide overvoltage breakdown, etc. There is an entire sub-industry devoted to electrostatic discharge (ESD), with conferences, products, consulting services, etc. * However, getting the voltages coupled into circuits is another matter. Modern chips can usually handle static charge buildups that are in the tens of thousands of volts range (input protection devices are on the input pads). Static discharge should be avoided (wrist straps, etc.), but most modern devices will survive the static discharges that folks can generate. * The point? A _distant_ (tens of meters away) source of electromagnetic fields will have a pretty hard time of creating field gradients able to equal these 10,000 volt local fields caused routinely by static buildup. (Electric fields are of course measured in terms of "volts per meter"...do the math.) * The traditional EMP work is well-covered in each year's "Nuclear and Space Radiation Effects Conference," the Proceedings of which are included in the December issue each year of "IEEE Transactions on Nuclear Science and Space Radiation Effects." I advise anyone interested in this topic to consult these sources. (I've been to a few of these conferences, beginning in 1978.) * Most of the traditional EMP work is oriented toward the detonation of nukes in orbit, where the interaction of the photons from the bomb with electrons in the upper atmosphere create an electromagnetic field of millions of volts per meter, the so-called "electromagnetic pulse" that blows circuits. (This effect was apparently first noticed, by U.S. scientists at least, after a 1962 high altitude burst over Johnson Atoll in the Pacific, with electric circuits as far away as Hawaii being blown.) * Schwartau has not, to my knowledge, ever seen a direct demonstration of the effects he is describing in his book. In fact, much of his "HERF gun" stuff is admittedly speculative. * He has gotten interest from British intelligence (MI-5 or MI-6, not sure which) in his "scenarios" for knocking out financial centers with EMP bombs and HERF guns. A friend of mine, who can speak up if he wishes here, has had some contacts with Schwartau and may have started to do some preliminary experiments on this stuff. (The EMP/HERF folks in governments have of course a lot of experience here. I'm just saying that the "Schwartau crowd" appears to just be getting started on actual experiments, so any speculations in "Information Warfare" should be taken as just that, as speculations.) * As a matter of commenting on one thread about damage to the "HERF gun" itself, the conventional notion is that such a device would be a "set and forget" device, with a suitcase planted near a corporate office complex and set to "detonate" some time later. All the talk about reuse and damage to the operator is beside the point. (As is the speculation about effects on the human body....bodies can withstand incredibly high fields, so long as a ground path for current does not form (electrocution)....I could go on about this, but won't.) * In my opinion, Schwartau's chief interest is in spreading fear and concern about the "vulnerability" of the world's "information infrastructure." This cranks up interest in his book, in getting talk show interviews, etc. He may have "patriotic" motives as well, but I think a large part of what we're seeing is the usual, and increasingly common, journalistic hype. This is not to say there is no basis for concern, just that this is not the first and foremost concern. After, cutting power lines has long been an easy way to knock out economic activity--it may have recently happened in Penang, Malaysis, for example, where many chip assembly plans were knocked off-line for a few weeks by a power cable cut. This is all I'll say on the current debate on TEMPEST, HERF, EMP, etc. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)sensemedia.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

SSL RC4 challenge
by Hal 17 Dec '03

17 Dec '03

Here is a challenge to try breaking SSL using the default exportable encryption mode, 40-bit RC4. It consists of a record of a submission of form data which was sent to Netscape's electronic shop order form in "secure" mode. However the data I entered in the form is not my real name and address. The challenge is to break the encryption and recover the name and address info I entered in the form and sent securely to Netscape. (A URL for info on SSL is http://home.netscape.com/newsref/std/SSL.html.) Below is the data which was sent back and forth, along with some annotations to help interpret it. The connection was made to order.netscape.com at port 443, the https port. The following is the first message from client to server, the CLIENT-HELLO message. It is not encrypted. 0x80 0x1c 0x01 0x00 0x02 0x00 0x03 0x00 0x00 0x00 0x10 0x02 0x00 0x80 0xaf 0x84 0xa7 0x79 0xf8 0x13 0x69 0x20 0x25 0x9b 0x53 0xa0 0x60 0xae 0x75 0x51 This is interpreted as follows: 0x80 0x1c Length field: 28 bytes follow in the packet. 0x01 MSG_CLIENT_HELLO 0x00 0x02 CLIENT-VERSION-MSB CLIENT-VERSION-LSB 0x00 0x03 CIPHER-SPECS-LENGTH-MSB CIPHER-SPECS-LENGTH-LSB 0x00 0x00 SESSION-ID-LENGTH-MSB SESSION-ID-LENGTH-LSB 0x00 0x10 CHALLENGE-LENGTH-MSB CHALLENGE-LENGTH-LSB 0x02 0x00 0x80 CIPHER-SPECS-DATA <none> SESSION-ID-DATA 0xaf...0x51 CHALLENGE-DATA [16 bytes] The only cipher spec sent (and hence supported) by the browser is 0x02 0x00 0x80, which is SSL_CK_RC4_128_EXPORT40_WITH_MD5. No session id is sent, hence new key information will be calculated for this session. And 16 bytes of challenge data are sent in the clear; this will be useful as known plaintext returned encrypted by the server later. The following data is then returned by the server, in the SERVER-HELLO message: 0x82 0x2b 0x04 0x00 0x01 0x00 0x02 0x02 0x0d 0x00 0x03 0x00 0x10 0x30 0x82 0x02 0x09 0x30 0x82 0x01 0x72 0x02 0x02 0x00 0x88 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x04 0x05 0x00 0x30 0x47 0x31 0x0b 0x30 0x09 0x06 0x03 0x55 0x04 0x06 0x13 0x02 0x55 0x53 0x31 0x10 0x30 0x0e 0x06 0x03 0x55 0x04 0x0b 0x13 0x07 0x54 0x65 0x73 0x74 0x20 0x43 0x41 0x31 0x26 0x30 0x24 0x06 0x03 0x55 0x04 0x0a 0x13 0x1d 0x4e 0x65 0x74 0x73 0x63 0x61 0x70 0x65 0x20 0x43 0x6f 0x6d 0x6d 0x75 0x6e 0x69 0x63 0x61 0x74 0x69 0x6f 0x6e 0x73 0x20 0x43 0x6f 0x72 0x70 0x2e 0x30 0x1e 0x17 0x0d 0x39 0x35 0x30 0x32 0x32 0x34 0x30 0x31 0x30 0x39 0x32 0x34 0x5a 0x17 0x0d 0x39 0x37 0x30 0x32 0x32 0x33 0x30 0x31 0x30 0x39 0x32 0x34 0x5a 0x30 0x81 0x97 0x31 0x0b 0x30 0x09 0x06 0x03 0x55 0x04 0x06 0x13 0x02 0x55 0x53 0x31 0x13 0x30 0x11 0x06 0x03 0x55 0x04 0x08 0x13 0x0a 0x43 0x61 0x6c 0x69 0x66 0x6f 0x72 0x6e 0x69 0x61 0x31 0x16 0x30 0x14 0x06 0x03 0x55 0x04 0x07 0x13 0x0d 0x4d 0x6f 0x75 0x6e 0x74 0x61 0x69 0x6e 0x20 0x56 0x69 0x65 0x77 0x31 0x2c 0x30 0x2a 0x06 0x03 0x55 0x04 0x0a 0x13 0x23 0x4e 0x65 0x74 0x73 0x63 0x61 0x70 0x65 0x20 0x43 0x6f 0x6d 0x6d 0x75 0x6e 0x69 0x63 0x61 0x74 0x69 0x6f 0x6e 0x73 0x20 0x43 0x6f 0x72 0x70 0x6f 0x72 0x61 0x74 0x69 0x6f 0x6e 0x31 0x16 0x30 0x14 0x06 0x03 0x55 0x04 0x0b 0x13 0x0d 0x4f 0x6e 0x6c 0x69 0x6e 0x65 0x20 0x4f 0x72 0x64 0x65 0x72 0x73 0x31 0x15 0x30 0x13 0x06 0x03 0x55 0x04 0x03 0x13 0x0c 0x41 0x72 0x69 0x20 0x4c 0x75 0x6f 0x74 0x6f 0x6e 0x65 0x6e 0x30 0x5a 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x01 0x05 0x00 0x03 0x49 0x00 0x30 0x46 0x02 0x41 0x00 0xa5 0xa7 0x7b 0x42 0xb1 0x79 0x2d 0x0b 0x35 0x08 0xb4 0x0d 0x74 0x1d 0x46 0x6a 0x29 0x07 0x47 0x08 0xdc 0x3a 0x76 0x36 0xbd 0x7f 0xb3 0xd4 0xa9 0x85 0x9d 0x4b 0x65 0x74 0xc1 0x00 0x56 0xec 0x5a 0x31 0x72 0x23 0x04 0xc1 0xcf 0x78 0x63 0x21 0x77 0x69 0xd9 0xf0 0x61 0xc8 0x73 0xf7 0xdc 0x4c 0xde 0xd2 0x22 0x99 0x79 0xdf 0x02 0x01 0x03 0x30 0x0d 0x06 0x09 0x2a 0x86 0x48 0x86 0xf7 0x0d 0x01 0x01 0x04 0x05 0x00 0x03 0x81 0x81 0x00 0x7e 0x4a 0x28 0x7d 0xba 0xfa 0x41 0x5a 0x19 0x1c 0x9a 0xea 0x6d 0x3b 0x07 0x1c 0x97 0xe0 0xf5 0xf8 0x4c 0xd5 0x92 0x0c 0x1c 0x30 0x49 0x06 0x72 0x42 0x9a 0x3f 0xfc 0x3b 0x11 0x17 0x78 0x7e 0x6c 0x27 0x8a 0x12 0x19 0xf3 0x08 0x18 0x6e 0xe0 0xc3 0xbe 0xe7 0x37 0xbd 0x4e 0xae 0xe1 0x9e 0x4a 0x3b 0xa9 0xbf 0xc0 0x92 0x59 0x2c 0xdb 0x37 0x34 0xc8 0xa0 0xc0 0xba 0xb8 0x6f 0xd3 0xd6 0xc7 0x48 0x88 0xbc 0xd6 0xff 0x7a 0xf7 0x76 0x70 0x2c 0x19 0x07 0xc8 0x7c 0x80 0x29 0x18 0x58 0xfc 0xd1 0x12 0x86 0x99 0x4e 0x32 0xee 0xb9 0xf5 0x11 0x70 0xd5 0x1b 0xf7 0x85 0x5b 0x4a 0x0e 0xd6 0xe6 0x6c 0x52 0xf5 0x8a 0x2c 0x97 0x3e 0x63 0x85 0x57 0x43 0xbc 0x02 0x00 0x80 0xbf 0xeb 0x90 0xf8 0x2c 0x0c 0xe1 0xea 0x18 0xac 0x11 0x4c 0x83 0x14 0x21 0xb6 This is interpreted as follows: 0x82 0x2b Packet length, 555 bytes follow. 0x04 MSG-SERVER-HELLO 0x00 SESSION-ID-HIT 0x01 CERTIFICATE-TYPE 0x00 0x02 SERVER-VERSION-MSB SERVER-VERSION-LSB 0x02 0x0d CERTIFICATE-LENGTH-MSB CERTIFICATE-LENGTH-LSB 0x00 0x03 CIPHER-SPECS-LENGTH-MSB CIPHER-SPECS-LENGTH-LSB 0x00 0x10 CONNECTION-ID-LENGTH-MSB CONNECTION-ID-LENGTH-LSB 0x30...0xbc CERTIFICATE-DATA [525 bytes] 0x02 0x00 0x80 CIPHER-SPECS-DATA 0xbf...0xb6 CONNECTION-ID-DATA [16 bytes] Most of the packet is the certificate. SESSION-ID-HIT is 0 since no session ID was sent by the client. After the 525 (0x020d) bytes of certificate comes the 3 byte code for 40 bit RC4, then the 16 byte connection ID. The main importance of the connection ID data here is that it helps to calculate the session keys as described below. The next message, from the client to the server, is the CLIENT-MASTER-KEY sent mostly in the clear: 0x80 0x55 0x02 0x02 0x00 0x80 0x00 0x0b 0x00 0x40 0x00 0x00 0x0e 0x89 0x94 0xb8 0xbf 0x0e 0xb9 0x2e 0x50 0x44 0x07 0x8c 0x52 0xeb 0xef 0x44 0xc1 0x01 0x4b 0xc1 0x02 0xd2 0x2e 0x37 0x1f 0x1d 0x54 0xc2 0x83 0x45 0x79 0x6b 0xc8 0xe3 0x85 0x17 0xb8 0xd4 0x84 0xc6 0x9f 0xb1 0x6a 0x03 0x2e 0x97 0xae 0x82 0x75 0x10 0xf0 0x7b 0x5f 0x25 0x7b 0x88 0x75 0xc6 0x7a 0x33 0x5f 0xd6 0x96 0x99 0x94 0xd0 0x7a 0x78 0xae 0x50 0x32 0x1a 0xbb 0x66 0x50 It is interpreted as follows: 0x80 0x55 Packet length, 85 bytes follow. 0x02 MSG-CLIENT-MASTER-KEY 0x02 0x00 0x80 CIPHER-KIND 0x00 0x0b CLEAR-KEY-LENGTH-MSB CLEAR-KEY-LENGTH-LSB 0x00 0x40 ENCRYPTED-KEY-LENGTH-MSB ENCRYPTED-KEY-LENGTH-LSB 0x00 0x00 KEY-ARG-LENGTH-MSB KEY-ARG-LENGTH-LSB 0x0e...0x07 CLEAR-KEY-DATA [11 bytes] 0x8c...0x50 ENCRYPTED-KEY-DATA [64 bytes] <none> KEY-ARG-DATA The 11 most significant bytes (88 bits) of "master key" information are sent in the clear as the CLEAR-KEY-DATA. The remaining 40 low-order bits of the 128-bit master key are RSA encrypted using the server's public key, expanding in the process to 64 bytes, and sent as the ENCRYPTED-KEY-DATA. No KEY-ARG-DATA is sent since RC4 doesn't need an initialization vector. Now that these packets have been exchanged, from this point on, all packets are sent encrypted. For each such packet, after the packet length bytes there is a 16-byte Message Authentication Code (MAC). Then comes the RC4 encrypted data itself. Two different session keys are used, both generated from the master key, the 16-byte challenge data, and the 16-byte connection ID data. The CLIENT-READ-KEY, used for data sent from server to client, is calculated as: MD5 (MASTER-KEY, "0", CHALLENGE, CONNECTION-ID). "0" is one byte of 0x30, ascii 0. The CLIENT-WRITE-KEY, used for data sent from client to server, is calculated as: MD5 (MASTER-KEY, "1", CHALLENGE, CONNECTION-ID). "1" is one byte of 0x31, ascii 1. MD5 produces 128 bits of output which are used directly as the key input to the RC4 algorithm. The next message, from server to client, is SERVER-VERIFY. It is sent encrypted: 0x80 0x21 0x37 0x68 0x3a 0x8c 0x7d 0x33 0xb2 0x2f 0xb9 0x66 0xeb 0xd2 0x63 0xcd 0xa7 0xed 0x71 0xa0 0xb6 0x2f 0xb6 0xe2 0x31 0xa4 0x2a 0x81 0xd3 0x25 0x61 0x58 0xbc 0xf0 0xf4 This is interpreted as follows: 0x80 0x21 Packet length, 33 bytes follow 0x37...0xed MAC [16 bytes] 0x71 RC4 encrypted MSG-SERVER-VERIFY (0x05) 0xa0...0xf4 RC4 encrypted CHALLENGE-DATA from CLIENT-HELLO message [16 bytes] The first RC4 encrypted byte is MSG-SERVER-VERIFY (which has a value of 0x05). This is followed by 16 bytes of challenge data from the first client message, encrypted. These 17 bytes represent known plaintext which can be used to easily check any guessed RC4 CLIENT-READ-KEY. Let me make this a little more clear. The first RC4 encryption with the CLIENT-READ-KEY, immediately after key setup, is as follows: Plaintext (MSG-SERVER-VERIFY plus CHALLENGE-DATA): 0x05 0xaf 0x84 0xa7 0x79 0xf8 0x13 0x69 0x20 0x25 0x9b 0x53 0xa0 0x60 0xae 0x75 0x51 Ciphertext (from SERVER-VERIFY packet): 0x71 0xa0 0xb6 0x2f 0xb6 0xe2 0x31 0xa4 0x2a 0x81 0xd3 0x25 0x61 0x58 0xbc 0xf0 0xf4 The next message in the protocol is CLIENT-FINISHED, sent encrypted from client to server: 0x80 0x21 0xed 0x59 0x0a 0x2a 0x80 0x50 0x42 0xec 0xcd 0xed 0x6c 0x96 0x0a 0xab 0x5c 0x0e 0xed 0x55 0xc3 0x21 0x6e 0x34 0x26 0x5b 0x46 0x41 0x35 0x51 0xb7 0xaa 0xec 0x57 0x9f This is interpreted as follows: 0x80 0x21 Packet length, 33 bytes follow 0xed...0x0e MAC [16 bytes] 0xed RC4 encrypted MSG-CLIENT-FINISHED (0x03) 0x55...0x9f RC4 encrypted CONNECTION-ID from SERVER-HELLO [16 bytes] This is the first message sent encrypted with the CLIENT-WRITE-KEY and could also be used as known plaintext to check a guessed key. The next message is SERVER-FINISHED, sent encrypted from server to client: 0x80 0x21 0x79 0x84 0xc6 0xb6 0xde 0xf4 0x4c 0xd2 0x52 0x56 0xdc 0x58 0x23 0xa0 0xfa 0x4d 0x06 0x7d 0x4c 0x12 0x32 0x32 0xea 0xaa 0x5a 0xb6 0xa7 0xb8 0x1a 0x66 0xeb 0x65 0x56 This is interpreted as follows: 0x80 0x21 Packet length, 33 bytes follow 0x79...0x4d MAC [16 bytes] 0x06 RC4 encrypted MSG-SERVER-FINISHED (0x06) 0x7d...0x56 RC4 encrypted SESSION-ID-DATA [16 bytes] The SESSION-ID-DATA has not been previously sent in the clear. It would be used to cache the key info for a future session. >From here on out, the handshaking is done. Every message sent will be encrypted and packetized. The first two bytes are packet length, then 16 bytes of MAC, then the data. First data message from client to server. Presumably it is an http "GET" request, with form information embedded in the URL. This is the main one to try decrypting (starting with 0x6b as the first encrypted byte). 0x82 0xf8 0x07 0x97 0xef 0x99 0x66 0x45 0x48 0x22 0xe4 0xdc 0x31 0xe4 0xf9 0x0b 0xb9 0x98 0x6b 0x99 0x2a 0x09 0x29 0xae 0xa6 0x8d 0xbf 0xb0 0xd3 0xa6 0x83 0xec 0x69 0x1c 0xcc 0x11 0x66 0x84 0x21 0x77 0xfb 0x86 0x73 0x10 0xfb 0xa9 0xe3 0x3b 0x2f 0xd4 0x0f 0xb9 0xbd 0x3f 0xa4 0x0b 0x41 0xd5 0xc9 0x90 0x6d 0xa7 0x34 0x7a 0x5a 0xc1 0x69 0x8d 0xe9 0x64 0xad 0x0d 0xa8 0xae 0x91 0xd1 0xa6 0x70 0xac 0xf9 0xe6 0x11 0x38 0xa0 0xa7 0xd9 0x7c 0xc7 0x18 0x17 0xe2 0x0d 0x8d 0x30 0xb0 0x1c 0x22 0x25 0xa3 0x61 0xee 0xa2 0xca 0xe5 0xf8 0x20 0x5b 0xe1 0x58 0xcf 0xa5 0x21 0xe3 0x23 0xa6 0xfb 0xf6 0x2b 0xba 0x69 0xca 0xa3 0xe6 0x4a 0x47 0x4c 0x77 0xb8 0xc2 0x93 0x8e 0xb7 0x5d 0x17 0x06 0x57 0x19 0x6e 0x00 0x34 0xd6 0xc5 0x64 0x5e 0x23 0x60 0x03 0xf9 0xb2 0x9d 0xee 0xb4 0x83 0x28 0xae 0xfe 0xbb 0xb0 0xe3 0x49 0xfc 0x8f 0x68 0x24 0x51 0x03 0x26 0x8f 0x2b 0xcd 0xc1 0x0c 0x6d 0x79 0xed 0xc4 0x7f 0x3a 0x1e 0x2a 0xc5 0x4e 0xd8 0xe9 0x35 0x27 0xb7 0xde 0x50 0xc3 0xac 0x49 0x84 0x55 0x90 0xa6 0x44 0xcb 0xf7 0xfc 0x69 0xb4 0x19 0xea 0xb6 0xf0 0x72 0x37 0xef 0xfc 0xdf 0x20 0xaf 0x34 0x10 0xa8 0xf9 0xc2 0x74 0xa8 0x64 0xb2 0xd5 0xe9 0x25 0xd8 0xf2 0xca 0xf6 0xb6 0xa0 0x35 0x6f 0x3c 0x6c 0x4c 0xc6 0x99 0x4e 0x51 0xc4 0x5c 0x32 0x8e 0x0b 0x7c 0x59 0x7b 0xda 0x19 0x3f 0x89 0x7b 0xd3 0x33 0x9c 0x2d 0x20 0x46 0x59 0x26 0xb4 0x20 0x61 0x54 0x49 0xb8 0x71 0xa4 0xde 0x2b 0x7b 0xf3 0xdd 0xb2 0x64 0xa1 0x1a 0x39 0x4b 0x50 0x20 0x21 0x6a 0x9c 0x3d 0x34 0xaf 0x91 0xf4 0x2e 0xe1 0x4c 0x74 0x6a 0xed 0x4e 0x18 0x3d 0x11 0xe5 0xa9 0xf6 0x87 0xb3 0x7a 0xf0 0xf1 0x5e 0x9b 0x9c 0x1f 0xc0 0x44 0x72 0xdc 0xc3 0xe9 0x62 0x88 0x0b 0xec 0x3c 0x71 0x29 0x99 0xac 0xfa 0x1f 0x31 0xdd 0xae 0x5f 0x84 0x3c 0x16 0x04 0xdb 0x9d 0x4b 0xbb 0xdf 0x6c 0x32 0x0e 0xa0 0xe7 0xa0 0xdc 0x6a 0xa5 0x49 0x12 0xd7 0x59 0xce 0x3c 0x5d 0x36 0x46 0xbf 0x0b 0xcb 0xf7 0x0e 0x41 0x50 0x37 0x53 0xb5 0xdf 0x6d 0xc0 0x7e 0x7f 0x35 0x75 0xf5 0xec 0xad 0x40 0xb5 0x69 0x3c 0xb7 0x5c 0x44 0x0b 0x48 0xe6 0x07 0x41 0xb8 0x4c 0x9d 0x2c 0x4c 0xdf 0xf3 0xa7 0x15 0xcf 0x12 0xdd 0x11 0xcb 0xeb 0x3b 0x89 0x11 0x2e 0x6b 0x84 0x1a 0x3d 0xd9 0x25 0xa2 0x51 0xed 0xdf 0x93 0x76 0x86 0xc4 0xa4 0xcb 0xe8 0x5c 0xd8 0x7a 0x41 0x7d 0xc8 0x70 0xa1 0x0c 0xa1 0xd8 0xda 0xe2 0x75 0x05 0x0b 0x0b 0x83 0x3c 0x6c 0x71 0x13 0x42 0x19 0xcd 0x5d 0xd0 0x99 0x7b 0x24 0xc9 0x7b 0xc2 0x1c 0x2e 0x6e 0x78 0xe0 0xad 0x7f 0x7b 0x4b 0x50 0x33 0x7e 0xa0 0xb9 0x93 0xf4 0x75 0x39 0x50 0x41 0x41 0xe3 0x2b 0x0f 0xf1 0xf3 0xbc 0x84 0x9d 0x6f 0xa7 0x27 0xa7 0x58 0x55 0x8d 0xc7 0xf1 0xa1 0xb8 0x60 0x6f 0x0f 0x19 0xac 0xea 0xef 0x2c 0xba 0x90 0x9b 0x79 0x7b 0x61 0x54 0x03 0xf6 0x92 0x10 0xb4 0x9c 0x78 0x85 0xf3 0x7b 0x3f 0x0e 0xf9 0x8e 0x3d 0xa3 0x43 0xab 0xf4 0x33 0xa4 0x55 0x4b 0x86 0x50 0x75 0x93 0x3a 0x50 0x24 0xae 0x70 0x0c 0xde 0xa7 0x52 0x28 0x43 0x07 0x35 0x5c 0x5a 0xeb 0xc0 0xe1 0xba 0x8c 0xcd 0x76 0xdc 0x07 0x1f 0xa4 0x57 0xdd 0x18 0xa3 0x4e 0xc3 0xf3 0x7b 0x2d 0x0e 0x6b 0xb9 0x92 0xc1 0xfb 0x54 0xc8 0xd7 0x33 0x31 0x43 0xe1 0xce 0xb5 0x89 0xbd 0x0d 0x4e 0x14 0xbc 0x64 0xc5 0xf6 0x28 0x58 0x84 0x64 0xe7 0x8c 0xb2 0xa9 0xd2 0x0b 0x9f 0x1c 0x28 0xfd 0x95 0x93 0x8e 0x51 0x9a 0x5b 0xeb 0x0d 0x51 0x60 0x93 0x35 0x7c 0x59 0x7d 0x6f 0x37 0xbd 0xa4 0x9b 0x2d 0x4f 0x75 0x92 0xbe 0x85 0xc6 0xc3 0x68 0xf6 0x41 0xcc 0x51 0x4c 0xfc 0xda 0x21 0xc3 0x77 0xc1 0xe2 0x79 0xe8 0x0d 0xc7 0x26 0xc3 0x14 0x9e 0x48 0x2f 0xa4 0x95 0x21 0x24 0x61 0x31 0xd5 0x3b 0x14 0x42 0x45 0xd1 0x6d 0x90 0xfe 0x72 0x28 0xa7 0x81 0xe9 0x07 0x47 0x8a 0x0d 0xda 0x08 0x99 0xbc 0x76 0x42 0xec 0x0b 0xfd 0xeb 0x69 0x47 0x58 0xd7 0x81 0x6b 0x71 0xf6 0xb6 0xbe 0xcd 0x4e 0x29 0xd9 0xdb 0xc8 0x12 0x5c 0x46 0xa0 0x3c 0x5b 0x57 0x2b 0x59 0x92 0x36 0x3c 0x6a 0xc3 0x4a 0x13 0x41 0x34 0x2f 0x12 0x13 0xa2 0x51 0xfb 0xf2 0xe0 0x0b 0x2f 0xfc 0x14 0x25 0xad 0x60 0x3a 0x35 0x62 0x7e 0xd2 0x11 0x4c 0x4a 0x29 0xa4 0xca 0x44 This is the first data packet response from the server: 0x80 0x84 0x16 0xc9 0xe0 0x80 0xd6 0x0b 0x4e 0xd8 0xfe 0x00 0xce 0xe2 0x07 0xe1 0xec 0xb9 0x03 0xa8 0x51 0x0b 0xc9 0xd5 0xd9 0x27 0x59 0x07 0x83 0x0c 0x2b 0x75 0x24 0x50 0xcf 0x0c 0xd2 0x8e 0x7b 0xbc 0xbe 0x65 0x48 0x23 0xc9 0xdb 0x82 0x2f 0x54 0x50 0x3b 0xf2 0x50 0xd3 0x15 0x30 0xec 0x78 0xa2 0x61 0x09 0x9a 0x2a 0xc8 0x9c 0x07 0x67 0x70 0x44 0x46 0xca 0xe4 0x65 0x1a 0x0e 0xd9 0x2a 0x77 0xeb 0xc1 0x7e 0x37 0x83 0x43 0x2e 0x26 0xde 0x5f 0x9d 0xa3 0x31 0x87 0xf2 0xe1 0x4f 0x67 0x8d 0xfc 0x4f 0x3f 0x00 0x2c 0x40 0x70 0x34 0x2b 0x62 0x80 0xcf 0x0d 0x93 0xff 0xc9 0x5e 0xd2 0x21 0xf6 0xa4 0xf4 0xd7 0x13 0x13 0x59 0x44 0x6c 0xd1 0xd1 0x05 0x8f 0x5f 0x15 0x10 0x08 0xed Here is the second data packet response from the server: 0x81 0x04 0xc9 0x4c 0x54 0xcb 0x2c 0xe0 0x8e 0xf9 0x13 0x31 0xb4 0xf1 0x82 0x92 0xd3 0x65 0xc9 0x45 0x7e 0x0f 0x8e 0x54 0x4f 0x7f 0x35 0xc8 0x20 0xa8 0x55 0x18 0x1e 0x27 0x5d 0x6a 0x53 0x79 0xd2 0x2e 0x01 0x5d 0x06 0x25 0x6f 0xaa 0x49 0x68 0x73 0x4e 0x35 0x6b 0x87 0x47 0x6d 0x26 0xb6 0xb0 0x1e 0xd0 0x96 0xd5 0xe6 0x4f 0x94 0x10 0x9f 0x5f 0x83 0x7e 0x0c 0x67 0x36 0x82 0xce 0xcb 0xb1 0xd5 0xc9 0xf9 0xf5 0x32 0xa9 0xf3 0x31 0xbf 0x40 0xe4 0xa6 0x24 0x0e 0xc3 0xfe 0x61 0x24 0x59 0x9d 0x85 0x35 0x0d 0x7d 0xbe 0x16 0x0b 0x8a 0x98 0x74 0x7b 0x5a 0x37 0x73 0x30 0xd9 0x66 0x6c 0x65 0xaf 0xd4 0xc7 0x2a 0x8f 0x14 0xe3 0xf6 0x06 0x63 0x19 0x53 0xc5 0x9a 0x69 0x63 0x29 0x04 0x7a 0x28 0x0e 0x7b 0x17 0xf3 0x60 0xee 0x9d 0xbd 0xe5 0x00 0x0a 0x9d 0x1b 0xc5 0x26 0x93 0x19 0x78 0x43 0x2f 0xe4 0x9a 0x27 0x3c 0x13 0x03 0x9c 0xab 0xad 0xad 0xe1 0xbd 0x8b 0x7c 0x04 0x74 0x7e 0x08 0x50 0xa6 0x19 0x28 0xb7 0x6c 0xbe 0x2b 0x48 0x14 0xd2 0xcb 0xa6 0xad 0x69 0x41 0x31 0x93 0x3a 0x8d 0x87 0x78 0x80 0xc1 0x85 0xa5 0x7a 0x79 0xd1 0x55 0xca 0xb8 0x94 0x0b 0x65 0x3e 0xf2 0x51 0x8d 0xae 0x89 0x87 0x96 0xae 0xd5 0x4d 0x2f 0x14 0x66 0xe6 0xcc 0x63 0x2f 0x50 0x98 0x98 0x59 0xfa 0xf6 0xeb 0xb6 0x44 0x9d 0xc2 0x6c 0xe2 0x7d 0xc9 0x47 0xfa 0x3d 0xa4 0x6b 0x71 0x52 0xcc 0x15 0xdf 0xb3 0x92 0x3f 0x67 0x8e 0x9e 0x84 0xd6 0x39 0xa0 This ends the communication. To try to attack this, the most effective approach would be to calculate CLIENT-READ-KEY by trying all possible values for the 40 least significant bits of the MASTER-KEY, and feeding that into the MD5 formula. Then use the known plaintext in the SERVER-VERIFY message to check the result. Once the proper 40 bit value is found, CLIENT-WRITE-KEY can easily be calculated and the data messages decrypted. Good luck! Hal Finney hfinney(a)shell.portal.com

3 2

Re: Don't trust the net too much
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <doug-9506121351.AA0053320(a)netman.eng.auburn.edu>, Doug.Hughes(a)Eng.Auburn.EDU (Doug Hughes) wrote: >Go see Winn Schwartau talk about HERF guns sometime. He passed around >a picture of a device for < US$500 that could crash any computer within >50 yards.. Then again, it isn't too good for the person firing the gun URL, anyone? I'd like to build one of those devices. - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMAQFfSoZzwIn1bdtAQGWBQF/YHqHS5rJfVnuLDd3SV+oq1KhXsP47mE8 WW6IPO+mCDlN+liSfU/4NujUT7mAfLl1 =G/P3 -----END PGP SIGNATURE-----

1 0

Re: RACIST MILITIA: ATF
by John Young 17 Dec '03

17 Dec '03

Responding to msg by alanh(a)infi.net (Alan Horowitz) on Wed, 12 Jul 6:21 PM For those in time-zones west of NYC, NBC Lightly News covers the ATF happy campers, and interviews the majordomo, who solemnly meins that he will investigate and do what's right. Another NBC LN item: DOJ is to "re-open" the look at the Ruby Ridge carnage.

1 0

17 down 696 to go /repost
by Censored Girls Anonymous 17 Dec '03

17 Dec '03

Something's wrong with the Primenet Mail server I think. I'm in pine, off the shell, so I can't sign it. Love Always, Carol Anne PGP.ZIP PART [017/713] This just cycles through: when part 713 is reached, part 0 will be recycled. We are on export 0 at the moment. _________________________________________________________________ ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ _________________________________________________________________ Warning: it may be illegal to use one of these as a sig file in the US Don't feel obliged to use this chunk just because you have requested it. It hardly matters if some parts aren't posted as there are easier ways to get PGP, like open ftp sites, from which it is 100% legal for both US and non-US people to ftp from. It is merely a political statement about the ridiculous nature of ITAR regulations Member Internet Society - Certified BETSI Programmer - WWW Page Creation ------------------------------------------------------------------------- Carol Anne Braddock <--now running linux 1.0.9 for your pleasure carolann(a)censored.org __ __ ____ ___ ___ ____ carolab(a)primenet.com /__)/__) / / / / /_ /\ / /_ / carolb(a)spring.com / / \ / / / / /__ / \/ /___ / ------------------------------------------------------------------------- A great place to start My Cyber Doc...

1 0

Re: Q E D_j a k
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

> The American intelligence establishment today unveiled > one of its oldest secrets: how a small team of > codebreakers found the first clues that the Soviet Union > sought to steal the blueprints for the atomic bomb in Wow! They must really be looking for some good publicity these days. I wonder how much of their motivation is to get PR support for the black budget, and how much is to support continued crypto export laws? After all, if the Evil Foreigners had good crypto, the NSA wouldn't have been able to crack their codes, so therefore it's _vital_ to _national_security_ that we continue these great laws that are keeping good crypto securely locked up inside the US borders! (Yes, I know one-time-pads are provably good crypto, but they also depend on the security of key distribution and one-time use, which apparently broke down here. And the CIA's pretty good at chasing the guy with briefcases of code material handcuffed to their arms.) Watch for more pressure from the Administration.... # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com

2 1

Re: Don't trust the net too much
by johnl＠radix.net 17 Dec '03

17 Dec '03

> A transistor radio puts out such a minute amount of RF (at 455 KHz and/or > 10.7 MHz, the IF freqs of the radio) that most insturments designed to > pick up RF can't detect this stuff from more than a few feet away. The problem is caused by local oscillator radiation interfering with the ILS receiver. Tune a FM broadcast band receiver to the right frequency and you get local oscillator radiation at (f + 10.7 MHz), right in the middle of the aviation band. //---------------------------------------------------------------------------- // John A. Limpert // johnl(a)radix.net

1 0

Re: QED_jak
by hardin＠cyberspace.com 17 Dec '03

17 Dec '03

Perry Metzger writes: > > > John Young writes: > > "U.S. Tells How It Found Soviets Sought A-Bomb: Discloses > > Clues That Led to Code-Breaking." > > [snip] > The reports claimed the spys were using one time pads in some flawed > manner, but did not explain very well what the problem was. Does > anyone out there know? > > .pm > > > A real good book with a fair amount of details is Peter Wright's great book "Spycatcher". The clueless media concentrated on Wright's allegation that Sir Roger Hollis, head of MI5 was a Soviet mole or the "5th Man" of the Philby, Burgess, Maclean & Blunt spyring. Now Wright may have been in Jesus Angleton's psychotic "wilderness of mirrors" too long, but he did a lot of bugging & stuff w/ GCHQ & he spends a great deal of his book talking about precisely the Venona decrypts. Briefly there was some reuse of "one time pads". He gives a fair amount of detail, & I suspect this is why HRM Govt. was so displeased, the supposed "embarrassment" of the allegations against long dead Sir Roger being just a cover story & much easier for the tabloids & general public to understand. tjh This is 1/713 of PGP262i DOS Executable Zipfile UUE'd Violate the Un-Constitutional ITAR Today! Get YOUR chunk @ web site below. ------------------ PGP.ZIP Part [005/713] ------------------- M@UIXP9EW\".^Q0XL1SO8"^*_O:U-=H(P&2,1A6YHB?KP@@H2/)$+P@-<PX_( MPTGLPBHDHSW<(,<O,D$XB'2TA`HQ4D'H@R#<)[Z3*D$P80%N*8D1:Q6"T`\J M/*/<G_$-/L9&%#L)P@HD82`ZHPG4$%#L*`A7D8M#F(/>"($GRAT$8246(Q:3 ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

RSA129 Project
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

Could someone point me to information about the RSA129 factoring project? I would like the see the programs involved, and learn a little about the coordinating efforts. ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

4 3

Anti-Electronic Racketeering Act of 1995 (fwd)
by Brad Dolan 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Wed, 12 Jul 1995 15:28:25 -0400 Subject: Anti-Electronic Racketeering Act of 1995 On June 27, Sen. Grassley introduced extensive criminal amendments to the federal racketeering act. S. 974, the "Anti-Electronic Racketeering Act of 1995," would amend U.S. Code sections 18 USC 1961 (criminal RICO statute), 18 USC 1030A (new section on computer crime), 18 USC 2515, 2516 (wiretapping), and 42 USC 2000aa (Privacy Protection Act). This proposed legislation is Very Bad. It would make all encryption software posted to computer networks that are accessible to foreigners illegal *regardless of whether the NSA has classified the software as a munition!!!* Here's the language: "Sec. 1030A. Racketeering-related crimes involving computers "(a) It shall be unlawful-- . . . "(2) to distribute computer software that encodes or encrypts electronic or digital communications to computer networks that the person distributing knows, or reasonably should know, is accessible to foreign nationals and foreign governments, regardless of whether such software has been designated nonexportable."

14 17

Re: [rah@shipwright.com: Re: digital monies]
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Steve, I'm forwarding this to cypherpunks, where this posting originated. Always ready to set the record straight. By the way, could I have an email copy of your original posting/publicity material for this, I'm curious about where it was announced to the net. Tighten up my links to the straight dope, etc. Thanks! Bob Hettinga >Bob, > >Carl Ellison at TIS brought this to my attention. We'll provide you with a >lengthier response in a bit, but let me comment briefly that the following >contains a number of inaccuracies. Two of particular note: Citibank is not >a principal in CyberCash, and the vaporware footnote is peculiar because >our system has been operational since early April and the client software, >which runs as a "viewer" with a number of browsers, is available from our >web site for downloading around the world. > >Steve > > >>CyberCash >>The last I heard from these guys, a "consortium" of various heavies like RSA >> and I believe Citibank even, was an article plastered all over the >>Marketing section of the Wall Street Journal last fall. To my knowlege they >>haven't come up for air. My memory of 'consortia' like this one, and >>Citicorp in particular (who was trying to reverse engineer Chaum's Digicash >>patent last time I looked), leads me to believe this dog won't hunt, or at >>least not until the coon's already been treed, anyway. Cf: Citi's Quotron >>boondoggle. > >-------------------- >Steve Crocker >CyberCash, Inc., Suite 430 Work: +1 703 620 4200 >2100 Reston Parkway Fax: +1 703 620 4215 >Reston, VA 22091 crocker(a)cybercash.com ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: NSA, Random Number Generation, Soviet Codes, Prohibition of Crypto
by Carl Ellison 17 Dec '03

17 Dec '03

If I remember correctly from "Spycatcher", the Soviets misused the one time pad allowing the Verona breaks, by using it twice, not by making slightly weak rannos. Of course, in this business, anything you read/hear could be a cover story. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme/home.html | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +----------------------------------------------------------- Jean Ellison -+

1 0

Re: Capt. Midnight decoder badges
by Carl Ellison 17 Dec '03

17 Dec '03

25 13 23 20 26 2 17 13 16 11 12 18 9 12 16 11 13 23 16 7 2 13 9 12 2 5 16 11 4 7 4 25. 11 13 9 15 13 2 5 17 13 4 18 12 16 16 26 7 4?

1 0

the sound of another shoe dropping...
by Matt Blaze 17 Dec '03

17 Dec '03

------- Forwarded Message Forwarded message: >From farber(a)eff.org Wed Jul 12 16:41:13 1995 Posted-Date: Wed, 12 Jul 1995 15:28:18 -0400 X-Sender: farber(a)linc.cis.upenn.edu Message-Id: <v02110184ac29d2a1b404(a)[130.91.88.102]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) Date: Wed, 12 Jul 1995 15:28:25 -0400 From: farber(a)central.cis.upenn.edu (David Farber) Subject: Anti-Electronic Racketeering Act of 1995 Precedence: list To: interesting-people(a)eff.org (interesting-people mailing list) X-Proccessed-By: mail2list Date: Wed, 12 Jul 1995 14:00:23 -0400 From: ssteele(a)eff.org (Shari Steele) Heavy sigh. On June 27, Sen. Grassley introduced extensive criminal amendments to the federal racketeering act. S. 974, the "Anti-Electronic Racketeering Act of 1995," would amend U.S. Code sections 18 USC 1961 (criminal RICO statute), 18 USC 1030A (new section on computer crime), 18 USC 2515, 2516 (wiretapping), and 42 USC 2000aa (Privacy Protection Act). This proposed legislation is Very Bad. It would make all encryption software posted to computer networks that are accessible to foreigners illegal *regardless of whether the NSA has classified the software as a munition!!!* Here's the language: "Sec. 1030A. Racketeering-related crimes involving computers "(a) It shall be unlawful-- . . . "(2) to distribute computer software that encodes or encrypts electronic or digital communications to computer networks that the person distributing knows, or reasonably should know, is accessible to foreign nationals and foreign governments, regardless of whether such software has been designated nonexportable." I'm up to my ears in analyses that need to be written, but I'll send around something more complete when I'm able to pull it together. Shari ------- End of Forwarded Message

2 1

Re: Is there a moderator in your future?
by roger＠coelacanth.com 17 Dec '03

17 Dec '03

In article <9507102137.AA26662(a)spirit.aud.alcatel.com> droelke(a)spirit.aud.alcatel.com (Daniel R. Oelke) writes: > Why is Dyson of EFF enthusiastic about the concept? Because as moderators add value to the vast amount of stuff out there. Why do some people pay to get a restricted subset of the cypherpunks? Because they don't want the massive flow of wide open communications and they *trust* the person giving them the subset. Moderators provide a great service, and it is finially being recognized as such in a monetary way. I think that this is a great thing! I agree that moderated groups are useful at keeping the SNR high, and are a great choice for those who can't or haven't time to set up their own filters. However, they can't solve the problems that the Internet is popularly supposed to have (e.g. no provisions for eliminating parental responsibility). Even supposing that US ISPs are *prohibited by law* from carrying unmoderated Usenet groups, how does this address all of the other services (current and future) that can be carried by the Internet? Sorry, the horse is out of the stable, and the only 99% control option open to the government now is cutting the phone lines at the border. If an individual (e.g. a parent) wants to limit net access for certain services to emasculated resources, perhaps Microsoft Restrict (TM) and Prodigy can provide a desired service. Otherwise, the solution to the problem has to lie closer to home. -- Roger Williams -- Coelacanth Engineering -- Middleborough, Mass #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% Sa2/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||die"$0 [-d] k n\n")&~1)/2)

1 0