Encryption Market Opening Up
MeriaDuck writes "Found this article on Cryptome,
the Clinton administration plans to announce next week that it
will permit U.S. software companies to sell their most sophisticated encryption systems to countries in the European Union without any licensing or review." Well its a start anyway.
Cypherpunks and others predicted many years ago
that the government would slowly relinquish
control over crypto as more and more of a commercial market developed.
PGP was never much more than a curiosity -- no
one used it for large-scale commerce systems,
and most of the users could be pointed to by
the government as privacy nuts or criminals.
SSL, despite inherent weaknesses, has made
crypto essential in e-commerce. The e-commerce
lobby (sites, vendors, end-users) exposed the
masses to crypto, and now depends upon crypto.
When users started demanding 40 or 128bit crypto
to keep their credit card numbers secure, that's
when crypto became widely deployed.
The next step is building crypto into the very
fabric of the Internet, in IPsec, and then making
that a "checklist item" for purchasing decisions.
Once people are only willing to buy products with
security designed in, the government will have
little choice but to allow its widespread use and
export.
(I'm waiting for encrypted cellphones, like
those being designed by Starium, to
be available...)
What I'm waiting for is them to open up restrictions enough to let these guys get their patches added to the main linux kernel tree. I think it's a shame that linux is lagging behind OpenBSD due to our country's legal hangups over crypto. This is good news.. I just hope it's enough.
Yes, I have read Shor's paper and the papaers about quantum secure communication.
But my point was altogether different. The so-called "software experts" were teorizing about the decryption possibilities of a future computer architecture without taking into account the encryption possibilities of the same architecture.
Louis Freeh was never able to show that if the Unite States blocked all its encryption products from export, that this would result in terrorists being unable to get that encryption. His agenda was pure fantasy.
And these things are entirely possible to no less a degree even with a total ban on all export restrictions. But take a look and his reference to "fairly unsophisticated operators". That description sure sounds to me like it also fits script kiddies. With his logic, we should suspend free speech to stop such crime. Better yet, suspend the whole US Constitution. That is what many in the upper levels of law enforcement actually want.
Or, make new encryption systems which would have no hope of ever being broken.
If he acquired this technology by means of encryption exported from the USA, then it might give the FBI some level of credibility here. If he did, but could have just as easily acquired it from somewhere else, that credibility is just shot back down. In fact, he was actually in the United States, and could have easily acquired the technology domestically. The only argument the FBI could logically derive from these events is that all encryption must be suppressed by all governments, and a massive world wide search conducted to expunge every bit of it from every corporation and individual on the planet. And we know how easily they could accomplish that. They probably know, too, so I wonder what their real agenda was, other than to just stir up emotions.
It remains to be seen just what level of bureaucracy will be imposed on this export. The article says "sell". Does that mean we don't get to give it away (in reference to what is already legally free)? Just how much will we be required to put people through to let them download strong encryption software? Will we be able to contribute source code to crypto projects located outside the US?
I suggest that the State Department provide a list of IP addresses which they want download refused for, and no more than that. It should be possible to get the addresses connecting "Cuba, Iran, Iraq, North Korea and others considered America's foes". This is sufficiently practical to manage and can be smoothly automated. Any more than that and I will certainly see it as excessive government interference in the private sector.
now we need to go OSS in diesel cars
Who needs to sell encryption technology when we have OpenBSD?
We've all heard of the nastiness with people snooping around our hard drives.. Since automated bootup's are important, I don't think it's practical to require a password JUST to decrypt stuff to start up the machine. Even if users can use encrypted loopback filesystems to encrypt stuff, there are other places where stuff can hide.
Here's what I'd like for linux:
Encrypted swap file. It doesn't get cleaned out regularily, there's no easy way TO clean it out, and it's something you can easily miss. As an alternative, clean it on boot and slowly overwrite unused pages. (Say, nuke one free page every X seconds.) Or encrypt and overwrite, to make things harder to backtrace.
Secure delete. Have the ability to secure-delete files, on a per-file or per-partitian basis. (I'd nominate '/var' for this.) Or, have a way to slowly run through free harddrive space and nuke anything sitting there. Best yet, have both.
Secure storage of old logfiles. Logfiles can be a goldmine, squid, httpd, mail, process accounting, lastlog, etc. You want to save them around, but you don't want anyone nosey to be able to look at them. How about secure deleting them and then running them through a user-chosen PGP key for storage, or making several different archival backups on different PGP key's. That way, I can keep the last week's logs on my pgp key, and secure-delete them after a week, while keeping the archival logs on a PGP key that isn't even physically located near the computer. (In a bank, or a friends house.)
Encrypted
None of these require a non-automatic bootup.
For semi-important stuff that you don't want people to look at easily (shell history, other history, email), you can store it in an automatically-generated encrypted file. Each file is encrypted with a seperate key. The inode stores the file-key XOR'ed with a user-key, a group-key, a root-key and an 'any-key'. Having a root-key on every file means that the contents can be compromised if root's password is compromised. This isn't much of a problem because any really important files can be in an encrypted partitian. Leaving it out doesn't buy you much either.
The group-key is stored in
This type of encryption is a good choice for something like ~/.bash_history, or ~/.ssh, or ~/.pgp. The 'any-key' is a the plaintext key, it exists if the file is readable to the public, It also must exist for any encrypted file that's required for bootup. (such file may be phsyically encrypted, but must be logically plaintext). All files are subject to normal access permission, and the above keys are altered appropriately and automatically on a chmod.
As we still want to retain automatic boot, some files must remain physically unencrypted, or logically unencrypted. (encrypted with a key, but a key that's stored unencrypted on the drive.) log files in
Unless I'm mistaken, the above, or a variant of the above won't prevent automatic booting. Also, it doesn't require anything extra from user-level code and it'll keep even very nosey people away.
Finally, you have encrypted filesystems. Real encrypted filesystems that are mounted manually by the user. These could be immune from everything but a hardware sniffer, or a root sniffer.
Personally, I can't wait to see some or all of these.. First priorty for me is encrypted swap file, secure deletion, and secure storeage of old logfiles. There is already a (hackish) implementation of encrypted filesystems. With that, you can hack an encrypted
Scene: Linux Expo, Andover Booth, Rob and the gang are playing Diablo 2 on their win2k boxes.
Rob"Guys, go to tux screensaver here comes some SlashBots!!!"
All hit their hotkeys. Up comes Joe Slashbot, With a CD full of Slashcode, looking for an autograph.
Joe"Hey guys, uhh remember me? I uhh, like posted that +5 insigtful comment about why Microsoft will never be as cool as Linux?"
Rob"Yeah sure right uh huh."
Joe"Yeah my karma is up over thirty now, and I have the +1 bonus!! Now everyone can see what I right!!
Rob and company nod and smile, and begin to crack jokes as the Slashbot wanders off. Once he is safely out of range Rob goes back to checking his E*Trade account, and the rest go right back to Diablo 2.
End Scene
There's zero chance that I'd trust the U.S. companies to have not made deals with the NSA/FBI/CIA triad, especially if they've been exporting crypto even before the relaxation of export restrictions. It was common practice for the NSA to send a man around to U.S. crypto vendors hinting that if they'd make a few changes to the code here, or alter the S-Box there, they'd get an export license for their 128-bit etc. product.
Granted, there are a few noteworthy cases of the U.S. tainting foreign crypto vendors, like the Crypto AG fiasco in which the Swiss(?) firm inserted a back door which allowed the U.S. access to messages encrypted with their very, very expensive hardware crypto devices. But I'd still trust a European vendor over an American one, though these days the important thing is having access to the source code.
For example, why use a PGP binary provided by Network Associates when you could either download the full-strength PGPi version from overseas, or better yet if you actually know your code you could dload the source and compile it yourself. Getting a binary from an American company just adds one more layer of uncertainty to the mix.
My favorite product for disk encryption is a perfect example. There are many American companies which offer encryption utilities, but why use one of those when I can download Scramdisk from www.scramdisk.clara.net along with the source code? It isn't GPL, but the source is still available for inspection and for personal use. Scramdisk comes from Britain, whose own crypto regulations are getting insane, but still Britain doesn't have the same long tradition of sabotaging their own domestically produced crypto products, as well as international ones, that the U.S. does.
Buying U.S. crypto, unless you have access to the source code and the skills to verify it, is just asking for trouble.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*