Slashdot Mirror
More New Crypto Rules (UPDATED)
Carl Brewer writes "Looks like the US is finally opening the gates." ...with this announcement from the Department of Commerce. Well, if you believe the draft of the new rules, supposedly just about anything will be okay to publish, including source code. Me, I keep thinking about Lucy, Charlie Brown, and the football, but maybe I'm just a cynic. Update: 01/13 13:40 by michael : The ACLU, EFF, and EPIC have put out a press release describing their reactions to the new rules. They still have plenty of problems with the U.S. export regulations.
1DeepThought wrote:
You all seem to think that the United States is the only place anyone can get full strenght ecryption.
Of course we don't think that. We do think that there is a lot of software, particularly Free software that is developed and exported from the US, or with the assistance of US citizens, that can benefit from having strong encryption built in, Linux and Mozilla being some of the more obvious examples. The current export regulations don't allow for that, they don't even allow for encryption hooks being put in place so a European or Australian can do a plugin piece of crypto.
----
----
Open mind, insert foot.
I, too, saw the many references to 64-bit symmetric/1024-bit RSA products. (There is a clause in there somewhere that mentions 1024-bit RSA as being possible to export with a licence). So it appears that this is still not the liberalization we need. While 1024-bit RSA is strong enough for today, most modern symmetric algorithms are 128 bit algorithms. Thus most modern cryptographic software would still be illegal to export, if I'm reading this mass of verbiage correctly.
-E
Send mail here if you want to reach me.
-E
Send mail here if you want to reach me.
It looks like someone in Washington is starting to realize the value of an open-sourced crypto. I wonder what made them think to include special considerations for OSS.
Considering all the recent press being accorded to Linux and friends (there's been some trial in which it's been mentioned as competition to the largest company ever, as I recall, not real firm on the details...) I'm not surprised at all. Not EVERYONE in Washington is clueless.
It's also worth noting that these rules are only in effect for 120 days, and will probably at least slightly revised at that time. If anybody reading this has any say in the matter, perhaps addressing the issue of derivative open source works -- at least in the associated documentation -- would be nice. i.e., what do I have to do if I want to contribute crypto code to my favorite os (OpenBSD, that is...).
All in all, a very positive step. Yay.
Under this rule, code released under the BSD or MIT X license would clearly be OK. But what if the code is licensed under the GPL? Because the GPL sets forth a specific quid pro quo for developers who wish to use the code (to wit: the developer must reveal his own source code and give away his work), it would not be exportable under this rule. This would actually be a good thing, since it would discourage the use of the GPL -- a license whose express purpose is to hurt commercial developers. But some of the GPL "faithful" would doubtless not like it.
Not true. The clause you cite CLEARLY states only "payment of a licensing fee... royalty...commercial production or sale". The GPL's restrictions would not trigger this clause.
This is simply not true. Under no circumstances can you sell binaries derived from GPLed code and not make source available for those binaries. While this makes GPL derivatives less attractive commercial products perhaps, it is does not make them impossible. In many cases the GPL derived portions can be compartmentalized so that only a small amount of code is forced to be released. And in many cases release of source code does not mean a commercial entity can't make money. In any case, in no circumstances are royalties or any payments required unless the commercial entity chooses to licence the code seperately from the copyright holder(s) in order to release a PROPRIETARY product (or at least not GPL compatible product), in which case the code is obviously no longer GPLed.
So in the eyes of this regulation, I believe that GPL and BSD code is equally kosher. As to your point that licencing your code essentially as public domain is better for commercial developers, I have no doubt that it is for some, and I have no arguments against coders who do so. In the case of cryptographic code, I believe users should demand open source, at least to the point of source being available and patchable for the users own benefit. Both the GPL and BSD as well as many more restrictive licences should satisfy the user in this case. A second best from the user's point of view is an open source library that can be relinked into the application. BSD or LGPL libraries are both good for this purpose. Third best (what you are suggesting) is a tightly linked library of open source code that is standard but not replacable by the user. BSD allows this, GPL does not.
If you believe that proprietary code is valuable, a situation in which no one gets to even see the code without restrictive licensing agreements, surely you can agree that the GPL is at least as valuable. Yes there is a quid pro quo, and no I don't define what the GPL protects as "free" in an absolute sense. The BSD license offers to give freedom to all coders who make a first generation derivative but therefore can make no gaurantees about further generations of derivatives. The GPL offers to give freedom to all users of all generations of derivative code but therefore can not give coders complete freedom.
So if you are keeping score, I believe that you are wrong about the cryptographic regulations being anti-GPL due to a misreading of the GPL itself. I believe that BSD is a reasonable license and have no reason to fault people who use it, but I think that GPL is also a reasonable license and that it and the LGPL are fine licenses for cryptographic work.
--
"L'IT c'est moi!"
As I see it, either one of two things has happened.:
Either way, doesn't look like we have a choice. Might as well keep using it...
This is rather odd. It seems to tilt the balance in favour of Open Source implementations. Proprietary closed source implementations are limited to a maximum of 64 bit key length. As a lot of people know this is weak encryption for a lot of applications.
I don't see any such restriction for Open Source though. As long as the code "isn't subject to an express agreement for the payment of a licensing fee or royalty for for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU."
The without review portion is important. I fully expect that even with the constraint of 64 bit key length that certain three letter acronyms will require some sort of back door. Either explicity or by insertion of weakness into the algorithms.
"Review and classification are not required for foreign made products using this source code." This is important as well, not only can it be exported but foreigners can use this code in their products.
There is a gotcha however. Once this free code is compiled into a commercial binary it would seem to fall under clause 2, which would indicate a 64 bit key length restriction. This is pretty easy to fix though, at least for a commercially packaged Linux. Distribute software with hooks that can make use of the encryption software but at the same time don't distribute binary implementations of the Open Source encryption code. Do however provide the source code. As part of the installation process a compile takes place and compiles the source code (remember, there are no restrictions on exporting source code as long as there is no requirement for fees), moves the shared library into its proper location and voila, you've got strong encryption without ever having shipped a binary.
The other option is to have an overseas finishing/distributor operation, ship them the distribution sans encryption binaries. They build the binaries, build the non-US package and handle overseas distribution.
The goal of export restrictions is to prevent ignorant law abiding citizens from getting good cryptography. Let's face it, the NSA isn't stupid. They know they can't spy on criminals(*), who can get good cryptography software regardless of the law. They know they can't spy on geeks, who also know how to get good cryptography. By process of elimination, the only people left who can be affected by crypto restrictions are law abiding non-geeks.
Why does the government want to keep crypto away from the unwashed masses? My guess is that if Microsoft can make encrypted communications (say, IPsec) the default in Windows, the government would have nothing left to spy on. Your guess is as good as mine. But the important point is that you shouldn't be deceived as to the intended target of the crypto restrictions. No matter how much the FBI screams about terrorist threats, the real target is the average law-abiding American.
(*) I am assuming the NSA can't break good cryptography. If they actually can break good cryptography, then they probably don't really care about crypto restrictions except insofar as the restrictions deceive outsiders about the NSA's cracking ability. But you can drive yourself in circles this way.
Even if the algorithms used in CSS were perfect in every way, it would never have worked.
I was going to have a go at explaining why but it turns out Bruce Schneier has already written a wonderful explanation, so I'll just quote him.
Those that want full crypto have it. Those that aren't bothered are not interested in whether or not they loosen the restrictions a bit or not.
Full crypto is available world wide and anything less than the total removal of all restrictions is a waste of breath. A lot of time and money will be spent on discussing whether or not to relax the restrictions a bit, but those outside the US that want full crypto will just go elsewhere and get full crypto.
I think that it is more relevant to look at what these gov. guys are thinking. Do they honestly believe that the Arabs don't have full crypto just because they say so? Are they really that dumb? and if so, why are they getting paid so much if they are that stupid?
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
On the other hand maybe RedHat likes being able to charge more to have you order their Commerce Servers direct from them :-)
This is more for licensing the use of RSA-patented algorithms in the commerce server package. $149 buys you a license to use the SSL server in the states.
My question is, though, when does the RSA patent expire? It's mildly ontopic..
Your Working Boy,
Who in the US is gonna have a party on 29 Sep 2000?
;)
That's when the hated RSA patent expires....
I think we should organize a giant SSL installfest on that day! Any takers?
Your Working Boy,
Thanks for the key, BrightSide, but I hope you're aware that if you make a practice of posting your key with messages to public forums, you open yourself up to spoofing attacks, where someone posts a message as you, with their own key. If you mess up your key management your 4096-bit key won't help you.
By putting a "PGP PUBLIC KEY BLOCK" in his message, isn't BrightSide just telling everyone what his public key is? How does that make him vulnerable? Unless you're completely misundersanding the way a public-key cryptosystem works, I don't see what you could be referring to. In a public-key system, someone generates a public/private key pair, and lets everybody know what the public key is, but keeps the private key secret. Then several thing are possible: anybody can encrypt a message in such a way that only the holder of the private key can decrypt it, the holder can uniquely sign a message in such a way that anyone can verify that he has done so, he can prove that he is the holder without leaking any information about the key itself, etc. The public key is no secret; hence the name. In fact, he wants the knowledge to be as ubiquitous as possible, and tagging it onto his Slashdot posts can only help with that. Basically, the public key block says two things: "Anyone wanting to send me a private message can express it numerically and raise it to the power of [X], mod [Y]", and "Anyone claiming to be me had better be prepared to prove that he knows what the factors of [X] are". In both cases, though, the "me" is only equivalent to "the person who wrote this message"; it does not prove that that person is actually ho he claims to be.
Or do you mean that, if someone compromises his Slashdot account, which is only as secure as the lesser of Slashdot's server and his e-mail account, then that person could post a message with a different key, and then impoersonate him more convincingly? I still don't see how the key helps. If they posted their own key, and later claimed to be him by using that key, he could simply deny owning that key. The spoofer could prove that he is the same person who posted the comment, but not that he is BrightSide.
Or maybe someone could post a comment anonymously, claiming "I'm BrightSide -- I forgot my Slashdot password, but this [...] is my public key. See, it's the same one I posted at http://slashdot.org/comments.pl?sid=00/01/12/2128
David Gould
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
After reading through several comments on this topic there seems to be a common thread - The goverment can't really be trusted, they must have some hidden agenda behind this announcement.
I have a different take on this. What's happened here is that the slow-moving beurocratic wheels of government are finally moving in the right direction. No, the governement is not made up entirely of men in black suits who take joy in hinding behind bushes and spying on you, or staying up late nights devising devious plans to control your computer usage.
The government is actually made up mostly of regular Joe's like you and me who have a day job to do. Do you think that there aren't men and women in the federal government who would like to see these rules revised just as much as you or I? Of course there are, and they're been advocating this for quite some time. The fact that it's finally happening doesn't require that there is a subversive mission in mind.
I think the inclussion of 'Open Source' in this announcement is a statement to how sucessful forumns like Slashdot have been in raising the issues of exporting encryption software to the world. No longer is encryption a munitions (product) to the government, but also a matter of free speech and free software.
Recall, as you might, that a few months ago the NSA reported being unable to engage in large scale monitoring of telecommunications because of the sheer number of bits travelling all over the place?
Could it be that the US government has decided to just fscking deal with the situation and not try to rebag unbagged cats?
Maybe.
Open Source software can be released "without review" but the first person to do so has to send them the URL. :-)
I can live with that restriction...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
They don't stop you or even slow you. You send an email and also put a link up. That is it.
You know, free speech also protects your right to hold a march downtown. You still have to notify the city, etc to do so.
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
For many companies, Red Hat included, it is far easier to justify "giving away the crown jewels" if you are guaranteed that your competitors won't be able to tweak them with a new feature and outsell you because they have the feature and you cannot figure out how they did it. For that reason companies that "give away the farm" feel far safer putting it under a GPL than they do a BSD license.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Forgot to say who did that (very nice) analysis.
It was Frank Hecker...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
A few weeks ago a copy of an earlier draft was sent past a mailing list I am on with a request for feedback. I couldn't make heads or tails of it and I said so, but I sent back a simple test case which I considered the minimum necessary for the relaxation to be meaningful. (My case was whether code to handle SSL could be distributed standard with Perl on the main ftp sites, allowing Perl programmers to retrieve https protected pages.)
:-)
Others on the list actually went a lot further and managed to show that with the way it was written open source could be exported only if it met a restriction which was, oh my, impossible for open source software to meet!
Well it looks like they took account those comments. The current language is unambiguous about open source being permissable, and unambiguously lets SSL modules to be put on CPAN.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
*sigh*
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
The rules say that open source software is eligible for export under "License Exception TSU", which also seems to be the exception for the think it says that you can export 128-bit-key open source software with the sole condition of sending a letter notifying the BXA of your internet address.
But, do not take my word for it -- IANAL.
I could be very wrong about this, but I tried to carefully read both the summary (the 1st link) and the actual ammendments (the 2nd link).
We Still Can't Export Crypto above 64bit symetric / 512-bit RSA
Look at the last paragraph in the summary. It concerns the Wassenaar agreement from 1998. Notice the key length restrictions.
After reading the actual proposal (which was exceedingly dense), I don't see anywhere that they indicate that restrictions on high-bit length keys are lifted.
What the proposal essentially does is allow anyone to export/re-export 56-bit symetric/512-bit RSA products without having to get an export license at all. Products that impliment up to 64-bit symetric can be exported if they are reviewed by BXA (let's face it, the NSA). You Still Can't Export 128-bit (1024-bit RSA)stuff
The one good point may be Open Source. I'm not sure how this affects Source Code exporting, as it's rather simple to change the bit-length in source code (and thus possibly run into the "key-too-long" restriction). It looks like they are going to let all source code out, but I'm not positive on that.
I hope my reading is wrong. But I'm pretty sure all they are doing is streamlining the regulations for the current situation, and not a real revamp.
Too bad.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
I doubt that many well-read people believe that. But that isn't important.
PGP and Fortify are useful programs. They are also inconsequential to the goal of putting strong, easy to use encryption on every desktop and server.
Most of the PCs in the world are running some version of Windows, which is closed software exported from the USA. They are not running OpenBSD or FreeS/WAN. That makes the US export regulations important. Unless Microsoft can put strong encryption in all of their products, not just special versions for domestic use, everyone loses.
Strong crypto needs to be included in every operating system, web browser and email program shipped by Microsoft, Apple and Netscape.
We need IPSEC and secure email with automatic key management. If it is hard to use, requires user action or needs to be patched/downloaded, it will be a failure. Strong encryption should be the default and transparent to the user.
I want a world where a user can buy a bog-standard PC from the local retailer, take it home and send strongly encrypted email to their grandmother, without having to think about it.
Mea navis aericumbens anguillis abundat
No... They realized that there are so many loopholes (exporting books and scanning them in over seas) that it was pointless to try to contain stong cryptography to just inside the US.
... up to and including 64 bits...".
But by my reading, I'm wondering something:
In the blurb about consumer retail products, it says any crypto up to 56 bits, and anything that does key exchange between 512 and 1024 bits.
In the details section (i'm not great with legalese, so bear with me...) it says "multilateraly
Source code can only be exported after review and classification. That would seem to mean that source and libraries and such can only be exported if it complies with the above rules?
Oh... now i'm at the summary:
If you could previously export products with 40 or 56 bit encryption, you can upgrade them to 64 bits, so long as you sign a letter saying that that's all you've done.
You can implement eliptic curve key exchange up to 112 bits.
You can use RSA for key exchange up to 512 bits.
Don't celebrate yet. This barely changes anything, IMO... All it really does is show what the current capabilities of the government are, I think.
From the text of the doc at http://www.cdt.org/crypto/admin/000110cryptoregs.
Returned Peace Corps IT Volunteer
If the US were to drop their crypto regulations altogether many projects would benefit -- distributions could include crypto without having to worry about whether the end-user is in the US or not, OpenBSD could ship a simpler "here's the crypto" distribution [well, I think we're all still waiting for the damn RSA patent to expire so we can get on without jumping through those hoops as well], and a large body of American programmers could actually contribute some code and peer-reviewing to the international crypto codebase. I realize to a degree this is an oversimplification (there are other countries with bad crypto policies as well, so removing USA's regulations would not be a panacea), but the world situation definitely improves without these sorts of silly barriers.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Well, as a Canadian, I'm pretty happy to see that passing this would legalize US mirrors of OpenBSD since it falls under the re-export provisions. However it looks like the OpenBSD development would continue out of Canada for some time.
:-)
If I understand this (possible) development correctly, it also would make it feasible for somebody to develop SSL support for Mozilla (as a plugin) outside the US and have it become part of the official US distribution. This would also be very good news for US-based Linux distros like RedHat since they could start including SSL support and other cryptographic support (encrypted e-mail anyone?) out of the box/FTP server.
On the other hand maybe RedHat likes being able to charge more to have you order their Commerce Servers direct from them
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
The BSDL allows commerical use of the code, right?
Well, wouldn't that trigger the "sale of any product developed using the source code" clause?
I can see that BDSL code may not "not subject to an express agreement for the payment of a licensing fee or royalty for commercial production", so it may be okay, but then GPL code is surely the same, isn't it?
I'm no licence bigot, but this kind of whining annoys me.
If you are going to start a BSD vs GPL flamewar, at least make your arguement internally consistent.
From the paper
3. Also in 740.13, to, in part, take into account the "open source" approach to software development, unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU. Intellectual property protection (e.g., copyright, patent, or trademark) would not, by itself, be construed as an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code. To qualify, exporters must notify BXA of the Internet location (e.g., URL or Internet address) or provide a copy of the source code by the time of export. These notifications are only required for the initial export; there are no notification requirements for end-users subsequently using the source code. Notification can be made by e-mail to crypt@bxa.doc.gov.
Wow, thats certanly great, I hope this does pass.
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
I also could be mistaken, but I've heard RSA allows non commercial export if you the reference library (rsaref). They would have a hard time collecting any money from these projects anyway!
from the ssleay FAQ:
"inside the USA RSA hold patents over the RSA algorithms, however if you use RSAREF (which SSLeay can link to) then non-commercial use is probably okay"
-- Virtual Windows Project
I haven't read the whole document but it looks like the commercial side of things haven't changed too much. The interesting part is that software that is "not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product" can export without review.
What is ironic about this is that :
a) The most commonly used public key algorithm is RSA which is patented by RSA. This patent is only valid in the US and the US has the strongest export. Though many countries respect US patents as well.
b) Now, open source projects will be able to export without review, but RSA will not collect any money from these projects.
c) Regulations are slowly changing, possibly by next year commercial vendors will be able to export. But in Sept 2000, RSA's patent expires and they won't be able to collect any money.
RSA really got screwed if you ask me. I'm glad their patent is expiring, but it was definately a valid one that the world has benifited from greatly.
-- Virtual Windows Project
This isn't a law. It's a regulation. Laws are passed by Congress and can only be changed by Congress. The Current law allows the Commerce Department to Issuse whatever regulations it wants to regarding Crypto. Last year Congress was moving towards changing the law and reducing the Departments power regarding Crypto. Clinton was having trouble keeping it bottled up in comitee. By changing the regulations now they avoided losing the power of setting regulations. They can change the rules again next year. Lucy (Commerce) still controlls the football. We might get to kick it today, But she can jerk it away anytime she thinks she can get away with it.
Quemadmodum gladius neminem occidit, occidentis telum est
This was *not* a troll, this was a deliberately provacative title to force people to stop and ask why they are so fast to rush to believe the content.
Think about it: why would an official announcement from a government agency use an IP address instead of a domain name? It's more secure, but only if the person knows the correct IP number. Unless you run nslookup it could have easily been posted from a cable modem.
Second, even if we accept that the web site is legitimate, why do we assume that the *content* is legitimate? The last I heard the announcement was expected a few days ago, and posting a bogus announcement a few days early would be a good way to cause confusion as the government attempts to invalidate the bogus report.
The obvious way to settle this is to call up the DoC and ask them if it's true -- but this report hit the net long after official Washington went home. More reason to be cautious.
Ironically, this is about the best proof possible for the need for relaxed export control. If the code hadn't been suppressed for so long, I would have known it was a valid DoC page because of the cryptographic signature on the content and the digital certificate of the server!
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Authority: 50 U.S.C. app. 2401 et seq.; 50 U.S.C. 1701 et seq.; E.O. 12924, 59 FR 43437, 3 CFR, 1994 Comp., p. 917; E.O. 12938, 59 FR 59099, 3 CFR, 1996 Comp. p. 219; E.O. 13026, 61 FR 58767, 3 CFR, 1996 Comp., p. 228;
Do you have sensitive data that could fall into the wrong hands? Need to restrict access to authorized users only? Has the access to information act forced you to publicly release documents that you'd prefer to keep hidden? Well, your worries are over!
NEW! Security Through Obscurity: legalese edition.
Keeping peons out of the legal process.
Drinking will help us plan!
The same argument applies to DeCSS. The DVD consortium's crypto gaffes made life easier for the authors from DeCSS, by my impression from the discussion surrounding the event was that it would have happened eventually anyhow because the DVD player itself has to contain all the information necessary to decrypt a disk. (The tacit assumption is that truly tamper-proof hardware is impossible, but for software even that is not an issue.)
-r
The encryption export controls were intended to increase national security, by enabling the NSA to continue to intercept and decode foreign traffic.
They have instead had the effect of decreasing national security, by preventing US citizens and corporations from hardening their information infrastructure.
Recently it has come to our government's attention that foreign governments, including many likely to become wartime enemies of the US, have set up cyber-warfare groups within their military, with the express purpose of waging offensive information warfare, including massive attacks on the US civilian information infrastructure.
Perhaps this proposal is a sign that our fearless leaders have finally sprayed themselves with clue musk and done a clue mating dance during clue mating season...
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I like the law is a little to lax, and I wonder if this isn't some sort of a ploy by the US gov't. I mean, for years, they have had very little popular support about their encryption laws, and now they draft a law that is so sweeping and reforming that even the US gov't staunchest critics go "Whoa, wait a minute, let's not get *too* crazy here". Then, with perfect honesty, the US gov't can yank the law away, and say, "Hey, we *wanted* to open the export laws up, but popular support was against us, so we dropped it because *we* *love* *our* *voters*".
That doesn't seem likely. Very few voters are even aware of cryptography, let alone the concept of export restrictions. Those who are, generally are technically savvy individuals like ourselves, who tend to oppose such regulation. Since nearly the entirety of the popular reaction to encryption limits has been from this fairly elite group, the scenario you illustrate is basically just as unlikely as the entire population of slashdot waking up tomorrow and deciding that online export freedoms are a bad thing. That is to say, very very unlikely.
But if we view the reality of the situation, we see that this has very little to do with voters. It is propelled by two forces. One apparently (and gratifyingly) is the "GnuPGP" project that essentially rendered strong crypto limits moot. The second, more important influence is from United States tech companies and their constituent option-paid workers. Many of these companies are horribly wealthy, and many of them feel annually the testing, development, and marketing pinch of producing both a high and a low version of their crypto-enabled products. These companies want restrictions dead.
If you want to pitch in your efforts by writing your congressman, I heartily recommend you elaborate to him/her the fact that your tech employer is paying through the nose because of this national policy and would be sure to see higher nets each year if this cumbersome beaurocratic nonsense went away. Better yet, I recommend getting your whole business involved in lobbying for this change, if only by means of a letter from the CEO/CIO to the appropriate lawmaker.
Congress is in the pocket of fat cats, but that doesn't mean we can't still get our way once in a while if we pull the right strings.
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
However (there's always a however)
In other words, what if strong encryption is used by TheBigCorps to prevent reverse engineering (and thus, compatibility by Open Source Software)?
Again, I'm all in favor of nuking the munitions restrictions (BTW, this is how you spoof the NSA folks, work the keywords into your message) but it could have side effects...
www.eFax.com are spammers
What section was that, I must have missed it?
I agree with you when you say that it probably doesn't mean much; what's to stop a foreign government from buying encryption downloaded from the USA by a foreign corporation?
"Don't mind me cutting myself on Occam's Razor"
What? Do you really think that the countries USA is at war with care the least bit about USA's laws? There are still hundreds of other countries they can get their crypto stuff from. USA != world.
First off, I completely understand that USA != world; I am Canadian, and none of my posts call USA *my* country (I use the term "the US" not "my US").
As for the countries "at war" with the USA; no, I don't think that they care about US laws. However, American citizens *should* care about US laws. My point was that whether American citizens will be able to export encryption software to countries (whether the destination is a private citizen, a private corporation, but not a foreign government, as Fruan pointed out).
You clear here, ViGe?
"Don't mind me cutting myself on Occam's Razor"
That doesn't seem likely. Very few voters are even aware of cryptography, let alone the concept of export restrictions. Those who are, generally are technically savvy individuals like ourselves, who tend to oppose such regulation. Since nearly the entirety of the popular reaction to encryption limits has been from this fairly elite group, the scenario you illustrate is basically just as unlikely as the entire population of slashdot waking up tomorrow and deciding that online export freedoms are a bad thing. That is to say, very very unlikely.
:)
Of course. I should have said, instead of "popular support", "any support". To me, there has been *no* support of encryption export restrictions. I agree with what you are saying, and thank you for pointing out my error.
But if we view the reality of the situation, we see that this has very little to do with voters. It is propelled by two forces. One apparently (and gratifyingly) is the "GnuPGP" project that essentially rendered strong crypto limits moot.
Not sure I agree with that point, but I am not armed with information to dispute your point. Can you back this (links to relevant documents)?
The second, more important influence is from United States tech companies and their constituent option-paid workers. Many of these companies are horribly wealthy, and many of them feel annually the testing, development, and marketing pinch of producing both a high and a low version of their crypto-enabled products. These companies want restrictions dead.
Of course, without the ability to export their products onto the international market, they are losing millions of dollars.
If you want to pitch in your efforts by writing your congressman
Can't, I am Canadian; for some dumb reason, I don't have a congressman, and none of the others with listen to me.
"Don't mind me cutting myself on Occam's Razor"
The US government does not own encryption or the minds of its citizens. The US government has no rights of control over things which are not its property or part of its legitimate functions.
:)
They think otherwise, I believe encryption falls under "munitions", which any government arguably can regulate (arguably, the government can regulate anything they want, but for clarity, we will just assume that they regulate only things they *should*).
My personal opinion on the matter is that the government should control encryption; that they have the right to because encryption, to me, falls under the same category as guns. Both can/should be used for self defense and protection(one physically, the other intellectually). Both can be misused. Both are very powerful tools and should be carefully regulated. And neither should be taken out of the hands of the people.
It is a legit function to provide for the common defense, but this is arguably not served by "controlling" encryption which really amounts to forbidding its citizens to use and/or sell encrpytion and encrypted communication and products worldwide. This does nothing to help defense.
That point is up for contention. The US military uses encryption for defense, and if said encryption is exported, that it could be exploited for a hole (we have all seen Star Wars, and know Grand Moff Tarkin's line "there is a possibility, however unlikely..."). At least, that was the arguement used to impose the restrictions on export (I believe...).
I think this is all a big smoke screen because the government snoops have the bucks and equipment to break any encryption scheme on the market with far less trouble than they wish to advertise.
Don't agree. I believe that no-one has the resources or time to read every packet on the Internet, much less crack the encryption on every packet on the Internet. That is a lost of information.
Generally, samantha, I don't agree with your arguements, but we seem to agree on the major point, and that's good enough for me
"Don't mind me cutting myself on Occam's Razor"
I, for one, am very skeptical about the documents continual use of the phrases "to all destinations" and "without additional review and classification". I mean, yes, open the flood gates, yada, yada, allow encryption for export, yada, yada. But what about countries the USA is at war with? And bluntly, by the sounds of it, this law takes away pretty much ALL of the US government's control on encryption; and traditionally, the US gov't doesn't like releasing control.
I like the law is a little to lax, and I wonder if this isn't some sort of a ploy by the US gov't. I mean, for years, they have had very little popular support about their encryption laws, and now they draft a law that is so sweeping and reforming that even the US gov't staunchest critics go "Whoa, wait a minute, let's not get *too* crazy here". Then, with perfect honesty, the US gov't can yank the law away, and say, "Hey, we *wanted* to open the export laws up, but popular support was against us, so we dropped it because *we* *love* *our* *voters*".
"Don't mind me cutting myself on Occam's Razor"
Why not email Secretary Daley, Deputy Secretary Mallett or the Office of Public Affairs and make your opinion known in a polite and respectful manner. I did!
The only people this is a major bonus for is US vendors not users around the world or at least not on the same scale.
I'd have to disagree with this part. Yes, this will benefit US vendors (or stop hurting them if you want to look at it from that angle.) Obviously a lot of software is developed in the US. Since the US companies have to jump through all sorts of hoops to include encryption without incuring the wrath of our government, they avoid it.
In other words, if it wasn't for the ridiculous encryption laws here in the US, there would be a lot more software (and hardware) with encryption included available to everyone. So, in effect, these laws have been hurting everyone by making encryption harder to get and harder to use.
By "hurting" I mean that there is a serious lack of privacy and security that is completely unnecessary. If you've ever run "ngrep" or "tcpdump" from a server with a lot of Internet packets passing by, then you probably understand the implications of not using encryption. I'd have to guess that most people haven't.
Since encryption is not just about computers and/or the Internet, I'll give a real world example. Do you use a cordless phone? Chances are that if it uses encryption it is very weak, but more likely it doesn't use it at all. I used to have a neighbor that would do nothing all day but play on his computer and listen to every un-encrypted cordless phone conversation in the apartment complex. He knew which women were cheating on their husbands, which neighbors had kinky fetishes, their personal problems, who was buying/selling drugs, and who was having pizza delivered...he could point them out and tell me just about any detail about any of them. This is a true story. No exagerration whatsoever. It makes me very uncomfortable talking on the phone, especially when I'm talking to the bank or credit card company. I need the ability to have a conversation encrypted end-to-end to feel comfortable talking on the phone about anything more personal than the weather. If US companies are freed from restrictions on encryption, this kind of technology could be widely available.
numb
Global Exports of Unrestricted Encryption Source Code
Encryption source code which is available to the public and which is not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed with the source code may be exported under a license exception without a technical review. The exporter must submit to the
Bureau of Export Administration a copy of the source code, or a written notification of its Internet location, by the time of export. Foreign products made with the unrestricted source code do not require review and classification by the U.S. Government for reexport. This license exception should apply to exports of most "open source" software.
--SolidGold
--SolidGold
Everything you know is wrong. Or more accurately, inaccurate.
SUMMARY: This rule amends the Export Administration Regulations (EAR) to allow the export and reexport of any encryption commodity or software to individuals, commercial firms, and other non-government end-users in all destinations. It also allows exports and reexports of retail encryption commodities and software to all end-users in all destinations. Post-export reporting requirements are streamlined, and changes are made to reflect amendments to the Wassenaar Arrangement. This rule implements the encryption policy announced by the White House on September 16 and will simplify U.S. encryption export rules. Restrictions on terrorist supporting states (Cuba, Iran, Iraq, Libya, North Korea, Sudan or Syria), their nationals and other sanctioned entities are not changed by this rule.
Note that there are still restrictions. Curious that you cannot export to a government user.
Enjoy.
Using your sig line to advertise for friends is lame.
Perhaps.
I think both the NSA and the government itself (though the legislature is slower to accept it because they don't UNDERSTAND it) finally realize that they actually LOST this encryption battle when Phil Zimmermann released PGP and it put military grade encryption in the hands of the masses.
The final nail in their coffin was when CLIPPER crashed and burned.
The cat has been out of the proverbial bag for 1/2 a decade and it's all just a simple matter of monolithic institutions taking a LONG time to adjust to realizations like these.
Eventually (probably sooner than later) all crypto will be freely exportable and this will be a non-issue. All the legislators need to THINK is that they CHOSE to do it, as opposed to having it rammed down their throats like actually happened, and they'll be happy. Since we all know they fear things like technology, and even though they know they actually can't control it, they need to think they can so that their egos stay adequately inflated so that they remain happy.
Ignore Alien Orders
Under this rule, code released under the BSD or MIT X license would clearly be OK. But what if the code is licensed under the GPL? Because the GPL sets forth a specific quid pro quo for developers who wish to use the code (to wit: the developer must reveal his own source code and give away his work), it would not be exportable under this rule. This would actually be a good thing, since it would discourage the use of the GPL -- a license whose express purpose is to hurt commercial developers. But some of the GPL "faithful" would doubtless not like it.
--Brett Glass
Another example is Fortify. This puts full strenght encryption back into Netscape browsers. I realise there are other reasons such as being able to share code etc but for the main part the real benefactors are only US vendors. Im fine down here in Australia with the products that are already available to me and Im sure many others around the world are.
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
Me, I keep thinking about Lucy, Charlie Brown, and the football, but maybe I'm just a cynic.
Now I'm really depressed we won't be seeing any more of Lucy, Charlie Brown, or the football. Our kids kids probably won't have even heard of Charlie Brown.
Anyway, back on topic. I think this is great news long overdue. The government really needs to try to keep their hand off of the internet. This is a self-policing non-meatspace and their troublesome meddling just hinders progress.
My favorite line Peanuts line... "Get that out of my ass, Charlie Brown!" yells Snoopy.
While the BXA consulted the computing industry in order to revise and liberalize export regulations, the UK has done the exact opposite. It appears they flat out ISPs when introducing this nasty piece of legislation, which tightens export controls and INTRODUCE EMAIL WIRE TAPPING.
As you can read, they still have to review anything before it's exported. (Which isn't any different then it is now.)
However, it does sound like they're going to make an honest attempt to loosen their grasp on the exportation of encryption. E-commerce seems to be fueling their decision, so I wouldn't be surprised if business oriented software is quickly approved, while stronger privacy type encryption software is still delayed/banned.
It relaxs the requirements.... but doesn't get rid of them.
Close but not quite huh?
Well it's a big step for the US goverment ot get this far.
A little AC who finally got a nick.