TrAC - Internet Column

To cite this article please refer to it as: R.E. Dessy, Trends Anal. Chem., 16 (1997) 1

The code makers

Raymond E. Dessy

Laboratories live to create data, then store and share it. The increasing use of groupware, corporate networks (Intranets), and the Internet are forcing data distribution and storage into environments where security and certification issues are important. The advent of extensive broadband and wireless networking make these issues paramount. This article explores the vocabulary and concepts behind the synergistic elements of cryptology and Information Technology as we approach the Electronically Distributed Age.

A history of the present

Scientists and instruments create data, the life blood of new knowledge. In the Electronic Distribution Age, that blood flows via conduits of copper, fiber, and Ether to other colleagues and clients. The traditional paper transfer protocols that have given us confidence in such exchanges for hundreds of years need to have electronic equivalents. These exist, although firm standards are still emerging. Chemists should understand the terminology of this new area, become confident in the protection such tools provide, and take an active part in their implementation in the laboratory.

This article will range from corporate-wide closed systems, to the Internet's and WWW's open environment. Hackers may lurk outside your corporate computing firewall, but they also inhabit your own Intranet. Imagine the day when your data link to a local docking computer, printer, intra-company network (Intranet), or the Internet is an infrared light beam or radio transmission. Do you really want other people to eavesdrop? Wouldn't it be convenient to have Corporate data available anywhere via secure routes, and to file NDAs and Patent applications electronically with full legal admissibility?

WHAT'S THE SECRET? Should you be concerned about encryption, certification and authentication for your personal lab work? Are scientific research labs using encryption? Yes, and Yes!

Log onto Glaxo's Intranet. If it is Lotus Notes V4 based, it uses encryption. If it is their in-house development, you will find RSA encryption. Today, collaborative team research and the use of Electronic Lab Notebooks means exchanging limited distribution reports. Encrypting those electronic documents so that only authorized recipients could read them makes sense. Would you leave your paper-based lab notebook around for just anyone to read? E-Mail often asks you to take actions. How can you be certain who the message actually came from? If the sender is certified and authentic, can they at some future date claim that you edited their message, and repudiate your disk copy? For vital patents the electronic equivalent of signatures, witnessing and dating are all necessary. Cryptology is the key.

The technology exists today. Are you free to have your Information Technology group implement it? Not necessarily. Government restrictions, based on questionable logic, can intervene. Is the software easy to use? Is it simple to install? Is the proper choice obvious? Not necessarily. Government de jure "standards" collide with several de facto industrial standards. The hype and jargon is formidable. The Chemist needs to know enough to assure that the IT Group make decisions appropriate to the lab. This article gives you the necessary background. The jargon used in the field is more formidable than the use of the tools. This article includes an acronym list, and some WWW entry points for reference.

"It's okay, you can admit it. The Senate hearings are on, there are reports in the newspaper-- and you still don't understand encryption. Help is just a click away..." (WSJ Interactive Edition, 1/7/96).

Let me count the ways

TODAY'S LAB: You are subscribing to a new service on the Net. The screen fills with the ominous box "Any information you submit in this open connection is insecure, and could be observed by a third party in transit. If you are submitting information you would like to keep private it would be safer to cancel your submission." What to do?

You've just installed Lotus Notes V4. There are new things on the screen. You can click on SIGN, ENCRYPT, or ENCRYPT SAVED, ENCRYPT SENT; and choices for STRONG, MEDIUM, WEAK encryption. Scrolling you see a 128 bit ID#, VALIDATION CODE, and KEY; then a PUBLIC KEY several Kbits long, as well as choices for (MAKE) NEW, COPY, and MAIL Public Key. Finally, the query: North America or International destination? What do all these mean and do? Other vendors have similar function sets. Regardless of whether you are on your Intranet or the Internet these tools will soon become essential.

THE GOALS: The confidences we appreciate in paper transfers are

• INTEGRITY OF DATA
• SECURITY OF TRANSFER
• AUTHENTICITY OF SOURCE
• NON-REFUTABILITY BY SOURCE

As paper is replaced by electronic transfer the scientist will seek some assurance of WHO sent WHAT, WHEN with the same attributes. These goals can be achieved by computer techniques that use encryption technologies. The area is often clouded by mathematical fog and political smoke so let's see how simple it really is.

INTEGRITY; DATA CORRUPTION AND ALTERATION: When data are stored or transmitted in digital format, noise corruption or mischievous alteration is a concern. In the old days the ASCII numbers representing the alphanumerics in a message were added, and the lower byte(s) of this sum sent along with the message as a check-sum. When the received message was read, the user calculated his own check-sum. If the two agreed then the message was correct - maybe. The difficulty: the transposition of two digits wouldn't affect the sum, and would go undetected. The next stage involved binary math techniques that multiplied each successive byte by a 16 bit binary polynomial, sometimes rotated the number produced, and kept a running sum. Truncated, this new check word would catch transpositions because the sum was dependent on the ordering of the letters. Cyclic Redundancy Checks (CRCs), used on disks and in other areas, work this way. Such CRCs can detect, but not correct, 16 bit error bursts.

Today, integrity in message traffic usually uses a related technique called a one-way hashing function. Its name is connected to an older approach commonly used in database search strategies. Items in a key field had their ASCII number equivalents added together and the sum used to separate keywords into numerically related subgroups. To search the database your keyword was hashed and only those members of the database that had similar values were examined. New hashing functions that assure message integrity actually employ binary operations similar to those described for CRC error checks. Typically 512 bit message blocks are iteratively compressed into a running 128 bit or 160 bit chain value. This hash generated string is a Message Digest. Secure Hash Algorithms (SHA) have several characteristics: (1) they are one-way, thus an attacker cannot regenerate the original message by back-calculating, and (2) it is infeasible to find two messages that hash to the same Message Digest. The latter assures that someone cannot substitute a false message over your digital signature, or that you cannot repudiate the message at a later date by claiming a third party substitution. What does a Message Digest look like? Take the phrase "There is $1500 in the blue box". Its Message Digest, using a popular MD5 hash, is the string: 05f8cfc03f4e58cbee731aa4a14b3f03. Drop just the period and it is: a4a5471a0e019a4a502134d38fb64729. (The strings are in hex.)

INTEGRITY; THE SOURCE, THE RECEIVER: The next step is to find a way to form a Digital Signature with the Message Digest so the receiver will know exactly who sent the message. This is important at the time of receipt, and often legally essential in the long term. One popular approach uses simple math to accomplish several goals. For example, parties A and B desire encryption techniques that can be used to change readable text to an encrypted form (see side bar). Each party generates TWO (2) keys that can be used for this purpose. One is called a Private Key, the other a Public Key. The Private Key is held secret by its owner. The corresponding Public Key is shared with any potential receiver. Commercial and Government (Post Office) repositories are also being developed to store Public Keys.

What is a Key? A key is a series of binary bits that can be used by software or hardware to convert plain-text to cipher-text by binary arithmetic processes. The length of the key, and how it is used, determines how secure the encryption is to attack by another party.

Certification, Authentication: If Ann is transmitting to Bob (Fig. 1a,b), then Ann would take her name, other classical ID information, and the Message Digest, encrypting them with her Private Key to create a Digital Signature cryptographic envelope. Bob could decrypt the encryptolope only via Ann's corresponding Public Key and thus identify the sender with some assurance. Concerned that someone might use a "nom de informatique" and fool you? Merely include a Digital Certificate in the original exchange of Public Keys or the encryptolope, a Certificate in which a third party assures that the identity of Ann and Ann's Public Key are linked and verified. This is analogous to Notarizing a document. Of course, the Certificate would be encrypted by the certifying organization using their own Private Key, and the reader would use the certifying organization's published Public Key to gain that reassurance. For the cautious or paranoid, a higher, second level, certifying organization could authenticate the authenticator (quis custodiet ipsos custodes?).

Fig.1a	Fig.1b

While Ann and Bob are about it, a Time/Date Stamp could be added by another third party in a similar way. This should leave no doubt about WHO sent WHAT, WHEN. Note that none of the third parties sees anything except the Message Digest, which reveals nothing about the message's content.

The technique addresses Certification and Authentication. Because the two keys in this system are not the same, it is termed an asymmetric approach. It often is called RSA from the first developers, Rivest, Shamir, and Adleman (1978). There is also a company with a major market share in the area called RSA Data Security. The algorithmic concept was first proposed by Diffie and Hellmann (DH, 1975), and their idea was eventually implemented by El Gamal (1985) using a different approach than RSA. Public/Private Key (PPK) will be a generic term to cover both public and commercially available approaches using RSA or DH approaches. A more complex key, the (Annie) Oakley, is being discussed on the WWW ( ftp://ds.internet .net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-00.txt ).

Security: But Ann and Bob are also probably concerned about security of the message. This could be similarly encrypted and sent. Unfortunately, Public/Private Key (PPK) systems are computationally slow. A single key, the same at both ends, is faster. This will be referred to as a Symmetric Encryption Key (SEK). The difficulty with symmetric keys is that somehow the sender generated key has to be passed to the receiver. Suppose that (1) Ann generated a SEK, (2) encrypted the message with it, (3) encrypted the SEK using a PPK technique, and (4) sent both the encrypted document and encrypted key to Bob- the best of both worlds, speed and security (see Figure 1a). The SEK key could be changed for each data transfer, creating a unique Session Key. Ann would use Bob's Public Key to encrypt the SEK, and Bob would use his own Private Key for its decryption (Figure 1b) prior to unlocking the message. Bob could recalculate his own Message Digest since they share the same SHA. If the two Digests agree, Bob knows the message is intact, and Ann cannot repudiate it since it used her Private Key.

The bottom line in this mixed mode approach is that Private Keys are never shared. Only Public Keys leave home. Are the techniques mathematically complicated? No; see The Math sidebar.

DEBUNKING THE MYTHS: Edward Cavazos, lawyer and author of Cyberspace and the Law, comments that three myths unfortunately seem self-perpetuating: (1) "Digital documents are inherently too unreliable to be admissible in court", (2) "Without a handwritten signature, legal documents like contracts are not binding", and (3) "The technology doesn't exist to reliably authenticate digital documents". All untrue, and all dissolve in the above techniques. But it will take open and informed minds in both the lab and law court to accept the new technologies.

FAQs (Frequently Asked Questions)

WHAT ARE SKIPJACK, CLIPPER, and DSS? The 1987 U.S. Computer Security Act authorized development of a set of standards for publicly available cryptography. The National Institute of Science and Technology (NIST) and the National Security Agency (NSA) are primary agencies for the project. The Secure Hash Standard (SHS-1) proposed by NIST produces a 160 bit hash value from a variable size input. The Digital Signature Standard (DSS) was selected by NIST (512-1024 bits) and involves a different approach than the RSA method described above. Cracking RSA encryption involves factoring, while DSS involves a discrete log approach. Both appear to be equally difficult.

The bulk data encryption algorithm, Skipjack, uses an 80 bit key operating on 64 bit blocks. The hardware it runs on is the famous, and infamous, Clipper chip. The Clipper Chip contains an 80 bit unit key which can be escrowed in two parts at two separate escrow agencies. Both parts are required to recover other keys. Clipper also has a serial number and Family key. When two devices equipped with Clipper wish to communicate, they agree on an 80 bit Session Key, encrypt the message, and send it along in an encryptolope which contains a Law Enforcement Access Field (LEAF). This can be used to extract all keys if access to the escrowed unit key segments has been authorized.

It is this LEAF portion of the project that attracted severe criticism from business, cipherpunks, coderpunks, lawyers, and concerned citizens. The situation was not helped when Blaze of AT&T published a classic paper reporting a flaw in the then current chip showing that it could be both cracked and legal access circumvented.

WHAT ARE THE ALTERNATIVES? RSA Inc. has MD 2,4 and 5 which produce 128 bit Message Digest hash functions. They are, respectively, each more secure, but slower. Exportable RC2 (block) and RC4 (stream) are variable keysize symmetric ciphers (SEK) for bulk encryption. They are 2 to 10 times faster than typical NIST Digital Encryption Standard approaches (DES, see sidebar) in software. RC5 is a high performance symmetric stream cipher. Currently, U.S. export control restrictions limit key sizes for foreign use, although pending legislation may release some of the restrictions. Key sizes of 56-128 bits are allowed for domestic and foreign subsidiaries or offices. 40 bit keys are permitted for export. Some approaches currently allot space for 128 bit keys, but make 88 bits known for foreign use. Future security expansion room is built in, if it is ever permitted. Lotus recently received permission to use 64 bits for foreign use if the NSA has quasi-escrow access to the keys.

VeriSign, an RSA Inc. spinoff, is building a seamless global Certification infrastructure. It has agreements with Oracle, IBM, MicroSoft, Netscape, Apple, and others. The approach is CCITT X.509, Public Key Cryptography Standards and Privacy Enhanced Mail compliant (see below). Various security levels are offered. Class 1 or 2 Digital IDs can be obtained through interactive or E-mail sessions. Class 3 or 4 IDs involve on-line registration and off-line verification. The system can provide a full featured 1024 bit PPK key generation distribution package including a self-destruct-on-tamper hardware box for in-house use.

Kerberos, developed at MIT, uses a trusted third-party scheme for authentication, and contains cryptographic tools.

WHAT ABOUT E-MAIL? Privacy Enhanced Mail (PEM) has been developed for Internet use. It includes encryption, authentication, and use of public/private and symmetric key cryptosystems. RSA and DES functions are available for key management, and DES in Cipher Block Chaining mode for message encryption. Certificates are supported meeting the International CCITT X.509 standard. Details can be found on Internet's RFC 1421-1424 (Request for Comments).

Public Key Cryptography Standards (PKCS) have been issued by an industry consortium including RSA, Apple, Microsoft, Lotus, Sun, and MIT. PEM compatible, they allow transmission of binary data as well as ASCII, and are CCITT X.509 compliant ( pkcs@rsa.com ).

Pretty Good Privacy (PGP) is available from MIT and commercial vendors. It uses MD5 to create Message Digests, and RSA Session Key encryption coupled with the International Data Encryption Algorithm (IDEA). This uses a DES-like algorithm based on a 128 bit key. PGP has a colorful history, patent issues have arisen, and the many extant versions are often not intercompatible.

Secure Multipurpose Internet Mail Extensions (S/MIME, RSA Inc.) is another approach. S/MIME, PGP, and PEM packages sum up a field in flux. PEM is based on a 7 bit message format. PGP works well with a small number of interacting users. S/MIME uses a symmetric key for bulk encryption, and public/private key algorithms for exchange of this key and digital signatures. S/MIME recommends either DES, triple DES, or RC2 symmetric keys. Digital Certificates (X.509 format) can be added. The product is scalable from small organizations to full Internet use. A public domain version will be available, and S/MIME will probably be included in RIPEM, a free PEM package (for non-commercial use) developed originally by RIordan.

WHAT ABOUT DISKS, INTRANETS, and INTERNET? For single user disk systems simple SEK systems are adequate. The keys should be changed periodically. To avoid having to rewrite all the files, a single encrypted file containing original keys can be periodically encrypted with a new key. Don't store the current master key on disk!

RSA Secure uses RC4 with institutional multiparty escrowing for traumatic recovery when a worker leaves the company or forgets the key. For multiuser systems the PPK-SEK systems provide adequate protection if administered properly (cf. VeriSign). As Intranet structures proliferate within corporations, users and the IT management will find security toolkits essential. Vendors like Microsoft and Lotus are starting to build these tools into their products, usually with third party software. Nortel's Entrust uses RSA cryptography; Entrust is used in MicroSoft's Exchange groupware.

Necessary? You can connect up to the Internet at kiosks in some airports, or use wireless communication in some geographic areas. Oy Nokia has announced a combined laptop, personal digital assistant (PDA) and cellular phone. Imagine losing your laptop with all your project records on it while travelling. Over 50,000 laptops were stolen in 1995, about 10% in airports. ENCRYPT IT, OR LOSE IT!

So now, let's look at Internet access software. It is 10 PM- what server is your PC really linked with? Secure Socket Layer (SSL) is an open, non-proprietary protocol providing data encryption, server authentication, and message integrity. Netscape's Navigator, beginning with beta 0.93, supports SSL. Netscape 3.0 supports Digital Certificates. You invoke SSL with https:/, not http:/. Servers can simultaneously run HTTP and HTTPS. Do not confuse HTTPS and S/HTTP! The former is a security layer underneath application protocols such as HTTP. S/HTTP adds security on top of HTTP, drawing on PEM and MIME analogies. S/HTTP can be used concurrently with SSL. Mosaic employs S/HTTP and can provide non-repudiation and certificates in some systems. An integrated approach is underway at Terisa Systems, backed by AOL, CompuServe, Prodigy, and Netscape. Microsoft has its own game with PCT http://pct.microsoft.com.

WHAT ARE OFFICIAL ORGANIZATIONS DOING? The American Bar Association closed public comment on their Digital Signature white paper in January 1996. The final draft was made available in mid-1996. The U.S. Patent Office convened a meeting in the Fall of 1995 to share opinions on digital signatures as part of a program to facilitate electronic patent submissions.

In 1994 the FDA issued a summary of comments received from its 1992 announcement of a proposed "Rule on Digital Signature Standards". The former 50 page document makes interesting reading and concludes that three levels of "signing" might be acceptable, based upon things a person "knows" (passwords), "has" (cards, smart-cards), or "is" (biometrics). Some quotes may illuminate their position on digital approaches. "Such measures may include electronic document encryption and use of digital signatures ... but because such measures are still evolving it would be premature to require their use; " and "FDA is aware that ... document encryption and digital signature standards ... (can) ... both authenticate an electronic record and establish its integrity. Accordingly, proposed Sect. 11.30 requires use of those controls in proposed Sect. 11.10 for closed (in-house) systems as appropriate."

Many official agencies seem to want to lead or follow. Some have difficulty getting out of the way.

BREAKING, CRACKING, AND FORGING: Encryption techniques are like Mount Everest. People will attempt to crack them because they are there. This is one strong argument for an "open" commercial development since potential weaknesses can be probed by deliberate challenges and responses. The RSA-129 attack by Atkins (MIT), described briefly above, is an example. 600 volunteers from 20 countries were involved. The final approach required 45 hours on a MasPar MP-1 massively parallel computer. Kocher's recent theoretical attack on RSA public key cryptosystems was immediately blocked by "blinding", which prevents derivation of private keys by measuring encryption processing time over a long period. Other attacks have quickly led to "salting" and "padding" protection schemes. These all basically involve adding bits to the encryption stream that improve the randomness, making the cracking process more difficult.

From a societal point of view it is interesting that the cipher community on the Internet has recently bifurcated. The coderpunks, who roam mathematical theory and programming lands, have separated from the cipherpunks interested in social and political issues. Are some of these really the crypto-anarchists so feared by Dorothy Denning of Georgetown University? And what of her own opinions-?

"the national security implications of uncontrolled encryption cannot be discussed or debated in a public forum ... for very legitimate reasons. It is even difficult to talk about the implications of encryption on law enforcement." (http://www.hotwired.com/clipper/denning.html, http://web.mit.edu/techreview/www/articles/july95/Denning.html )

Secure systems result more quickly and less painfully from attacks by friendly enemies. And the enemy is indeed US. Most of the details of Government supported approaches remain classified, and their security is unknown since attacks are unreported.

US or U.S.? Last year, Netscape was cracked (by friends) twice. Netscape Navigator/Netscape Commerce Server use RC4 (40/128 bit keys), RC2 (40/128 bits), DES (64 bits), and triple DES (192 bits). The Export (lite) versions, limited by the U.S. State & Commerce Departments under the International Traffic in Arms Regulation, often have just a 40 bit RC4. It was the latter that was cracked in 8 days using 120 workstations and two parallel supercomputers (64 MIPS-years). Netscape and VeriSign quickly distributed fixes that blocked the attack used at no cost. They pointed out that the resources used for this, and a second successful attack, were massive except for a very resource rich attacker. Many used the occasion to question the Government's continuing stand on export restrictions which forces most vendors to either distribute two versions (strong and weak) or only distribute the worldwide weak versions. Good point!

In June 1996 the NRC's Committee to Study National Cryptography Policy, a Congressionally-mandated effort, recommended that a 56 bit DES approach should be easily exportable. Many cryptographers feel that although a step in the right direction, a 56 bit key space is already inadequate. While Congress deliberates, the NIST DES standard must be rereviewed in 1997. What will happen?

In May 1996 the Executive Office of the President, Office of Management and Budget, produced a draft white paper that has some interesting sections:

"The Government will help set standards for the Key Management Infrastructure (KMI) ... and assure timely, lawful, government decryption access. Electronic surveillance and search and seizure are essential ... . Self-Escrow will be permitted (if performance requirements for law enforcement access are met. User desire for data recovery and law enforcement's need for access can be accommodated in a single locale, so long as the user trusts the key storage and law enforcement has confidentiality of access (sic). Government would be authorized to establish standards for Public Key Infrastructure. (It is intended to) expand the administration's key escrow initiative to permit export of 64 bit software and 80 bit hardware keys".

Watch http://www.capitolwatch.com .

In the meantime, a few select corporations can get their public keys authenticated by the Post Office, and their E-Mail Message Digests time/date stamped. A Diffie-Hellman approach is involved. Specific details remain diffuse. Microsoft and RSA Inc. (Security Dynamics) are cross-licensing. But, Microsoft has released a CryptoAPI, and IBM and HP have announced their intent to provide suites of encryption tools.

There are many players, a diversity of goals, considerable politics, and much fog and smoke. The laboratory must make certain that its needs are met by encryption tools, and that scientists requiring security can communicate at will and Internationally.

If each of us goes our own way, we will all go the same way!

Acknowledgements: The author would like to express his thanks to Ching-Wan Yip of Wake-Forest University and Ron Earp, Virginia Tech, for the discussions, technical advice, and reviewing which helped shape this article. He would also like to acknowledge the input from scientists in the U.S. and in Europe associated with MDL, SmithKline Beecham, Glaxo-Wellcome, Pfizer, and Novartis (Ciba-Geigy). The external reviewers provided many valuable suggestions and some seminal WWW references.

Useful sources

All of the areas discussed in this article are moving rapidly. The bulk of the technical information has been derived from multiple WWW sources using a Netscape Browser. These sources appear, disappear, and are altered periodically. Therefore it is suggested that those who wish further details might best search the Internet using the keywords in this article. That will lead to a tree of information. In such a search you will experience both the strengths and weaknesses of the Internet. The citations below include both seminal print and electronic sources that have proved useful in understanding the area. If you need assistance please contact the author at rdessy@chemserver.chem.vt.edu.

References

1. Hughes, L.J. Internet Security Techniques, New Riders Publishing: Indianapolis, IN; 1995. (seminal text)

2. Weber, R. Digital Rights Management Technologies, International Federation of Reproduction Rights Organizations: 222 Rosewood Drive, Danvers, MA 01923.

3. "Electronic Signatures; Electronic Records," Food and Drug Administration, 21 CFR Part 11, Docket No. 92N-0251, Aug. 1994.

4. Diffie, W., and Hellman, M.; "New Directions in Cryptography", IEEE Transactions in Information Theory, IT-22, 6:644-654, 1976.

5. Gardner, M., "A New Kind of Cipher", Scientific American, 237, 8, 120-124.

6. El Gamal, "A Public-Key Cryptosystem", IEEE Transactions in Information Theory, IT-31, 469-472, 1985.

7. Rivest, R., Shamir, A., Adleman, L.; "A Method for Obtaining Digital Signatures and Public Key Cryptosystems", Communications of the ACM, 21(2), 120-126, 1978.

8. Cavazos R., "Cyberspace and the Law", MIT Press, 1992.

9. National Institute of Standards and Technology, DSS, Communications of the ACM, 35(7), 36-54, 1992; SHS, FIPS Publ. #180, 11 May 1993; DES, FIPS Publ. 46-1, 22 Jan. 1988.

10. Miller, S., et al., "Kerberos", ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.ps

11. http://www.rsa.com

12. http://www.cis.ohio-state.edu/hypertext/faq/usenet/ cryptography-faq/top.html

13. http://www.verisign.com

14. http://www.cylink.com

15. http://www2.nas.edu/cstbweb

16. http://csrc.ncsl.nist.gov/fips/fip180-1.txt

17. http://csrc.ncsl.nist.gov/keyrecovery/vp.txt
http://csrc.ncsl.nist.gov/keyrecovery/admin.txt
http://csrc.ncsl.nist.gov/keyrecovery/clip.txt
http://csrc.ncsl.nist.gov/keyrecovery/cap.txt

18. http://www.isse.gmu.edu/~pfarrell/nist/kmi.html

19. http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html

20. http://lor.trincoll.edu/cpsc/cryptography/

21. http://www.microsoft.com/workshop/admin/adm-sec/websec.htm

22. http://www.netsurf.com/nsf/

23. http://www.eff.org

© 1996 Elsevier Science bv. Back to the TrAC Home Page