USS Clueless              Voyages of a restless mind

Main: normal long no graphics Contact Log archives Best log entries Other articles Site Search

Stardate 20011018.1750 (On Screen): Lock technology is interesting. Originally, the key was a certain shape, and there was a template inside the lock which was the same shape. If the key had any protrusions on it which were taller than the template permitted, then it couldn't be turned. That left open the possibility of making what was known as a "skeleton key", one which had the lowest hump possible in each of the critical positions. It would never hit the template on any lock, so it could always open them. That was a problem.

The solution was to use a different mechanism. Instead of a template, each position has two rods whose lengths add up to a constant sum. The upper rod is always the same length as the hump on the key it is intended to match, while the lower rod is the inverse length. When the proper key is inserted, this pushes the rods up, and the sum of the key and lower rod in each location is a constant. This pushes the upper rods into the lock while leaving the lower rods in the barrel, and the barrel can turn. If a wrong key is inserted, at least one rod will either rise too high (in which case the lower rod will lock the barrel in place and prevent it from rotating) or not high enough (in which case an upper rod will do the same thing). A skeleton key isn't possible; it would be too short and all the upper rods would block rotation.

So how do they make a master key? It works out that the locks actually have three rods in them instead of two for each bump on the key. One division matches the master key, the other the local key intended for just this lock. Of course, this means that if someone can actually extract a lock barrel and take it apart, they can figure out what the master key looks like and fabricate their own. Nothing is perfect. (It's been done, too; that's why most secure areas these days use electronics locks, such as card-keys, instead.)

Someone in Congress had the bright idea, now abandoned, of doing the same with crypto. They would require by law that all crypto not only work with a key (new meaning) designated by the user and presumably secret, but also with a closely-guarded master key. No matter what key the user used to encrypt, it would always be possible to decrypt with the master key. The only way to do that I can conceive of would be to encrypt twice: once with the user's key and in parallel with the master key on a separate copy of the clear; then store the two encrypted copies in the output file. Thus encryption would double the size. To decrypt with the user's key, one copy would be used; to decrypt with the master key the other would be used. I don't know how mathematically a cipher could be made so that a single copy could be decrypted by two different keys not related to each other.

The problem with this idea is that it is extremely fragile. If anyone ever leaks that master key, all the data stored everywhere with that particular cipher product is instantly open to anyone who gets hold of it. All it would take is one guy posting it to a usenet user group or putting it onto a chat room, and it would be all over the world in days, and people who had been using that cipher to protect their data would find that their armor plate had turned to wet tissue paper. I do not believe that anyone will willingly take that risk.

Another problem with it is that it could be defeated. It would be possible for someone to build a pair of hack programs. The first one takes the output of the encryption program and removes from it the copy using the master key, thus reducing the size of the file by 50%. To decrypt again, the other program would be used with would stuff 0's (or something else) into all the appropriate place so as to recreates a double-length file prior to being sent through the program. Presumably this wouldn't be as difficult as just taking the first half of the file, but however the two copies are processed into the final encrypted file, the code that did it would be in the product and could be reverse engineered.

The worst problem, though, is simply that strong encryption without all this crap is already readily available, and even if it weren't it could be implemented by any competent programmer in a week or less. It's just not that hard to do. So if the risks and expense associated with using products like this became too onerous, people would bypass it and use their own, defeating the point. I'm really glad they gave up on this; like most of the legislative ideas about crypto in recent years, it was extremely ill conceived. No matter how much the US government would like to control strong crypto, that is no longer within its capability. It hasn't been for at least ten years. (discussion in progress)

Update: I completely missed a different way to do it which actually is very practical. David enlightened me. (Thanks!)