- cypherpunks-legacy@lists.ogf.org

["Vinton G. Cerf": Letter to Congress/RSA + DES]
by Marc Horowitz 14 Apr '93

14 Apr '93

Vint Cerf is a very well-known and respected person in the Internet community. I don't know if his testimony will mean anything, but it's interesting to read. Marc ------- Forwarded Message To: internauts:;@IETF.CNRI.Reston.VA.US Subject: Letter to Congress/RSA + DES Date: Tue, 13 Apr 93 20:26:01 -0400 Sender: cclark(a)IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" <vcerf(a)CNRI.Reston.VA.US> Dr. Vinton G. Cerf 3614 Camelot Drive Annandale, VA 22003-1302 11 April 1993 The Honorable Timothy Valentine Committee on Science, Space and Technology Subcommittee on Technology, Environment and Aviation House of Representatives Rayburn House Office Building Dear Chairman Valentine: I recently had the honor of testifying before the Subcommittee on Technology, Environment and Aviation during which time Representative Rohrabacher (R, California) made the request that I prepare correspondence to the committee concerning the present US policy on the export of hardware and software implementing the Data Encryption Standard (DES) and the RSA Public Key encryption algorithm (RSA). As you know, the DES was developed by the National Institute for Standards and Technology (NIST) in the mid-1970s, based on technology developed by Internatonal Business Machines (IBM). The details of the algorithm were made widely available to the public and considerable opportunity for public comment on the technology was offered. In the same general time period, two researchers at Stanford University (Martin Hellman and Whitfield Diffie) published a paper describing the possible existence of mathematical functions which, unlike the symmetric DES algorithm, could act in a special, pairwise fashion to support encryption and decryption. These so-called "public key algorithms" had the unusual property that one function would encrypt and the other decrypt -- differing from the symmetric DES in which a single function performs both operations. The public key system uses a pair of keys, one held private and the other made public. DES uses one key which is kept secret by all parties using it. Three researchers at MIT (Rivest, Shamir and Adelman) discovered an algorithm which met Hellman and Diffie's criteria. This algorithm is now called "RSA" in reference to its inventors. The RSA technology was patented by Stanford and MIT and a company, Public Key Partners (PKP), created to manage licensing of the RSA technology. A company called RSA Data Security, Inc., was also formed, which licensed the technology from PKP and markets products to the public based on the technology. The current policy of the United States places DES and RSA technology under export control. Because cryptography falls into the category of munitions, it is controlled not only by the Commerce Department but also by the State Department under the terms of the International Traffic in Arms regulations. Despite the public development of both of these technologies and their documented availability outside the United States over the last 15 years, US policy has been uniformly restrictive concerning export licensing. As the United States and the rest of the world enter more fully into the Information Age in which digital communications plays a critical role in the global infrastructure, the "digital signature" capability of public key cryptography is a critical necessity for validating business transactions and for identifying ownership of intellectual property expressed in digital electronic forms. Registration and transfer of intellectual property rights in works which can be represented in digital form will be cenral factors in the national and global information infrastructure. A number of parties are exploring technical means for carrying out rights registration and transfer, making use of public key cryptography as a basic tool. In addition, there is a great deal of current work on electronic mail systems which support privacy by means of encryption and support authenticity by means of digital signatures. One of these systems, developed in the Internet environment I mentioned in my testimony, is called Privacy-enhanced Mail (PEM) and makes use of DES, RSA and some other special "hash" functions which are integral to the production of digital signatures. For these various systems to be compatible on an international basis, it would be very helpful for the cryptographic components to be exportable on a world-wide basis. A number of vendors make produces relying on these technologies within the United States but often find it very difficult to engage in international commerce owing to the export licensing required for these technologies. Ironically, the technology appears to be widely available outside the US and also outside the COCOM countries, so US firms face both competition outside the US and export inhibitions in their attempts to develop worldwide markets. There are many valid national security reasons for limiting the export of cryptographic capabilities, since these technologies may aid an opponent in time of war or other conflict. Perhaps just as important, US intelligence gathering capability can be eroded by the availability of high grade cryptography on a worldwide basis. Recently, it has also been alleged that the world-wide availability of cryptography would also seriously impede US drug enforcement and anti-crime efforts. While these reasons seem sufficient, many have pointed out that the widespread accessibility to the detailed specifications of DES and RSA and availability and existence of software and hardware outside the US have long since done whatever damage is going to be done in respect of warfighting, crime or drug potential. This line of reasoning leads to the conclusion that our policies only inhibit legitimate commerce, but have little impact on the other concerns expressed. As in all such controversy, there is often some truth on both sides. The National Institutes of Standards and Technology (NIST), has offered alternative digital signature capability. Technical assessments of the alternative have turned up weaknesses, in the opinions of some experts. There is not yet an alternative to DES, unless it is to be found in NSA's Commercial Crypto Evaluation Program (CCEP) in which NSA proposes to provide algorithms which are implemented in hardware by industry and made available for civilian use. As I understand this program, NSA does not intend to release any details of the algorithms, leaving open questions about the nature and strength of the technology. Some experts will persist in the belief that such offerings have weaknesses which are deliberately built in and hidden (so-called "Trojan Horses") which will allow the agency to "break" any messages protected by this means. The critics complained loudly that the reasoning behind the design of certain parts of the DES algorithm (specifically the "S-boxes") was never made public and therefore that the algorithm was suspect. In fact, the DES has proven to be very strong - indeed, it may be that very fact which makes it so unpalatable in some quarters to permit its unrestricted export. It may be that the CCEP technology offered is satisfactory, but this is hard to tell without knowing more about its provenance. Presuming the wide availability of both DES and RSA technology, it seems to me appropriate and timely to re-examine US export control policy regarding these two algorithms. In all probability, any such review will require some classified testimony which will have to be heard in confidence by cleared members of your committee. I sincerely hope that the outcome will be favorable to use by US industry in international commerce, but even if the outcome results in continuation of present policy, it is timely to make such a review, in my opinion. Sincerely, Vinton G. Cerf ------- End of Forwarded Message

1 0

how secure is secring.pgp?
by J. Michael Diehl 14 Apr '93

14 Apr '93

Yet another pgp question... We don't get any pgp news groups here. Since we need a passphrase to access our secret key, it is reasonable to think that our secring.pgp file is pretty secure, as long as our passphrase is notrivial. What am I missing here? Thanx in advance. +----------------------+----------------------------------------------------+ | J. Michael Diehl ;-) | I thought I was wrong once. But, I was mistaken. | | +----------------------------------------------------+ | mdiehl(a)triton.unm.edu| "I'm just looking for the opportunity to be | | Thunder@forum | Politically Incorrect! | | (505) 299-2282 | <me> | +----------------------+----------------------------------------------------+

4 4

Sign-off
by sean＠gomez.Jpl.Nasa.Gov 13 Apr '93

13 Apr '93

Please remove me from this list. Thanks. -- Sean Barrett How many boards would the Mongols sean(a)pugsley.jpl.nasa.gov (fast) hoard, if the Mongol Hordes got bored? sbar(a)genie.geis.com (reliable) PGP key by finger or from key servers.

1 0

Re: Modem encryption proposal
by karn＠qualcomm.com 13 Apr '93

13 Apr '93

Crypto synchronization seems to be a problem mainly in real-time appliations like digital voice, where you don't have a reliable protocol underneath you. I advocate two approaches that don't seem to have been pursued much yet, at least in the Internet: per-packet encryption (and possibly) authentication) just above the IP layer, and stream encryption just above TCP. The former technique has the advantage of denying your adversary the maximum amount of information, because only the IP header is in the clear. The transport header and all user data is protected, so an eavesdropper can't tell which applications are communicating. And with IP-in-IP encapsulation, you can even deny him knowledge about which machines are actually communicating - a network-level service analogous to anonymous remailers. With authentication, network level security also provides good protection against replay attacks. The latter technique (encrypting above TCP) has the advantage of being more efficient (it doesn't break Van Jacobson TCP/IP header compression), which may make it desirable for some interactive sessions. This is essentially how encrypted Kerberos Telnet works now, although I would like to generalize the service to work with any TCP client. Phil

3 2

forward: cryptanalysis talk abstract
by david＠staff.udc.upenn.edu 13 Apr '93

13 Apr '93

Thought people might find this abstract of a talk being given here at Penn of some interest. Please let me know if I'm wrong <grin>. (And, no, I won't be attending; almost all of it would be over my head. What is in this abstract is probably as much of it as I could understand without considerable preparation <grin>). ------------------------------------------------------------------------ In article <119753(a)netnews.upenn.edu>, holland(a)central.cis.upenn.edu (Billie Holland) writes: > > Statistical Techniques for Language Recognition: > An Introduction and Empirical Study for Cryptanalysts > > Alan T. Sherman > Computer Science Department > University of Maryland Baltimore County > > In cryptanalysis, how can a computer program recognize when it has > discovered all or part of the secret message? For example, how can a > program recognize character strings such as ``Attack at dawn!'', > ``DES@RT ST\&RM'', or ``?tta????t d?wn'' as fragments of intelligible > messages? In the early days of cryptology a human would perform these > language-recognition tasks manually. In this talk I will explain how > to recognize language automatically with statistical techniques. > > Statistical techniques provide powerful tools for solving several > language-recognition problems that arise in cryptanalysis and other > domains. Language recognition is important in cryptanalysis because, > among other applications, an exhaustive key search of any cryptosystem > from ciphertext alone requires a test that recognizes valid plaintext. > Although I will focus on cryptanalysis, this talk should be relevant > to anyone interested in statistical inference on Markov chains or > applied language recognition. > > Modeling language as a finite stationary Markov process, I will adapt > a statistical model of pattern recognition to language recognition. > Within this framework I will consider four well-defined > language-recognition problems: 1) recognizing a known language, 2) > distinguishing a known language from uniform noise, 3) distinguishing > unknown 0th-order noise from unknown 1st-order language, and 4) > detecting non-uniform unknown language. For the second problem I will > give a most powerful test based on the Neyman-Pearson Lemma. For the > other problems, which typically have no uniformly most powerful tests, > I will give likelihood ratio tests. I will also discuss the > chi-squared test statistic $X^2$ and the Index of Coincidence $IC$. > > In addition, I will present the results of computer experiments that > characterize the distributions of five test statistics when applied to > strings of various lengths drawn from nine types of real and simulated > English. > > > This is joint work with Ravi Ganesan. Most of this work was carried > out while Sherman was a member of the Institute for Advanced Computer > Studies, University of Maryland College Park. > > Thursday, 15 April 93 > TOWNE BUILDING - 337 > 3:00 - 4:30 > -- david david(a)staff.udc.upenn.edu

2 1

Security Dynamics
by Brad Huntting 13 Apr '93

13 Apr '93

The MIS department where I work has started using "Secure-ID" cards made by Security Dynamics Inc for access to their MVS systems. After listening to a presentation by marketing droids and technical support from Security Dynamics I had these impressions: The cards are programmed at the factory with a "random" seed. They have an internal clock, and a lithium battery. They use a proprietary encryption algorithm to encrypt the time of day using the internal seed and display it on an LCD display using about 6 or 7 digits. The display updates itself every 60 seconds (this frequency is adjustable when you order the cards) An authenticating host will have the cards seed, as well as the cards "clock offset" (the time the card was seeded, and the clock reset). The user has a 4 digit PIN (personal identification number) known only to the host (and of course written on the back of the card :-). PIN numbers must be unique since they are used to identify the user. At login time, the user is asked to type in her PIN, as well as the number currently displayed on the card. This is checked by the host, and if it's correct the user is authenticated. If used on a regular basis, the authenticating host can detect clock drift and will adjust it's database accordingly. Cards can be used across multiple "realms", but this nessesitates trusting the cards shared key with each host that wants to authenticate that card. The cards are timed to deactivate after some time interval (again, this is an option) the default lifespan is 3 years, they can go as high as 4 or 5, but after that, the battery isn't reliable. You can probably imagine some of the problems with such a system. First and foremost in my opinion, it uses an unknown proprietary algorithm which is a closely guarded company secret known only to them and anyone which a dissasembler. Obviously such an algorithm has never undergone any serious scrutiny. Most respectable researchers (outside of Ft Meade) do not need to disassemble code to find material to write papers on. Second, the cards are programmed at the factory, and the user has no way of reseeding them. The company actually touts the fact that they have all the card info for all customers on file, and will gladly send you encrypted tapes or floppys if you loose you database! Of course they will only talk with one designated contact at your site, and they will only ship materials to that person. In all fairness if your a big client, and you insist, they might be compelled to tell you how to seed the cards, and give you a batch of "raw" cards. When I mentioned how ludicrous it was for us to trust their internal security, they made some lame noises about employees being "bonded". In other words, they have established plausible denyability and are "out of the loop" should your security data be compromised. I was a little furious. Lastly, their expensive. Something on the order of $60/card in quantities of 250 to 500 for cards that last 3 years and change every 60 seconds. Programmable DES devices (used by DEC and others) which employ a challenge response system are about one third as much. I came away from the talk with a bitter taste in my mouth. As I understand it (and please correct me if I'm wrong) they are, at this point, one of the largest companies "crypto card" companies in the world. This is, to say the least, unsettling. If you want more info, they're Colorado office is at: Security Dynamics 5299 DTC Boulevard Suite 500 Englewood, CO 80111 Phone: +1 303 773-6519 brad

4 4

Re: Security Dynamics
by Peter Honeyman 13 Apr '93

13 Apr '93

> I read an article about a pseudorandom number generator > which appeared random to every test they used on it. Then they went > and did a monte carlo simulation of something based on that prng. > Guess what? It wasn't quite random enough. Lesson: it can be *very* > hard to determine randomness. if this is the phys. rev. let. paper by ferenburg et al., there's a postscript copy up for ftp in csp2.csp.uga.edu:/pub/documents/amf1/. i can summarize. their simulations were based on five to ten runs, with 10^7 updates per run. they aren't precise about the exact number of random numbers needed, at least not in this paper, but i assume it's in the order of one per update, in which case 10,000 would not be enough. more info can be gleaned from the paper in /pub/documents/adler3/. they compared four basic rngs. a linear congruential algorithm (cong) x[n] = (16807 * x[n-1]) mod 2^31-1 two different shift register algorithms (sr250 and sr1279) x[n] = x[n-103] xor x[n-250] x[n] = x[n-103] xor x[n-1279] a subtract with carry generator algorithm (swc) x[n] = x[n-22] - x[n-43] - c if x[n] < 0 { x[n] += 2^32 - 5 c = 1 } else c = 0 a combined swc-Weyl generator (swcw) y[n] = (y[n-1] - 362436069) mod 2^32 x[n] = (swc[n] - y[n]) mod 2^32 the authors report that the tables were initialized with some care (i.e., with cong). the result reported in the phys rev let paper is that r250 gave results that were way off (the model being simulated has an exact solution), swc was better, but had error in the opposite direction, swcw was better but still showed signs of bias, and cong was within error limits. they also report that r1279 was much better than r250, but the tables are missing from the paper, so ... on the other hand, using every fifth value from r250 gave results within error limits. same with swc. odd ... maybe someone can comment on the particular rngs being tested here. they don't look particularly sophisticated to me, although the authors describe them as "ostensibly high quality rngs." hmmm ... looking over thir recent pubs, it doesn't look like this group (of statistical physicists) is following up on the rng testing angle. peter

2 1

Re: FWEE!: kiosks
by karn＠qualcomm.com 13 Apr '93

13 Apr '93

Eric's comment about the complementary natures of a public kiosk and a person's home suggests a hybrid whistleblowing scheme that combines the best of both. The whistleblower creates his file in the privacy of his own home on a floppy disk, encrypts it in the public key of the whistleblowing system, and carries it to a public kiosk where he sends it. This gives the whistleblower plenty of time and quite a bit of privacy as he composes his message (unless the PTB have bugged his home computer, a possibility for a suspected repeat "offender"). The step of physically carrying his file to the kiosk eliminates anything that could be done to the whistleblower's phone (including traffic analysis), although it would not stop physical surveillance of the whistleblower. And if the whistleblower is accosted on his way to the kiosk, all they could seize would be the ciphertext of his message, encrypted in the public key of the whistleblowing service -- which the whistleblower himself would not be able to decrypt even if he wanted to. Think of the kiosk more as a public mailbox than a public phone. Phil

2 1

Modem encryption proposal
by miron＠extropia.wimsey.com 13 Apr '93

13 Apr '93

-----BEGIN PGP SIGNED MESSAGE----- Let's talk less and do more. :) How about adding encryption to kermit and iScreen so that they may talk to each other in a secure manner? I am proposing these two programs because they are widely portable. kermit works on most Unix and MSDOS systems. iScreen works on most Unix systems. (Note that this would solve the network/modem eavesdropping problem, but not the untrusted remote system problem. The latter has no solution in my opinion. You just have to trust the sysadmin.) I propose writing a link encryption library which could be usable in other comm and BBS programs. Any takers? BTW, watch for an encrypted Unix talk program coming to a ftp site near you. - -- Miron Cuperman <miron(a)extropia.wimsey.com> | NeXTmail/Mime ok | Public key avail AMIX: MCuperman | PSM 18Mar93 0/0 Laissez faire, laissez passer. Le monde va de lui meme. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK8jc6pNxvvA36ONDAQEJlAP9HYJ94Ll7H0YHr5tNj3Kp3xQ8WRryyO2W BNLKYhBvoPapNMZ/4mPiPSgVZw8Tu/JXFdVtbhhA2Q7u8ef7+daf2g/fyi4M1Mb4 0a9+AKjDG6FvwMMo4AjlqTG1x0+Xl/YeizBqD1hVW/2pAu3I7IyvZavWY2HkVwwD tTDfiOSIxVk= =zhoD -----END PGP SIGNATURE-----

4 3

Re: Security Dynamics
by karn＠qualcomm.com 13 Apr '93

13 Apr '93

Several years ago, before leaving Bellcore, I got so annoyed at the SecurID cards and how they were being foisted on us by a paranoid security organization that I built an alternative one-time password system of my own. It's now called "S/KEY" (no, I didn't pick the name). Essentially, I reinvented a scheme of Leslie Lamport involving iterated one way functions. Each time you log in, you crunch your password N-1 times through a one-way function like MD4 or MD5, where N is the number of times you did it last time. The host crunches it once more (to make its password file somewhat less sensitive) and compares it to the stored password. If it matches, the file is updated and you get in. A passive eavesdropper cannot generate the next password in the sequence from the current one because that would require inverting the one-way function. The nice thing about this scheme is that it provides essentially the same service as SecurID (protection against passive eavesdropping of user passwords) without having to pay exhorbitant prices for cards and integrating some really clunky hardware into your host. You have the option of building the algorithm into your own comm programs, or even the ultra-low-tech option of printing out a list in advance and putting it in your wallet. (Use rice paper if you fear capture - you can eat it! :-)) The bad thing about this scheme is that it provides no more protection than SecurID -- it doesn't stop someone from hijacking your session after you've authenticated it, nor does it protect the session itself against eavesdropping. And frankly, at the time I was more concerned about the security droids reading my email off the Ethernet than I was about some outside cracker guessing my password. Phil

1 0