- 1.1 Opinions, Products
- 1.2 Roadmap to the Book
- 1.3 Terminology
- 1.4 Notation
- 1.5 Cryptographically Protected Sessions
- 1.6 Active and Passive Attacks
- 1.7 Legal Issues
- 1.8 Some Network Basics
- 1.9 Names for Humans
- 1.10 Authentication and Authorization
- 1.11 Malware: Viruses, Worms, Trojan Horses
- 1.12 Security Gateway
- 1.13 Denial-of-Service (DoS) Attacks
- 1.14 NAT (Network Address Translation)
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.7 Legal Issues
The legal aspects of cryptography are fascinating, but the picture changes quickly, and we are certainly not experts in law. Although it pains us to say it, if you’re going to build anything involving cryptography, talk to a lawyer. The combination of patents and export controls slowed down deployment of cryptographically secure networking, and caused strange technical choices.
1.7.1 Patents
One legal issue that affects the choice of security mechanisms is patents. Most cryptographic techniques were covered by patents and historically this has slowed their deployment. One of the important criteria for NIST’s selection of algorithms (such as AES [§3.7 Advanced Encryption Standard (AES)], SHA-3 [§5.6.2 Construction of SHA-3], and post-quantum algorithms [Chapter 8 Post-Quantum Cryptography]) is whether they are royalty-free.
The widely deployed RSA algorithm (see §6.3) was developed at MIT, and under the terms of MIT’s funding at the time, there were no license fees for U.S. government use. It was only patented in the U.S., and licensing was controlled by one company, which claimed that the Hellman-Merkle patent also covered RSA, and that patent is international. Interpretation of patent rights varies by country, so the legal issues were complex. At any rate, the last patent on RSA ran out on 20 September 2000. There were many parties on that day.
“I don’t know what you mean by your way,” said the Queen: “all the ways about here belong to me…”
—Through the Looking Glass
To avoid large licensing fees, many protocol standards used DSA (see §6.5) instead of RSA. Although in most respects DSA is technically inferior to RSA, when first announced it was advertised that DSA would be freely licensable so it would not be necessary to reach agreement with the RSA-licensing company. But the company claimed Hellman-Merkle covered all public key cryptography, and strengthened its position by acquiring rights to a patent by Schnorr that was closely related to DSA. Until the patents expired (and luckily the relevant patents have expired), the situation was murky.
1.7.2 Government Regulations
Mary had a little key
(It’s all she could export)
And all the email that she sent
Was opened at the Fort.
—Ron Rivest
The U.S. government (as well as other governments) used to impose severe restrictions on export of encryption. This caused much bitterness in the computer industry and led to some fascinating technical designs so that domestic products, which were legally allowed to use strong encryption, could use strong encryption where possible, and yet interoperate with exportable products that were not allowed to use strong encryption. Although U.S. companies still need permission from the Department of Commerce to export products containing cryptography, since around the year 2000 it has been easy to get products approved.
Additionally, even today, some countries have usage controls, so even if it were legal to export a product, it might not be legally usable inside some other country. For instance, some countries have developed their own cryptographic algorithms, and they want all their citizens to use those. Most of the reason for these sorts of rules is so that a government can’t be prevented from accessing data, for instance, for law enforcement purposes.