December 2003 - cypherpunks-legacy

Re: Attorneys: RSA patent invalid
by Michael C Taylor 17 Dec '03

17 Dec '03

At 05:29 PM 23/07/97 -0700, you wrote: >$25K upfront is prohibitively expensive for freeware and >for garage-shop programmers. It's a drop in the bucket for a >large project such as Netscape that wants to add some security, >but in a 3-person-month email widget it's excessive. > >On the other hand, it's now possible to license RSAREF for a much >more reasonable fee from Concentric; I think it's just per-copy >rather than a big up-front hit. As of March, 1997 Consensus Development (www.consensus.com) stopped licensing RSAREF for a very reasonable amount (~$200 US + 2-3% range I think it was??) Consensus' "SSL Plus" toolkit requires licensee to also license BSAFE from RSADSI. Maybe too many people were using commerical RSAREF licenses rather than the BSAFE toolkit. -M

1 0

Revisionist Reinterpretation
by chen＠intuit.com 17 Dec '03

17 Dec '03

Blanc writes: > Responding to msg by Jim choate, quoting another: > > >> We might also add Shay's Rebellion, Bacon's > >Rebellion, the Hudson > >> River Renters' Uprising, the Pullman Strike, the > >Homestead Strike, the > >> Ludlow Massacre, the Lawrence Textile Strikes, etc., > >etc. Many of > >> these were full-scale insurrections. This country's > >"progress" is > >> really just a series of grudging concessions made by > >authoritarian > >> power structures to various nearly catastrophic > >crises. > > I have a hard time comparing any of these histricaly > important but comparatively minor events to the half a > million dead of the Civil War or the 50,000+ dead of > Vietnam. Perhaps you have extended the analogy a > little too far?... > .......................................................... > > I think he was talking about the Principle of the deal, Jim - > about what this means regarding the relationship of the > citizenry to the big G. > Put all of those insurrections together and what do they spell? > > F _ _ _ _ _ F Blanc is right. You are correct, Jim, in that in terms of destruction, the wars you mention surpass in magnitude the other events that I listed (though I'll point out that if we count Indochinese dead, Vietnam's cost was far higher than 55,000, even if we add in the more than 60,000 who committed suicide in the aftermath). What I am really saying is that we are not, even in "normal" times, the slightly rambunctious but contented citizenry that popular mythology makes us out to be. This country has serious problems, and it always has. I think that we may be in agreement on this. Another good point that you've made elsewhere is the importance of economics as a motivator. I believe that you are exactly right. I'd like to add more, and also to say something about the perceptive comments from John Young, but I think I have a flu, so I'll go home and pick this up again on Monday. Meanwhile, wishing you all a good weekend. . . . - Mark - -- Mark Chen chen(a)netcom.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D

1 0

Re: your mail
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

What do you put in the Subject: line of an encrypted or anonymous message? We need something standard to prevent traffic analysis on this field. My suggestion is always to put "Subject: Re: your mail", since so much mail already has that, due to a feature of the popular mailer elm. If there is no standard, one could correlate Subject: patterns with people. Notice this message has been sent through "fmt" (and almost through "spell") to remove more nuances. Next we need an English-to-bland-English translator that smooths over individual language features (unless you're practicing stegonagraphy, then you want one that inserts them!)

2 1

Gopher access to Federal Register
by gnu 17 Dec '03

17 Dec '03

Gopher to gopher.internet.com, port 2002, and you will find the Federal Register online. For most documents, you can only get the first 100 lines, but the use of the indexes is free, and many documents are useful in this form. You can pay them for access to the full documents, but they prohibit republishing online -- though you're free to print the documents out. What heart these guys have! John

2 1

Source code
by David Colston 17 Dec '03

17 Dec '03

In case any one is interested, I have the source code for a non-RSA public key system. I wrote it in Microsoft PDS 7.1, which is a version of quick basic. It does 1024 bit keys and I can out run PGP in Basic<G>. If anyone out there is a semi-mathematical type, I will also furnish a paper on the subject. Since this is non-RSA and I'm sure everyone reading this is in the U.S., I don't think I'm involation of ITAR<G>. Uncle Dave

1 0

Re: Standard Headers for Anonymous Remailers
by Eli Brandt 17 Dec '03

17 Dec '03

> From: gtoal(a)an-teallach.com (Graham Toal) > Actually it wasn't the content of the articles that narked me, it was > that I actually wanted to *reply* to the authors. However the subjects > were way too off-topic to be worth responding to in public, which is > the only option the anonymous remailers allows. Though it's a bit clunky to use, the present remailers do support return addressses. I will admit that I haven't seen anybody supply one. Eli ebrandt(a)jarthur.claremont.edu

1 0

Bidzos on PGP and ITAR verbatim
by L. Detweiler 17 Dec '03

17 Dec '03

Bidzos comments on PGP related to ITAR, from sci.crypt a while ago (not sure of date). Essential argument: it was illegally exported, and ITAR prohibits re entry of things illegally exported, therefore it is illegally imported. Relevant section, Software export: Section 123.2 of the ITAR reads: >"123.2 Imports. > >No defense article may be imported into the United States unless (a) >it was previously exported temporarily under a license issued by the >Office of Munitions Control; or (b) it constitutes a temporary >import/intransit shipment licensed under Section 123.3; or (c) its >import is authorized by the Department of the Treasury (see 27 CFR >parts 47, 178, and 179)." There is a section on `illegal export of unclassified technical data to foreign nationals' (paraphrase) and Bidzos claims it applies to PGP export. But he appears to me to be using a bit of sleight of hand to conflate this category with *cryptographic software* mentioned elsewhere (sections also as quoted also by H. Finney). I'll let others pick it apart for the loopholes. ===cut=here=== Date: Mon, 20 Sep 93 19:31:08 PDT Message-Id: <9309210231.AA16113(a)RSA.COM> To: ld231782(a)longs.lance.colostate.edu In-Reply-To: "L. Detweiler"'s message of Mon, 20 Sep 93 19:57:35 -0600 <9309210157.AA04992(a)longs.lance.colostate.edu> Subject: PGP & ITAR Here's the ITAR part. (This was posted in 1992, so I don't know, since pgp has changed since then I understand, how it would apply.) Also, the ITAR has changed recently, and I haven't studied the changes to see how they would affect these comments. Risks of using pgp One should be careful about assuming that the documentation in electronically distributed software is accurate, especially where law is concerned. There are a few things the documentation for a program called "pgp" does not tell you about patent and export law that you should be aware of. Further, there are a number of claims and offered interpretations of patent and export law that are simply false. pgp seems to be an attempt to mislead netters into joining an illegal activity that violates patent and export law, letting them believe that they run no serious risk in doing so. EXPORT LAW pgp leads users to believe that it has circumvented export controls "...since it is not illegal to import..." You are led to believe that since you didn't import it, it's legal to use it. The "no import restrictions" claim has been made so many times, many people probably believe it. One would be well advised not to accept this legal opinion. While stated as if it were a well-known fact, the claim that "there are no import restrictions" is simply false. Section 123.2 of the ITAR (International Traffic in Arms Regulations) reads: "123.2 Imports. No defense article may be imported into the United States unless (a) it was previously exported temporarily under a license issued by the Office of Munitions Control; or (b) it constitutes a temporary import/intransit shipment licensed under Section 123.3; or (c) its import is authorized by the Department of the Treasury (see 27 CFR parts 47, 178, and 179)." Was pgp illegally exported? Was pgp illegally imported? Of course. It didn't export or import itself. pgp 1 was illegally exported from the U.S., and pgp 2, based on pgp 1, is illegally imported into the U.S. Is a license required? According to the ITAR, it is. 125.2 Exports of unclassified technical data. Paragraph (c) reads: "(c) Disclosures. Unless otherwise expressly exempted in this subchapter, a license is required for the oral, visual, or documentary disclosure of technical data to foreign nationals in connection with visits by U.S. persons to foreign countries, visits by foreign persons to the United States, or otherwise. A license is required regardless of the manner in which the technical data is transmitted (e.g., in person, by telephone, correspondence, electronic means, telex, etc.)." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What is "export?" Section 120.10, "Export," begins: "'Export' means, for purposes of this subchapter: ...(c) Sending or taking technical data outside of the United States in any manner except that by mere travel outside of the United States by a person whose technical knowledge includes technical data; or..." Crypto software is controlled by the ITAR. See Part 121, the Munitions List, includes Category XIII, of which paragraph (b) reads, in part, "...privacy devices, cryptographic devices and software (encoding and decoding), and components specifically designed or modified therefore,..." A further definition in 121.8, paragraph (f) reads: "Software includes but is not limited to the system functional design, logic flow, algorithms, application programs, ..." pgp encourages you to post it on computer bulletin boards. Anybody who considers following this advice is taking quite a risk. When you make a defense item available on a BBS, you have exported it. pgp's obvious attempts to downplay any risk of violating export law won't help you a bit if you're ever charged under the ITAR. Penalties under the ITARs are quite serious. The ITARs were clearly designed to put teeth into laws that make exporting munitions illegal. It's unfortunate that cryptography is on the munitions list. But it is. pgp is software tainted by serious ITAR violations. ------- End of Forwarded Message

7 8

GOPHER: now on port 70
by Karl Lui Barrus 17 Dec '03

17 Dec '03

Cypherpunks, Chael has made the necessary changes, and the cypherpunks gopher now listens to port 70 as standard gophers do... So 'gopher chaos.bsu.edu' or 'gopher 147.226.53.28'. I will look into announcing the site to the gopher list maintainers at UMN; perhaps some sites that are able to look up chaos.bsu.edu consistently will consider including a pointer to us! Karl Barrus <klbarrus(a)owlnet.rice.edu>

1 0

Why RSA?
by derek＠cs.wisc.edu 17 Dec '03

17 Dec '03

Is there some reason that we shouldn't pick a different public key encryption algorithm than RSA to use as a freely-available standard? The PGP docs imply that "almost" all practical such schemes are patented, implying that some are not. The legitimacy problems of PGP are a major roadblock to widespread use of encryption, IMO. Let's get something in the public domain! derek

3 3

jarthur is running pgp 2.3
by Eli Brandt 17 Dec '03

17 Dec '03

Just tested a 2.3-encrypted message through here, and it seems to be working. Share and enjoy. Eli ebrandt(a)jarthur.claremont.edu

1 0

Master Key: A Clipper Story
by remailer＠netcom.com 17 Dec '03

17 Dec '03

MASTER KEY ~~~~~~ ~~~ by Infocalypse an36586(a)anon.penet.fi September 21, 2002 This file contains important information regarding the Skipjack standard encryption system. Please read this file through before coming to any conclusions. Please do not ask me who I am. I have no intention of revealing my identity. I will start at the beginning. The Skipjack encryption system, initially known as Clipper, was first publicly announced in mid- 1993. After an initial storm of controversy died down, escrow agents were selected and the chip went into production in early 1994. Several major hardware vendors used Skipjack, and sales began to accelerate in the third quarter of 1994 as business users recognized the advantages of the convenient, inexpensive, and highly secure system. By the first quarter of 1995, Mykotronx could no longer keep up with the orders, and demand was still increasing rapidly. Several other electronics companies came forward, arguing that they could manufacture Skipjack chips more cheaply than Mykotronx, in larger volume, and with at least equal security. The NSA hesitated to give more companies its classified algorithm, but at the same time, they certainly did not want Skipjack to die from lack of available hardware just as it was becoming a standard. After a delay and threats of restraint-of-trade lawsuits, NIST released a set of security requirements. Any company which met them could receive the classified algorithm and make Skipjack chips. Numerous companies jumped in immediately. By Christmas 1995, the price of Skipjack chips had fallen sharply. Secure telephones were rapidly becoming a consumer product, just as the telecom companies started their Christmas advertising drive. Remember these slogans? "This Christmas, Give The Gift Of Privacy. AT&T Secure Telephones!" "Motorola Secure Cellular Network. Because It's Nobody's Business But Yours!" The promotion worked - secure phones were the hottest-selling product of the season. At the start of 1996, there was an installed base of over ten million, with no end in sight. Companies were making secure faxes, secure modems, secure LAN's, and secure microwave systems. The long-awaited crypto revolution had begun, and NSA was thrilled. Skipjack would soon be used for all types of business communications as well as telephones - everything which needed protection could be taken care of with a single solution. At the time, I was a senior in college and working evenings for a company which had just received its security clearance. I did not have access to any classified data; my job was to operate and maintain their front-end system, which took orders, kept track of stock, etc. There was a separate, isolated LAN for the classified work of designing and programming chips. The company tried to follow all of the technical rules, but the people were hackers and businesspeople, not spooks. And most security problems are people problems. My boss did have a security clearance. He was working late one Friday on one of the classified machines used to write microcode. When everyone else had left, he asked me to fix a problem with the network. That was a violation of security, but I did know more about networks than he did, and all the classified data was supposed to be locked up for the weekend. The safe had a time lock, which could not be opened until Monday. My boss had made a mistake while he was logged in as root, and he did an excellent job of hosing the file server. He was not supposed to have the root password at all. He'd had an argument with his supervisor about computer access. The supervisor refused to give him the password, so he stole it. Now his ass was on the line - if the file server wasn't fixed by the next morning, he was history. He didn't exactly admit it all at once, but that's what happened. We took a look at the damage, and began the long, slow job of recreating the filesystems, reinstalling Unix, restoring the data from backup tapes, and, most importantly, hiding the evidence. By 8 o'clock, we were both starved. I was doing most of the work - he was watching, reading manuals, and sweating bullets - so he decided to go for food. While waiting for a backup tape to run, I opened the desk drawer out of boredom, and - whoops! - there was a manual stamped SECRET. Some programmer was using it to write the microcode for a new low- power CMOS Skipjack chip, and he hadn't locked it up. After all, this is a secure building. Nobody without a security clearance is even allowed in this room, right? So what's the big deal? People problems! I couldn't resist taking a look, and there was a complete description of the Skipjack algorithm, among other things, with each page marked SECRET at the top and bottom. I had about 20 minutes until my boss returned. There was a Xerox machine, warmed up and ready to go, in the next room. What would you do? So I stood there, turning pages and hitting the button, listening to my heart pound, waiting for the click of the outer door as my boss walked in. I wasn't hungry any more. If I heard that click, I had just enough time to toss everything behind the copier, run back to the workstation, and hope to put the manual back later. But there was no click. By the time my boss returned with a pizza, the copies were in my car and the manual was in the drawer. My appetite returned with a vengeance as the adrenaline wore off. By 2 am, the machine was restored to normal. My boss shook my hand and thanked me, and then I went home and passed out cold. The next day, I woke up around noon and took a look at my loot. The algorithm strongly resembles DES. It's a highly improved DES, of course, but the structure is similar. It uses 32 rounds, and an 80- bit key, and they process the key before using it to eliminate weak keys. I started coding it at home in C to hack around with, not having any particular plans as to what I'd do with it. I was just enjoying the thrill of having something few others had. The program worked, but it was horribly slow. Skipjack is optimized for a pipelined hardware implementation, using 32 processing elements, one for each round. Even a good software implementation is almost uselessly slow. Once I had the basic electronic-codebook function working, I started implementing the rest of the Skipjack protocol around it. After a month of on-and-off hacking, I had a complete software clone of a Skipjack chip, which could be assigned any serial number and device-unique key. Without the family key, however, there was no way to create a proper LEAF. The version of Skipjack in this file is much improved, but similar in structure, to the original. For a long time, that was all I did with it. Without hardware, it wasn't fast enough for a no-LEAF secure telephone. I scanned the copies I'd made, encrypted the image files, and made a bonfire with the paper copies. Not the kind of thing one should keep around. Then I started experimenting with a programming technique called genetic algorithms. These are algorithms which evolve their outputs by creating successively better results. Multiple results are generated and evaluated, the best are copied, the rest erased. The remaining ones are then "crossed", simulating sexual reproduction, and the cycle repeats. Looking for an application, I decided to see how far a genetic algorithm could go in attacking Skipjack. At the time, I'd have been thrilled if it broke one round. What happened next - I didn't do it! I didn't know then and don't know now how it works. Using keys as the strings my algorithm would create was no good. Genetic algorithms make incremental progress; with crypto, if one bit is off, it's useless. Instead, my strings were programs written in a little interpreted language, specifically designed for cryptography. The genetic algorithm would evolve programs. This approach has been used for various things in the past. I started out with less than a round, with only the first transformation of the first round. The genetic algorithm wrote a program to solve that, no problem. But as I made it harder, using more of the round, it failed to progress. So I tried something new: there are programs which clean up spaghetti code, making readable and usable code out of it. They are used to make 30-year-old Cobol maintainable. I used one to take the most successful programs which evolved, clean them up, and add them to the language itself as new commands. When it got to the second round, the blocks out of which those programs were built included the most successful methods used against the first round. This way the program could build on its own successes. The computer ran 24 hours a day, and it progressed as far as the fifth round. I was surprised that it worked at all, but I didn't know if five rounds was good or bad. There has never been any public research with Skipjack, but DES is much easier to break if fewer rounds are used, so I assumed I hadn't really done much. Before leaving for a weekend, I made several changes to the program: improvements to the crossover routines, removing old, nonuseful commands added by the evolver, and code which increased the difficulty, one piece of one round at a time, each time the programs were successful. There were a few other changes. There were also several bugs in the program, including at least one wild pointer which scrambled some of the evolved functions. How these bugs affected the ultimate outcome, I don't know. Something like Frankenstein's lightning, I suppose. When I got back Sunday evening, I turned on the monitor and couldn't believe it. It had gone through all 32 rounds - cracked the code! Impossible, had to be a program bug. So I encrypted some text using the function I'd written, fed it in, and went to bed. The next morning, I expected the program to be crashed. Instead, there was the key. Somehow, I don't have a clue how, the algorithms evolve to fit each piece of ciphertext. They go down, like a diver taking treasure from a sunken ship, and pull those patterns to the surface. I've never been able to trace it. All the data looks random, but the solution emerges in the end. Much like neural networks: they can solve a problem, but they can't tell you how they did it. That's one reason why people don't trust neural nets. The next day, I kept trying it with different pieces of text. Imagine opening your trunk and finding it stuffed with cash - I kept opening it and looking to see if the money was really there. Sometimes it was faster than others, but it always worked as long as there was a pattern to the plaintext. I started acquiring equipment and components. 32 RAM-based logic array chips, similar to PAL's but using SRAM instead of ROM. One for each round. These I connected to form the equivalent of a Skipjack chip, equally fast but fully controllable. A used minivan. Nonmetallic composites are popular for car bodies - they may stop a bullet, but radio signals go right through them. No need for visible antennas on the outside. A new 8-gigabyte hard drive. Plenty of RAM for a disk cache. A software encryption program - I wasn't about to use Skipjack, and my hard drive would need encrypting. A small microwave dish and receiver - they've replaced cable, carrying TV and all kinds of data transmissions. Encrypted with Skipjack, of course. By this time, mid-1997, Skipjack had already gone global. Most of the money transferred around the world moves by Skipjack. Almost all large corporations use it for their voice, data, and fax networks. It has been designed into the lowest levels of the new Information Superhighway under construction, and has replaced RIPEM as the official privacy standard on the Internet. Each country keeps escrows for all chips manufactured and used within its borders. These are used for national law enforcement. The United Nations has a master escrow, containing all of the keys in the world. This is used to police international terrorism, arms and drug trafficking, etc. There are, of course, very strict rules governing when and to whom the UN will release keys. This system works very well. It has put the squeeze on drug money like nothing that came before it, because the large cash transaction stands out in a world of electronic money. All major crimes are difficult - the Mafia is nearly extinct. ATM and credit card fraud are almost a thing of the past - the Skipjack smart card has replaced the mag stripe and the card number. New phones have a slot, rather than a built-in chip, allowing people to carry their identities wherever they go. I didn't counterfeit electronic money - that would eventually be noticed, and besides, I'm not a thief. Nor did I secretly transfer money to myself. I just drove to New York, one of many places where information worth billions of dollars moves everyday over microwave beams. Then I parked in the path of one, turned on my inverter - connected to four marine batteries; running out of power during a hot intercept is highly annoying - and powered up my scanner. Having cracked the family key, I could quickly extract the serial number from each transmission. The hardest part is deciding what, out of the gigabytes flowing by, to tap. Once I choose a transmission, I feed it to the genetic algorithm. If I get anything interesting, I keep that serial number, and I know to tap that chip again when I see the serial number. Perhaps I intercept the draft of your lousy quarterly earnings report, bouncing from one suit to another as they try to cover their asses. Then I sell your company short. Or if I intercept good sales figures, I buy your stock. Sometimes I buy options, although it's easier to lose your shirt that way. They aren't all winners - the market reacts strangely sometimes - but enough of them are to make me a millionaire in a couple of years. Besides, it wouldn't work if all my picks were accurate. Someone would get suspicious. I've really made very poor use of my luck. A corporation could have practically taken over the world. But it would have been detected eventually. By keeping it small and being careful, I've been successful. For the last five years, I've lived as a parasite, feeding on information and using it to my advantage. For a while, I went through a voyeuristic phase, driving down the freeway, tapping phone calls at random. That didn't stay interesting for very long; most phone calls are boring. So why am I revealing this now? Why would I give up my master key? Not willingly, I assure you. But I feel that I have no choice. Recently, there have been two unexplained crimes: large amounts of money have been electronically transferred from corporate accounts, simply vanishing. In both cases, the police have suspected an inside job. MIS and finance managers were arrested - and released, because there was absolutely no evidence against them. There was, in fact, no evidence at all. The money was just gone. The police may suspect an inside job, but I think otherwise. I am very familiar with such crimes, because I spent much of that first year planning them, thinking about how they could be accomplished. Someone else, I am convinced, has discovered the master key. I would suspect an organization, not an individual. Either they have corrupted the escrow system, or they have cracked the code too. And they do not intend to stop at personal wealth. From an offshore base, they could, in one day of frantic activity, hold the world economy hostage. Or they could drain us more slowly, over a period of a few weeks. The thefts were intended to provide them with capital and experience for what could be the greatest heist in the history of money. So what can I do to prevent this? I could go to the NCPI - the National Cryptography and Privacy Institute, formerly the NSA - and show them my system. They might throw me in the slammer for espionage and securities fraud. More likely, they would make me a deal - my freedom for my silence - and begin the long process of designing a new encryption algorithm. But they would not believe me when I told them that someone else had also cracked the code. The idea is almost too horrible for them to contemplate - the whole world runs on Skipjack - and without convincing evidence, there is no way they would believe me. I don't have any convincing evidence. Action has to be taken now, before it's too late, and there's only one way to cause that. Tell the secret. Publish the algorithm, publish the method of breaking it, and of course, publish this file, so people will understand why I did what I did. I will be flamed, called every name in the book and some that will be made up for the occasion. They may try to hunt me down. There will be chaos for a few days, maybe a few weeks. The world financial system will grind to a halt, as programmers work frantically around the clock. Software cryptography will have to be quickly installed, until a new hardware system can be designed. For now, incompatibility will return, efficiency will be reduced, and a lesson will be learned. Hopefully, the NCPI will not make the same mistake twice. Hopefully, they won't classify the algorithm next time. --==<< Infocalypse >>==-- (Binary file transmission follows this message)

3 2

MAIL: anonymous, positive reputations
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Earlier, Graham mentioned some concerns about anonymous mail; specifically it isn't easy to respond to the author, most messages are off topic, etc. (hopefully not referring to my posts sent through remailers :-) on topics like the cypherpunks gopher and caching remailers...) And some people are asking about marking anonymous mail (gopher plug: check the article "Why Mark Anonymous Mail?" at the gopher site in the "Anonymous Mail" section, contributed by Hal Finney sometime ago). Currently, I sign my posts sent through anonymous remailer, sometimes including my address at the bottom of the post itself. I know others do this as well - Hal Finney, probably others I can't think of. I am working on (and off as time constraints crop up) a positive reputation scheme for anonymous mail. My stab at this is somewhat modest: a program that sifts through elm mail folders (similar to the elm frm command) and produces a formatted list containing message number, email address of author (frm sometimes reports name and I like email addresses instead), and subject. BUT, instead of printing email address, if the message is pgp signed, report the signature instead. Under this program, the fact that an anonymous remailer was used is somewhat transparent since you would see who signed the document sent through a remailer. This would allow somebody to build up a positive reputation attached to a pgp signature (which could be fairly anonymous) and possibly help guide anonymous mail kill file users. Naturally, it would be best if it were easy to respond to an anonymous mail, if this were incorporated into mail programs, etc. but I have two problems: time constraints, and disk quota (I can't lay out the source code for elm, pgp, whatever else). I'm to the point where the script I include below does what I want expect check for digital signatures on letters. Since there isn't a pgp library (yet), the next step will be difficult since I'd rather not pipe the message through pgp just to get the signature, although for testing I'll implement something in the next few weeks. Here is the script: if anybody has input, speak up! I named it scan after the mh command it is a poor imitation of. Usage: 'scan foldername returns a formatted list of mail in the folder "foldername" Ug, I see an improvement I will make tonight: using getenv() to get my home directory instead of plugging it in directly: - ----------8< cut here >8---------- #!/usr/local/bin/perl #report email address and subject of messages in an elm folder #frm sometimes reports name and not email address - not that I # guarantee this works in all cases #simple version of mh scan command #Karl L. Barrus <klbarrus(a)owlnet.rice.edu> chdir "/home/klbarrus/Mail" || die "Can't cd to ~/Mail\n"; while (@ARGV) { $file = shift @ARGV; if (-T $file) { if (-z $file) { #zero length folders with no messages print "Folder $file has no messages\n"; } elsif (!open(FOLDER, "/home/klbarrus/Mail/$file")) { print STDERR "Can't open $file\n"; } else { $state = 1; #Look for a new message $num = 0; while (<FOLDER>) { if (/^From[^:]/) { #Delimits a new message $num++; $from = ""; $subject = ""; $state = 2; #Look for From: and Subject: } if ($state == 2) { #Already found a message; looking for headers /^Subject: (.*)/ && ($subject = $1); #match subject /^From: (.+)/ && ($from = $1); #match "From: add" /^From: (.+) <(.+)>/ && ($from = $2); #match "From: name <add>" /^From: (.+) $(.+)$/ && ($from = $1); #match "From: add (name)" if ($from ne "" && $subject ne "") { #found both headers $state = 1; #go back to looking for message delimiter write; } } } } } elsif (-d $file) { print STDERR "$file is a directory\n"; } } exit; format STDOUT_TOP =

1 0

Re: crypto import
by smb＠research.att.com 17 Dec '03

17 Dec '03

> if a law was broken. And Sternlight is right -- if they decide to i ndict, > they may throw in charges of importing IDEA ... THERE IS NO LAW AGAINST THE IMPORT OF CRYPTOGRAPHY! How many times does this idiocy have to be squashed? Perhaps not now, but the statutory and regulatory provisions exist: >From the ITAR: 120.1 -- General authorities and eligibility. (a) Section 38 of the Arms Export Control Act (22 U.S.C. 2778) authorizes the President to control the export and import of defense articles and defense services. 120.5 -- Relation to regulations of other agencies. If an article or service is covered by the U.S. Munitions List, its export is regulated by the Department of State, except as indicated otherwise in this subchapter. For the relationship of this subchapter to regulations of the Department of Commerce, the Department of Energy and the Nuclear Regulatory Commission, see ^U 123.20 of this subchapter. The Treasury Department controls permanent imports of articles and services covered by the U.S. Munitions Import List from foreign countries by persons subject to U.S. jurisdiction (31 CFR part 505). 123.2 -- Import jurisdiction. The Department of State regulates the temporary import of defense articles. Permanent imports of defense articles into the United States are regulated by the Department of the Treasury (see 27 CFR parts 47, 178 and 179). etc. I confess that I don't happen to have a copy of the Munitions Import List. Are you certain that crypto gear isn't on it? Are you certain it wasn't added last week? Or next? But the same authority -- dubious though it may be -- that lets them ban export of crypto would let them ban import if they chose to try. John PS: I heard a rumor it's against the law to breathe. Only if there's a coded message in the timing.

1 0

NIST Comment Deadline
by Dave Banisar 17 Dec '03

17 Dec '03

NIST Comment Deadline The September 28 deadline for the submission of comments on NIST's proposal to establish the "Skipjack" key-escrow system as a Federal Information Processing Standard (FIPS) is rapidly approaching. The full text of the NIST Federal Register notice follows. CPSR is urging all interested individuals and organizations to express their views on the proposal and to submit comments directly to NIST. Comments need not be lengthy or very detailed; all thoughtful statements addressing a particular concern will likely contribute to NIST's evaluation of the key-escrow proposal. The following points could be raised about the NIST proposal (additional materials on Clipper and the key escrow proposal, including comments already submitted to NIST, may be found at the CPSR ftp site, cpsr.org /cpsr/crypto/clipper): * The potential risks of the proposal have not been assessed and many questions about the implementation remain unanswered. The NIST notice states that the current proposal "does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys." The key escrow configuration may also create a dangerous vulnerability in a communications network. The risks of misuse of this feature should be weighed against any perceived benefit. * The classification of the Skipjack algorithm as a "national security" matter is inappropriate for technology that will be used primarily in civilian and commercial applications. Classification of technical information also limits the computing community's ability to evaluate fully the proposal and the general public's right to know about the activities of government. * The proposal was not developed in response to a public concern or a business request. It was put forward by the National Security Agency and the Federal Bureau of Investigation so that these two agencies could continue surveillance of electronic communications. It has not been established that is necessary for crime prevention. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. * The NIST proposal states that the escrow agents will provide the key components to a government agency that "properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted." The crucial term "legal authorization" has not been defined. The vagueness of the term "legal authorization" leaves open the possibility that court- issued warrants may not be required in some circumstances. This issue must be squarely addressed and clarified. * Adoption of the proposed key escrow standard may have an adverse impact upon the ability of U.S. manufacturers to market cryptographic products abroad. It is unlikely that non-U.S. users would purchase communication security products to which the U.S. government holds keys. Comments on the NIST proposal should be sent to: Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Written submissions must be received by September 28, 1993 (CPSR asked NIST that provisions be made to allow for electronic submission of comments, but the agency recently rejected that suggestion). Please also send copies of your comments on the key escrow proposal to CPSR for inclusion in the CPSR Internet Library, our ftp site. Copies should be sent to <clipper(a)washofc.cpsr.org>. ================================================================= FEDERAL REGISTER VOL. 58, No. 145 DEPARTMENT OF COMMERCE (DOC) National Institute of Standards and Technology (NIST) Docket No. 930659-3159 RIN 0693-AB19 A Proposed Federal Information Processing Standard for an Escrowed Encryption Standard (EES) 58 FR 40791 Friday, July 30, 1993 Notice; request for comments. SUMMARY: A Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard (EES) is being proposed. This proposed standard specifies use of a symmetric-key encryption/decryption algorithm and a key escrowing method which are to be implemented in electronic devices and used for protecting certain unclassified government communications when such protection is required. The algorithm and the key escrowing method are classified and are referenced, but not specified, in the standard. This proposed standard adopts encryption technology developed by the Federal government to provide strong protection for unclassified information and to enable the keys used in the encryption and decryption processes to be escrowed. This latter feature will assist law enforcement and other government agencies, under the proper legal authority, in the collection and decryption of electronically transmitted information. This proposed standard does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys. These issues will be addressed by the Department of Justice. The purpose of this notice is to solicit views from the public, manufacturers, and Federal, state, and local government users so that their needs can be considered prior to submission of this proposed standard to the Secretary of Commerce for review and approval. The proposed standard contains two sections: (1) An announcement section, which provides information concerning the applicability, implementation, and maintenance of the standard; and (2) a specifications section which deals with the technical aspects of the standard. Both sections are provided in this notice. DATES: Comments on this proposed standard must be received on or before September 28, 1993. ADDRESSES: Written comments concerning the proposed standard should be sent to: Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, room 6020, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues, NW., Washington, DC 20230. FOR FURTHER INFORMATION CONTACT: Dr. Dennis Branstad, National Institute of Standards and Technology, Gaithersburg, MD 20899, telephone (301) 975-2913. SUPPLEMENTARY INFORMATION: This proposed FIPS implements the initiative announced by the White House Office of the Press Secretary on April 16, 1993. The President of the U.S. approved a Public Encryption Management directive, which among other actions, called for standards to facilitate the procurement and use of encryption devices fitted with key-escrow microcircuits in Federal communication systems that process sensitive, but unclassified information. Dated: July 26, 1993. Arati Prabhakar, Director.(NIST) ---------------------------------------------------- Federal Information Processing Standards Publication XX 1993 XX Announcing the Escrowed Encryption Standard (EES) Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. Name of Standard: Escrowed Encryption Standard (EES). Category of Standard: Telecommunications Security. Explanation: This Standard specifies use of a symmetric-key encryption (and decryption) algorithm and a Law Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which provide for decryption of encrypted telecommunications when interception of the telecommunications is lawfully authorized. Both the algorithm and the LEAF creation method are to be implemented in electronic devices (e.g., very large scale integration chips). The devices may be incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved through the acquisition and use of the LEAF, the decryption algorithm and escrowed key components. To escrow something (e.g., a document, an encryption key) means that it is "delivered to a third person to be given to the grantee only upon the fulfillment of a condition" (Webster's Seventh New Collegiate Dictionary). A key escrow system is one that entrusts components of a key used to encrypt telecommunications to third persons, called key component escrow agents. In accordance with the common definition of "escrow", the key component escrow agents provide the key components to a "grantee" (i.e., a government agency) only upon fulfillment of the condition that the grantee properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted using the specific device whose key component is requested. The key components obtained through this process are then used by the grantee to reconstruct the device unique key and obtain the session key (contained in the LEAF) which is used to decrypt the telecommunications that are encrypted with that device. The term, "escrow", for purposes of this standard, is restricted to the dictionary definition. The encryption/decryption algorithm has been approved for government applications requiring encryption of sensitive unclassified telecommunications of data as defined herein. The specific operations of the algorithm and the LEAF creation method are classified and hence are referenced, but not specified, in this standard. Data, for purposes of this standard, includes voice, facsimile and computer information communicated in a telephone system. Telephone system, for purposes of this standard, is limited to systems circuit-switched up to no more than 14.4 kbs or which use basic-rate ISDN, or to a similar grade wireless service. Data that is considered sensitive by a responsible authority should be encrypted if it is vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be performed under the direction of a responsible authority to determine potential threats and risks. The costs of providing encryption using this standard as well as alternative methods and their respective costs should be projected. A responsible authority should then make a decision, based on the risk and cost analyses, whether or not to use encryption and then whether or not to use this standard. Approving Authority: Secretary of Commerce. Maintenance Agency: Department of Commerce, National Institute of Standards and Technology. Applicability: This standard is applicable to all Federal departments and agencies and their contractors under the conditions specified below. This standard may be used in designing and implementing security products and systems which Federal departments and agencies use or operate or which are operated for them under contract. These products may be used when replacing Type II and Type III (DES) encryption devices and products owned by the government and government contractors. This standard may be used when the following conditions apply: 1. An authorized official or manager responsible for data security or the security of a computer system decides that encryption is required and cost justified as per OMB Circular A- 130; and 2. The data is not classified according to the National Security Act of 1947, as amended, or the Atomic Energy Act of 1954, as amended. However, Federal departments or agencies which use encryption devices for protecting data that is classified according to either of these acts may use those devices also for protecting unclassified data in lieu of this standard. In addition, this standard may be adopted and used by non- Federal Government organizations. Such use is encouraged when it provides the desired security. Applications: Devices conforming to this standard may be used for protecting unclassified communications. Implementations: The encryption/decryption algorithm and the LEAF creation method shall be implemented in electronic devices (e.g., electronic chip packages) that can be physically protected against unauthorized entry, modification and reverse engineering. Implementations which are tested and validated by NIST will be considered as complying with this standard. An electronic device shall be incorporated into a cyptographic module in accordance with FIPS 140-1. NIST will test for conformance with FIPS 140-1. Cryptographic modules can then be integrated into security equipment for sale and use in an application. Information about devices that have been validated, procedures for testing equipment for conformance with NIST standards, and information about obtaining approval of security equipment are available from the Computer Systems Laboratory, NIST, Gaithersburg, MD 20899. Export Control: Implementations of this standard are subject to Federal Government export controls as specified in title 22, Code of Federal Regulations, parts 120 through 131 (International Traffic of Arms Regulations -ITAR). Exporters of encryption devices, equipment and technical data are advised to contact the U.S. Department of State, Office of Defense Trade Controls for more information. Patents: Implementations of this standard may be covered by U.S. and foreign patents. Implementation Schedule: This standard becomes effective thirty days following publication of this FIPS PUB. Specifications: Federal Information Processing Standard (FIPS XXX)(affixed). Cross Index: a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, Modes of Operation of the DES c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. Glossary: The following terms are used as defined below for purposes of this standard: Data-Voice, facsimile and computer information communicated in a telephone system. Decryption-Conversion of ciphertext to plaintext through the use of a cryptographic algorithm. Device (cryptographic)-An electronic implementation of the encryption/decryption algorithm and the LEAF creation method as specified in this standard. Digital data-Data that have been converted to a binary representation. Encryption-Conversion of plaintext to ciphertext through the use of a cryptographic algorithm. Key components-The values from which a key can be derived (e.g., KU sub 1 + KU sub 2). Key escrow -A process involving transferring one or more components of a cryptographic key to one or more trusted key component escrow agents for storage and later use by government agencies to decrypt ciphertext if access to the plaintext is lawfully authorized. LEAF Creation Method 1-A part of a key escrow system that is implemented in a cryptographic device and creates a Law Enforcement Access Field. Type I cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting classified information. Type II cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting sensitive unclassified information in systems as specified in section 2315 of Title 10 United State Code, or section 3502(2) of Title 44, United States Code. Type III cryptography-A cryptographic algorithm or device approved as a Federal Information Processing Standard. Type III(E) cryptography-A Type III algorithm or device that is approved for export from the United States. Qualifications. The protection provided by a security product or system is dependent on several factors. The protection provided by this standard against key search attacks is greater than that provided by the DES (e.g., the cryptographic key is longer). However, provisions of this standard are intended to ensure that information encrypted through use of devices implementing this standard can be decrypted by a legally authorized entity. Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit account or charged to a credit card accepted by NTIS. Specifications for the Escrowed Encryption Standard 1. Introduction This publication specifies Escrowed Encryption Standard (EES) functions and parameters. 2. General This standard specifies use of the SKIPJACK cryptographic algorithm and the LEAF Creation Method 1 (LCM-1) to be implemented in an approved electronic device (e.g., a very large scale integration electronic chip). The device is contained in a logical cryptographic module which is then integrated in a security product for encrypting and decrypting telecommunications. Approved implementations may be procured by authorized organizations for integration into security equipment. Devices must be tested and validated by NIST for conformance to this standard. Cryptographic modules must be tested and validated by NIST for conformance to FIPS 140-1. 3. Algorithm Specifications The specifications of the encryption/decryption algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) are classified. The National Security Agency maintains these classified specifications and approves the manufacture of devices which implement the specifications. NIST tests for conformance of the devices implementing this standard in cryptographic modules to FIPS 140-1 and FIPS 81. 4. Functions and Parameters 4.1 Functions The following functions, at a minimum, shall be implemented: 1. Data Encryption: A session key (80 bits) shall be used to encrypt plaintext information in one or more of the following modes of operation as specified in FIPS 81: ECB, CBC, OFB (64) CFB (1, 8, 16, 32, 64). 2. Data Decryption: The session key (80 bits) used to encrypt the data shall be used to decrypt resulting ciphertext to obtain the data. 3. Key Escrow: The Family Key (KF) shall be used to create the Law Enforcement Access Field (LEAF) in accordance with the LEAF Creation Method 1 (LCM-1). The Session Key shall be encrypted with the Device Unique Key and transmitted as part of the LEAF. The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and ciphertext may be decrypted with legal authorization. No additional encryption or modification of the LEAF is permitted. 4.2 Parameters The following parameters shall be used in performing the prescribed functions: 1. Device Identifier (DID): The identifier unique to a particular device and used by the Key Escrow System. 2. Device Unique Key (KU): The cryptographic key unique to a particular device and used by the Key Escrow System. 3. Cryptographic Protocol Field (CPF): The field identifying the registered cryptographic protocol used by a particular application and used by the Key Escrow System (reserved for future specification and use). 4. Escrow Authenticator (EA): A binary pattern that is inserted in the LEAF to ensure that the LEAF is transmitted and received properly and has not been modified, deleted or replaced in an unauthorized manner. 5. Initialization Vector (IV): A mode and application dependent vector of bytes used to initialize, synchronize and verify the encryption, decryption and key escrow functions. 6. Family Key (KF): The cryptographic key stored in all devices designated as a family that is used to create the LEAF. 7. Session Key (KS): The cryptographic key used by a device to encrypt and decrypt data during a session. 8. Law Enforcement Access Field (LEAF): The field containing the encrypted session key and the device identifier and the escrow authenticator. 5. Implementation The Cryptographic Algorithm and the LEAF Creation Method shall be implemented in an electronic device (e.g., VLSI chip) which is highly resistant to reverse engineering (destructive or non- destructive) to obtain or modify the cryptographic algorithms, the DID, the KF, the KU, the EA, the CPF, the operational KS, or any other security or Key Escrow System relevant information. The device shall be able to be programmed/personalized (i.e., made unique) after mass production in such a manner that the DID, KU (or its components), KF (or its components) and EA fixed pattern can be entered once (and only once) and maintained without external electrical power. The LEAF and the IV shall be transmitted with the ciphertext. The specifics of the protocols used to create and transmit the LEAF, IV, and encrypted data shall be registered and a CPF assigned. The CPF shall then be transmitted in accordance with the registered specifications. The specific electric, physical and logical interface will vary with the implementation. Each approved, registered implementation shall have an unclassified electrical, physical and logical interface specification sufficient for an equipment manufacturer to understand the general requirements for using the device. Some of the requirements may be classified and therefore would not be specified in the unclassified interface specification.

1 0

REMAIL: policy
by catalyst＠netcom.com 17 Dec '03

17 Dec '03

What follows is the policy for the remailer running at catalyst(a)netcom.com as of 21 Sept 1993: - 1 - I don't normally keep logs because (a) I lack the time to examine them; (b) I lack the space to keep them; and (c) frankly, I would rather _not_ know. If some exceptional situation requires it, I will temporarily log to resolve that situation. - 2 - I will block remailing to a given address on request and proof of identity by the owner. I run a remailer because I believe privacy is an inaliable human right. However, "Your right to swing your fist ends where my nose begins!". I will not condone, promote or aid the violation of other human rights in the name of privacy. Because I don't keep logs, I can do no more than block (nor would I wish to), although, see - 1 -. - 3 - I do not own the machine my remailer is running on. In fact it is a commercial system. Be nice. If they ask me to stop running my remailer on their system... I will. Additionally, you implicitly accept all the risks associated with trusting somebody elses machine. - 4 - I don't read mail that goes through my remailer _BUT_ it is my personal account, and personal mail addressed to me passes through it, therefore, if a message doesn't look like it contains remailer commands, the remailer assumes it must be to me and I get it. I read all mail that is addressed to me. The consequence is that poorly addressed messages intended to be remailed will be read by me. I will throw these messages away without responding, correcting, or forwarding them, as soon as I realize they were to have been remailed. Be aware that this can happen. I'm sure there is some threshold beyond which the content would force me to action in some way. What the content, threshold and possible actions are, I do not know. Protect yourself from this result by using multiple remailers and encrypting at each stage. - 5 - I am an engineer. I like to play. I probably cannot stop myself from constantly tweaking and growing the remailer code. It is, after all, an expermental system. The remailer you use today may not be the same one you get tomorrow. - 6 - I am a human being and suffer from all the associated frailties. When someone points a gun (actually or metaphorically) at me or my family, I must almost certainly comply with that entities wishes. I do NOT advocate law breaking and will comply with the law to the extent required and enforced; e.g., if the FBI comes to my door and says: "start logging your remailer, or shut it down" ("shut it down" might only be inferred <and, _no_, I didn't mean 'implied'>), then it is likely that I will comply to the extent required and enforced. - 7 - As with my kids: I reserve the right to change the rules at any time and for any reason; though I seldom exercise this right to explicitly revoke previously explicitly granted freedoms. - 8 - I run this remailer as a personal activity. It is in no way associated with my place of employment, my employer or the activities I engage in on the behalf of my employer. I run it out of a personal account on a commercial system that I pay for with my own money. If you have problems with the remailer, please talk to me first. If we can't resolve it, of course you can always report it to NetCom. - 9 - Finally, be aware that I am not _providing_ privacy. I am allowing it. That is, _you_ are the caretaker of your rights and must actively seek to protect them. I will help, but that is all I can do. If you wish to protect your privacy, I urge you to learn how and why these remailers (and other associated tools) work so that you can use them to the best advantage. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: Why RSA?
by derek＠cs.wisc.edu 17 Dec '03

17 Dec '03

First, the ViaCrypt version: I realize that it is legal. It's also very expensive when compared to the price of email readers/composers that people normally use (often weighing in at about $50 / seat). A $200 add-on is not likely to be universally accepted. It's as if somebody had patented car door locks and claimed that $40,000 was a reasonable price to have them included on a $10,000 car. I'm not complaining about the price; people can charge whatever they want for their products. However it does seem kind of high, creating market pressure... that market pressure surfaces in messages like this one and hopefully someday competing products from somebody. Perry Metzger: > All are patented in so far as one of the patents covers ALL public key > schemes. Some, like Rabin's scheme, have possible technical advantages > over RSA. I am just beginning to study the mathematics behind public key crypto (got Simmons's _Contemporary Cryptology_ from the library this morning), but I haven't seen anything about what exactly this means (that is, I haven't been able to "look it up"). I was under the impression that many people participated in the development of P.K.Crypto... how can somebody patent all of their work? Don't these kind of patents apply only to specific algorithms? Begging the indulgence of this list, two more questions: * is there a reference I can read that covers the scope of public key crypto patents? * in broad terms, what would I have to do to develop an algorithm that works from a user's perspective like p.k.c. (ie public/private keys, the central functional point of all the wonderful schemes based on pkc) but doesn't violate patents? Thanks! derek

4 3

Re: Bidzos on PGP and ITAR verbatim
by doug＠netcom.com 17 Dec '03

17 Dec '03

>Similarly, it was taught in an advanced discrete math course at the Since no one else has mentioned it...the NSA tried to head off the original publication of public key cryptography, threatening star chambers, national security directives, and jail terms. This was thwarted by profs at a hundred colleges across the U.S. immediately assigning the algorithm as homework to every software class they were teaching at the same time, thus rather letting the cat out of the bag. The NSA then backed off, and publications followed. The material has been a natural part of certain courses ever since, depending on tastes of the prof. Part of the above story I experienced directly, since I was at Berkeley at the time, and other parts I heard from Ralph Merkle, who was either still there or had just gone to Stanford...I can't recall which. So if someone is collecting stories about the commonality of teaching such things, I imagine there must be some hundreds of thousands of eye witness reports. I implemented a 512 bit pubkey algorithm for kicks on a Z80 CPM system around 1982 based on a paper in the open literature that aimed at non-mathematicians and gave details such as efficient GCD algorithms. There cannot be any question about how widely known these techniques are. Doug

1 0

Re: Master Key: A Clipper Story
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>Message-Id: <9309212027.AA09946(a)dun-dun-noodles.aktis.com> >Date: Tue, 21 Sep 1993 16:27:24 -0400 >From: Marc Horowitz <marc(a)GZA.COM> >>> Well done! > >I agree! Yes -- only -- I wish there were more than 1/2 sentence on breaking into the escrow agencies. That's clearly where the first break would be.

1 0

(1) PRZ excluded (2) PM vs. LD (3) grand jury procedure
by L. Detweiler 17 Dec '03

17 Dec '03

I was thinking. What is the significance that PRZ was not actually cited in any subpoena so far? This is very puzzling. It seems to contradict the theory that the investigation is primarily PGP oriented. On one hand, we might attribute it to the idea that the grand jury & the Attorneys don't have a very clear idea of what exactly is going on with PGP anyway, which would fit in with some of the tidbits I've posted. The president of ViaCrypt *was* subpoenaed -- but he has only been in associated with PGP for a few weeks, since the commercial announcement. But, still, how could they *not* query PRZ if they are inquiring on PGP? This is what I call a `conspicuous omission'. Also, the targeting of ViaCrypt and not PRZ directly is very interesting to contemplate. It definitely suggests that the move of PGP to a commercial company was critical in the timing of the subpoenas. Was it critical in convening a grand jury in the first place? what is it about the situation that caused action after a company was involved? are relevant laws only applicable to companies, not individuals? surely not, but there is very likely something going on here beneath the surface. (BTW, let the record show I have only replied directly to PM's voluminous onslaught of public flames [to say nothing of my vast, superb private collection] in one message on the list, which I think is sufficient [or more precisely, nothing could be sufficient, but it is the minimum]. If there is any `bickering' going on beyond this, it is only the reader's fertile imagination that I was *engaged* [*targeted*? definitely]. Or, feel free to cite the messages to contradict me, in email. I say all this only because I fear I am becoming a symbol in everyone's psyche of any message that challenges PM, no matter who wrote it, quite to the contrary of actual developments.) Here's a bit more which is helpful in describing a grand jury investigation (although I'd like to see more) from someone who gives me too much credit :) ===cut=here=== Date: Tue, 21 Sep 1993 11:49:33 -0400 From: [...] To: ld231782(a)longs.lance.colostate.edu Subject: Re: more musings You are absolutely right about the Grand Jury proceedings. They are simply a fact finding venture. They are secret hearings and I doubt that Phil Zimmerman will even be able to talk about the proceedings after they are done. In addition to this, you are also correct that attorneys are not permitted inside the grand jury hearing (although the witness may leave the room to confer with the attorney). Once inside the room, you will only have the Grand Jury (of 23 people I believe) and the D.A. While it may seem nice to believe that Phil Zimmerman will be able to make a grand Perry Mason like speech in front of the Grand Jury. In reality, he will be under the control of the D.A. and will probably not have much of a chance to say much of anything except to answer the questions of the D.A. On the last point, yes you are also right, since the Grand Jury is NOT a criminal trial. Any evidence that would normally be held as illegally obtained, or just generally inadmissable in court (ie. hearsay) is perfectly acceptable for a Grand Jury, and I'm sure that it will be used. The grand jury's only purpose is to pass either an indictment (called a True Bill ) or no indictment, they are not there to determine guilt.

3 2

Re: crypto import
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>123.2 -- Import jurisdiction. > The Department of State regulates the temporary import of defense articles. > Permanent imports of defense articles into the United States are regulated by > the Department of the Treasury (see 27 CFR parts 47, 178 and 179). Mayhaps this explains why the Treasury is involved with Grady/Zimmerman

1 0

Subjects in anon msgs
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Someone writes: > What do you put in the Subject: line of an encrypted or anonymous > message? > > We need something standard to prevent traffic analysis on this field. ... Isn't it okay to have the subject appear in the last hop, according to a :: field in the second-to-last message? ::Remail-with-Subject: All Right Bugsy Lets Get Down To Brass Tacks With remailers that unencrypt at each hop, this doesn't seem a problem to me. With remailers that accept unencrypted input, this is no more of a steganoweakness than the body of the message already is. -fnerd(a)smds.com

1 0

PGP IN SF CHRONICLE
by Sandy 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort(a)attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Remind me someday to explain why I think there are only 10-20 million people in the world, max. One "proof" is all the "coincidences" we experience. Anyway, here's another one. Because I have written for MONDO 2000, WIRED and FUTURE SEX, a friend sent me a newspaper clipping about some new culture and technology oriented magazines. She thought I should try to crack them. FAST COMPANY sounded interesting, so I called the column's writer to find out where it is published. We talked for a while and he mentioned he had an article in today's paper about the PGP indictments, Phil Zimmermann, etc. Hey, there are no accidents. If I'm lyin' I'm flyin'. The article was neutral to sympathetic. The factual content was okay-doke except for one misguided reference to "cypherfreaks." Oh well, what's in a name? The article was on the first page of the business section of the 21 September San Francisco Chronicle. "Cypherfreak" John Gilmore got in some good quotes. S a n d y >>>>>> Please send e-mail to: ssandfort(a)attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

New York Times: Federal Inquiry on Software...
by Zeek 17 Dec '03

17 Dec '03

---------------------------- The New York Times Tuesday, September 21, 1993 Business Day ---------------------------- Federal Inquiry on Software Examines Privacy Programs By John Markoff SAN FRANCISCO, Sept. 20 - In a Government investigation with implications for free speech and privacy in the information age, a Federal grand jury in San Jose, Calif., has issued subpoenas to two software publishers selling versions of a program that protects the privacy of electronic mail and other computer data. The investigation appears to focus on whether the program has been illegally exported in violation of State Department regulations that control the sale of weapons and other technologies whose export the Government believes may compromise national security. The relevance of such regulations in the post-cold war era is the topic of growing debate in Washington, where communications and computer executives plan to testify before Congress on Wednesday. [Page C3.] The software program, known as Pretty Good Privacy, or P.G.P., was written several years ago by an independent programmer in response to Federal threats to crack down on the distribution of encryption software which is used to protect computer data by converting them into secret code. No one can read the encoded information without access to mathematical keys - one that is publicly known, a second known only to the recipient of the coded message. The program has since been freely distributed around the world, used on thousands of personal computers and work stations. Receiving the Federal subpoenas were Viacrypt, a Phoenix company that plans to sell a licensed version of P.G.P., and Austin Code Works of Austin, Tex., which is selling a version of P.G.P. for other software developers to incorporate their own programs. The grand jury subpoenas, which the companies received Sept. 9, ordered them to supply all correspondence and records related to the international distribution of P.G.P. and other information related to computer cryptography. A Customs Department official refused to comment on the case today. William P. Keane, the assistant United States attorney who signed the subpoenas, confirmed that there was a grand jury investigation, but said he could not comment. Both publishers said they had no plans to sell their products abroad. "I think they're more concerned with our intentions than what we've done," said Leonard Mikus, president of Viacrypt, which is a division of the software company Lemcom Systems Inc. of Phoenix. "They're on a fishing expedition, but this could become a landmark case that sets the limits that distinguish between electronic and conventional publishing." Battling the N.S.A. The investigation is the latest round in a growing battle in recent years between the National Security Agency and a variety of groups in this country, including high-technology companies, computer researchers and civil libertarians, over the role of coding software in protecting computer data. The N.S.A., whose role is to monitor electronic communications around the world, has consistently acted to block the adoption of new technologies that would make its mission more difficult. But the widespread availability of high-speed digital communication links and inexpensive personal computers may make it impossible to enforce technology restrictions in the future - as the widespread international dissemination of P.G.P. has already indicated. President Clinton alluded to the problems of controlling distribution of software technology in a speech last week promoting the North American Free Trade Agreement. "Nothing we do in this great capital can change the fact that factories or information can flash across the world, that people can move money around in the blink of an eye," the President said. "Nothing can change the fact that technology can be adopted, once created, by people all across the world and then rapidly adapted in new and different ways by people who have a little different take on the way that technology works." Question of Legality Government regulations, enforced by the State Department, make it illegal to export cryptographic software without a special munitions export license issued for weapons sales. Those restrictions have angered many computer industry executives who argue that encryption software is the crucial technology underlying a variety of information-age services, ranging from secure electronic mail to computerized payment of bills. Last year, a number of United States software companies, represented by the Software Publishers Association, a trade group, struck a deal with the N.S.A. permitting them to export software that contained coding functions. Those codes, however, are believed to be easily cracked by the N.S.A. The P.G.P. software under investigation is thought to defy most N.S.A. code-cracking efforts. The legitimacy of the export regulations is also disputed by legal scholars who argue that they restrict freedom of speech. "There is a First Amendment right to speak in a encrypted way," said Eben Moglen, a professor of law and legal history at Columbia University who is familiar with the case. "The right to speak P.G.P. is like the right to speak Navajo. The Government has no particular right to prevent you from speaking in a technical manner even if it is inconvenient for them to understand." Protection from Code-Breaking P.G.P. has been controversial since it was written by the programmer, Philip Zimmerman, because it uses a coding formula that many researchers believe powerful enough to protect information from even the National Security Agency's high-speed code-cracking computers. The formula was developed by three well known computer scientists: Ronald Rivest, Adi Shamir, and Leonard Adelman. --------------

1 0

Stunned and amazed
by msattler＠netcom.com 17 Dec '03

17 Dec '03

>Perry Metzger >Puzzled and incredulous I'm not one to snivel about bandwidth ('cause I think the Internet can deal with a lot more text messages from us to ourselves), but the kind of thing that's gotten Perry in the state he's in reminds me of a time-honored way of dealing with trivial, nonsensical, toxic waste messages: IGNORE THEM AND THEY'LL GO AWAY. It's the attention that's craved. We now return you to your insightful cypherpunks list, already in progress. :-) M ----------------------------------------------------------------------------- Michael S. Sattler msattler(a)netcom.com +1 (415) 358-3058 Digital Jungle Software Encrypt now; ask me how. (finger for PGP key) "Don't Panic!" -- Douglas Adams "Don't Panic. Stay Cool." -- PRZ

1 0

Health Security Card
by Duncan Frissell 17 Dec '03

17 Dec '03

Senator Harris Wafford (sp?) on Larry King Live just flashed a mockup of the Health Security Card. It is white. It has a red, white, and blue flag on it. It looks like it has a 7 digit number on it in the EIN split pattern 99 99999. It was hard to count digits though. It might have 9 digits rather than 7. Wafford did use the term "smartcard." I'm sure Willy will feature one in his speech tomorrow night. Duncan Frissell "Where's your Health Security Smartcard." "Sorry, I'm don't believe in that sort of thing. I'm an anarchist. You know, that's an alternative life style sort of like sodomy. They're starting to teach it in the schools and everything." --- WinQwk 2.0b#0

1 0