Slashdot Mirror
Rumors of Liberalized US Crypto Policy
GoBears writes "A "high-placed" AC within the federal government leaked the news. The Merc says: Exporters of the strongest encryption products, which generally have keys of 128 bits or more, will no longer need to license each shipment. Instead, they will in most instances only need to have a one-time technical review of the product. " At least its a step in the right direction. Of course,
the real end is no restrictions on any kind of software, but we can dream, right?
To reduce government control over--and involvement with--the export of software would be a step towards Libertarianism, not Liberalism. As someone who tries to occupy both camps at the same time, I'd argue that there's a powerful distinction.
;) Freedom and Fairness are not always congruent.
A Liberal move would be more along the lines of "A PGP install on every desktop in America!"
http://slashdot.org/comments.pl?sid=nomic
Like has been noted, this is a concession to the high tech industry, because they have money and have been up their playing the Washington game. It is evidence that the current regime is willing to heed to corruption from sources other than its own departments of love, but not much more than that.
Government by balanced corruption. How about it?
Does this mean that efforts like GPG will be able to accept American developers? Does it mean that we will no longer need to have two versions of every browser? And does this mean that Linus can start including crypographic features in the kernel?
As long as the American regime is still pushing crytography as something that will let evil terrophiles reign free, I wouldn't hold my breath.
-
This isn't a move towards liberalisation; it's simply an (admittedly rare) concession to reality.
The G4 is officially classed as 'munitions', and if the US has any pretentions at all towards an electronic economy, it's got to do this. I don't imagine it was done with any zeal on the part of the government.
This only seems to be an improvement at first gloss. It'll make it easier for companies to distribute products with strong encryption once they've passed a technical review. However consider the technical review itself for a minute. Will the government be using experts to ensure that the underlying cryptological techniques are sound and that the implementation is sound? A more likely scenario is that the technical review will center more around required backdoors or weaknesses so that the government can get in if they deem it necessary. The end result isn't easy export of strong encryption, the end result is easy export of "strong" encryption.
How does this apply to open source products? What If a company decides to export open source software as part of their product? Will this one check apply to all instances of export for a given product?
Please, explain more, as I have never dealt with export controls before, but it's EXTREMELY interesting..
-- I'm the root of all that's evil, but you can call me cookie..
No. I would imagine that the technical review would be there in order that the US Government keeps its regulatory powers there, on a sort of "use it or lose it" basis. That way, if they decide to change the regime back again, they wouldn't need to establish new powers.
Also, the technical review lets them see exactly what the non-government sector has, and to keep track of how far ahead of the envelope the NSA is. The US encryption law is a lousy thing, but I would not waste energy on constructing a conspiracy theory around the technical review. This reminds me too much of the "back door" into DES which turned out not to be there. (Everyone thought that the NSA was being cagey about the reasons for the form of the DES s-boxes in order to protect a bank door; in fact they were not giving details because DES was optimised against a kind of cryptanalysis which wasn't in the public domain).
On a related point, I think there's an inconsistency in this post. If the NSA can spot "back doors" in commonly available packages, and if that were the reason they wanted to check new packages, then it would not be true that strong encryption was out of the bag.
jsm
I found this quote *really* interesting...
The timing of the announcement is fortuitous for Vice President Al Gore, who is scheduled to be in Los Altos on Friday to raise funds for his presidential bid. A year ago, Gore promised to redraft the administration's encryption policy and is widely credited with spearheading the effort.
Hmmmm. Call me paranoid and cynical, but here is what I see:
1. Al Gore, after "inventing" the Internet, declares he was the one to free crypto from its shackles. Much rejoicing ensues. He is able to use this pending legislation to rake in the Corporate money into his "war chest" and makes his election as "Top Dog of the USA" that much easier.
2. Meanwhile, a draft bill is presented to Congress to authorize Crypto export. Conveniently, some representative proposes this (controversial) bill to be examined later on -- say, right after the 2000 presidential election.
3. A short while after the election, some idiot declares that this law cannot be accepted and has to be repelled. Which is what happens after much discussion behind closed doors with the US intelligence community (read: CIA/FBI/NSA).
4. Al Gore, from behind the Great Seal of the President of the United States, puts the blame squarely on Congress. Why should he care anyway? The guy has got the job he wanted.
Remember: this is the same administration that prosecuted Phil Zimmermann for PGP, let Congress pass the CDA and offered the NSA Clipper chip as the ultimate in personal security and encryption.
Just my US$0.02...
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
> opposed to software implementations because they did not believe
> that any software encryption solution was secure.
True. And correct - even today, if you can fab DES chips and place them into DES gadgets, ideally in tamper-resistant packaging, you can be more confident of the security of your implementation than a guy with a DES-in-bits-of-magnetic-flux computer. It's a lot harder to replace a chip than it is to install a trojan on a target machine :)
> Every intervention of the NSA of which I am aware has had the effect of
> making a product more secure, not less.
Amen. The strengthening of DES against differential attacks is probably just the best--known example. Just because NSA's hat isn't lily-white doesn't mean it's black. At the time of the strengthening, a strong DES was a Very Good Thing for national security.
Truth be known - and I'm still not saying that I'd trust NSA as far as I could throw it - I'd trust them before I'd trust the FBI. NSA's actions are consistent with the use of SIGINT for national security. Compare the number of times NSA has played the "drug dealers, pedophiles, and terrorists" card with the number of times we've heard it coming from Ms. Reno and Mr. Freeh.
IMHO part of this is likely cultural - NSA knows it's got better things to do with its time than invade your privacy. Any harm done to your privacy from NSA is simply collateral damage as it carries out its mission. Law enforcement, presumably since it comes from a culture in which "chasing down bad guys" is more important than "leaving the good guys alone", has yet to figure this out.
Obviously Debian cannot ship GPG as part of the base system or even on CDs. But would it be legal for the initial selection list in dselect to include gpg? I don't think gpg should be upgraded to priority Standard, but perhaps it could be included in the Mail metapackage; would this count as an encryption "hook"? There was a proposal recently to allow packages to declare which metapackage(s) they belong to; would this be a generic enough "hook" mechanism that gpg could be included in it?
Daniel
Hurry up and jump on the individualist bandwagon!
For this I'm sure I want to be an AC...
When I was at Apple, I heard a bit about the "technical review" that the NSA did on AOCE. The NSA apparently insisted that a function be inserted into the key generation. My understanding is that the function reduced the keyspace from 2^64 to about 2^40, though the keys remained 64 bits in length. The function also avoided classes of keys known to be weak. I have to believe that there are more than 2^40 strong keys in that space.
So, while in some sense strengthening the product - by avoiding weak keys - they also, in my opinion, enabled their ability to decrypt communication.
Now, I never knew what the function was - I really don't want to know - but I doubt that it would take more than a few weeks for an attacker with MacNosy to find the function in AOCE.
Do you think that other "technical reviews" are significantly different? Lets hear from someone directly involved in one.
The kind of technical review they're referring to already happens during a license request under the current rules. If it didn't we could all be exporting strong crypto and lying to the government about its strength.
There's no reason to believe they'd be any more likely to coerce companies into including backdoors than they are now. The real news is that they're proposing to allow companies to go through the process less frequently. This means the companies waste less money and aren't as late in getting their products to market.
/* The beatings will continue until morale improves. */
Maybe, but there's no reason why that same governement in North Korea can't buy or construct similar software without having to steal it from the US - given enough time and resources, of course.
That's the whole problem with US encryption export restrictions; anything that can be thought of or manufactured in the US of A, can also be thought of or manufactured anywhere else in the world (well, technically speaking anyway). While the US governement was vigilantly trying to protect its technology, the rest of the world was simply playing catch-up. Now that non-US companies are freely selling and exporting encryption products of similar or identical strength as their American counterparts to anywhere in the world, US companies are finding themselves crippled by the very laws that were meant to protect them.
Hee-hee. Dying tickles!
Perhaps this is a side issue, but are you sure about wanting _no_
export controlls on software? If so, I hear there's a government
in North Korea itching to buy some atomic bomb simulation
software for their weapons research programme.
We may justifiably complain when our governments are over-zealous,
but they don't make these rules purely to screw over Joe Citizen.
Simon Hibbs
My understanding of the NSA's position re. DES was that they were opposed to software implementations because they did not believe that any software encryption solution was secure. Indeed, this is still the official line -- check out the Data Encryption Standard and you'll find that it specifies only hardware implementations are compliant.
I don't think the standard could have been published at all without giving away the algorithm; I don't see how releasing DES in "non-algorithm form" could have been done. This "NSA wanted to sit on DES" thing is acquiring the status of an urban myth.
I'm quite prepared to believe that the NSA are black hats, and that they have all sorts of back doors into things. But their public behaviour has not given much support to this view. Every intervention of the NSA of which I am aware has had the effect of making a product more secure, not less.
Which seems right to me. Although encryption can be used by terrorists etc, it would be a poor intelligence organisation indeed which depended on broken signals for its information. The major use of encryption is commercial. And the damage which might be caused by not being able to intercept an email is absolutely nothing compared to the damage to the USA which might be caused by allowing the Bank of America and Citicorp to use an insecure encryption system for their transactions.
I wouldn't rule conspiracy theories out entirely, but I am currently not convinced.
jsm