December 2003 - cypherpunks-legacy

Re: IMP (was Re: ecash-info (fwd))
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Hal <hfinney(a)shell.portal.com> wrote, >> 1.) Chaum's e-cash coupled with WWW/Mosaic is a de facto internet >> mercantile protocol. > >You're jumping the gun here a little, aren't you? There is no evidence >yet that Chaum's current proposals are going to catch on. The CommerceNet >idea seemed to have more backing judging from the press releases. And it >did not appear to support anonymous transactions. While I don't see how the two technologies are mutually exclusive, you may have a point about anonymity. But WWW/Mosaic's acceptance of e-cash may make it more attractive (don't know how just yet, but I bet it has to do with liquidity), with or without anonymity. > >> 2.) It seems to me that that e-cash, contrary to the status quo's thinking, >> is *critical* to internet commerce. An anonymous cash market is most >> unrestricted and efficient market there is, because privacy/security (more >> than trust, I think) is the capstone of any serious transaction mechanism. > >I don't follow this argument. You are suggesting that an anonymous cash >market would be more efficient than one based on checks and credit cards? >It would have lower transaction costs, so things would be available for lower >prices? Why is this? The hypothetical discussions we've had here on "if I >ran an anonymous bank" often talked about service charges. > While only increasing the velocity of the air around here with my all my hand-waving, I expect that the service charges would be justified with increased liquidity of e-cash, I believe that the increased liquidity comes from not having to balance a bunch of customer accounts at the end of the day, either at the issuer of the cash, or the vendor who received the cash. When a retailer goes to the bank with checks, each check is specifically identified. When the check bounces (a straw man in an electronic market), it has to be collected. When a customer reneges on a credit card transaction, it has to be traced back to the retailer. That doesn't happen in e-cash. I expect someone's said all this here before, and I beg the cypher.gods indulgence... >Your use of the term "capstone" is unclear in this context. Are you suggesting >that retaining privacy is more important for most people than trusting a >seller in most transactions? Most people would rather buy from FlyByNight >Corp if they could stay anonymous than from Sears using their credit card? >I don't think so. For some people, the kind who won't use checks today and >get by with cash and money orders, this might be true. But I don't see >it as being the rule. I think that the credibility of the issuer is important to the security of e-cash. That security is upheld with cryptography and Chaum's technology. I think that privacy is a by-product of a very liquid and efficient funds transfer system. All the byproducts of the reduced paperwork. So, I think I got the chicken and the egg mixed up. Point taken. >It seemed to me that the IMP list discussions degenerated into flame wars >between Detweiler and cypherpunks. Those in the middle, which included >most subscribers, were shocked and disgusted by Detweiler's crude flaming >and this made everyone uncomfortable about bringing up the topic of anon- >ymity and cash. With Detweiler on the list it was impossible to have a >serious discussion of the matter. True. But Tim(?) had a point back there when he talked about them having to work around Chaum. I also think that something important did happen on imp-interest. Most of the pertinent discussion delt with the need to put something up and test it out. I didn't *see* anything in that vein until I heard here about Tacky-Tokens and Magic Money. But as Perry aptly pointed out, Unless you denominate them in *real* money, you're just trading baseball cards (or coke cans). It ain't real until the financial system plays. TT and MM are important, because they address the operational issues. They're where the rubber meets the road. They aren't the engine, however. That's a true player in the financial system (a bank or bank-like entity), and the people who have the technology: Digicash > >Chaum is trying to make money off his ideas. In doing so, he is being >guided by the invisible hand of the market to try to find those niches where >his technologies can be most profitable. Maybe going after the bankers is >the wrong idea, not at all >but it is understandably tempting to prefer trying to get >millions of dollars from a few people than a few dollars from millions of >people. It does sound, though, like he is trying to branch out now and >spread his technology around. Perhaps he will follow the lead of RSA and >make a "ChaumREF" free implementation of his cash technology. The Commerce- >Net model had RSA supplying free client software while charging the vendors >licensing fees, I believe. Chaum may be planning a similar approach. I hope he goes after the banks, central and otherwise, and lets the mercantile protocol sort itself out in the market. When I started reading about you folks, I ran into an article in one of Stuart Brand's publications (The Whole Earth Review?). It talked about the "fax effect". That is, one fax machine is worthless, but millions are very valuable. I think this is what the whole PGP idea was about. In this case, if the ability to spend and receive money was cheap (or free) the franchise to print money would be very dear indeed. I think Chaum understands this. I hope he does, anyway. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

News Flash: Clipper Bug?
by qwerty＠netcom.com 17 Dec '03

17 Dec '03

Is this for real? Or did some future Nobel prize winner discover that PGP exists? WIRETAP FLAW NEW YORK (AP) -- A computer scientist reportedly has discovered a basic flaw in coding technology that the Clinton administration has been promoting as a standard for electronic communications. Matthew Blaze, a researcher at AT&T Bell Laboratories, told the New York Times that his research had shown that someone with sufficient computer skills can beat the government's technology by encoding messages so that no one, not even the government, can crack them. The administration has been urging private industry to adopt the so-called ``Clipper chip'' as a standard encoding system.

3 3

Fwd: eWorld & Anonymity
by Pierre＠eworld.com 17 Dec '03

17 Dec '03

My first attempt to post this met with strange results; hopefully this attempt will work. Pierre --------------------- Forwarded message: Subj: eWorld & Anonymity Date: 94-05-31 22:35:57 PDT From: Pierre To: cypherpunks(a)toad.com I thought this might interest people... eWorld's "policy" on anonymity... *************************************** Date: Sat, May 28, 1994 5:52 AM EST From: eWorldAlert(a)eworld.com Subj: About Member Profiles. To: Pierre Dear eWorld Beta Tester, The recent eWorld host software upgrade rebuilt Member Profiles using the name you entered during registration. If you do not want your complete name reflected in the Member Profile you can change it. We ask that you enter at least your first initial and true last name. You can edit this field for the next couple of weeks, after which you can no longer change it. We want eWorld members to have real identities to encourage responsible online behavior. In the near future the eWorld Member Name in the Member Profile of newly-registered people will automatically reflect the name provided during registration and will not be editable. During registration members will choose between listing first & last name or first initial & last name in the Member Profile. This prevents people from using anonymous member names in eWorld, such as Your Worstnightmare. It also allows members to have impersonal identities in eWorld if they are concerned about harassment. Someone asks, "What if I have an uncommon last name, live in a small community and express an unpopular viewpoint in a discussion where tempers are high? Someone can use my Member Name and Location information to find my phone number (or even my address) and harass me!" Those with unusual last names have two options. The first is to change the community name from a city or town to a geographical region, or even to change the geographic reference to Somewhere Else. The second is to call the eWorld Assistance Center at 1-800-775-4556, explain the problem and ask for an altered Member Name. You don't need to do that now, though -- at this point you can change it yourself. We don't want anyone getting beat up or harassed because of membership in eWorld. But we do want to *substantially* reduce the amount of anonymity and consequent irresponsible behavior possible with the present registration system.

1 0

Re: News Flash: Clipper Bug?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> Here is what the article on the upper right hand side of this morning's > New York Times says: > > "To defeat the system, Dr. Blaze programmed a 'rouge' unit to test > thousands of LEAF's. Once he found a valid key, he inserted it in place I assume 'rouge' is a typo - Matt's paper was talking about rogue units, rather than Commies or makeup-artists :-) One weakness in the weakness is that most Clippersystems appear to be designed to use the same session key in each direction, so both ends have to be privacy-protected versions to prevent wiretapping, since a non-rogue LEAF from either end will give away the key. But it's a good start, and ought to be exploited for all the political mileage we can get out of it.... and it's not surprising that security in a conversation is everybody's job... Bill

1 0

QUERY: who is this man?
by ddt＠lsd.com 17 Dec '03

17 Dec '03

>ENCRYPTION: The Clinton administration's encryption > plans are having licensing troubles: The US Commerce > Department's NIST is having licensing discussions > with inventors over its Digital Signature Standard, > and an MIT scientist claims that the Clipper chip > infringes on his patents. <WSJ 5/31 p.B6> Can someone please post the id of this "MIT Scientist?" Also, any comments (however brief) on the NIST discussions?

1 0

funny-byte
by ddt＠lsd.com 17 Dec '03

17 Dec '03

"Yeah, I worked for the Phone Company back then, an' I guess it was an OK job, but I didn't much like the way they calculated my paycheck: I got $11.50 for the first hour, and twenty-five cents for each additional hour..." [w/apologies to Charles Kozar, the Angry Black comic]

1 0

Re: News Flash: Clipper Bug?
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

> >My friend Matt Blaze at Bell Labs showed that you can forge LEAFs on >Tessera cards so that you can use Skipjack without anyone being able >to get the key you are using. Its a slick piece of work -- slick >enough that it made the front page of today's New York Times. I'm not >sure how practical it is, but its extraordinarily noteworthy. Please explain how to forge the LEAFs. I presume that this doesn't involve super-encryption.

3 5

Re: CEB 5 - The Hangover
by lefty＠apple.com 17 Dec '03

17 Dec '03

> Its sort of like bringing home a rabbit for supper & everybody > dumps on you cause it wasn't a moose. > >It looked more like someone saying "Hey! Let's have rabbit for >dinner! Now, you there, go kill us a rabbit. And you, over there, >start a fire. And you..." I realize that you think that you brought >a rabbit home, but others seem to think that you only brought a menu. No, Mr. Jeffers is _too_ _busy_ debugging his TSR to bring a menu. He thinks it would be a terrific idea, though, and is beside himself that no one has rushed out and invested their savings into buying a desktop publishing system to produce a menu, and then opening a restaurant to provide the cookware and the kitchen needed to prepare the rabbit which _he_ has decided _we_ all need to eat. For someone who professes to want to "beat the State", Mr. Jeffers seems to have a lot of personal energy invested in trying to get people to do what he says... As Tim has pointed out with his usual grandmotherly kindness, the "CEB" is hardly an original idea. Every three or four months, someone new runs in and shouts, "Hey, kids! Let's put on a _show_!" Mr. Jeffers will, sadly, not be the last, I suspect. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

Re: PGP 2.6 FAQ
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

>Engineering; Brian LaMacchia, graduate student in Computer Science; ~~~~~~~~~ Stoopid question: is the above-mentioned LaMacchia any relation to the LaMacchia who got busted for running the illicit fsp site? Yes, Brian is the elder brother. I asked him right after David was charged if he thought there was any connection, like using his brother to put pressure on him about the key servers. He said he was fairly sure it was entirely independent. Personally I don't rule out MIT internecine warfare and personal grudges. University politics can get as dirty as the real thing at times, but I think we can rule out *real* politics in this. G

2 1

Re: News Flash: Clipper Bug?
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> From: "Perry E. Metzger" <perry(a)imsi.com> > > My friend Matt Blaze at Bell Labs showed that you can forge LEAFs on > Tessera cards so that you can use Skipjack without anyone being able > to get the key you are using. Its a slick piece of work -- slick > enough that it made the front page of today's New York Times. More specifically, it was the TOP STORY in the Times. Ha ha ha. --Dave.

1 0

Re: News Flash: Clipper Bug?
by W Lee Nussbaum 17 Dec '03

17 Dec '03

In <9406021400.AA08779(a)disvnm2.lehman.com>, dmandl(a)lehman.com (David Mandl) writes: > >More specifically, it was the TOP STORY in the Times. Ha ha ha. Lesbian invisibility strikes again... (of the six columns on a Times front page, three of today's are topped by a picture, two by the article "Pentagon Must Reinstate Nurse Who Declared She Is a Lesbian", and one by this article, "Flaw Discovered In Federal Plan For Wiretapping") - Lee

2 1

Re: News Flash: Clipper Bug?
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>Eli Brandt says: >Its not pre-encryption. He's actually getting around the key escrow >features and using Skipjack in a secure manner. Its very slick. I've been saying it can be done for more than a year. I wrote a C model of some operating code for the chip. The clipper chip has save and restore commands that are used to dump and restore the LR register (crypto state). You keep your own LEAF and feed it back to the chip. You take the initial value of the LR register after IV generation and reload, it contains the IV. You exchange IVs with the distant end, who has also feed his own LEAF back to his chip. You have achieved crypto sync. The save and restore commands are to allow a single cryptographic algorithm embodiment to be used for two or more contexts - in the case of a duplex communications channel - send and receive. The question should really be how easy it is to subborn a clipper phone unit. The TSD 3600 is the only one available at this time. You need to be able to capture its programming, either by modifying ROM, exception handling and additional ROM, etc. I've been hesitant to buy a couple and try it for several reasons: 1) I'm not sure the key exchange is satisfactory, any TSD 3600 will talk to any other. 2) There might be anti-tamper features (re: FIPS Pub 140-1), causing loss of crypto variables (say for key exchange). It might be possible the TSD won't operate it all if security features are tripped. (unlikely, when you consider mechanical switches might bounce when one of these is thrown is a briefcase). 3) Its potentially a lot of work to capture the instruction stream. If internal ROM is used in something, its probably security locked. I could think of a couple of ways to make it harder to break into the code that operates a clipper chip.

2 1

Re: Clipper in patent trouble?
by Mark Voorhees 17 Dec '03

17 Dec '03

*********************************************************** Information Law Alert ||||||||| || |||| * a voorhees report * || || || || * * || || || || * 718-369-0906 * || || ||||||||| * voice * || || || || * 718-369-3250 * || || || || * fax * ||||||||| |||||||| || || markvoor(a)phantom.com* *********************************************************** 411 First St., Brooklyn, NY 11215-2507 May 27, 1994 _ __________ Clipper's dirty little secret ADMINISTRATION'S CRYPTO PLAN MAY HAVE PATENT PROBLEMS MIT professor says he deserves royalties An MIT computer scientist is trying to earn royalties on the use of the Administration's Clipper encryption plan. Negotiations, which one government official described as "erratic," have been going on for a couple months. Silvio Micali, the professor, holds one patent that he says covers a critical part of the government's Clipper project. He says the U.S. Patent and Trademark Office approved but has not yet publicly issued a second patent improving on the original invention. The royalty negotiations throw a wildcard onto the table of U.S. cryptography policy at an uncertain time. If the patent covers Clipper, opponents of U.S. policy will likely seize on the patent dispute as just one more reason to kill Clipper; users of Clipper will face higher costs; and the U.S. government will also have a much harder time exporting Clipper technology. Foreign governments recoil at the prospect of paying royalties to a U.S. citizen. Still, it is unclear how committed Micali is to facing off against barrel-chested U.S. negotiators. So far, he has been talking amiably to Michael Rubin, deputy general counsel of the National Institute of Standards and Technology, without the aid of a lawyer. "I didn't think that in dealing with the U.S. government, I would need a lawyer," Micali says. "I may be proved wrong." The key escrow, or Clipper, proposal is a coding scheme to provide privacy to voice, fax, and computer communications through the use of a secret codes. The code is embedded in a computer chipDthe Clipper chipDthat the government wants installed in telephones, fax machines and computers. But there's a catch: The secret key that unlocks messages is broken into two pieces and held in escrow by the government. With a court order, the government can reunite the two escrowed keys and tap the coded communications. Micali says that his patent covers the basic notion of escrowed keys in which trustees are given guaranteed pieces of the key. And while most of the 18 claims of the patent don't seem relevant to Clipper, the last four could be troubling. One of the claims clearly covers the division of a secret key into pieces and the recreation of those pieces in order to tap a line. If it applies to Clipper, Micali's patent would pose a vexing problem. Unlike most of the rest of the key U.S. cryptographic patents, the government does not seem to be able to use Micali's technology for free. Micali says he made the invention on his own time, not while working on a government-funded project, which would give the U.S. government royalty-free use. At least initially, the government will be the primary user of Clipper chip encryption devices. Officially, it is a voluntary standard for government use. But the Clinton Administration hopes the concept will spread into the private market. If that happens, consumers could face a higher price tag because of the Micali patent. The Clipper chip itself currently costs $25. A NIST official says the government is now evaluating Micali's patent and talking to the professor. The analysis includes whether the government provided any sort of funding to Micali's research that led to the invention underlying the patent. Micali initially approached the government several years ago about adopting a cryptographic scheme that he says is preferable to Clipper. Clipper is a private key system in which the same key, a so-called session key, is used to both code and decode a message. From a practical point of view, this requires the sender and user to exchange keys beforehand, which can be dangerous, time-consuming and expensive. Micali envisioned a public key system that would still give the government access to tap phone lines. Public key, of course, is the greatest recent cryptographic breakthrough because it frees the parties from selecting a key in advance. In a public key system, a sender will code a message with the receiver's public key, which is widely known. The receiver will then decode the message with his or her private key, which is mathematically related to the public key but difficult to compute. Under Micali's scheme, users would break their private keys into pieces and give each escrow agent a piece and a mathematical proof that the piece is legitimate. Upon proper authority, the government could then reassemble the pieces of the key to tap a message. The government obviously opted for Clipper rather than Micali's approach, but Micali did not go away. Last January, the patent office issued his patent, so the topic of conversations shifted to royalties. Micali won't say what sum he is seeking from the government except that it is reasonable compared to standard practices. It is not unusual for patent holders to seek 5 percent to 10 percent of sales if they feel they hold a core patent and up to 2 percent if their invention is peripheral. The Micali patent covers a public key system, which Micali says would give users more control over their keys and would be less expensive, even with royalty payments, than a hardware-based solution, like Clipper. Most of the patent's claims, therefore, don't cover Clipper, which is a private key system. (A user, however, may want to use a public key system like RSA to generate the session key under Clipper.) Micali's patent lawyer was wise enough to round out the patent with four general claims that cover the use of escrowed keys, regardless of the method. Micali says his second patent, which is not yet public, may cover Clipper even more directly. Claim interpretation, of course, is a matter of impression and imprecision, especially when it relates to inventions implemented in software. And it may be that NIST decides that Micali's claims don't specifically cover Clipper. In that case, Micali would be facing a legal bill of hundreds of thousands of dollars to make his case in court. Until that time, Micali is not revealing his strategy other than to say that he may soon need a lawyer. ************************ ----- that's all -----

1 0

PGP 2.6 FAQ
by Hal Abelson 17 Dec '03

17 Dec '03

Questions and Answers about MIT's Release of PGP 2.6 by Hal Abelson, Jeff Schiller, Brian LaMacchia, and Derek Atkins June 2, 1994 Q: Is PGP 2.6 an official release from MIT? A: Yes. PGP 2.6 is distributed via the Internet to non-commercial U.S. users by MIT Information Systems, via anonymous ftp from net-dist.mit.edu in the directory pub/PGP. Planning for the PGP 2.6 release was conducted with the knowledge and approval of the MIT administration. The MIT News Office officially announced the availability of PGP 2.6 in a press release dated May 26, 1994. *** Q: Was PGP 2.6 released in cooperation with RSA Data Security, Inc.? A: Yes. PGP 2.6 uses the RSAREF(TM) Free Cryptographic Toolkit (Version 1) licensed by RSADSI. RSADSI has granted MIT permission to access the non-published routines in RSAREF required to support PGP. *** Q: Was Phil Zimmermann involved in the PGP 2.6 release? A: Yes. Zimmermann has been fully involved in the release process. In addition, he approved all code changes from earlier versions of PGP and updated the PGP documentation for version 2.6. *** Q: Can PGP 2.6 interoperate with previous versions of PGP? A: Not completely. There are two different incompatibilities between PGP 2.6 and earlier versions of PGP. The first incompatibility is a deliberate format change that will trigger on September 1, 1994. The intent of this change is to discourage PGP users in the U.S. from using PGP 2.3a, which potentially infringes patents. The second incompatibility is that PGP 2.6 requires signatures to be in PKCS format, which has been the default since PGP 2.3, although PGP 2.3 was able to process non-PKCS signatures. *** Q: What's the effect of the September 1 format change? Will I still be able to use my old keys? Will I still be able to decrypt old messages? A: Both now and after September 1, PGP 2.6 will decrypt messages and uses keys generated by PGP 2.3a. To quote from the PGP 2.6 manual: PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4, or 2.5. However, because of a negotiated agreement between MIT and RSA Data Security, PGP 2.6 will change its behavior slightly on 1 September 1994, triggered by a built-in software timer. On that date, version 2.6 will start producing a new and slightly different data format for messages, signatures and keys. PGP 2.6 will still read and process messages, signatures, and keys produced under the old format, but it will generate the new format. *** Q: What about the PKCS requirement? A: PKCS Stands for Public Key Cryptography Standards and is a voluntary standard created by RSA Data Security and several industry leading organizations, including MIT. PKCS specifies standard encodings for encrypted and signed objects as well as some key formats. The standard documents themselves may be obtained via anonymous FTP from rsa.com. Starting with PGP version 2.3, PGP signatures have conformed to the PKCS signature standard. Although PGP version 2.3 generated PKCS format signatures, it was capable of understanding the non-PKCS format generated by PGP 2.2 and earlier versions. PGP 2.6 removes this compatibility code. This makes some of the PGP 2.6 code cleaner and ensures compatibility with future versions of RSAREF and other future standard software. Making the change now also encourages people to obtain fresh signatures on their keys, which is a prudent thing to do every so often. Note: The PKCS requirement has nothing to do with the September 1 PGP format change. It is an independent decision of the PGP development team. *** Q: Is there a technical reason for the September 1 format change? A: No. The format change is being made for legal reasons, not technical reasons. MIT wanted to bring out a version of PGP that would have the support of RSADSI. RSADSI would not lend their support to a product that fully interoperates with PGP 2.3, which, when used in the United States, potentially infringes patents licensed to them by Stanford and MIT. The intent of this format change is to discourage people from continuing to use the earlier software, which will mitigate the patent-caused problems that have hampered use of PGP within the U.S. The time delay between now and September is to give people adequate time to upgrade to the new software. *** Q: Does using RSAREF make PGP 2.6 run more slowly than previous versions of PGP? A: No. The speed-critical portions of PGP 2.6 use the same multi-precision integer libraries as in PGP 2.3a. We have noticed no appreciable speed difference between PGP 2.3a and PGP 2.6 on any of the platforms we have tried. If you observe a performance problem with PGP 2.6, please send details to pgp-bugs(a)mit.edu. Be sure to tell us what platform and compiler you are using. *** Q: Is there a back door in PGP 2.6? A: No. You need not take our word for it. PGP is distributed in source code, so that you can verify its integrity yourself, or get someone you trust to verify it for you. The 2.6 MSDOS executable file that we distribute has been digitally signed, so you will know that it has not been tampered with. In general, you should be wary of using encryption programs that you receive as object code, whose origin you cannot authenticate. *** Q: Why is PGP 2.6 limited to 1024-bit keys? Does this compromise the security of PGP 2.6? A: To quote from the PGP 2.6 manual: Beginning with version 2.4 (which was ViaCrypt's first version) through at least 2.6, PGP does not allow you to generate RSA keys bigger than 1024 bits. The upper limit was always intended to be 1024 bits. But because of a bug in earlier versions of PGP, it was possible to generate keys larger than 1024 bits. These larger keys caused interoperability problems between different older versions of PGP that used different arithmetic algorithms with different native word sizes. On some platforms, PGP choked on the larger keys. In addition to these older key size problems, the 1024-bit limit is now enforced by RSAREF. A 1024-bit key is very likely to be well out of reach of attacks by major governments. Cracking a 1024-bit key is far beyond any publicly known computational capability. The table below, originally posted to Usenet in October, 1993, gives some numbers for the expected amount of work required to crack keys of various sizes. The prediction for RSA129, which was finally factored in April, 1994, was very close to the actual time required. (The time was about 5000 MIPS-years, depending on your definition of a MIPS.) RSA129 (429 bits): 4,600 MIPS-YEARS a 512 bit key 420,000 MIPS-YEARS (safe for a little while!) a 700 bit key 4,200,000,000 MIPS-YEARS (seems pretty safe to me!) a 1024 bit key 2.8 x 10^15 MIPS-YEARS (Wow!) The above table is based on the Multiple-Polynomial Quadratic Sieve (MPQS). Other algorithms under development may have slightly better performance. The bottom line is that cracking a 1024-bit key using anything like presently known factoring methods will probably not happen within the lifetime of anyone reading this FAQ at the time of this writing (1994). A breakthrough in computer technology or algorithm efficiency that threatens a 1024 bit key is likely to be so powerful that it will threaten much larger keys as well, and then all bets are off! Any successful attack on PGP with large key sizes is more likely to come from exploiting other aspects of the system (such as the prime number generation algorithm) than by brute-force factoring of keys. Given this, it is not at all clear that key sizes larger than 1024 bits provide increased security in any practical sense. Nevertheless, RSADSI has granted MIT permission to modify RSAREF to increase the key size, and larger keys will be supported in a future PGP release. These larger keys, however, will not be manipulated by PGP 2.6 and earlier releases, so users will need to upgrade in order to use them. *** Q: There is no patent problem with using PGP 2.3a outside the U.S. Isn't it offensive to impose a change on PGP users around the world to accommodate a legal problem in the U.S.? A: To quote from the PGP 2.6 manual: Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. Hopefully, implementors of PGP versions outside the US will also switch to the new format, whose detailed description is available from MIT. If everyone upgrades before 1 September 1994, no one will experience any discontinuity in interoperability. We apologize to PGP users outside the U.S. We are asking them to undergo the inconvenience of making a change to the non-U.S. version of PGP for no technical reason. We hope that the effect of this change, which will remove any legal controversy from the use of PGP in the U.S., will benefit PGP users outside the U.S. as well as within the U.S. *** Q: How can PGP users outside the U.S. upgrade, if PGP 2.6 might be subject to U.S. export controls? A: The format change that will become effective on September 1, 1994 can be accomplished by a simple modification to the PGP 2.3a code, which was developed outside the U.S. MIT has published the new format specification. Consequently, a non-U.S. version of PGP that interoperates with PGP 2.6 can be produced without the need for anyone to attempt to export PGP software from the U.S. *** Q: With this incompatible change, what provisions are being made for users of ViaCrypt PGP (PGP 2.4) ? A: ViaCrypt has announced a new release of their product, called PGP 2.7, that supports both the old and new formats. They will also provide upgrade kits for users for version 2.4. For further information, contact Paul E. Uhlhorn Director of Marketing, ViaCrypt Products Mail: 2104 W. Peoria Ave Phoenix AZ 85029 Phone: (602) 944-0773 Fax: (602) 943-2601 Internet: viacrypt(a)acm.org Compuserve: 70304.41 *** Q: Does PGP 2.6 use RSAREF version 1, or RSAREF 2.0? A: PGP 2.6 uses RSAREF version 1. PGP 2.5 used RSAREF version 2.0. During the discussions that led to the creation of PGP 2.6, RSA Data Security requested that MIT switch to RSAREF 1. Furthermore, RSADSI gave MIT formal written permission to make calls to internal program interfaces in RSAREF 1, consistent with the RSAREF 1 license. From a technical standpoint, it doesn't matter which version of RSAREF is used by PGP. The major enhancements to RSAREF 2.0 have to do with functionality not required by PGP. Also, RSADSI's licensing restrictions (which require non-commercial use only) are not significantly different from RSAREF 1 to RSAREF 2. It is possible that later releases of PGP from MIT may use a different release of RSAREF, but we see no reason to do so at this time. *** Q: What is PGP 2.5 and what is its status? A: MIT initially released PGP 2.5 for beta test on May 9, 1994. During the beta test period, we continued discussions with RSA Data Security. These discussions led us to decide to install the September 1 format change, as well to use RSAREF 1 (see question above). PGP 2.5 contained several important bugs that have been fixed in PGP 2.6. PGP 2.5 does *not* contain the software necessary to understand messages generated by PGP 2.6 after September 1. We therefore urge all U.S. users to upgrade to PGP 2.6 (or a subsequent version). *** Q: What is PGP 3.0? A: PGP 3.0 is an anticipated upgrade to PGP. Unlike PGP 2.6, PGP 3.0 will be a major rewrite and reconstruction of the PGP internal software. PGP 3.0 might be ready before the end of 1994, but there are no specific release plans yet. *** Q: Will there be further incompatible changes to PGP? A: Almost certainly. As new features are added, the format of messages and other data structures will no doubt be changed. For example, we have considered adding a new packet type for signatures that places the signature at the end of a signed packet rather then the beginning. This will permit restructuring the PGP software so that it can operate in one pass, with no need to create the numerous temporary files that PGP now creates. This will facilitate applications that are not now currently possible. For example, a one-pass PGP could be used to encrypt data to a tape drive during backup. This cannot be done with PGP today because it would need to create temporary files that consume almost twice as much disk space as the data being backed up! *** Q: Will keys generated prior to PGP 2.6 continue to be usable? A: Yes. PGP 2.6 will always be able to use keys created by prior versions. New keys, generated *after* September 1 will *not* be usable by prior versions of PGP. However we hope that all PGP users will have upgraded to PGP 2.6 or better (or its non-U.S. equivalent) by September. *** Q: Why did MIT release PGP 2.6, when PGP 2.3 is already available? A: Using PGP 2.3 in the U.S. potentially infringes patents licensed exclusively to Public Key Partners by Stanford University and MIT. This sticky patent situation has deterred the spread of PGP, because many people and institutions did not wish to risk violating intellectual property restrictions. MIT has addressed this problem in PGP 2.6 by using RSAREF, which is licensed by RSA Data Security, Inc. RSADSI acknowledges that PGP 2.6 is a legitimate RSAREF application. The RSAREF license includes rights to all of the relevant U.S. patents on public key cryptography for non-commercial use. *** Q: Will there be version of PGP 2.6 for the Mac? A: People are working on this, but it's not ready yet. We hope it will be available within a couple of weeks. *** Q: Is MIT distributing PGP 2.6 to Canada? A: No, or at least not yet. There are some legal issues involved, having to do with possible U.S. export control restrictions, and we're getting advice on how to deal with these. We hope to sort this out next week. *** Q: Who are the people who are working on the PGP 2.6 release? A: People outside MIT working directly on the 2.6 release are Phil Zimmermann and Colin Plumb. People at MIT coordinating the PGP 2.6 release are Jeff Schiller, MIT Network Manager; Hal Abelson, Prof. of Computer Science and Engineering; Brian LaMacchia, graduate student in Computer Science; and Derek Atkins, graduate student in Media Arts and Sciences. Support from the MIT administration was provided by Jim Bruce, MIT Vice-President for Information Systems; David Litster, MIT Vice-President and Dean for Research; Karen Hersey, MIT Intellectual Property Counsel; and John Preston, MIT Director of Technology Development. *** Q: Are there more questions? A: Certainly. If there are other questions about PGP 2.6 that you think ought to be answered here, please send us to them (at pgp-bugs(a)mit.edu) and we will try to include answers in future versions of this FAQ.

1 0

No Subject
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

San Jose Mercury News, Front Page June 2, 1994 SCIENTIST FINDS FLAW IN CODE TECHNOLOGY New York Times A computer scientist at AT&T Bell Laboratories has discovered a basic flaw in the technology that the Clinton administration has been promoting to allow law-enforcement officials to eavesdrop on electronically scrambled telephone and computer conversations. Someone with sufficient computer skills can defeat the government's technology by using it to encode messages so that not event the government can crack them, according to the Bell Labs researcher, Matthew Blaze. For more than a year, the Clinton administration has been advocating the encoding technology as the best way to ensure the privacy of telephone and computer conversations while retaining the traditional right of law- enforcement officials to use court-authorized wiretaps to eavesdrop on the conversations of suspected criminals or terrorists. The technology, based on what is known as the Clipper chip, has been widely criticized by communications executives and privacy-rights advocates, who fear its Big Brother potential. The industry also fears foreign customers might shun equipment if Washington keeps a set of electronic keys. But now, Blaze, as a result of his independent testing of Clipper, is putting forth perhaps the most compelling criticism yet: The technology simply does not work as advertised. Blaze spelled out his findings in a draft report that has been quietly circulated among computer researchers and federal agencies in recent weeks. "The government is fighting an uphill battle," said Martin Hellman, a Stanford University computer scientist who has read Blaze's paper and is an expert in data encryption, as the field is known. "People who want to work around Clipper will be able to do it." But the National Security Agency, the government's electronic spying agency, which played a lead role in developing the technology, said Wednesday that Clipper remained useful, despite the flaw uncovered by Blaze. Agency officials do not dispute the flaw's existence. "Anyone interested in circumventing law-enforcement access would most likely choose simpler alternatives," Micheal A. Smith, the agency's director of policy, said in a written statement. "More difficult and time-consuming efforts, like those discussed in the Blaze paper, are very unlikely to be employed." A necessary compromise? Since announcing the Clipper coding technology 13 months ago, White House and Justice Department officials have argued forcefully that it is a necessary information-age compromise between the constitutional right to privacy and the traditional powers of law-enforcement officials. The Clinton administration intends to use Clipper, which it is trying to promote as an industry standard, for the government's sensitive non-military communications. The federal government is the nation's largest purchaser of information technology. But industry executives have resisted adopting Clipper's electronic "backdoor," which is designed for legal wiretapping of communications, could make it subject to abuse by the government or unscrupulous civilian computer experts, who might eavesdrop without first obtaining a court order and the electronic "keys" that are to be held in escrow by two government agencies. Privacy-rights advocates have cited similar concerns. Industry executives also have worried that making Clipper a federal government standard would be a first step toward prescribing the technology for private industry or requiring that it be included in sophisticated computing and communications that are to be exported. Secret conversations Blaze said that the flaw he discovered in the Clipper design would not permit a third party to break a coded computer conversation. But it would enable two people to have a secret conversation that law-enforcement officials could not unscramble. And that could render Clipper no more useful to the government than encryption technology already on the market to which it does not hold the mathematical keys. "Nothing I've found affects the security of the Clipper system from the point of view of people who might want to break the system," Blaze said Wednesday. "This does quite the opposite, Somebody can use it to circumvent the law-enforcement surveillance mechanism." Blaze said that several simple changes to the Clipper design could correct the flaw but that they might be difficult to adopt because they would require the government to start over in the designing of Clipper. The government has already begun ordering telephones containing the Clipper chip for use by federal agencies, and it is designing another Clipper-based device, called the Tessera card, for use in personal computers. Hellman at Stanford said that the government was counting on most crooks and terrorists not to go to the trouble of modifying the Clipper design or otherwise seeking to disable it - fi they used it at all. System not subverted One computer scientist who has been a proponent of the Clipper plan and who is familiar with Blaze's paper said that the flaw would not immediately subvert the system. "I don't think this undermines the Clipper," said Dorthy Denning, a computer scientist at Georgetown University and part of a team chosen by the government to evaluate the technology. "But it's good to know what the vulnerabilities are." Clipper was designed by researchers at the National Security Agency in cooperation with computer scientists at the National Institute of Standards and Technology, a civilian agency that is responsible for setting computer standards for non-military government applications. The Clipper chip is known as an "escrowed encryption system." It is designed so that law-enforcement officials wishing to eavesdrop on Clipper-encoded communications must present a court warrant and a special number - or key - generated by a Clipper chip to two separate government agencies. Each of the agencies would hold portions of a special number, which can be used together to decode the conversation.

1 0

Re: PGP 2.6 FAQ
by tim werner 17 Dec '03

17 Dec '03

>Date: Thu, 2 Jun 94 10:56:11 -0400 >From: Hal Abelson <hal(a)martigny.ai.mit.edu> >To: cypherpunks(a)toad.com > >People at MIT coordinating the PGP 2.6 release are Jeff Schiller, MIT >Network Manager; Hal Abelson, Prof. of Computer Science and >Engineering; Brian LaMacchia, graduate student in Computer Science; ~~~~~~~~~ >and Derek Atkins, graduate student in Media Arts and Sciences. >Support from the MIT administration was provided by Jim Bruce, MIT >Vice-President for Information Systems; David Litster, MIT >Vice-President and Dean for Research; Karen Hersey, MIT Intellectual >Property Counsel; and John Preston, MIT Director of Technology >Development. Stoopid question: is the above-mentioned LaMacchia any relation to the LaMacchia who got busted for running the illicit fsp site? Just curious. tw

1 0

patent musings
by hughes＠ah.com 17 Dec '03

17 Dec '03

I wonder what would happen if Micali sold his patent to RSADSI? Might there be another turnaround as with Schnorr/DSA? Eric

1 0

LEAF forgery
by perry＠imsi.com 17 Dec '03

17 Dec '03

Matt gave me permission to explain the technical details of the paper. This is the hack. Its idiotically simple. According to the paper, because of the nature of the communications involved, the Capstone chip is forced to accept as valid any LEAF with the right 16 bit checksum. Note that the LEAF contains only the the chip's ID, the key encrypted in the chip's "secret never to be divulged except by escrow" key, and this checksum, all encrypted with the family key. Since the other chip lacks the "supersecret" key, it can't check that the session key matches the encrypted session key. It relies on the checksum for everything. That checksum is a silly 16 bits long. Thus, you just have to try about 2^15 random LEAFs and you can get one that works. You can even precompute them if you wish. Its that simple. Then all you do is send the rogue LEAF instead of a legitimate one. Matt Blaze should be commended for finding such a big hole. As with most such ideas, its obvious in retrospect but took some good thought to come up with in the first place. Let me say also that the NSA should feel highly embarassed. They fucked up big time. My terror of them from a few days ago when we heard the Russian Coup intercept story has lessened. Even if they are years ahead of us, they are still human. Perry PS There are also a bunch of neat techniques out there for the "lets say that you don't care about interoperating" case, but they are naturally less general.

1 0

Re: News Flash: Clipper Bug?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

smb wrote: Perry's right. Several of us have seen Matt's paper, and the attacks really do work. (Even NSA admits that.) But out of courtesy to Matt, we'd rather leave it to him to discuss the details. One thing this shows, even if the application of the technique turns out to be too difficult to be practical, is that Dorothy Denning's evaluation of the design was worthless. That team should have found this themselves. No wonder she was trying to play it down in the NYT. G

3 2

Re: PGP 2.6 FAQ
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

tim werner(a)mc.ab.com wrote: >Stoopid question: is the above-mentioned LaMacchia any relation to the >LaMacchia who got busted for running the illicit fsp site? Yes; it's his brother.

1 0

Re: Pedophiles in Cyberspace
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Duncan Frissell <frissell(a)panix.com> writes: > The WSJ op ed page today has an article on the 1st > Amendment in Cyberspace by Stephen Bates that focusses > (analytically) on pedophiles and Usenet. It is not > hysterically negative but discusses the "downside" of our > technology. Just what the world needs. Another reporter who spends a short time on Usenet and emerges to proclaim to the clueless masses that the Internet is bursting at the seams with child porn GIFs and that the pedophiles are frolicking uncontrollably. While it would be difficult to list all the inaccuracies and misstatements of fact contained in Steven Bates' WSJ article in a single message, the following leap out at even the most inexperienced Internet user. The newsgroup, alt.sex.pedophile.mike-labbe, originally formed to discuss the legal problems of a BBS Sysop, is almost dead and averages no more than a few posts a week. While pictures are occasionally posted, they are almost without exception art taken from legal sources. While some messages have been posted which might seem to solicit illegal activity, such messages are regularly flamed by other readers of the group, and illegal activity is discouraged. Calling this group "alt.sex.pedophile" and characterizing it as the Internet's official distribution point for illegal child porn is a gross misrepresentation of reality. The newsgroup, alt.sex.intergen, formed to discuss issues surrounding intergenerational relationships, including those between adults and minors, is represented as a place where pedophiles congregate to plot their evil deeds. But discussion of the sexual rights of minors is only one issue covered under the alt.sex.intergen charter and it would be ludicrous to suggest that pedophiles are the only people to whom such issues are important. You don't have to be a member of a sexual minority to find fault with American sex and censorship laws, and such issues are discussed by people representing all ages, sexual orientations, and professions. Taking a few lurid-sounding quotes out of context from many months of postings does little to correctly convey the tone of this newsgroup. Mr. Bates repeats the popular myth that Europe is some bastion of readily available child porn easily accessed via the Internet. This is simply not the case. All the European and Scandinavian countries now have laws against distributing such material with severe penalities for violations. With the large number of American net.cops trolling the Internet looking for illegal pornography and the cooperation of foreign law enforcement agencies in shutting down sites, no such operation could stay in business for long. The comparison the article makes between "advocating pedophilia" and Holocaust Revisionism should be equally offensive to Jews and non-Jews alike. Suggesting that teenagers should have the right to choose their own sexual partners cannot be compared to denying the deliberate killing of six million men, women, and children. Dr. Fred Berlin, who should have known better, is quoted in the article as suggesting that people in general, and pedophiles in particular, are prone to do in real life everything they contemplate in fantasy. Since the world of fantasy is largely devoid of the moral and social inhibitions which constrain our real-world behavior, this is unlikely to be the case. Since Dr. Berlin is the world's foremost authority on the treatment of paraphilias, we should give him the benefit of the doubt and assume he was either quoted out of context, or like Ken Udut, deliberately misled as to the purpose for which his comments were being solicited. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd(a)netcom.com $ via Finger. $

2 1

Re: New MacPGP
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

Eric writ, >I deleted it. Enough said. BTW, BinHexed files are pure ascii. -=GuEsS WhO=-

1 0

Re: CEB 5 - The Hangover
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: For someone who professes to want to "beat the State", Mr. Jeffers seems to : have a lot of personal energy invested in trying to get people to do what : he says... Well, if he *really really* wants it that much, and the only thing stopping him is lack of expertise, then I'll do the work for him for two hundred dollars a day. (That's my cheap rate for fill-in work while I'm idle, which I may well be in a couple of months time...) G

1 0

what I can say...
by perry＠imsi.com 17 Dec '03

17 Dec '03

Having seen Matt's paper, and having been asked by him not to distribute it, I feel somewhat obligated not to give any details. The complete method can actually be determined from the newspaper article (which was astonishingly lucid, all things considered) but having been "mentally contaminated" its not ethical for me to describe it. However, I'll say this. 1) He found a beautiful little defect -- it can be explained in a couple of lines, and it seems obvious, but somehow no one but Matt saw it. Its a classic -- he deserves lots of kudos. It permits full interoperability between a "rogue" Tessera user and a non-rogue user. 2) Its likely that a redesign of the EES (escrowed encryption standard) could avoid this defect. Whether it could avoid all defects is, of course, unknowable -- but the current design is simply flawed and does not truly achieve its stated goal. 3) If the NSA actually worked for years designing this thing, someone wasn't thinking. Perry

1 0

Re: what I can say...
by Graham Toal 17 Dec '03

17 Dec '03

From: "Perry E. Metzger" <perry(a)imsi.com> 3) If the NSA actually worked for years designing this thing, someone wasn't thinking. I still maintain that the FOIA'd docs extracted by gnu imply that there's a *real* backdoor as well as the key escrow, and I suspect the key escrow/ Law Enforcement Abuse Field stuff was hurriedly tacked on as an afterthought. Personally I wouldn't rely on clipper ever *with* a private session key. G

2 1