Comments on "Encryption is Key to Securing Data" 22 Jun 98

[Bruce Schneier <schneier@counterpane.com>]

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