Slashdot Mirror
How Would Crypto Back Doors Work?
frantzdb writes "We've been hearing about adding crypto back doors for the govement to snoop on us, but how would they work? Would there be one key that could be cracked opening up all such traffic? Also, how would/does the government know wether a bitstream is random bits, or encrypted data?"
I?d assume that one of the ideas would be to revive the idea of key escrow. All generated keys would have to be ?registered with the state.?
I can?t wait until I can purchase a ?You?ll get my 1024 bit private key when you pry it out of my cold, dead Palm? bumper sticker.
Steven Levy's excellent book "Crypto", which was reviewed here a few months back has the basic gist of the technology. As the technology is mired in classified work and patents, it's a minefield that will have to be carefully traversed
If god had intended you to be naked, you would have been born that way.
Crypto backdoors sound good, but in reality they won't help at all. The biggest part of the problem, as you pointed out, is just figuring out what is encrypted and what isn't. According to this article, the hijackers were sending each other unecrypted emails. If they couldn't even intercept unencrypted messages, how do they think backdoors will help?
One basic assumption of crypto backdoors is that people will actually use crypto that has the backdoor capability. Its like trying to limit encryption to 128 bits or 4096 bits or whatever it is these days. You can just write your own encryption program (or download & hack the source to some existing program) and create 65536 bit encryption if you want. Sure, its illegal, but if you don't want the feds to find out about your nefarious plans, so what?
Believe me, we can expect a lot more stupid, reactionary legislation in the coming weeks & months (am I the only one who doesn't feel any safer knowing that the guy on the plane next to me doesn't have his Bic disposable razors????). Thank god we haven't locked up all the Arab-Americans because they could be terrorists...
---- I made the Kessel Run in under 11 parsecs.
The government has already done a lot of research into the area, and pretty much implemented a whole key-escrow system. Nobody used it and as a result it was a flop. To be honest, I don't know how much of the supporting infrastructure was actually deployed.
The basics of Clipper worked like this. The system was based on hardware encryption chips which implemented the protocol. No software versions existed AFAIK for obvious reasons. Each and every chip had a unique ID and "unit key". Each encrypted transmission had a Law Enforcement Access Field (or LEAF) prepended to it. The LEAF consisted primarily of the current session key encrypted with the unit key of the sending chip and it's ID number. I believe the whole LEAF was then encrypted with a single key shared by all chips.
On the law enforcement end, the DoJ was supposed to maintain a database of all the chip ID / unit keys. There was lots of fancy promises made about the security of the database, and how it would be split it two so that two separate agencies would have to cooperate in order to gain access to the database, etc. All very feel good but in the end un-auditable and basically BS since the regulations guaranteed that there would be no penalty for improper access to the keys.
Anyway, the LEAF field in combination with the database allows access to the session key and hence the plaintext of any message.
The whole scheme has so many problems it's not even funny. Not the least of which are: the whole protocol has to be keep top secret. If you know how to generate a legitimate LEAF field, you know how to generate a bogus LEAF field too. An AT&T researcher published a paper about how to get two Clipper chips to talk to each other with bogus LEAF fields. It took a fair amount of trying to get random LEAF's which had valid checksums, but it was quite doable. Presumably, they won't repeat that mistake. Software implementations are pretty much verboten, since they are far too easy to reverse engineer or tamper with. If you are trying to mandate back-doored encryption, you would pretty much just mandate that all encryption be performed using NSA designed and approved chips manufactured by a secure contractor.
As to what stops you from sending random data, one need only imagine the governments response when they detect that you are sending random data. Such random data would be presumed to be illegally encrypted data, and you would be arrested as such. It's quite possible that you would be freed once you had shown that the data was random. In the mean time, your face would be plastered on the front page of the paper as a "suspected terrorist". You might expect to be held without bail due to the extreme danger a suspected terrorist poses to society. The draconian penalties involved will serve to keep people in check, not any technical ability. Look at the penalties handed down for DMCA violations. Then compare the severity of pirating a movie versus flying an airliner into a building. Finally, scale the DMCA penalties accordingly. You can imagine the outcome.
If a normal guy like me can come up with these, you know that scary, insidious, Terrorist types are lightyears ahead:
1. Use existing crypto programs or write your own. Anyone with access to a high-level math textbook or a book on encryption and a little bit of coding experience can currently write crypto that is brute-forceable only by supercomputers. The same is true of the existing versions of PGP and other crypto programs available world-wide.
2. Steganography. Apps exist world-wide that will hide plain or crypted data in all sorts of things. Images, MP3's, Spam Mail, etc...
3. Use non government-controlled chanels to transmit data. Sneaker-net, by definition, is uncrackable without a spy in the house. No technology currently allows LEO's to read a CD without first placing it in a drive. This may not be far off, but it's still effective, so far as I know. Also, most phone companies can be persuaded to install 'burglar alarm' circuits that are just non-powered plain copper that between any two given locations.
4. XOR Crypted data in a manner so that if decrypted without first XORing it back, it will decrypt into useless, but not random information. I'm not a coder, but I can imagine that some talented hacker somewhere could come up with a scheme of encoding a crypted message so that it decrypted as Mom's cookie recipe if you didn't decode it properly.
5. For communications in which anonymity is more important than secrecy, use existing file-sharing networks to propogate messages. Freenet is the best example of this.
6. Transmit textual data in non-standard image formats. Ascii text is easy to detect. A compressed PNG of text data would be much more difficult to detect, especially by automated methods. A compressed or reencrypted raw bitmap would be even more difficult to detect. Existing image scanning programs work by scanning for a predertimined signature. Making images of text so that there is no signature possible is fairly easy in photoshop.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
The problem here is that this system-wide key now becomes the sweet one-stop-shopping target for crackers that the whole escrow system seeks to avoid.
-- MarkusQ
Thus the primary purpose of the proposed legislation is not to allow law-enforcement personnel to read terrorists' communications -- terrorists will continue to use unreadable, strong cryptography -- but rather to narrow the search space that law-enforcement personnel must examine when hunting for suspected criminals. One would presume that if a person were discovered to have used unapproved cryptography, such evidence alone would be sufficient to obtain warrants for full searches, wire-tapping, keyboard recording, and the like, and those additional measures would likely yield hard evidence of any additional illegal activities. Thus it is not necessary to decrypt the criminals' messages: The illegally encrypted messages alone are sufficient to reveal suspects, and then old-fashioned investigative methods are likely to be effective.
Of course, the effectiveness of this law-enforcement technique depends on having a practical and enforceable definition of "unapproved cryptography". The problem for law-enforcement personnel -- and law-abiding citizens who wish to protect their legitimate secrets -- thus becomes determining what constitutes an illegally encrypted message. It is well known that a message that has been encrypted with a one-time-pad cannot be distinguished from a string of random bits. Should the government also make access to true randomness illegal so that any string of bits that seems sufficiently random can be assumed to be an illegally encrypted message? Further, is it realistic to believe that covert channels and steganography are detectable?
If not, how will law-enforcement personnel detect illegally encrypted messages? And what if they can't? In that case, what real security have we citizens purchased by sacrificing our liberties?
Those are the questions I want my government to answer. Until they are answered -- and hard evidence provided to support the answers -- I must remain sceptical.
Easy, automatic testing for Perl.
"Honest citizens don't send random data around". So if it looks random, has no compression headers, it is encrypted. Obviously, this reasoning is utterly flawed, but I'm sure at least some law enforcer will make it.