Cryptography: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
imported>Sandy Harris
Line 122: Line 122:
Then there is the optimism of programmers. As for databases and real-time programming, cryptography looks deceptively simple. Almost any programmer can handle the basics — implement something that handles straightforward cases — fairly easily.  However, as in the other fields, anyone who tackles the hard cases without ''both'' some study of relevant theory ''and'' considerable practical experience is ''almost certain to get it horribly wrong''. This is demonstrated far too often.
Then there is the optimism of programmers. As for databases and real-time programming, cryptography looks deceptively simple. Almost any programmer can handle the basics — implement something that handles straightforward cases — fairly easily.  However, as in the other fields, anyone who tackles the hard cases without ''both'' some study of relevant theory ''and'' considerable practical experience is ''almost certain to get it horribly wrong''. This is demonstrated far too often.


For example, many companies that implement their own crypto as part of a product end up with something that is easily broken. The programmers on these product teams are competent, but they routinely get the crypto wrong. Well-known examples include the addition of encryption to products like [[Microsoft Office]] <ref>{{cite paper|author=Hongjun Wu|title=The Misuse of RC4 in Microsoft Word and Excel|url=http://eprint.iacr.org/2005/007}}</ref>, [http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Netscape] and many others. Generally, such problems are fixed in later releases.
For example, many companies that implement their own crypto as part of a product end up with something that is easily broken. The programmers on these product teams are competent, but they routinely get the crypto wrong. Examples include the addition of encryption to products like [[Microsoft Office]] <ref>{{cite paper|author=Hongjun Wu|title=The Misuse of RC4 in Microsoft Word and Excel|url=http://eprint.iacr.org/2005/007}}</ref>, [http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Netscape] and many others. Generally, such problems are fixed in later releases.


There are also failures in products where encryption is central to the design, such as the [[CSS]] encryption on [[DVD]]s <ref>{{cite paper|author=David Touretsky|title=Gallery of CSS Descramblers|url=http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/}}</ref> and the [[WEP]] <ref>{{cite paper|author=Nikita Borisov, Ian Goldberg, and David Wagner|title=Security of the WEP algorithm|url=http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html}}</ref> encryption in wireless networking. Such problems are much harder to fix if the flawed designs are included in widely deployed standards; updating a standard takes much longer than releasing a new software version.
There are also failures in products where encryption is central to the design, such as the [[CSS]] encryption on [[DVD]]s <ref>{{cite paper|author=David Touretsky|title=Gallery of CSS Descramblers|url=http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/}}</ref> and the [[WEP]] <ref>{{cite paper|author=Nikita Borisov, Ian Goldberg, and David Wagner|title=Security of the WEP algorithm|url=http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html}}</ref> encryption in wireless networking. Such problems are much harder to fix if the flawed designs are included in widely deployed standards; updating a standard takes much longer than releasing a new software version.

Revision as of 04:30, 23 October 2008

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Template:TOC-right Cryptography is a branch of mathematics concerned with obscuring information and then controlling who can retrieve the information. While this article will focus on modern applications and technique, cryptography has been in use for three millenia; when literacy was rare, writing could be considered a means of obscurement. See History of cryptography.

Cryptography has found many practical applications related to security and reliability in computers, especially when connected to networks. Cryptography is central to digital rights management (DRM) in computers and is important in the fields of computer science and engineering, as well as mathematics. By encrypting a message, we can be fairly certain who sent it, fairly certain that others can’t read it, and we can determine that the message likely has not been altered. If someone scrambles a message to make it illegible, the original message is called plaintext, and the scrambled message is called ciphertext. Encryption is the act of turning plain text into cipher text. Decryption is the act of turning cipher text back to plain text

Cryptology ("the study of secrets", from the Greek) describes the field of cryptography as a whole, while cryptography proper is the subfield of encryption and decryption. Cryptanalysis or "codebreaking" refers to the study of how to break into an encrypted message without possession of the key.

As well as being aware of cryptographic history, cryptographic algorithm and system designers must also carefully consider probable future developments in their designs. For instance, the continued improvements in computer processing power in increasing the scope of brute-force attacks must be taken into account when specifying key lengths, and the potential effects of quantum computing are already being considered by good cryptographic system designers.[1]

Essentially, prior to the early 20th century, cryptography was chiefly concerned with linguistic patterns. Since then the emphasis has shifted, and cryptography now makes extensive use of mathematics, including aspects of information theory, computational complexity, statistics, combinatorics, abstract algebra, and number theory. Cryptography is also a branch of engineering, but an unusual one as it deals with active, intelligent, and malevolent opposition (see cryptographic engineering and security engineering). There is also active research examining the relationship between cryptographic problems and quantum physics (see quantum cryptography and quantum computing).

Codes versus ciphers

In common usage, the term "code" is often used to mean any method of encryption or meaning-concealment. In cryptography, however, code is more specific, meaning a linguistic procedure which replaces a unit of plain text with a code word (for example, apple pie replaces attack at dawn). Codes are not practical for lengthy communications, and are especially difficult to do in software, as they are as much linguistic as mathematical problems. Nevertheless, there are niches where codes are quite useful.

A cipher (or cypher) is a system of algorithms for encryption and decryption. The exact operation of a cipher is controlled by a key, which is a secret parameter for the cipher algorithm.

Ciphers use a mathematical operation to convert understandable plaintext into unintelligible ciphertext. In general, for two-way ciphers, the number of plaintext symbols is equal to, or slightly less if error-checking is in use, than the number of ciphertext symbols.

A small number of codes can represent a set of operations known to sender and receiver; there is no information to help a cryptanalyst. "Climb Mount Niikata" was a final order for the Japanese mobile striking fleet to attack Pearl Harbor, while "visit Aunt Shirley" could order a terrorist to trigger a chemical weapon at a particular place.

Principles of cryptosystems

In encryption and decryption, a key is one or more unique values used by an encryption or decryption algorithm. Encryption algorithms take as input a key and plaintext, producing ciphertext output. For decryption, the process is reversed to turn ciphertext into plaintext, but decryption need not use the same key(s) or algorithms for decryption as was used for encryption.

The ciphertext produced by an encryption algorithm should bear no resemblance to the original message. Ideally, it should be indistinguishable from a random string of symbols.

One-way encryption

There are a substantial number of applications where it is not necessary to be able to reconstruct the plaintext from the ciphertext, but merely to be able to prove that some piece of information could be generated only from the original plaintext. See one-way encryption for the techniques; some applications are presented here.

Protection against record modification

Protection against file modification

Protecting stored passwords

When passwords are stored on a computer, it is essential that they be kept secret. Thus it is recommended practice to encrypt the passwords before writing them to disk, and furthermore to prevent anyone who might find them from decrypting them. One-way encryption involves storing an encrypted string which cannot be decrypted. When a user later enters their password, the newly enter password is first encrypted, and then is compared to the encrypted stored string.

The password is usually encrypted as a hash digest (a large number generated by scrambling and condensing plain text letters). An example of a hash digest is SHA-1, which dates from 1994. The SHA-1 algorithm takes a string as input. The algorithm is a digest because the result is a fixed-size number. The SHA-1 algorithm always outputs a 160-bit number (20 bytes of storage). 48 decimal digits would be required to express this number, and it is usually displayed to humans as a 28-character, base-64 encoded string. Here are some examples:

Hello World   z7R8yBtZz0+eqead7UEYzPvVFjw=
VB            L1SHP0uzuGbMUpT4z0zlAdEzfPE=
vb            eOcnhoZRmuoC/Ed5iRrW7IxlCDw=
Vb            e3PaiF6tMmhPGUfGg1nrfdV3I+I=
vB            gzt6my3YIrzJiTiucvqBTgM6LtM=

Two-way encryption

Some approaches are said to be two-way because text messages are both encrypted and decrypted. One approach is called secret key or symmetric key cryptography, in which the sender encrypts with a secret key and the receiver must have an identical copy of that key to decrypt. The second method is called public key or asymmetric key cryptography; in this, keys are created in pairs, such that when one is used to encrypt, the other must be used to decrypt. One key is the private key; this is kept secret from everyone. The other is the public key; this can be published anywhere; on the net, in the phonebook, on business cards.

Practical use of asymmetric cryptography, on any sizable basis, requires a public key infrastructure (PKI). A public key will normally be embedded in a digital certificate that is issued by a certification authority. In the event of compromise of the private key, the certification authority can revoke the key by adding it to a certificate revocation list. Digital certificates, like passports or other identification documents, usually have expiration dates, and a means of verifying both the validity of the certificate and of the certificate issuer.

Public key exchanges are used to open up secure secret key channels between strangers across the internet.

Units on which encryption operates

Character ciphers
Block ciphers

These break the data up into fixed-size blocks and encrypt each block under control of the key. Since the message will rarely have the same length of an integer number of blocks, there will usually need to be some form of "paddding" to make the final block be long enough. The padding, if not pseudorandom, may provide a probable plaintext attack point, and certainly adds overhead to the encryption process.

Stream ciphers

These encrypt a stream of input data by combining it with a pseudo-random stream of data; the pseudo-random stream is generated under control of the encryption key. They are statistically stronger as there is no block size to use as one controlled variable in cryptanalysis.

Paradigms of encryption

Symmetric key encryption

Symmetric key cryptography requires only one key. That key can be used either to encrypt or decrypt a message. Both the sender and receiver must have the key, and third parties (potential intruders) must be prevented from obtaining the key. Symmetric key encryption may also be called traditional, shared-secret, secret-key, or conventional encryption. This was the only kind of two-way encryption publicly known until 1976.[2] With this kind of encryption alone, it would not be possible to open up a new secure connection on the internet, because there would be no safe way initially to transmit the shared key to the other end of the connection without intruders being able to intercept it.

One example of a secret-key algorithm is the Data Encryption Standard (DES). DES uses a 56-bit key which is used to derive 16 48-bit round keys. Neither DES nor the variant, triple DES, are secure against modern attacks (see cryptographic strength for the reasons).

One practical consideration for using secret key encryption is where, and how, to safely store the key on the computer so that intruders will not be able to obtain it, if they should gain access to the machine. Simply storing the key unencrypted in a file or database is a poor strategy. Hard coding it inside a program is also risky because it could be fished out using a decompiler or debugger. A preferable strategy would be to encrypt the private key and store it in a file that is protected by the file system; this way, only authorized users of the system should be able to read the file. But then, where should one store the key used to encrypt the private key? It becomes a recursive problem.

Asymmetric key encryption

In contrast with symmetric encryption, asymmetric encryption, a user has their computer produce two different keys, related mathematically so that data encrypted with one can only be decrypted with the other. One key is the public key and can be published. The other is the private key and is kept secret, never leaving the user's computer. It was first proposed, in public, in 1976 by Whitfield Diffie and Martin Hellman.[3].

A public key cryptography system is constructed so that calculation of the private key is computationally infeasible from knowledge of the public key, even though they are necessarily related. Instead, both keys are generated secretly, as an interrelated pair[4]. The historian David Kahn described public-key cryptography as "the most revolutionary new concept in the field since polyalphabetic substitution emerged in the Renaissance".[5]

When used for content confidentiality, the public key is typically used for encryption, while the private or secret key is used for decryption. There needs to be a separate public-private pair in each direction of communication. The early asymmetric techniques were vulnerable to some forms of cryptanalysis, until Diffie and Hellman showed that public-key cryptography was practucak by presenting the Diffie-Hellman key exchange protocol[2]. In 1978, Ronald Rivest, Adi Shamir, and Len Adleman invented Rivest-Shamir-Adleman (RSA), another public-key system[6] [7] Previously released as an MIT "Technical Memo" in April 1977, and published in Martin Gardner's Scientific American "Mathematical Recreations" column</ref>. In 1997, it finally became publicly known that asymmetric cryptography had been invented by James H. Ellis at GCHQ, a British intelligence organization, in the early 1970s, and that both the Diffie-Hellman and RSA algorithms had been previously developed (by Malcolm J. Williamson and Clifford Cocks, respectively)[8].

Generating session keys

The primary usage of public-key encryption is in hybrid systems where a symmetric algorithm does the bulk data encryption while the public key algorithm provides other services. Public-key encryption is slower than conventional symmetric encryption.For example, in Pretty Good Privacy (PGP) email encryption the sender generates a random key for the symmetric bulk encryption and uses public key techniques to securely deliver it to the receiver. In the Diffie-Hellman key agreement protocol, used in IPsec and other systems, public key techniques provide authentication.

An advantage of asymmetric over symmetric cryptosystems is that all symmetric system keys must be kept secret, and the logistics of key management become complex. Each distinct pair of communicating parties must share a different key. The number of keys required increases as the square of the number of network members, which requires very complex key management schemes in large networks. The difficulty of establishing a secret key between two communicating parties when a secure channel doesn't already exist between them also presents a chicken-and-egg problem which is a considerably practical obstacle for cryptography users in the real world.

Digital signatures

In addition to encryption, public-key cryptography can be used to implement digital signature schemes. A digital signature is somewhat like an ordinary signature; they have the characteristic that they are easy for a user to produce, but difficult for anyone else to forge. Digital signatures can also be permanently tied to the content of the message being signed; they cannot be 'moved' from one document to another, for any attempt will be detectable. In digital signature schemes, there are two algorithms: one for signing, in which a secret key is used to process the message (or a hash of the message or both), and one for verification, in which the matching public key is used with the message to check the validity of the signature. RSA and DSA are two of the most popular digital signature schemes. Digital signatures are central to the operation of public key infrastructures and to many network security schemes (Transport Layer Security (TLS),[9] also Secure Sockets Layer (SSL)), many VPNs, etc).[10]

Cryptography is difficult

Cryptography in particular and communications security in general are difficult to do well, partly because neither the user nor the system designer gets feedback on problems. If your word processor fails or your bank's web site goes down, you see the results and are quite likely to complain to the supplier. If your cryptosystem fails, you may not know. If your bank's cryptosystem fails, they may not know, and may not tell you if they do.

If a serious attacker — a criminal breaking into a bank, a government running a monitoring program, an enemy in war, or any other — breaks a cryptosystem, he will certainly not tell the victims, If the victims become aware of the break, then they will change their system. They might change to something more secure, so it is very much in the attacker's interest to keep the break secret, In a famous example, the British ULTRA project at Bletchley Park read many German codes through most of World War II, and the Germans never realised it.

This is one reason cryptographers often publish details of their designs and invite attacks. In accordance with Kerckhoffs' Principle, a cryptosysten cannot be considered secure unless it remains safe even when the attacker knows all details except the key in use. A published design that withstands analysis is a candidate for trust; an unpublished design simply is not trustworthy. Of course "published" has a special meaning in some situations. Someone in a major government cryptographic agency need not make a design public to have it analysed; he need only ask the cryptanalysts down the hall to have a look.

Having a design publicly broken might be a bit embarrassing for the designer, but he can console himself that he is in good company; breaks routinely happen. Even the NSA can get it wrong, as Matt Blaze demonstrated in "Protocol failure in the escrowed encryption standard" [1]. Other large organisations can too: Deutsche Telecom's Magenta cipher was broken by Schneier and others [2] within hours of being first made public at an AES candidate's conference. Nor are the experts immune; Blaze and Schneier designed a cipher called McGuffin [3] that was broken [4] before the end of the conference they presented it at.

In any case, having a design publicly broken — even broken by (horrors!) some unknown graduate student rather than a famous expert — is far less embarrassing than having a deployed system fall to a malicious attacker. At least when both design and attacks are in public research literature, the designer can either fix any problems that are found or discard one approach and try something different.

Well-known papers on the difficulties of cryptography include Anderson "Why Cryptosystems Fail" [11], Schneier "Why Cryptography Is Harder Than It Looks" [12], and Gutmann "Lessons Learned in Implementing and Deploying Crypto Software" [13]. Anderson's book "Security Enginneering" [14] provides more detailed coverage.

Then there is the optimism of programmers. As for databases and real-time programming, cryptography looks deceptively simple. Almost any programmer can handle the basics — implement something that handles straightforward cases — fairly easily. However, as in the other fields, anyone who tackles the hard cases without both some study of relevant theory and considerable practical experience is almost certain to get it horribly wrong. This is demonstrated far too often.

For example, many companies that implement their own crypto as part of a product end up with something that is easily broken. The programmers on these product teams are competent, but they routinely get the crypto wrong. Examples include the addition of encryption to products like Microsoft Office [15], Netscape and many others. Generally, such problems are fixed in later releases.

There are also failures in products where encryption is central to the design, such as the CSS encryption on DVDs [16] and the WEP [17] encryption in wireless networking. Such problems are much harder to fix if the flawed designs are included in widely deployed standards; updating a standard takes much longer than releasing a new software version.

Beyond the real difficulties in implementing real products are some systems that both get the cryptography horribly wrong and make extravagant marketing claims. These are often referred to as snake oil [18],

Legal issues involving cryptography

Prohibitions

Because of its potential to assist the malicious in their schemes, cryptography has long been of interest to intelligence gathering agencies and law enforcement agencies. Because of its facilitation of privacy, and the diminution of privacy attendant on its prohibition, cryptography is also of considerable interest to civil rights supporters. Accordingly, there has been a history of controversial legal issues surrounding cryptography, especially since the advent of inexpensive computers has made possible wide spread access to high quality cryptography.

In some countries, even the domestic use of cryptography is, or has been, restricted. Until 1999, France significantly restricted the use of cryptography domestically. In China, a license is still required to use cryptography. Many countries have tight restrictions on the use of cryptography. Among the more restrictive are laws in Belarus, China, Kazakhstan, Mongolia, Pakistan, Russia, Singapore, Tunisia, Venezuela, and Vietnam[19].

In the United States, cryptography is legal for domestic use, but there has been much conflict over legal issues related to cryptography. One particularly important issue has been the export of cryptography and cryptographic software and hardware. Because of the importance of cryptanalysis in World War II and an expectation that cryptography would continue to be important for national security, many western governments have, at some point, strictly regulated export of cryptography. After World War II, it was illegal in the US to sell or distribute encryption technology overseas; in fact, encryption was classified as a munition, like tanks and nuclear weapons[20]. Until the advent of the personal computer and the Internet, this was not especially problematic as sgood cryptography was indistinguishable from bad cryptography for nearly all users, and because most of the cryptographic techniques generally available were slow and error prone whether good or bad. However, as the Internet grew and computers became more widely available, high quality encryption techniques became well-known around the globe. As a result, export controls came to be understood to be an impediment to commerce and to research.

Export Controls

In the 1990s, several challenges were launched against US regulations for export of cryptography. Philip Zimmermann's Pretty Good Privacy (PGP) encryption program, as well as its source code, was released in the US, and found its way onto the Internet in June of 1991. After a complaint by RSA Security (then called RSA Data Security, Inc., or RSADSI), Zimmermann was criminally investigated by the Customs Service and the FBI for several years but no charges were filed[21][22]. Also, Daniel Bernstein, then a graduate student at University of California at Berkeley, brought a lawsuit against the US government challenging aspects of those restrictions on free speech grounds in the 1995 case Bernstein v. United States which ultimately resulted in a 1999 decision that printed source code for cryptographic algorithms and systems was protected as free speech by the United States Constitution.[23].

In 1996, thirty-nine countries signed the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies, an arms control treaty that deals with the export of arms and "dual-use" technologies such as cryptography. The treaty stipulated that the use of cryptography with short key-lengths (56-bit for symmetric encryption, 512-bit for RSA) would no longer be export-controlled[24]. Cryptography exports from the US are now much less strictly regulated than in the past as a consequence of a major relaxation in 2000[19]; there are no longer many restrictions on key sizes in US-exported mass-market software.

In practice today, since the relaxation in US export restrictions, and because almost every personal computer connected to the Internet, everywhere in the world, includes a US-sourced web browser such as Mozilla Firefox or Microsoft Internet Explorer, almost every Internet user worldwide has strong cryptography (i.e., using long keys) in their browser's Transport Layer Security or Secure Sockets Layer stack. The Mozilla Thunderbird and Microsoft Outlook E-mail client programs similarly can connect to Internet Message Access Protocol or Post Office Protocol(POP) servers via TLS, and can send and receive email encrypted with S/MIME.

Many Internet users don't realize that their basic application software contains such extensive cryptography systems. These browsers and email programs are so ubiquitous that even governments whose intent is to regulate civilian use of cryptography generally don't find it practical to do much to control distribution or use of this quality of cryptography, so even when such laws are in force, actual enforcement is often lax.

NSA involvement

Another contentious issue connected to cryptography in the United States, is influence of the National Security Agency in high quality cipher development and policy. NSA was involved with the design of DES during its development at IBM and its consideration by the National Bureau of Standards as a possible Federal Standard for cryptography[25]. DES was designed to be secure against differential cryptanalysis[26], a powerful and general cryptanalytic technique known to NSA and IBM, that became publicly known only when it was rediscovered in the late 1980s[27]. According to Steven Levy, IBM discovered differential cryptanalysis[28] and kept the technique secret at NSA's request.

Another instance of NSA's involvement was the 1993 Clipper chip affair, an encryption microchip intended to be part of the Capstone cryptography-control initiative. Clipper was widely criticized for two cryptographic reasons: the cipher algorithm was classified (the cipher, called Skipjack, was declassified in 1998 after the Clipper initiative lapsed), which led to concerns that NSA had deliberately made the cipher weak in order to assist its intelligence efforts. The whole initiative was also criticized based on its violation of Kerckhoffs' Principle, as the scheme included a special escrow key held by the government for use by law enforcement, for example in wiretaps[22]. Also, Matt Blaze showed in 1994 [29] that the protocol was flawed and easily subverted.

Digital rights management

Cryptography is central to Digital Rights Management (DRM), a group of techniques for technologically controlling use of copyrighted material, being widely implemented and deployed at the behest of some copyright holders. In 1998, Bill Clinton signed the Digital Millennium Copyright Act (DMCA), which criminalized the production, dissemination, and use of certain cryptanalytic techniques and technology; specifically, those that could be used to circumvent DRM technological schemes[30]. This had a very serious potential impact on the cryptography research community since an argument can be made that virtually any cryptanalytic research violated, or might violate, the DMCA. The FBI has not enforced the DMCA as rigorously as had been feared by some, but the law, nonetheless, remains a controversial one. One well-respected cryptography researcher, Niels Ferguson, has publicly stated that he will not release some research into an Intel security design for fear of prosecution under the DMCA, and both Alan Cox (longtime number 2 in Linux kernel development) and Professor Edward Felten (and some of his students at Princeton) have encountered problems related to the Act. Dmitry Sklyarov was arrested, and jailed for some months, for alleged violations of the DMCA which occurred in Russia, where the work for which he was arrested and charged was legal.

References

  1. Menezes, AJ; PC van Oorschot & SA Vanstone (Fifth Edition, 2001), Handbook of Applied Cryptography, ISBN 0-8493-8523-7
  2. 2.0 2.1 Diffie, Whitfield & Martin Hellman (Nov. 1976), "pdf New Directions in Cryptography", IEEE Transactions on Information Theory IT-22 pages = 644-654
  3. Diffie, Whitfield (June 8, 1976), "Multi-user cryptographic techniques", AFIPS Proceedings 4 5: 109-112
  4. Ralph Merkle was working on similar ideas at the time, and Hellman has suggested that the term used should be Diffie-Hellman-Merkle asymmetric key cryptography.
  5. David Kahn, "Cryptology Goes Public", 58 Foreign Affairs] 141, 151 (fall 1979), p. 153.
  6. Rivest, Ronald L.; Adi Shamir & Len Adleman, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems
  7. Communications of the ACM, Vol. 21 (2), pp.120–126. 1978
  8. Clifford Cocks. A Note on 'Non-Secret Encryption', CESG Research Report, 20 November 1973.
  9. T. Dierks, E. Rescorla (August 2008), The Transport Layer Security (TLS) Protocol Version 1.2., RFC5246
  10. Schneier, Bruce (2nd edition, 1996,), Applied Cryptography, John Wiley & Sons, ISBN 0-471-11709-9
  11. Ross Anderson. Why Cryptosystems Fail.
  12. Bruce Schneier. Why Cryptography Is Harder Than It Looks.
  13. Peter Gutmann (2002). Lessons Learned in Implementing and Deploying Crypto Software.
  14. Ross Anderson. Security Engineering. 
  15. Hongjun Wu. The Misuse of RC4 in Microsoft Word and Excel.
  16. David Touretsky. Gallery of CSS Descramblers.
  17. Nikita Borisov, Ian Goldberg, and David Wagner. Security of the WEP algorithm.
  18. Bruce Schneier (February 1999). Snake Oil. Counterpane Inc..
  19. 19.0 19.1 RSA Laboratories' Frequently Asked Questions About Today's Cryptography
  20. Cryptography & Speech from Cyberlaw
  21. "Case Closed on Zimmermann PGP Investigation", press note from the IEEE.
  22. 22.0 22.1 Levy, Steven (2001). "Crypto: How the Code Rebels Beat the Government — Saving Privacy in the Digital Age. Penguin Books, 56. ISBN 0-14-024432-8. 
  23. Bernstein v USDOJ, 9th Circuit court of appeals decision.
  24. The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies
  25. "The Data Encryption Standard (DES)" from Bruce Schneier's CryptoGram newsletter, June 15, 2000
  26. Coppersmith, D. (May 1994). "The Data Encryption Standard (DES) and its strength against attacks" (PDF). IBM Journal of Research and Development 38 (3): 243.
  27. E. Biham and A. Shamir, "Differential cryptanalysis of DES-like cryptosystems", Journal of Cryptology, vol. 4 num. 1, pp. 3-72, Springer-Verlag, 1991.
  28. Levy, pg. 56
  29. Blaze, Matt (November 1994). Protocol Failure in the Escrowed Encryption Standard. 
  30. Digital Millennium Copyright Act