[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Terrible story on crypto in InfoWorld
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 � 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
[email protected] 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
[email protected] http://research.megasoft.com/people/cmcurtin/