Channels ▼

A Conversation with Ron Rivest

Dr. Dobb's Journal October 1997: A Conversation with Ron Rivest

How important is cryptography and computer security?

Jack programs client/server applications, some of them in Rexx, from Golden, Colorado. He can be contacted at

Ron Rivest leaped into the computer-science limelight in 1977 when, along with fellow MIT assistant professors Adi Shamir and Leonard Adelman, he invented the RSA public-key cryptosystem. For more than two decades now, this cryptosystem has withstood extensive cryptanalysis, inspiring confidence in the theoretical underpinnings of the algorithm. The RSA cryptosystem also formed the foundation of RSA Data Security, a company Rivest helped launch and of which he still serves as a director.

Still, Rivest is first and foremost an educator. He is currently the Webster Professor of Electrical Engineering and Computer Science at MIT, an Associate Director of MIT's Laboratory for Computer Science, and a leader of that lab's Cryptography and Information Security research group. With Thomas H. Cormen and Charles E. Leiserson, Rivest is coauthor of Introduction to Algorithms, a comprehensive introduction to the modern study of computer algorithms that has been identified by DDJ as a fundamental book for computer programmers (and included on Dr. Dobb's Essential Books on Algorithms and Data Structures CD-ROM). Rivest published his paper "The RC5 Encryption Algorithm" in DDJ (January 1995), and is also the recipient of DDJ's 1997 Excellence in Programming Award (see DDJ, May 1997).

We're pleased that Professor Rivest recently had time to sit down with frequent DDJ contributor Jack Woehr to talk about cryptography, computer science, and a host of other topics. (Rivest's home page, located at ~rivest/homepage.html, is also rife with interesting technological resources and bibliographical references.)

DDJ: Can you define computer security?

RR: Computer security covers a broad range of activities. The two primary goals are information confidentiality, seeing that information is not disclosed to parties it shouldn't be disclosed to; and authentication, making sure that a message has integrity and that you know who wrote it. Information security may branch out into other things, too, if you've got computers that are controlling things like dams and telephone systems. When you get into payment systems, you're talking application-level now, where you've got a variety of specified system objectives about how a payment system should work.

In general, security consists of implementing the policies of someone who designed the system, policies regarding who should have access to, and who should control, various kinds of information.

DDJ: A Nielsen survey released March 12, 1997 showed that people fear buying things on the Internet because they don't think their credit card numbers are safe.

RR: They're probably safer using their credit card for Internet transactions than they are using it in a local restaurant. It's a question as to what the risk is; the risk in a restaurant is that the waiter/waitress you give the credit card number to copies it down, keeps a copy of the carbon, whatever, sells it to a friend...My personal guess is that this is more likely to happen in a restaurant than on the Internet. Not that this situation couldn't turn around at some point, but currently, the number of credit card thefts carried out over the Internet is probably very small compared to the number carried out in ordinary institutions like a restaurant or a shopping center.

DDJ: Is our world coming to mirror that genre of dystopic science fiction that depicts infinite opportunities for corruption, people picking your pocket in the street, people picking your pocket electronically, and so on?

RR: To evaluate such a risk, you have to evaluate how many people out there have both the motive and the means to carry out an attack. It's much easier for the clerk with a credit card slip to make off with your number than it is for someone to mount a sophisticated attack against an encrypted Internet line.

DDJ: And suppose the information arrives intact and authenticated: Could the legitimate electronic recipient of consumer transactions be trying to rob you?

RR: Absolutely. Someone is manning the store. If it's totally automated, then it's a question of whether the people implementing the system are engaged in widespread fraud. This seems much less likely than individual fraud, when you have lots of people handling individual transactions. This is why some proposed protocols don't even show the credit card number to the merchant: It's encrypted all the way to the bank.

DDJ: How about logistical scams, such as the one last spring when the online pornography service in Moldova was taking a cut from the Moldovan phone company? (DDJ, "News & Views," May 1997). The software to access their service would turn off the user's modem speaker, dial direct to Moldova, and incur telephone charges that AT&T is obligated by international treaty to pay without demur.

RR: I love examples like that! They illustrate basic attacks. People have to learn that there are risks, just like they learn to keep their wallet in their front pocket rather than in their back pocket. There are concerns, when you have a system where you can download software and execute it on your machine. You have to be pretty careful about who you download the material from, or what constraints you set upon your operating system when such applications are allowed to run.

DDJ: Does Java solve this problem?

RR: Java has as a goal solving this problem, and is getting nearer to it. I think it's got a way to go yet. In terms of allowing an operating system to specify what are the conditions under which a Java program may execute, you may want a variety of policies for different Java applets. You need a good way of specifying and enforcing what your policy is for the different kinds of applets.

DDJ: Is the "you" that is enforcing such policies "you" the user, "you" the operating system designer, "you" the software provider, or all of them?

RR: In some cases, the user might want to get directly involved, might need to be asked, "Here's a program that's attempting to access one of your files, may we acquiesce in that?" The user might be trying an experimental word-processing program and want to grant access. He may not need to be involved; it may be an explicit policy of his operating system that every applet digitally signed by Manufacturer "X" can be executed without further checking with the user.

Digital certificates are valuable; people want assurance that the applets they are loading are what they pretend to be, at least in terms of authorship. The applets may have further qualities; for example, they need access to files, qualities which themselves may be the subject of a signature. I think the manufacturer stepping up and taking responsibility for these qualities is a good thing. It allows the user side, the browser side, to start making policy decisions based on those qualities that can be authenticated.

DDJ: How do these certificates work and how good are they?

RR: Digital certificates are based on public-key cryptography, which has been around for a long time now. We have a very high level of confidence that it works well and does what it's supposed to do; that is, create a signed document that may include such things as a program or an applet, even assert certain things about the applet, if you like. This is a technology that is pretty well understood even though it is still evolving.

Standards are essential. If a manufacturer is signing applets, the browser needs to understand the public-key technology used in the signatures. A modest number of standards are needed just to make the system work. It doesn't need to be one standard, two or three might emerge.

As usual, there is chaos as all the companies rush ahead to be first to market. In this case, the World Wide Web Consortium, which is housed at MIT's Laboratory for Computer Science, has coordinated the industry's attempt to get together on a digital signature initiative for this kind of application. I think that the industry as a whole will get behind that. It's not one of those things where there's any particular market advantage for a company to be different.

DDJ: Will people ever vote in elections via the Internet?

RR: I have students working on an electronic voting project. We're refining a protocol by Fujioka, Okamoto, and Ohta of Japan, trying to make it as practical and scalable as we can.

The protocol posits a variety of parties involved. There are one or more administrators that know the list of authorized voters; there are the voters themselves; there's an anonymizer for sending anonymous mail to a counter who tallies the mail and publishes the results. There are a variety of steps whereby you get your authorization to vote: You download a web page that has the ballot on it, you fill it out, there's a hash, the hash gets blinded and sent to the administrator who signs it for you, you unblind it and send it back, an anonymizer sends it to the counter and it gets published, with some checking to make sure everything's okay.

In a way, this is tinkertoys compared to some of the protocols that have been proposed. We'd like to implement it and see how it works in practice.

DDJ: The voting system has traditionally been weak on technical integrity. There are many known voting scams.

RR: With electronic voting, you can tell that your vote has been counted.

DDJ: Until the "bad guys" figure out the next way to spoof it?

RR: When you've got cryptography, it's hard for the bad guys to get in the middle of it. The difficult scenario with electronic protocols is where you've got the bad guys corrupting the insiders, corrupting the registrar of voters, who can stuff the ballot box with imaginary voters.

DDJ: There have appeared fairly well documented reports of attempts to influence Congress by deluging members with phony constituent mail generated by other branches of the government. If all voting is done online, will we find government agencies deciding the presidential election surreptitiously?

RR: I would hope they wouldn't be able to generate spurious voters. Each registrar of voters is independent. If there were attempts at voting time to deluge the systems with phony e-mail, you might need fast machines to dump it in a timely fashion. You may need to declare a delay in the election if someone manages to bring down the whole network, which I suppose could be done. But by and large, with electronic elections, you can tell when it's working properly.

DDJ: So you're saying that the partition of the conceptual network of American elections, in that there are individual human registrars as nodes of this network, will protect the system, that it's not all going to a big computer in Washington?

RR: Well, it could all go to a big computer in Washington. But these results all get published. You can take your own PC and download these results, and see that each of the votes that is there has actually been signed by an appropriate administrator, a registrar of voters, in a blinded manner. You can see that your own vote is there.

You could have several administrators, one from each major party, one from the ACLU, and so on. Then you'd need to corrupt all three administrators to vote the same way on the same day to forge one single vote.

You'll end up in the same situation, in that if the people running the elections are corrupt, you've got problems. But you can divide the problem: having several mutually mistrusting parties having to cooperate to spoof the election gives you some assurance the election's running properly.

DDJ: So in electronic voting, and in electronic commerce, there's no one big, friendly technology that's going to guarantee that everything is safe.

RR: One has to be aware of the risks involved in having sensitive information used in a global network. We have to lose our naïveté. Some measures may be taken automatically to protect you, while others you may have to be aware of.

DDJ: And how many consumers understand the phrase, "sensitive data on a global network"?

RR: How many people in the year 1950 understood a credit card? People now use credit cards, and understand the risk of credit cards. It's an education process.

DDJ: How painful an education process?

RR: Stories wherein there's a modest amount of damage, as it appears in the Moldovan episode, which are also highly publicized, can have a great educational effect.

Security is a cat-and-mouse game. You can't afford perfect security. Companies make investments to ameliorate the risks. Over time, the technologies improve, it gets harder for the bad guys. Breaking into bank vaults isn't done much today: It's gotten really hard to do. It went through a series of stages, and now you've got vaults that are really elaborate. We'll see the same evolution with Internet security.

DDJ: What does the commercial turmoil of general computing look like from inside Academe?

RR: There's a great deal of creativity and turmoil indeed. At the Laboratory for Computer Science we see the industry close up, because we work with them on emerging technical problems with the Internet, the Web, advanced hardware specs, whatever.

DDJ: It seems that computer science used to be LISP, Prolog, Knuth, but you're telling me it's much more sophisticated than it was 15 to 20 years ago.

RR: The character of what computer science is about has changed quite a bit. Analyzing algorithms and programming language issues are still talked about, but the existence of the Internet and the World Wide Web have changed the focus of some of the research. People are looking at caching algorithms for the Internet, secure transactions, lots and lots of Internet-related stuff. The hardware has gotten to the point where parallel computation is a very hot topic as people look at how to harness all this silicon power that we're capable of assembling in a single machine.

Our students are going out there and founding companies and being successful. A recent report found that companies that were spun off from MIT have had a tremendous impact on the economy. We have a paternal relationship to some of these companies, which are run by people who have come through the MIT educational process with the Computer Science department, through the Laboratory for Computer Science, through the AI lab.

The amount of programming that goes on in universities has gone down compared to the amount that goes on in industry. There are interesting things that industry does that couldn't take place in academia, just because they take too much effort. The applications have gotten quite large. You can't have such a large-scale effort within a university.

DDJ: No more situations like Berkeley writing whole operating systems?

RR: There's still a lot of that going on. Universities are still the seedbed for this, they do the initial designs, the prototyping, the feasibility studies. When these things become a little bit more real, they get spun off in a technology transfer, which works quite well in this country.

DDJ: My son lasted one year in computer engineering, then was seduced into a job and left school. Will the demands of industry let the kids finish school these days?

RR: I think the students realize it's usually in their own best interests to complete through the degree program. We see more students going to the master's level than before, the number of Ph.D. students is the same, or may have gone down a little bit. Some of that's industry pull, I'm sure.

DDJ: Do you have a warm feeling for academia? Is it what you wanted?

RR: I certainly enjoy working for MIT and the Lab for Computer Science and for the department here. It's a very exciting place to work. I've also enjoyed the opportunity to have one foot in industry and to consult and found companies. It's a nice blend of activities.

DDJ: I remember 30 years ago going with my mother to see the Foucault pendulum at Temple University in Philadelphia. At that time, a university really was a temple, it had the atmosphere of a mystical temple of learning. Are universities still like that?

RR: Some of them may be. MIT has the character of being very dynamic, very embedded in and integrated with industry and working with government on policy issues. MIT is interesting because, in some ways, it's not an ivory tower that's cut off, It's a place where you can choose to shut your office door and think about problems quietly if you wish, but it's also got opportunities for making connections with lots of places outside MIT.

DDJ: What's the most interesting part of your work?

RR: On the whole, cryptography. Cryptography is fascinating from many angles. It's got beautiful mathematics, it has gamesmanship of good guys and bad guys, and it's got real applications.

For the past decade, I've done quite a bit of research in machine learning.

DDJ: How smart is Deep Blue when it beats Gary Kasparov at chess?

RR: Computers are getting very good at playing chess. I don't know if you want to apply the word "smart" to that, because "smart" has a general intelligence flavor to it, and this is not general intelligence. This is very good specialized intelligence.

DDJ: Is it possible that computers are aware?

RR: That's a very excellent and deep question. I spent quite a bit of my time trying to figure out what that means. I think most computers are not aware in any useful sense of the word, but trying to make computers aware, in whatever sense one means that, is a fascinating research goal. I don't think we've gotten very far along that at all.

DDJ: As a cryptographer, do you feel as Phil Zimmerman, our local Colorado hero, does?

RR: He's more than a local hero these days. Phil and I go back a long ways. I like Phil, and he's done a lot of interesting stuff. I think he and I share a lot of the same concerns. The ability of the government to have surveillance over nearly everything is very worrisome. It's appropriate for individuals to be able to have private conversations protected by cryptography.

If you're having a voting system, the government should not have the means or the right to see what you're voting, for example, if the means exists to do that privately. Et cetera. I think there are lots of places the government should be restricted from listening into.

Cryptography is -- computer security is -- essential to the modern science of information processing. I would urge Dr. Dobb's readers to find out more about those areas.


Copyright © 1997, Dr. Dobb's Journal

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.