From: C Matthew Curtin <cmcurtin@research.megasoft.com>
Date: Tue, 3 Sep 1996 02:39:57 +0800
To: cypherpunks@toad.com
Subject: Terrible story on crypto in InfoWorld
Message-ID: <199609021327.JAA06854@goffette.research.megasoft.com>
MIME-Version: 1.0
Content-Type: text/plain



There's a story covering crypto in this weeks' InfoWorld
Electric. Since it's a members-only thing, I'll include the text here,
as well as my response to it. I'm hoping that they'll take the article
down and take up my offer to provide a better replacement.

I suspect that the problem here is that someone was given a subject
and a deadline, and told to "go for it." The requisite background for
getting clued on crypto is probably significantly longer than the
amount of time allowed by the deadline. I suspect that the issue was
further clouded by the crypto-clued people she talked to during the
research speaking directly about what they're doing, without giving
any sort of analogies to make the ideas click and make sense. I hope
that my illustration of the bicycle lock serves to clear up the
confusion...

In any event, we've all got a lot of work to do. I think we should
take it upon ourselves to not only talk about crypto and why it's such
a Good Thing(tm), but also to *educate* people to help them understand
what in the world we're talking about. 

-matt

------------------------ begin silly article -------------------------
[Image] [PageOne]  [Search]  [Reader Service]  [Ads Services]  [Overview Map]
 [Todays News Logo]            [Opinions]         [Forums]
                               [Test Center]      [Calendar]
                               [This Week In Print[Week In Review]

  Encryption technology can help secure private data over public
  carriers, but tackling its own issues is another story

  By Julie Bort
  InfoWorld Electric

  Think about this: Every time one of your end-users sends an
  electronic communication from your network, it opens the door
  to an attack. It is unbelievably easy for a knowledgeable
  hacker to exploit the failings of SMTP and other communications
  protocols to eavesdrop on Internet e-mail, send phony messages,
  or even gain access to other networked systems, security
  consultants say. A domain name or single IP address is the only
  information needed, and from there the door is wide open for
  other mischief.

  One increasingly popular way to plug this gaping hole is to
  encrypt e-mail and other electronic communications. Encryption
  is a way to encode text using complex mathematical algorithms.

  "When explaining encryption, I like to use the analogy of the
  Cap'n Crunch Super Secret Decoder Rings. These rings
  [distributed in Cap'n Crunch cereal boxes in the 1960s]
  contained a very simple algorithm. It was something like `take
  a letter then add 5.' So an A became an F. Simply speaking,
  that's all these algorithms are, mathematical formulas,"
  explains Gary Fresen, a member of the American Bar
  Association's committee on digital signatures and an attorney
  and partner at Baker McKenzie LLP, in Chicago, one of the
  world's largest law firms.

  Although no encryption algorithm is in and of itself
  crack-proof, several of them are so complex that they are
  virtually unbreakable. Coupled with proper implementation,
  authentication, and secure connections, encryption solutions
  can add a high level of security to any company's arsenal.
  However, it is an area that requires a knowledgeable person to
  make the purchasing decision because the technology is very
  complex, the best product selected will add a level of
  administration overhead, and numerous industry consortiums are
  developing competing APIs.

  NUMEROUS USES. Is encryption security overkill? Absolutely not,
  say users who have already adopted it or are in the processing
  of adopting it. One reason is to gain some security control
  over public telecommunications lines used in wide area
  networks.

  "We have a good idea of our internal security, but we also use
  the public carriers for our worldwide WAN, such as CompuServe
  [Inc.'s] frame relay and British Telecom [Plc.'s] frame relay,
  and we [don't control] their level of security," says Richard
  Perlotto, corporate network security manager for VLSI
  Technology Inc., in Tempe, Ariz.

  "Even if you own most of your own equipment, with frame relay
  you don't own the router, the carrier does. Frequently [the
  carrier has] modems attached to those routers to manage the
  equipment remotely," Perlotto adds.

  Those modems can allow hackers to tap in and grab data as it is
  being transmitted, without ever being detected by the company's
  security systems.

  Consequently, VLSI is currently evaluating encryption boxes and
  other products that sit on either end of a connection, such as
  NetFortress from Digital Secured Networks Technology Inc.
  (DSN), in Englewood Cliffs, N.J. One box encodes all traffic on
  the fly when it's being transmitted, and the other decodes the
  information upon receipt. Router vendors offer similar add-ons.

  Besides simply letting employees sleep better at night with the
  knowledge that their corporate secrets are safe, encryption
  technology can mean that a company can operate more efficiently
  and cost-effectively, users say.

  "Right now, we drop letters into the post office, which isn't
  very secure when you think about it," Fresen says. "After all,
  anyone could look at them. Or we send a courier. But if we can
  secure our [Lotus Development Corp.] cc:Mail system, there's a
  tremendous cost savings to us compared to sending a courier to
  Hong Kong three times a day. And we'll be able to do things in
  a day that used to take a week." Fresen is currently testing
  Entrust 2.0 from Northern Telecom Ltd. (NorTel), in Research
  Triangle Park, N.C., as an encryption add-on to e-mail.

  GETTING KEYED IN. But before you can go out and purchase an
  encryption system, you need to do some serious homework.
  Encryption involves multiple technologies, competing protocols,
  and complex mathematics.

  You can start the learning process by understanding the two
  components that make up most encryption systems: the key and
  the certificate.

  The key is the algorithm or mathematical formula that encodes
  the message itself. It must be sent to the message recipient so
  the message can be decoded, hence the term key.

  The size of the key, measured in bits, determines how complex
  the algorithm is and how tough the code is to crack. The state
  of the art for encryption technology used exclusively within
  the United States is 1,024 bits. However, the maximum size key
  that is allowed to be exported is 40 bits.

  Keys come in two flavors: symmetrical, or public key model; and
  asymmetrical, or public key/private key model.

  A symmetrical key uses the same algorithm to encode and decode
  a message. This is the technique used by the public key
  encryption program Pretty Good Privacy (PGP).

  PGP assumes what security experts call the peer trust model.
  That is, the sender knows and trusts the receiver and is
  therefore perfectly comfortable in sending the key on its way.
  Herein lies the "pretty good" part of the privacy. Although the
  algorithm itself makes the message difficult to crack, the key
  exchange is only pretty good when compared with other methods.

  On the other hand, the great advantage to PGP is that it
  creates no key management overhead, which is the biggest
  drawback of asymmetrical keys.

  In the asymmetrical model, users have a public key stored
  somewhere that is available. Should someone want to send an
  encrypted message, the sender locates the public key of the
  recipient, encodes the message, and sends it off. The receiver
  then uses a private key to decode the message. The private key
  is different from the public key, but they are mathematically
  linked so that the private key is capable of decoding the
  message.

  Asymmetrical systems require no trust between the sender and
  the recipient. That's good. But they do create administration
  overhead in the form of storing and maintaining public and
  private keys.

  Public/private key exchange is the technique used by RSA Data
  Security Inc., which was recently sold to Security Dynamics
  Inc., in Bedford, Mass. RSA uses a technology that is actually
  an adaptation of the decade-old National Institute of Standards
  and Technology's peer-trust Data Encryption Standard (DES),
  still used in many products. DES is a method of grabbing random
  keys for each encryption task, rather than using the same key
  repeatedly. Cryptographers say that RSA solves some problems,
  such as the trust issue but generates others.

  "Say I want to send a secure message. The first thing I do is
  take a random key and encrypt the message with it," says Paul
  Kocher, an independent cryptography consultant in Menlo Park,
  Calif., and one of the people responsible for discovering the
  flaw in the security of Netscape Communication Corp.'s Netscape
  Navigator.

  "But without that key, I won't know how to decode [the
  message], so I take an RSA public key and encrypt the random
  DES key with my recipient's public key. The recipient uses a
  private RSA key to decrypt the DES key. If it sounds
  convoluted, it is. RSA is very slow and cumbersome. DES is fast
  and efficient, but it doesn't give you the security of the
  public/private key system," Kocher explains.

  RSA remains one of the most well-known encryption technologies,
  but it is not, by far, the only public/private key exchange
  method currently in use.

  For example, other vendors use a competing version called
  Diffie-Hellman. It is a mathematically different implementation
  of the asymmetrical model, and it is the method employed by
  DSN's NetFortress.

  THE REAL YOU. Using public or public and private keys is the
  foundation of encryption, but keys can't verify a recipient's
  identity.

  "When you're talking about sending secured messages, there are
  two goals you've got. One is to make sure that the information
  stays confidential, and the other is that it does not get
  tampered with," Kocher says.

  Enter the certificate, also called the digital signature.
  Certificates act like an electronic driver's license. They
  authenticate that the receivers and senders are who they say
  they are.

  "The issue is trust. When we owned our own 3270 cabling, we
  trusted it, we worried less. Now I have someone at Daytona Co.
  that needs access to Chrysler Corp. across multiple networks.
  What sort of trust do I have?" asks Bob Maskowitz, technical
  support specialist for Chrysler, in Detroit, and a member of
  the Internet Architecture Board of the Internet Engineering
  Task Force (IETF). "I need to authenticate that this person is
  allowed to update [a document]."

  Certificates can be created and managed by a third party, such
  as VeriSign Inc., in Mountain View, Calif., or they can be
  created and managed internally, with products such as NorTel's
  Entrust, which also performs encryption. Once a certificate is
  obtained, it becomes the user's digital signature.

  When digitally signing something, the recipient of the
  signature gets all of the information contained on the
  certificate, such as who the person is, the person's address,
  or other items chosen to be included on the certificate. The
  digital signature also says who granted the certificate, when
  it expires, and what level of verification was done.

  "There are three classes of certificates," explains Gina
  Jorasch, director of product marketing for VeriSign. "In Class
  1, we check for a unique name, that the e-mail address is
  correct, and that the person receiving it has authority to
  access that e-mail account. In Class 2, we check the name,
  address, driver's license, social security number, and date of
  birth. For a Class 3 we check all of those things, plus we
  check against the Equifax [credit reporting bureau] database."

  Although certificates provide the invaluable service of
  authenticating users, organizations that care enough about
  their security to use encryption and certificates may not want
  to trust an outsider to handle them, according to users.

  "Do you think Ford [Motor Co.] or Chrysler is going to let
  someone else control their certificates? Then there is this
  issue of where did you get your certificate from? Am I going to
  let you query my database to get a key? No way," Maskowitz
  says.

  From a network management perspective, certificates are also an
  issue. Unless they are outsourced, they will add a significant
  amount of system management overhead to an encryption system,
  even with systems such as Entrust that include management
  features.

  Most certificates are set to expire in a set amount of time,
  such as a year. Someone will have to see that they get
  reissued. Someone will also have to make sure that certificates
  for employees who leave a company are revoked and that new
  employee certificates are issued.

  SMIME'S THE WORD. The final area of concern IS managers face is
  the new wave of protocols being spewed out by various industry
  consortiums. Numerous APIs are being created that cover all the
  aspects of using encryption.

  Although these APIs are posing as standards, in truth the two
  most popular APIs for the commercial sector are merely vehicles
  for the mass adoption of a particular company's key technology.

  Nevertheless, vendors of products such as e-mail packages are
  lining up behind them.

  The four big protocols being worked on are Secure Multipurpose
  Internet Mail Extensions (SMIME), Multipart Object Security
  Standard (MOSS), the next-generation version of PGP that allows
  asymmetrical key exchange, and Message Security Protocol, says
  Rik Drummond, chairman of the IETF's electronic data
  interchange over the Internet committee and president of The
  Drummond Group, a consultancy in Fort Worth, Texas, that helps
  corporations choose and implement networking and security
  systems.

  MOSS is the API for the Department of Defense, and it will be
  mandatory for anyone in the government or anyone who does
  business with it.

  But commercially, SMIME and PGP, Version 3.0, are more robust
  choices, Drummond says, and they offer features best-suited for
  the commercial sector, such as backward compatibility, and
  better key and certificate management capabilities.

  By far the biggest names in the Internet world have lined up
  behind SMIME, including Microsoft Corp., which intends to make
  Microsoft Exchange SMIME-compliant; Netscape; and Qualcomm
  Inc., maker of the Eudora e-mail package.

  That makes it a comforting set of protocols to choose because
  corporations that buy products with SMIME or that purchase
  SMIME toolkits for customer applications will know that they
  will be able to communicate with the vast majority of others
  through a de facto standard. Those using other protocols will
  be left talking to themselves.

  Still, SMIME, as it stands now, isn't a panacea. Among its
  problems is that "the signature is exposed outside the
  encryption envelope," Maskowitz says.

  Also, once a message is encrypted with someone else's public
  key, the sender of the message can't open the message to make
  changes, Maskowitz adds.

  The architects of SMIME haven't completed the APIs yet, so
  there is some possibility that these problems will be fixed but
  in all likelihood not in time to be included in the first crop
  of SMIME-compliant applications, due to start rolling out this
  fall.

  Even with such serious issues still up in the air, today's
  encryption and certification products can offer a great deal of
  protection, especially if the Internet or a wide area intranet
  is becoming a serious business tool for a particular
  organization, and it can't wait for a de facto standard to
  emerge.

  For those with the time to wait, the learning curve should be
  ascended now. Mass adoption of encryption technology is a
  virtual certainty. Those that ignore it will find their secrets
  being blabbed to the world.

  --------------------------------
  Uses for encryption technology:

     * Sending sensitive data over publicly owned wide area
       links;
     * Sending sensitive data over Internet e-mail;
     * Electronic commerce;
     * Electronic data interchange over the Internet;
     * Order entry/order status over an intranet or the Internet;
     * Automated access to personnel files;
     * Storing sensitive data online;
     * Distribution, newsgroup style, of sensitive data.

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

  Will the export of strong encryption be allowed?

  One of the problems with adopting encryption worldwide is that
  the federal government severely restricts its export. In fact,
  encryption technology is classified as munitions.

  Therefore, U.S. encryption vendors and corporations are
  forbidden from exporting and deploying versions that use more
  than a 40-bit key. However, companies in other countries, such
  as Japan, can freely sell encryption technology that uses the
  tougher 1,024-bit standard.

  The U.S. government isn't completely closing its eyes to the
  matter. In July, Vice President Al Gore unveiled a proposal
  that would create a key-escrow system allowing keys greater
  than 40 bits to be exported but requiring a third party to keep
  a copy of a key that could be used by law enforcement
  officials. (See U.S. considers easing encryption export laws.)

  And this past June, the Senate Subcommittee on Technology,
  Science, and Space heard a slew of testimony from encryption
  vendors and other experts on the problem. In fact, there are
  several bills pending in both houses of Congress that would
  relax the current export restrictions. The Security and Freedom
  Through Encryption Act was introduced in the House by Rep.
  Robert Goodlatte, R-Va. Meanwhile, The Encrypted Communications
  Privacy Act of 1996 was introduced in the Senate by Sen.
  Patrick Leahy, D-Vt., and the Promotion of Commerce On-Line in
  the Digital Era Act of 1996 also sits before the Senate.

  All three laws would relax the 40-bit restriction on keys as
  well as eliminate other restrictions on international use and
  development of encryption.

  Officials of U.S. corporations look forward to these changes
  and believe that such changes would improve their ability to
  compete in the international marketplace.

  "We're an international company, so we can't use the domestic
  version of Netscape [Communications Corp.'s Netscape
  Navigator]. And we can't trust the data using the international
  versions," says Richard Perlotto, corporate network security
  manager at VLSI Technology Inc., in Tempe, Ariz.

  Julie Bort is a free-lance writer based in Dillon, Colo.


Please direct your comments to InfoWorld Electric News Editor Dana Gardner.

                                  [Image]

                To respond to this review, go to the forum.

                            [Image]     [Image]

               Copyright (c) 1996 InfoWorld Publishing Company
------------------------- end silly article --------------------------

--------------------------- begin response ---------------------------
-----BEGIN PGP SIGNED MESSAGE-----


This references
http://www.infoworld.com/cgi-bin/displayStory.pl?960830.crypt.htm

Hi,

First of all, I'd like to commend InfoWorld for covering a very
important topic: cryptography. There are, however, some very
significant flaws in the story, which I hope will be corrected
soon. As the article exists now, the information is sufficiently
incorrect to be more harm than if the article didn't exist at
all. Anyone using it as a guide will be only further confused.

The quotes are indented two spaces, with my comments below...

  Although no encryption algorithm is in and of itself
  crack-proof, several of them are so complex that they are
  virtually unbreakable. Coupled with proper implementation,
  authentication, and secure connections, encryption solutions
  can add a high level of security to any company's arsenal.
  However, it is an area that requires a knowledgeable person to
  make the purchasing decision because the technology is very
  complex, the best product selected will add a level of
  administration overhead, and numerous industry consortiums are
  developing competing APIs.

Also, there are a lot of people who simply don't know what they're
doing when it comes to cryptography and security. Many products claim
high degrees of security, but are hardly strong enough to keep
someone's kid sister from deciphering the message.

  The key is the algorithm or mathematical formula that encodes
  the message itself. It must be sent to the message recipient so
  the message can be decoded, hence the term key.

Bzzzt. The formula is the algorithm. The key is a piece of data (often
times, a passphrase, or a relatively small file) that is fed to the
algorithm along with the data to be encrypted or decrypted to produce
the desired result. The idea being that if an attacker knows what
algorithm someone is using, and they have the encrypted message,
they'll not be able to break the message unless they can also get
their hands on the key. Hence, the key needs to be sufficiently large
such that it can't be easily guessed by an attacker trying keys at
random (or by effectively starting at "1" and working his way up.)

  The size of the key, measured in bits, determines how complex
  the algorithm is and how tough the code is to crack. The state
  of the art for encryption technology used exclusively within
  the United States is 1,024 bits. However, the maximum size key
  that is allowed to be exported is 40 bits.

Bzzzt. The complexity of the algorithm and key size are two different
matters entirely. The level of complexity, by the way, typically
increases the chance for error (in both algorithm design and
implementation) more than adding any levels of security. A secure
algorithm doesn't have to be complex. However, its key must be of
sufficient length to be "computationally infeasable to break."

Let's take the example of a bicycle combination lock. It has a chain
which will secure the bicycle to a rack; we'll assume that it's some
newfangled sort of chain which is resistant to bolt cutters and all of
those sorts of things. The security of this lock now rests in the
actual locking mechanism. It's a very simple tumbler lock, perhaps
having three or four digits between 0 and 9 that collectively make up
the combination. The "key" is the combination in this case. The lock
is simple, but it can be difficult to break, if the length of the key
is long enough. If there is only one digit, there are 10 possible
(10**1) keys. An attacker can quickly guess this and have a new
bicycle. However, each time a digit is added to the key, it increases
the number of combinations an order of magnitude. Two digits will have
100 possible (10**2) keys, three digits will have 1000 (10**3), four
will have 10,000 (10**4) possible, etc.

The key size necessary to prevent breaking the solution will depend on
your attacker. I mentioned the term "computationally infeasable"
earlier. The term simply means that more time and money would need to
be spent in breaking the key than the value of that which it locks. If
a bike combination has 10**8 (100,000,000) possible combinations, and a
thief can try 60 combinations per minute, it would take 165 weeks of
continuous attempts to try every combination. By that time, enough
lawns could be cut to buy two such bikes.

Because computers are binary, we work in bases of two, instead of base
10, which the bicycle combination lock uses, but the principle is the
same. Each time you add a digit, you increase the number of keys by an
order of magnitude (in a binary system, that means you double it, in
a base 10 system, you increase it 10 times.) The key size of your
algorithm, therefore, must be large enough to prevent an attacker from
having any benefit to recovering that which is encrypted.

  Keys come in two flavors: symmetrical, or public key model; and
  asymmetrical, or public key/private key model.

Symmetric cryptosystems are sometimes known as "conventional."
Asymmetric cryptosystems are known as "public key" ciphers. (Public
key/private key *is* the public key model, and an asymmetric cipher!)

Symmetric ciphers require the same key to encrypt and decrypt. If you
imagine the encryption formula on the left side, and decryption on the
right, you apply the same key to both sides in order to encrypt or
retrieve the plaintext. Hence, the name "symmetric." Systems which use
a different key to encrypt from the key to decrypt, therefore, are
asymmetrical.

The note about key sizes is also misleading: conventional
cryptosystems require a much, much smaller key for security than do
public key cryptosystems. Because the math is different, a 128 bit key
on a conventional algorithm is roughly the same security as a 2304 bit
asymmetric cipher key. The "state of the art" in symmetric
cryptosystems is about 128 bits. In this type of system, the
government does not allow export of keys greater than 40 bits. Using a
1024 bit key in a symmetric cipher would provide an insane level of
security, but would also be very, very slow to use.

  A symmetrical key uses the same algorithm to encode and decode
  a message. This is the technique used by the public key
  encryption program Pretty Good Privacy (PGP).

This is wrong, I will explain later.

  PGP assumes what security experts call the peer trust model.
  That is, the sender knows and trusts the receiver and is
  therefore perfectly comfortable in sending the key on its way.
  Herein lies the "pretty good" part of the privacy. Although the
  algorithm itself makes the message difficult to crack, the key
  exchange is only pretty good when compared with other methods.

VERY WRONG! I'll explain this also later.

  On the other hand, the great advantage to PGP is that it
  creates no key management overhead, which is the biggest
  drawback of asymmetrical keys.

Key management is the biggest problem for the keys of symmetric
ciphers, not asymetric ciphers.

  In the asymmetrical model, users have a public key stored
  somewhere that is available. Should someone want to send an
  encrypted message, the sender locates the public key of the
  recipient, encodes the message, and sends it off. The receiver
  then uses a private key to decode the message. The private key
  is different from the public key, but they are mathematically
  linked so that the private key is capable of decoding the
  message.

Entirely correct.

  Public/private key exchange is the technique used by RSA Data
  Security Inc., which was recently sold to Security Dynamics
  Inc., in Bedford, Mass. RSA uses a technology that is actually
  an adaptation of the decade-old National Institute of Standards
  and Technology's peer-trust Data Encryption Standard (DES),
  still used in many products. DES is a method of grabbing random
  keys for each encryption task, rather than using the same key
  repeatedly. Cryptographers say that RSA solves some problems,
  such as the trust issue but generates others.

ACK! NO! RSA is an asymmetric cipher. DES is a symmetric
cipher. That's the only difference. How keys are managed is entirely
dependant on how the system is implemented. Anything can be assigned a
key "at random," by allowing a user's passphrase to be the key.

Now it seems like a good time to explain the way that PGP (and
Netscape's encryption system) works.

Asymmetric ciphers, such as RSA, are very slow. Their key management,
however, is very nice and flexible, which is why we like to use
them. In a system that requires flexible key management, a high level
of security, as well as decent performance, both symmetric and
asymmetric ciphers are used.

If Alice wants to send Bob a message in such a system (like PGP), she
simply composes her message, and tells her mailer to PGP-encrypt the
message. PGP will find Bob's public key (either from her key ring, or
from a database, perhaps, but it doesn't matter.) The message will
then be encrypted with a random SYMMETRIC key (in the case of PGP, it
will use the 128-bit-key IDEA cipher). That session key, then, will be
encrypted using Bob's public key, and both the session key and message
will be sent off (in one PGP encrypted message). Bob will see his mail
from Alice, and then his PGP will decrypt the session key, and apply
it to the encrypted message, yielding the plaintext: Alice's message.

So, in PGP, the MESSAGE is encrypted using a random session key (which
is symmetric.) The SESSION KEY, then, is encrypted using the
recipient's public key.

The rest of the article seems to be generally on track, but
certificates and signatures have been confused. A certificate is a
cryptographically secure message that states the identify of the
presenter. In that way, the analogy to a driver's license is
correct. A trusted third party issues the certificate.

A digital signature, however, is the cryptographic equivalent of
signing your name to something. For example, with PGP, I can digitally
sign an email message. PGP does this by taking the message, encrypting
it with my PRIVATE key, running the result of that through a secure
one-way function ("hash"), and attaching the result to the bottom of
the message. A user can then verify that the signature is legitimate
by applying my PUBLIC key to the message, and running the result back
through the hash, and comparing the two. If they match, the signature
is good, if not, something is amiss.

(PGP, naturally, handles all of this automatically.)

  Therefore, U.S. encryption vendors and corporations are
  forbidden from exporting and deploying versions that use more
  than a 40-bit key. However, companies in other countries, such
  as Japan, can freely sell encryption technology that uses the
  tougher 1,024-bit standard.

The two are being confused again. See my earlier note about comparable
keys.

If you have further questions, please feel free to contact me. If
there is interest, I would also be willing to write a series on how to
choose a cryptosystem.

I am very concerned about the state of cryptographic knowledge in the
industry. The area is vital for successful companies' IS departments
to understand, and understand well. Yet, the general level of
knowledge is abysmally low. I applaud efforts by InfoWorld to increase
coverage of this important topic, but I emphasize that the material
presented must be correct. Many vendors are currently offering
solutions they call secure. Without an understanding of how
cryptography works, an IS organization is completely unable to choose
between that which is good security and that which is snake oil.

A "snake oil FAQ" is being drafted, but is not yet available. In the
mean time, there are cryptography FAQs available from
ftp://rtfm.mit.edu/pub/usenet-by-group/sci.crypt/ 

- -- 
C Matthew Curtin                MEGASOFT, INC                Chief Scientist
I speak only for myself.  Don't whine to anyone but me about anything I say.
Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet
cmcurtin@research.megasoft.com http://research.megasoft.com/people/cmcurtin/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Have you encrypted your data today?

iQEVAwUBMireN36R34u/f3zNAQF+BQf/XD0fPYFuOQsd+u2k4zE1UpfZQKaP+SDw
RUhx6R7LnD0ZK5dA+seStvsLl+cvg5tu2wMzf9bniS7taj2DHwmu8MDWYwJPnQST
Iiti6XBAoFjCJYWaVghHQzVKw8vxlNC20LzyJ791PdabpUo5ztpf+AXVHGAfWaTg
F3ZNYWbbyxg81uxAnKMM/Li6NOKJhcE6nNO+eHUMFLciFki+mz/mOT45fUPs0R9y
4UYLQDvcSVAt246xSufwqbrSY/4dUB3A7KjYvbqWUjYRF/40c1h3K6h69dDnOR/8
SY+AZNnZSzQZbMbHNpjlJ+E71Yz+9Ppvgl6Eeo7oqa+PNeYW0W9GMQ==
=PS8M
-----END PGP SIGNATURE-----

---------------------------- end response ----------------------------

-- 
C Matthew Curtin                MEGASOFT, INC                Chief Scientist
I speak only for myself.  Don't whine to anyone but me about anything I say.
Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet
cmcurtin@research.megasoft.com http://research.megasoft.com/people/cmcurtin/