"Key escrow encryption is part of the Clinton Administration's initiative to promote the use of strong techniques to protect the privacy of data and voice transmissions by companies, government agencies and others without compromising the government's ability to carry out lawful electronic surveillance and to execute search warrants for electronically stored communications."-- U.S. GOVERNMENT SEEKS PUBLIC COMMENT ON DRAFT EXPORT CRITERIA FOR KEY ESCROW ENCRYPTION
Clipper was not well received by anyone involved with electronic communications. While it did a very good job of providing security agencies with everything necessary to listen to every illegal encrypted conversation, it did almost nothing to allow for cheap integration of the cryptosystem. It did nothing to help it compete with non-escrowed systems. It did nothing helpful in making it seem more useful than RSA or triple-DES. It in fact, did nothing except propose a new 80-bit encryption standard that was completely secret, and where they keys were also held by the government. In all respects, it was a flop.
"I agree with the Vice President that balancing economic and privacy needs with law enforcement and national security is not always an easy task. But we can do better than Clipper Chip."-- Senator Patrick Leahy
After almost a year of silence, the government tried once again to revive Clipper. This time, however, they claimed they were going to pay more attention to industry requirements, and were interested in compromise. They convened meetings with representatives of concerned groups, and tried to come up with a palatable solution.
Clipper tried to reconcile a big problem the government foresaw in the digital age: On one hand, people were interested in having strong cryptography to ensure the security of their data (encryption, authentication, validation, etc). On the other, the government wanted to maintain their ability to observe communications in the hope of preventing crime. The solution to the dilemma, or so the government thought, was to support strong cryptography in a way that ensured that all keys were given to the government, but in such a way that it would take a court-order if keys were to be released (using key-escrow to split the key in two and give to separate government entities). Of course, there were many objections raised, and those included:
Given the above objections, plus many unfavorable articles
published in major publications such as Wired, The New
York Times, The Washington Post and USA
Today, as well as mailing lists such as Cypherpunks and
Risks Digest, the government backed off for a while. The
National Security Agency got flamed some more, and although stuff was
being made available Clipper-enabled, it didn't seem to take
off. Industry worked together to achieve other
standards. Unfortunately, due to ITAR restrictions, these were hard to
export, or else were very weak. Netscape, for example, was made in two
versions: a 40-bit RC4 exportable version, and a 128-bit restricted
one.
So the government, supposedly after listening to all these objections, offered what they believed to be a compromise. Many analysts would claim that this was not in fact a compromise, but more what the government believed was acceptable to relax, plus a few changes they were willing to make, and of course, a 'prize' to entice participants to go along with their plan.
Put simply, the government ended up suggesting the following proposal for allowing export of cryptosystems for export:
With these requirements (available at http://csrc.ncsl.nist.gov/keyescrow/), it is now possible for software companies to make one product which they can sell around then world, as long as it uses escrowing to provide the government with access to the keys.
The immediate question that comes to mind when one looks at these new proposals is of course : "What have we gained from this?".
It is certainly not any worse. If nothing else, Clipper details a hardware device that people may use in order to enhance security of digital communications. Clipper 2 doesn't really detail that. Instead, it loosens slightly the stranglehold the government has had on the export of cryptography. Unfortunately, it does this at the cost of mandatory escrow. This is a double-edged sword to many software companies. On one hand, 64 bits is much nicer than 40. However, accepting escrow in order to be allowed the 64 bits is a sacrifice some people would rather not make. Robert Holleyman (a delegate at the december convention for the Business Software Alliance, representing companies such as Microsoft, Novell, Lotus and others) expressed his frustration well, indicating that current policy "directly threatens" the industry because of "The US Government's continuing refusal to adopt realistic export control policies. (as quoted by Pat Farell).
There are other problems with this proposal. This is intended to be seen as a cooperation between government and industry with the hopes of arriving at a workable solution. Yet, people have complained that the government had come to the bargaining table with an exact model of how the meeting will go, and simply refused to accept useful suggestions. It seemed more like a question-and-answer session to many people, and statements were made to unwilling ears both ways. It is clear from statements made by companies such as MCI, Netscape, and others, that this is simply no better as far as they are concerned than having complete export restrictions.
This is not to say that everyone was unhappy with the proposal. Every company involved was probably working on some technique for encrypting data that involves some sort of escrow. And some probably were willing to accept the proposal (specifically since it was pointed out that 64 bits was an initial thing, and if it looked like stuff was working out, the number could be raised). It was clear, however, that people were going to have to work within very strict bounds.
Part of the problem being experienced here is that given the requirements of strong cryptography AND the requirement for law enforcement abilities, the solution people always come up with is some form of key-escrow. However, Clipper and Clipper 2 are not the only possibilities. Adi Shamir, in 6.805, proposed one possible solution that offered some more security for those concerned with the government massively eavesdropping, while at the same time gave the government the ability to carry out lawful tapping when necessary. This scheme simply put in escrow part of the key, instead of the entire one. The size of the part of the key could be made variable to allow for control over the number of messages the government could decrypt. Basically, it put in escrow most of the key, while leaving a set number of bits to be set secretly (at random) by the user. An unauthorized adversary would have to attempt to search the entire keyspace to decode the conversation. An authorized eavesdropper would have most of the work done for him, but still will need to go through some work to decode. This ensures that the government could not attempt to eavesdrop on a large number of people, and even if the keys are compromised, the system doesn't become completely weak (only as strong as the number of bits that are not escrowed.)
Of course there are other answers. Some members of the cryptographic community believe that the entire concept of a need for the government to eavesdrop on its citizens is absurd. If the telephone was designed to allow the government to listen in, video cameras with the same principle, and security systems, we would be living in a world where the government knows about our every move, word, and behavior. They got lucky that phones made it easy for them to listen. Now they are unlucky that cryptography is making it hard to do so. Tough. Let law enforcement evolve to utilize other methods than tapping phones to stop criminals. Honest people should not have to suffer or go through absurd databases and registries in order to use simple security devices. This claim isn't that absurd.
The above claim is one that is highly desired by most companies. They want to have the freedom to use whatever they feel is secure and useful. They have priorities that include safety and speed, and don't want to add support for government eavesdropping that would simply make them lose customers to software products that don't have these features in them.
And of course, there is the last alternative, which some people believe is actually what the government would like to see happen: No strong cryptography. Put simply, all of this is aimed at making it appear that the government is trying to help people have secure systems, but in reality, is aimed at making life so difficult that people just choose to use weaker systems. This view is a little paranoid, and isn't based on much fact, but nonetheless, it is a possibility that other places have adopted. Several nations have already outlawed the use of strong cryptography or require registration of its use.
So why is the government bothering to invite all these business representatives to discussions, and becoming more lenient with export but with a new requirement that demands escrow for keys of lengths between 40 and 64?
The answer to the question is not clear. Companies have made it clear that 40-bit security is not secure enough. A recent crack of a 40-bit RC4 encrypted message by a student in France received global attention and made Netscape look less-than-secure. Companies are becoming more vocal in their demand for a right to export software they know to be far more secure. The 64 bits is clearly meant to entice these companies to go along with the government's plan. Many people believe ITAR (which NIST and the NSA use to restrict export of such software) to be unconstitutional, but this has never been fully tested. The government has no interest in losing ITAR, so instead, they try not to end up in situations where the ITAR would be challenged. This change now gives vendors the choice of going with cryptosystems that are more secure, at the cost of giving the keys to the government. The government hopes that this will force escrow through, simply because of the drive for more security. This is simply not true. Certain ompanies have made it very clear that they do not accept such measures. Netscape Corporation, a very prominent software manufacturer currently, has stated their disdain for this new policy:
"Netscape will continue to work with industry organizations, partners, and customers who are in similar opposition to the government's proposal to ensure that the current administration understands the unacceptability of this plan."-- Netscape Policy On Encryption Export
Well, there is even more reason to object to the proposal . A minor and seemingly innocuous requirement in the specification for the protocol has far-reaching implications for software programmers. The ultimate goal of these companies is to be able to have a single product that is used globally. The requirement simply states that the encryption software will not talk to software that doesn't do escrowing. Taken to its ultimate end, we realize that all implementations, both national and exported, will have to have escrowing in order to be able to communicate with all other devices of the same nature. This is not at all helpful to manufacturers who up untll this were selling useful security systems in the U.S. that didn't do escrowing, and were interested in exporting them.
Of course, to be honest, 64 bits is simply not enough. The number of bits is not necessarily a good indicator of the security of the system. A 64 bit RSA key is in fact much simpler to break than a 64 bit ElGamal key. Even in the strictest sense, at the rate computer speed is growing, as well as improvement in algorithms, 64 bits is not going to be secure for long. NIST has indicated that this number will be increased, but not until the government is sure the escrow proposal is working. Again, they are trying to entice people to accept this compromise, which is not really a compromise at all.
Some companies have complained vocally about software they have written that supports all the real requirements, but because of the use of things such as 2000 bit keys, will still be unexportable. This seems to make no sense to these companies, and they would like some requirements revised.
It seems then, that the proposal is aimed at ending up in a situation where strong cryptography, which is already available within the U.S. without any crypto, is replaced with strong cryptography which escrows, in order to allow for interoperable software to be exported. This may be worthwhile for companies, but is certainly not the best situation for them.
Will this succeed? It currently seems that the same people who objected to Clipper are now objecting to Clipper 2, though not as vocally. The 'reward' for accepting Clipper 2 is certainly nicer than what is available now. But it is certainly not what these companies want. They want an exportable system which doesn't put peoples' security in the hands of others. It's already available in the U.S., and is being leaked to the rest of the world anyway. Why shouldn't export restrictions, which are probably unconstitutional, be lifted?
It is likely that this proposal will also end up being mostly ignored. As was the case with Clipper, there are going to be a few companies that will manufacture compliant software, but sales are likely to be low.
"The government's not-so-new "Clipper II":a train wreck waiting to happen."-- Bruce N. Meeks
Clipper 2 is certainly no compromise. It is also no solution to the problem. It is merely an attempt by the government to maintain its tight grip over communications. It is holding a carrot on a stick, promising the permission of export of cryptographic software. In reality, it is trying to force everybody who blindly reach for the carrot to accept key escrow. Fortunately, so far, people are not as blind as some organizations hope. Economic needs, however, might force people to accept this deal even though it is clearly foul.
Companies are slowly realizing what they are having to put up with, and demanding better. It is clear that the government representatives were not really listening to industry demands, however, so a different approach at achieving a lifting of export controls might be necessary. Whether this ends up being through court challenges to these restrictions, or through development of code outside the country (something that is bound to be detrimental to the U.S. economy), it will have to be done. People are unlikely to accept key-escrow, and therefore, software manufacturers are going to have to stand up and demand saner regulation.