December 2003 - cypherpunks-legacy

Re: Why RSA?
by msattler＠netcom.com 17 Dec '03

17 Dec '03

>I don't know if ViaCrypt includes any distinguishing features >that let you tell a ViaCrypt PGP message from a Real PGP message - >they could do subtle stuff like make the session keys all >include some checksum (e.g. be a multiple of N mod M), >or crude stuff like put "Version 2.3ViaCrypt" in the headers, >which would let them detect non-ViaCrypt PGP users. >I assume not, but I haven't seen it. PRZ has specifically said that it is his intention to have no difference between the output of the PGP and ViaCrypt so that users of the free-ware version can't be ferreted out. ----------------------------------------------------------------------------- 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

the PTB etc. - errata
by L. Detweiler 17 Dec '03

17 Dec '03

I wrote: >Or, it might be that the investigators thought that a mere >subpoena for records would be less explosive than one for documents. That should read: Or, it might be that the investigators thought that a mere subpoena for records would be less explosive than one for key witnesses & testimony. And to anticipate questions in email, >This is >not to say it was not on the minds of `the powers that be', which I >will henceforth coin the PTB, and let it serve as the hypothetical TLA >responsible for all *unsolved* conspiracies in existence. TLA is a silly self-referential term: Three Letter Acronym.

1 0

PGP question
by Sameer Parekh 17 Dec '03

17 Dec '03

I have run into a rather embarrasing problem with PGP. I accidentally deleted the secret key to my cory remailer. Luckily, I have kept a backup of all my remailer keys in a safe place, so I still have it. Unfortunately, I can't figure out how to extract the cory secret key from the keyring containing the secret keys for my other remailers. pgp -kx and pgp -kr work quite fine for the public keys, but I can't get them to work for the secret keys. (All 6 keys were on the same keyring.) Any help? (Because of this problem, PGP on cs60a-qu(a)cory.eecs.berkeley isn't working-- if you want to do pGP through one of my remailers, use sameer(a)soda.berkeley.edu or sameer(a)netcom.com)

1 0

Source for MacPGP2.3?
by jrk＠sys.uea.ac.uk 17 Dec '03

17 Dec '03

I have MacPGP 2.3 (the Macintosh application). From what ftp site can I obtain the source? soda only has Mac source for 2.2. -- ____ Richard Kennaway __\_ / School of Information Systems Internet: jrk(a)sys.uea.ac.uk \ X/ University of East Anglia uucp: ...mcsun!ukc!uea-sys!jrk \/ Norwich NR4 7TJ, U.K.

1 0

NIST Explains Clipper "Review" (fwd)
by Anonymous 17 Dec '03

17 Dec '03

In case you haven't heard: To: Cypherpunks <toad.com!cypherpunks> Date: Thu, 23 Sep 1993 16:51:12 EST Subject: NIST Explains Clipper "Revi NIST Explains Clipper "Review" The National Institute of Standards and Technology (NIST) has clarified the role of five experts selected by the agency to evaluate the government's Clipper Chip proposal and the underlying SKIPJACK cryptographic algorithm. In a recent letter to the CPSR Washington Office, NIST asserts that the panel was not established to provide "advice or recommendations" to the government. Rather, according to NIST, the reason for convening the group was "to provide the opportunity for independent experts to satisfy themselves as to the strength and effectiveness of the algorithm in order to encourage widespread acceptance of it in the marketplace." NIST concludes that the panel's evaluation therefore falls outside the scope of the Federal Advisory Committee Act, which opens the work of advisory panels to public scrutiny. In response to CPSR's request for documents relevant to the panel's review, the agency reveals that NIST has no records which were made available to or prepared for the five experts for the purpose of enabling them to evaluate the Clipper Chip proposal. Any such records would be in the possession of the National Security Agency, where all activities related to the work of the experts were conducted. This disclosure provides further confirmation that NSA, and not NIST, is the driving force behind the Clipper proposal, despite NIST's public role as the "proposing" agency. The only NIST document released to CPSR is a copy of the invitation sent to the five experts who participated in the evaluation. That letter describes the "key escrow" system and states that the escrowed keys will be made available "only to authorized government officials under proper legal authorizations, usually a court order." This language -- "usually a court order" -- suggests that there will be instances in which the escrow keys will be provided to government agents without presentation of a judicial warrant. The government has never clearly defined what will constitute "legal authorization" under the Clipper system. David L. Sobel CPSR Legal Counsel <dsobel(a)washofc.cpsr.org>

1 0

Re: NIST Explains Clipper "Review"
by mjr＠TIS.COM 17 Dec '03

17 Dec '03

One thing that occurs to me: rather than arguing Clipper's technical merits, or whether or not it's Big Brother and therefore evil, we should be making the press aware of the fact that Clipper is going to cost major $$ for the taxpayers. This will be reflected in terms of increased cost on consumer electronics, and in the cost of administration of the key escrow system. Since both agencies for the escrow will be government, the taxpayers are going to bear the entire burden of the very complex (and presumably expensive) escrow management. Our CEO, Steve Walker, has asked how many court ordered wire taps are performed anually. Apparently, the number is very low (under 1,000) - we must question the cost effectiveness of a measure designed to protect wiretapping at a cost of hundreds of millions of dollars, when apparently wiretapping is not that important a tool in the arsenal of law enforcement. Recently, at the NCSC conference, a Mr. Brooks from NSA spoke on the Clipper panel, and stated proudly that they had been working hard on clipper for over 3 years. Unfortunately, NSA's budget is classified, so we'll never find out how much this B1-bomber of telecommunications has already cost the taxpayer, but we need to bring the potential expense involved to the attention of our various representatives. In a time when people are losing their jobs and government is trying desperately to cut costs, we must ask ourselves if it would be more cost effective to spend the hundreds of millions of dollars clipper will cost the taxpayer on hiring more police officers, or on social programs. I don't believe that our elected representatives or the non-technical press understand the issues behind key escrow. We need to make them understand that effectively clipper means that the consumer will pay more for certain forms of electronics, that the taxpayer will pay more for administering programs of questionable usefulness, and that the government is using covert budgets to subsidize an attempt to compete in the telecommunications business. Our elected representatives and the press understand $300 government toilet seats. Perhaps we need to come up with a nice name for clipper. Rather than calling it the "big brother chip" perhaps we should call it the "B1 bomber of data communications" or point out that it is really an implicit tax on telecommunications. mjr. [PS - these are my personal opinions]

1 0

Re: the public key minefield
by smb＠research.att.com 17 Dec '03

17 Dec '03

> derek(a)cs.wisc.edu (Derek Zahn) > >* 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? L. Detweiler writes: > others have well addressed how patent issues are involved in this. b ut > this appears to be a simple technical question on one level. What do es > it take to come up with a good public key system? How about a poor public key system? What is the simplest public key system you can invent, if you didn't care that it is trivial to break? If the NSA can crack RSA, does that change the fact that it is a pkc? message=99 public_key= 1/3 private_key= 3 encrypted_message= message * public_key message= encrypted_message * private_key Would PKP reading of their patent claims cover this pkc? Seems overbr oad! No, because of the language in the patent which requires that it be infeasible to find the deciphering key from the enciphering key. Here's the claim, from patent 4218582, that covers all of public key cryptography: 1. In a method of communicating securely over an insecure communication channel of the type which communicates a message from a transmitter to a receiver, the improvement characterized by: providing random numbers at the receiver; generating from said random numbers a public enciphering key at the receiver; generating from said random numbers a secret deciphering key at the receiver such that the secret deciphering key is directly related to and computationally infeasible to generate from the public enciphering key; communicating the public enciphering key from the receiver to the transmitter; processing the message and the public enciphering key at the transmitter and generating an enciphered message by an enciphering transformation, such that the enciphering transformation is easy to effect but computationally infeasible to invert without the secret deciphering key; transmitting the enciphered message from the transmitter to the receiver; and processing the enciphered message and the secret deciphering key at the receiver to transform the enciphered message with the secret deciphering key to generate the message.

1 0

Re: Why RSA?
by smb＠research.att.com 17 Dec '03

17 Dec '03

Let me try to answer some of these questions by giving a broad overview of patent law. I'm not a lawyer, but I've spent a lot of time talking to lawyers about patents during the last several years, and about what they are and aren't. First of all, a patent is (theoretically) a contract between an inventor and society. In return for the inventor teaching everyone about the new idea, he or she gets a monopoly on use of that idea for a limited period (normally 17 years in the U.S.). Patents cover the right to build, make, import, or even *use* the protected idea. A patent is *not* a license to do something. Rather, it is the right to prevent others from doing it. Thus, if I invented the pencil, and you invented the eraser, neither of us could make a pencil+eraser without permission from the other. Patent infringement is not a crime; you cannot go to jail for it. It is a civil offense, and the patent holder has to sue you for infringing. You can get a patent for things that are new, useful, and non-obvious. All three criteria must be satisfied. Note specifically that a new use for an old idea is patentable. R, S, and A did not patent particular equations; rather, they patented certain specific uses for those equations. If you can find a new use for them, you're home free. (I and a colleague almost did that. We came up with a new application for them, and we felt that the security of our scheme would be strengthened tremendously by the work that's gone into RSA. However, our application was just different enough that I managed to crack it. Sigh. But better that I cracked it before publishing...) For our purposes, a patent consists of two major parts. The first is more or less a technical paper; this is what you're supposed to learn from. Some of the language is rather stylized, but for the most part it will be comprehensible to someone who understands the field. The second part is the ``claims''; these are written in very dense legalese, and are supposed to delimit exactly what's new. You infringe a patent if your activity includes all of the elements of any one claim. Writing good claims is at the heart of a patent attorney's skills. You want to claim as much as you possibly can, even if you think some of it is worthless -- but you have to make sure that what you claim doesn't include prior art. In the RSA patent, for example, almost every claim speaks of both encryption and decryption. The idea of mine that I alluded to involved encryption only; thus, it did not fall within the scope of all but one of the RSA claims. For various other reasons, it didn't fall within the scope of the other one. > All are patented in so far as one of the patents covers ALL public k ey > schemes. Some, like Rabin's scheme, have possible technical advantag es > over RSA. First, a note: "Rabin's scheme" is (as Perry said) the one provably linked to factoring (a major advance!) and I assume it's the one implemented in RPEM. According to the RIPEM FAQ, PKP squashed that development by claiming that their patents were broad enough to cover Rabin's scheme, and the effort was abandoned "for pragmatic reasons" (another example of how superior technology can be suppressed by monopolies). Well, Rabin's scheme has other problems as well, including the lack of an unambiguous decryption algorithm. You get a few answers, one of which will be correct. Under patent law, though, the ``superior'' technology hasn't been suppressed. Rather, Rabin would need a license from RSA (and Diffie-Hellman) to practice his invention. And he couldn't have come up with his idea unless RSA had been published. Now, I've looked a little further into the patent issue, and I remain kind of confused. I went to the library and read the four patents in question (but only made a hardcopy of the first chronologically). I found the documents difficult to understand (for legal rather than crypto-tech reasons). All four applications were made in 1977-1978, and the patents were granted variously from 1980-1984. The earliest one has Hellman, Diffie, and Merkle as inventors; the second just Hellman and Merkle. Both are assigned to Stanford University. It seems to me that one of these is the one that covers, broadly, public key cryptography -- presumably the earliest one (4,200,770), since it has all three major players as inventors and the language of the eight claims seems to be rather broad (though only the second patent, 4,218,582, has the phrase "public key" in its title). Patent 4,405,829, granted in 1983, is for the RSA algorithm [footnote: the RSA patent apparently celebrated its tenth birthday two days ago; was there a party?]. There is no overlap between this patent's inventors and assignees and the earlier more general patent. Here's a question for somebody in the know: if the earlier patents cover all public key cryptography and RSA is a public key system, isn't it in violation of the earlier broader patent? Does PKP pay license fees to Stanford, or were they granted exclusive rights by Stanford as well as MIT? As I explained above, a patent does not infringe per se. However, practicing RSA would indeed require a license from Stanford. But both Stanford and MIT assigned exclusive licensing rights to those patents to Public Key Partners, a deal which arguably violates the antitrust laws. (Down, libertarians, down. I know you don't believe in such things...) Anyway, patent 4200770 claims virtually all mechanisms for public key distribution or exchange systems. Exponential key exchange is the particular example given; it's claimed, too. Patent 4218582 claims all of public-key cryptography. The knapsack system was the particular system given; it was claimed, as well. I should note here -- to patent something, while you don't (as a rule) have to build it, you do have to show that it's buildable. If there's any doubt, the patent examiner can order you to produce one. This is used to deal with perpetual motion machines and the like. The concept of public key cryptography couldn't have been patented without a working example. And, while knapsack systems were subsequently cracked, at the time the patent was issued there were no (publicly) known attacks. Similarly, apparently a public-key scheme called Warlock has been granted patent protection. How is this possible if somebody else holds patents covering all of public key encryption? If I understand patents correctly (hah!) they last for 17 years from the time they are granted. This means that the earliest public key patent will expire in about 3.5 years. After that presumably there will be no restrictions on new public key systems. The RSA patent would expire in 2000. If somebody could clarify which patent is the "broad" public key patent, I'd appreciate it (even with them right in front of me, I can't tell)! My guess is that it would have to be either 4,200,770 or 4,218,582 -- if it's the latter, how did Merkle get squeezed out of inventorship? Have a look at "The first ten years of public key cryptography", Diffie, W., Proceedings of the IEEE 76:5, 1988, pp 560-577. Respondents to my initial questions pointed out that the patents may be over-broad and could be challenged on those grounds; given the history of how public key crypto was invented, it seems to me that it would be difficult to contend that the idea is obvious (Simmons says that the idea "stunned" the crypto community) -- but I'm no lawyer, and I'll leave that issue to those with more skill, brains, and money than me! There was some question of prior art published more than one year before the patent was filed. See "Multi-user cryptographic techniques", Diffie and Hellman, AFIPS Proceedings 45, pp109-112, June 8, 1976. The patent apparently contains some language explaing why that doesn't count, and in particular because there was no demonstration that it was even possible to build such a thing as a public key cryptosystem.

1 0

Re: P. Wayner on CSSPAB meeting
by Jason Zions 17 Dec '03

17 Dec '03

Mr. "Hyperbole-R-Us" Detweiller said: >>A group of computer scientists from NIST came to discuss their plan >>for the Federal Criteria for secure systems and the new "Common >>Criteria" that may emerge. This is an updated version of the old >>Orange Book classification scheme of C2 and B1 and stuff like that. >>The scientists said the draft is being finished but it isn't ready >>for release. But now, they're working on "Something Better." This >>is a new plan to standardize the grading of secure systems with >>other countries and evolve a "Common Criteria." In general, the >>board groused about the fact that the public and industry have never >>been invited to give comments during the process. The summary >>of this talk is: "We might be able to tell you something someday." > >`other countries'? `Common Criteria'? holy cow, this is something *very >big* in the works. The U.S. can barely figure out its *own* >cryptographic policies, and imagine the sheer logistical nightmare of >trying to come to an agreement between the most isolated and imperious >agencies! It's a shame you understand so little of this. The "Federal Criteria" they're discussing are the Trusted Computer Security Evaluation Criteria, or TCSEC. This is also called the "Orange Book", since it was published in an orange cover. It's a purely-US DOD document that defines various levels of computer security - you remember, C2, B1, B3, all that stuff. It talks about Mandatory Access Controls, Discretionary Access Controls, Auditing, Authentication, etc. Cryptography as such is not addressed by the TCSEC. I believe the TCSEC discusses cryptographic authentication techniques in an abstract manner, but not even to the degree of naming any. The UK and other European countries have their equivalent to the TCSEC. The security levels have different names, and the included features differ slightly. The EC recognized that this difference in nomenclature and definitions would act as a barrier to free trade, so they began a program to harmonize these definitions. The "Common Criteria" would take this EC stuff beyond Europe into the US, allowing vendors of secure systems to get them rated once and sell them in a bunch of countries instead of building country-specific secure systems as they are required to do today. Another aspect of the Common Criteria is that they are expected to be a little more commercial in focus. The TCSEC and its counterparts were generally developed by the Defense organizations within their respective countries of origin; the focus of control and security reflects the needs of the developing organizations. Commercial users have been complaining for years that the TCSEC et al don't meet their needs in a useful and flexible manner; one desired goal for the Common Criteria is to meet this need. Cryptography is almost completely unrelated to the actual criteria themselves. Cryptography is one possible implementation mechanism for several of the capabilities required by the TCSEC and its successors; it is not the only such mechanism. The TCSEC does not prescribe or proscribe implementation technology. > I suspect GCHQ (Britain's NSA) would be involved in this at >least. (There is a very cozy relationship between NSA and GCHQ that >Kahn was harassed for revealing in _CodeBreakers_.)What other agencies? The TCSEC and Common Criteria are really being developed by various Defense agencies; in the US, NIST is also involved, as I suppose DIN, BSI, AFNOR, etc. are. NSA is uninterested in making systems secure; their job is to break them anyway. Since the TCSEC doesn't specify mechanism, it's at too abstract a level for NSA to tamper with. There are no boogie men from the Spy House involved here, at least in the US. You can sleep well again. Jason Zions

3 2

Re: on the `R' in `RSA'
by smb＠research.att.com 17 Dec '03

17 Dec '03

I'd also be interested in hearing of any other accounts that match my own passion for the subject :) Also, if others have any educated opinion, evidence, or theories of whether public key crypto was *undiscovered* by the NSA prior to the publication of Diffie and Hellman and RSA, I'd read them with great fascination. NSA claims to have developed public-key cryptography about ten years before the public discovery. See @article{Diffie88, author = {Whitfield Diffie}, journal = {Proceedings of the IEEE}, month = {May}, number = {5}, pages = {560--577}, title = {The First Ten Years of Public Key Cryptography}, volume = {76}, year = {1988} } a paper I hightly recommend to this entire list.

1 0