Interview with Phil Zimmerman

A reader writes "PGP's creator is participating in an online interview this week. Phil is mainly interested in clearing the air about the recently discovered ADK bug, but the larger topics of encryption and worldwide organized snoop rings (Echelon) have already come up. The interview is open to questions from anyone; runs through Friday 9/8."

Comments

We need secure protocols, not content.

[Tackhead]

The evidence we're seeing - Carnivore being the best example - indicates that The Powers That Be are more interested in traffic analysis than in terms of decrypting your content.

In other words, all the strong crypto in the DATA segment of the SMTP transaction isn't gonna save you if an FBI agent decides he wants to forge a "From: kiddypr0narchive@fbi.gov" in an email to you. For mail to truly be secure, it's clear that we now need to encrypt all headers in the SMTP and/or POP transactions.

Likewise, for safe browsing, SSL on the content of the pages isn't enough; all the metadata in the HTTP GET requests have to be encrypted too.

Traffic analysis makes sense; it's machine-readable data, machine-parsable, and very easy to inject into a database for profiling purposes. Scanning a database for all From: addresses associated with To: fields of osama_bin_laden@secretterroristcamp.iq, or IP addresses associated with Referrer-ID: fields matching the regexp *janetreno*goat*pr0n* is a lot easier than actually trying to examine a terabyte of .JPGs.

We've seen it in the public domain with the "auto-sue" programs used against Napster users.

We're seeing the gummint getting into the act with Carnivore. Whaddyawannabet that 5 years from now, when Jaz and ZIP drives are no longer available, the "physical evidence" ceases to be a piddly 120M disk (which can probably only hold the sniffed headers from a handful of users before it has to be swapped for another disc) and becomes a 200G hard drive (which can hold everyone's traffic for a few days)? Hell, the cost of the "removable hard drive Carnivore" isn't much more than the ZIP drive one today.

At what point will we redesign our basic communications protocols to be snoop-resistant?

Re:We need secure protocols, not content.

[Bill Currie]

I agree with you about SMTP (and other protocols in general), but your thinking on SSL is flawed. Nothing of the higher level protocols (eg http) is un-encrypted. Try sniffing an SSL connection some time. You will not see anything recognisable (except maybe the SSL protocol itself). No GET, no POST, nothing but gibberish.

So, going with the intent of your posting, all that's needed is to use SSL for everything. Now, there is still one problem. `They' can tell what machine you are connecting to (the tcp/ip headers are not encrypted, but then I don't really see how they can be*). One way to avoid this is to have multiple secure relays, but each relay is an openning for them to get in to grab the un-encrypted protocol information.

* Routers need to know where to send the packets, so at least the IP and possibly the TCP headers can not be encrypted.

Bill - aka taniwha
--

Re:We need secure protocols, not content.

[Tackhead]

> your thinking on SSL is flawed. Nothing of the higher level protocols (eg http) is un-encrypted. Try sniffing an SSL connection some time.

Yeah, I just recalled Hotmail as an example where the sign-in process was done securely, but everything else was done in plaintext. Rather a silly implementation.

As for SSL in general, what was I thinking when I posted that? (I shouldn't try sniffing an SSL connection, I should just try drinking more coffee before I post a brainfart like that again.) *doh!*

Re:We need secure protocols, not content.

[metoc]

Just remember not to go overboard. If you make it too hard, outfits like the FBI will just do a little late night B&E and plant a trojan on your system to send unencrypted copies of your traffic, degrade your encryption, steal your keys, etc.

They may not have legal right to do it, but once your data hits Carnivore (assuming a legal e-tap is in place) its your word versus theirs on how the trojan got in your system (not like its going to have ©FBI in it).

Just to be fancy, how many regular users would notice if someone added a Promise IDE RAID card and a second harddrive (in mirror mode) to their system.

Re:should everything on the internet be encrypted

[ffujita]

If big brother like organizations waste a week trying to decrypt your mother's letter about a new recipe she just tried, that is a week they don't have to decrypt the message you reply with explaining why your family has to go into hiding. We need to inject more noise into the system.

Ummm, I thought that if they decrypt your mother's new recipe then they have your private key, and then they can decrypt everything else you send without much force. Of course, I'm somewhat ignorant -- do people change their keys every message? Does the software exist to change the key for each packet that is sent?

Re:What about quantum computers?

[mOdQuArK!]

I know that, but my points were:

1) quantum computers do not break symmetric encryption, so if quantum computation becomes commonplace, then we're no worse off than before public-key encryption became a common concept (and in fact, our symmetric systems will still be useful).

Unfortunately, we will have to resort to physical means to securely pass our keys (with the accompanying possibility of rubber-hose or sticky-fingers decryption techniques...)

2) There are still mathematical operations which look like they have the same kind of property that factoring large numbers or doing discrete logarithms have right now, i.e., being easy to do in one direction, and hard to do in the other, but do not look like they will be easily solveable by a quantum computer.

So...the advent of practical quantum computing might make the CURRENT public key infrastructure useless (in which case we are no worse off than our current state where hardly ANYTHING on the net is encrypted), but there will still be the ability to transition back to an encrypted state.

Re:Publishing Source

[Frank T. Lofaro Jr.]

DMCA makes a circumvention device illegal. Code is at least possible to consider a virtual device. It does something. Okay, it really makes a real device (computer) do something, technically it is only instructions. But we think of it and use it as a device. We say the Linux kernel, for example, does something when a user makes a system call.

A printed version of the code does not act as a virtual device, it can't do anything or automatically make a computer or any other device do something.

Now it lets a person (or a computer with OCR) make a copy of the code, but the DMCA doesn't say instructions for making a circumvention device are illegal. Heck it doesn't even say a device that makes a circumvention device is illegal. (Although I wouldn't want to rely on that it court). They can hang a lot on the prohibition on "trafficing" in such devices.

In summary, there may be reasons a printed version is exempt.

Here is another difference, DeCSS is illegal, PGP wasn't, as far as export regs go. (the patent situation was a different issue). So copying it to paper and exporting that when that is legal under export laws is apparently a workable workaround. That might not work with DeCSS.

I am not a lawyer, any care to comment?

Re:should everything on the internet be encrypted

[Bill Currie]

I believe the key that's used to encrypt the message is changed each message (randomly generated, the pub/priv key stuff is used to exchange this key). However, I suspect that if they find the OTP, they might be able to derive your private key from the key packet (they have both the plain text and the encrypted text of the key).

Bill - aka taniwha
--

Why not GPL?

[argoff]

I would want to ask, why didn't you GPL PGP. In all fairness, this latest incident may have never happened to begin with if the code was GPL'd from the start. (or even if it was, it would have likely been an option that could easially be left out). Given a choice in the matter, I know I never would have used a product that implements key-escrow unless I specifically wanted and needed it.

Re:Why not GPL?

[qnonsense]

In all fairness, this latest incident may have never happened to begin with if the code was GPL'd from the start.

How? The code is not GPL'd for sure, but it sure as hell is open for us to see. Just because it uses the MITPGP License not the GPL does not make it any less secure.

...it would have likely been an option that could easially be left out...

It is an option that is easially left out. Just dissable it. Or, for that matter, don't complile it in, just as you would have the option of doing so with GPL'd code.

I really don't see what the big deal is that this doesn't use GPL. For security purposes, one Open Source License is just as good as the next.

What about quantum computers?

[ca1v1n]

I'm sure everyone here has read about the quantum computers that are still in the pre-infancy stages at places like IBM and Los Alamos. Because of their peculiar nature, the quantum computers can factor numbers as easily as they can multiply them, rendering public-key encryption schemes useless. Of course, these systems are still very primitive, the latest ones at around 5 to 7 qubits. Still, it is inevitable that this technology will grow to the point where it could be capable of cracking 128-bit encryption or whatever we are using when the rapidly advancing quantum technology starts to catch up with traditional computers. Quantum computers do offer the possibility of quantum encryption, but due to the inevitable extreme expense of quantum computers at the early stages of development, it is quite likely that intelligence organizations or large corporations will have the ability to crack our codes several years before we gain the ability to protect ourselves from this threat. When this happens, what will we do to protect our privacy against powerful forces that can compromise it at will?

Re:What about quantum computers?

[Sanity]

Quantum theory also provides a solution to this. Quantum cryptography allows the transmission of information so securely that you can *guarantee* that nobody is listening in - making it irrelevant whether they are using a quantum computer or not. I am unsure whether this will allow anything analogous to public/private key cryptography, although given that there are ways to prove that you know how to do something, without revealing what that thing is (see section on digital cash in "Applied Cryptography"), perhaps there is an answer.

--

Re:What about quantum computers?

[mOdQuArK!]

Ummm...as far as I know, quantum computation is primarily useful at cracking current PUBLIC key encryption methods (factoring large numbers and/or discrete logarithms), not symmetric key encryption, which can still be set at lifetime-of-the-universe key lengths. (Anybody knowledgeable, feel free to correct me...)

Even when they do that, there are other public key mathematical operations (elliptical curves come to mind) which people haven't come up with easy ways to crack yet, even with quantum computation. Doesn't mean it won't happen, but there will still be alternatives.

Close, but not quite

[dangermouse]

The reason for encrypting everything you can is a concept called "plausible deniability". If you only encrypt important things, someone can point to encrypted data and say "that's important, he must be up to something, I can tell because it's encrypted." If you encrypt everything, you can deny that any of it (or any given piece of data, more importantly) is at all interesting, and such denial is entirely plausible.

A very large pair...

[DESADE]

Whatever your opinion on encryption is, Phil Zimmerman deserves some respect. He released PGP despite very legitimate threats to his own personal well being.

I read an interview a long time ago about his reason for doing do. He said he had heard of a rebel group (forget which country) that was fighting against an oppressive govermnent was using PGP to communicate.

He decided that if his tool could be used to help people struggling for freedom, it did not matter what would happen to him. He released the software shortly thereafter. In my opinion, he's of the earliest true idealists in the world of hi-tech.

Publishing Source

[jerdenn]

from the article: We avoided the export controls by publishing PGP source code in printed books and legally exporting the books (which were not subject to export controls) to Europe, where they were scanned in via OCR and compiled back into working software again and sold on CDROMs all over the world. A neat trick, don't you think? It worked beautifully...

Actually, one wonders if this will become the method of choice for distribution of 'illegal' source code such as DeCSS, etc...

-jerdenn

Too many features

[Animats]

Putting that ADK feature in was stupid. It complicated the cryptographic system, and in the end, broke it. Why would you want it for E-mail, anyway? Worst case, you have to ask for some recent E-mails to be resent. E-mail encryption should be brutally simple and well-understood, probably, now that the patent has expired, RSA/triple DES.

Re:Too many features

[Bob Uhl]

The reason that this is needed is that when an employee sends an email, he sends it not as himself but as a representative of his company. In fact, some companies (I believe certain ones dealing with stocks & finances) have a legal responsibility to track and audit all communications. There are very good reasons for much of this.

Third-party decryption keys are a good thing; however, they should never have been implemented as they were, in a fashion which lead to the ability for anyone to subvert a key and read mail encrypted for it. Fortunately, it appears that this problem has been fixed.

When sending email on company time to company contacts regarding company business, one has no right to expect privacy. Indeed, one has a duty to make one's communications visible--one's superiors have a definite right to audit one's performance and business dealings. It's no different from calling a customer after the salesman has left and conducting a satisfaction survey.

Re:Too many features

[Animats]

If mail logging is really needed (which is rare), it should be at the sender end, not inside the crypto system. Never get cute in a crypto system; you'll break it.

No new cypher is worth looking at unless it comes from someone who has already broken a very hard one. - Friedman.

Re:should everything on the internet be encrypted

[muldrake]

Instead, why not just fill all "idle" bandwidth with random noise? Any well-encrypted data will blend right in, without the high CPU overhead of crunching lots of numbers to encrypt routine traffic.

should everything on the internet be encrypted

[daniell]

On NPR I heard a pundit espouse that realistically everything on the internet should be encrypted. [this was the founder of 3com btw]. But I'm of the opinion that this is incorrect in that a lot of stuff doesn't really matter; why for example should you recieve encrypted ad banners (and I'm sure someone will think of a reason they're comfortable with). Arn't we forever going to run into a case where speed is more desireable for some applications (i.e. multicasted video)?

This has to do with the interview topic of encryption as you may be able to see

-Daniel

Re:should everything on the internet be encrypted

[rjh]

Realistically? No. Encrypting a "The system is going down in 15 minutes!" message, broadcast over a network for each user on a network, makes absolutely no sense--why would you want that message to be protected from eavesdropping?

There are two sorts of communications which go out over the Net: public and private. Private communications (email, Web pages, etc.) ought to be transmitted securely in order to ensure privacy; public communications ought to be transmitted in the clear to ensure they remain public.

Re:should everything on the internet be encrypted

[walnut]

Please, encode your add banners.

That way I can choose not to get your public key.

Re:should everything on the internet be encrypted

[Bill Currie]

Heh, I just thought of a reason for encrypted banner ads: targeted advertising. You wouldn't want your neighbour using his tcp sniffer (assuming cable and a smart neighbour, I guess) and seeing banner ads for the local adult toy shop showing up in your stream :).

Only hole in this I can see is your neighbour could just crack into the ad server and look at the records for what's been sent to you, but that's another issue, I guess.

Bill - aka taniwha
--

Re:should everything on the internet be encrypted

[prak]

Come on.. you know the answer to this one. If only "interesting" traffic is encrypted there is a lot less encrypted traffic flying across the lines to confuse big brother like organizations. You encrypt everything to make it more difficult to figure out which encrypted packets are the ones you should be interested in brute forcing.

If big brother like organizations waste a week trying to decrypt your mother's letter about a new recipe she just tried, that is a week they don't have to decrypt the message you reply with explaining why your family has to go into hiding. We need to inject more noise into the system.

-prak

Re:should everything on the internet be encrypted

[photon317]

My primary argument for "encrypt everything" is that it makes for better security for the important things you encrypt. If you send a large bulk of unencrypted traffic, then encrypt one important email... gee, it's real hard for the NSA to target the important stuff with $700 Billion in custom cracking equipment. OTOH, if everything is encrypted, the sheer volume of stuff to crack in order to search for "sensitive" items makes things more secure.

This is why host-to-host encryption should be standard issue at the hosts' IP stack.

Question.

[Auckerman]

Ask him what the NSA's director likes to have for dinner. He should be able to answer that one.

Redundant

[Sloppy]

Zimmerman himself already made his view on this pretty clear, years ago.

---

Yes, everything should be encrypted.

[Paul Crowley]

Encryption can be computationally *very* cheap. And encrypting only your sensitive traffic will rather draw attention to it.

Multicasted video may want to go out unencrypted; not for speed reasons, but because collecting the key might incur unnecessary expense for all parties. But the same argument should not apply to normal, point-to-point communications.
--

Phil did NOT release PGP.

[Anonymous Coward]

Phil Z. never released PGP. This is a common misperception that he has never done much to discourage.

Rather, he was paid to write it, and the other person (who prefers to keep a low profile - but was investigated with Phil by the Grand Jury) is the person who released it.

This is an important distinction. Without that other person hiring Phil to write PGP, and having the balls to release it, PGP would not exist.

It's also interesting, and alas, degrading to Phil's reputation, that Phil Z. has done quite a lot to trash the other person's reputation, while trying to grab more glory (and undeserved glory at that).

If Phil Z. is a hero, he is a sad one at that.

For references, read some of the original material about the release, starting with Jim Warren's article from Microtimes.

DON'T POST QUESTIONS HERE

[64.28.67.48]

Go to the actual site (http://forums.itworld.com/webx?14@@.ee6 caf5) to post a question. /. is not hosting the interview.

Thrashing...please wait...

-------------

Complexity and Security

[nestler]

What do you have to say about complexity and its detrimental impact on security systems?

PGP seems to be a case study in this in that the recent bug has no effect on the older, simpler PGP 2.6. As requests for features by everyone from paranoid hackers (bigger keys) to corporations (ADK's) come in, it is natural to want to add things to software. The problem is that as the software gets more complex, dangerous flaws get much harder to spot (even in open source software). Once a bug like this creeps in, the "feature-rich" software is significantly less useful than the old version in that it doesn't accomplish its original goal: privacy.

How do you think one should go about trying to achieve a good balance of features/complexity and security?