From: Declan McCullagh
To: politech@vorlon.mit.edu
---------- Forwarded message ----------
Date: Wed, 24 Jun 1998 12:31:21 -0500
From: Bruce Schneier
To: ryasin@cmp.com, stito@cmp.com, advancedinfo@email.msn.com
Subject: Comments on "Encryption is Key to Securing Data" 22 Jun 98
This note is to comment on your article, "Encryption is Key to Securing
Data," that appeared in the 22 Jun 98 issue of InternetWeek. I'm not sure
where to start. Almost every statement made in the copy is erroneous.
(There was an error when I tried to download the article from your
website, so I will retype. Apologies for minor typos.)
Encryption is Key to Securing Data
by Dayna DelMonico
"Although encryption terminology can make even the most technically astute
user cringe, encryption is fairly simple."
I agree, although the rest of this article seems to prove me wrong.
"It's the process of scambling and unscrambling information."
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.
"Encryption products showed up when MIS managers adopted two basic
encryption technologies from the federal government: private and
public-key encryption."
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.
"With private key encryption, the sends and recieve are the holders and
use the same key (algorithm) to secure information."
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 seperate. This is one of the cornerstones of post-Medieval
cryptography.
"With public key encryption, senders and receivers hold a commonly used
public key, with an additional private key held only by specific
institutions."
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).
"To protect systems from the loss of the key, many vendors offer
assymetric encypion, which uses two keys."
Sort of. Assymetric 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.)
"Users can choose from products based on various schemes. Beware,
however, that even stronger encryption methods are on the horizon and
destined for the next generation of encryption products. The National
Institute of Standards and Technology (NIST) is expected to complete and
Advanced Encryption Standard (AES) by the end of the year."
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.
"The new standard wil luse a 128-bit block size, with key lengths of 128-,
192-, and 256-bits, as opposed to the current 64-bit blocks with 56-bit
key standard."
True. The current standard is DES.
"RSA Data Security also has proposed its own algorithm to content for the
new AES standard."
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.
"RSA's extensions to DES, RC4 and RC5 implement multiple keys as well as
digital signatures."
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.
"Another contender is Blowfish II."
I submitted this algorithm. We called it Twofish, but some early press
reports called it Blowfish II.
"The Blowfish scheme, often referred to as PGP (Pretty Good Privacy), lets
the sending and receiving computers negotiate a complex number."
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.
"That number is used to scamble the transmission and unscramble the data
that is received."
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.
"For more on encryption and encryption products, a buyer's first stop
should be the International Computer Security Association. This ICSA is
an independent organization that tests and certifies security products."
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.
Honestly, I can't believe this article made it into print. Don't you have
editors?
Bruce Schneier
President, Counterpane Systems
Author, Applied Cryptography
http://www.counterpane.com