InternetWeek: "Although encryption terminology can make even the most technically astute user cringe, encryption is fairly simple."
Schneier: I agree, although the rest of this article seems to prove me wrong.
Schneier: Partly. It's confidentially (what you said above--making sure secret things stay secret), integrity (making sure data doesn't get modified in transit), authentication (the digital analogue of a signature), and non-repudiation (making sure someone can't say something and then later deny saying it). Cryptography is a lot more than simple encryption.
Schnier:Nothing correct here. The Federal government has no public-key cryptography standards; MIS managers have nothing to adopt from the Federal government. You might be thinking of DES, a symmetric encryption algorithm. (More on this confusion below.) In any case, commercial use of cryptography products has developed completely independently from government interference. In fact, things like export control and key escrow are making it harder to buy secure commercial products, not easier.
Schneier: No. First off, private-key encryption is a bad term; use "symmetric encryption." Second, I'm not sure what they are the holders of. With symmetric encryption, both the sender and the receiver must have the same key; that may be what you mean. In any case, the key and the algorithm are completely separate. This is one of the cornerstones of post-Medieval cryptography.
Schnier: Not even close. With public-key encryption, each receiver has a public key and a private key. The public key is published. The private key is held, in secret, by the receiver. To send a message to someone, the sender gets the public key form some public database and uses it to encrypt the message. The receiver uses his private key to decrypt it. There are no specific institutions that have additional private keys, unless you are thinking about key escrow systems (which are related, but not the same).
Schneier: Sort of. Asymmetric encryption is the same as public-key encryption (just another word), and there are two keys. But the reason for using public-key encryption is not to prevent the loss of a key, but to facilitate key management. (With symmetric encryption, both the sender and receiver have to share a key. How this sharing takes place can be very complicated.)
Schneier: Even NIST has said that AES will not be finalized before 2000. And AES is just a new symmetric algorithm; it has nothing to do with public-key cryptography.
Schneier: True. The current standard is DES.
Schneier: Sort of. NIST has solicited proposals for algorithms. Fifteen groups submitted, including RSA Data Security. RSADSI is competing with other groups--Cylink, IBM, Entrust, Counterpane Systems, NTT, etc--not with NIST. NIST does not hav an algorithm.
Schneier: Many mistakes here. RSADSI submitted RC6 to the AES process, which uses many ideas from RC5. It has nothing to do with DES or RC4. I'm not sure why multiple keys is something to talk about; as I said above, every algorithm post the Middle Ages uses multiple keys. And digital signatures have nothing to do with the AES process. AES is a new symmetric encryption algorithm; digital signatures are done with public key cryptography. They are different.
Schneier: I submitted this algorithm. We called it Twofish, but some early press reports called it Blowfish II.
Schneier: First, Blowfish is never referred to as PGP. Blowfish is a symmetric encryption algorithm. PGP is an email security product. PGP could have decided to use Blowfish, but it used IDEA and CAST instead. Those are two different encrytpion algorithms. And neither PGP, nor Blowfish, nor anything else discussed to or alluded to in this article, involve sending and receiving computers negotiating complex numbers.
Schneier: What you mean to say, I think, is that PGP uses public-key cryptography for key exchange. The sender uses the reciver's public key to encrypt a session key, and that session key is used to encrypt the email message.
Schneier: ICSA is a private for-profit company, despite what the name implies. And while they do do some testing and certifying of security products, they do not test or certify encryption products.
President, Counterpane Systems
Author, Applied Cryptography
http://www.counterpane.com