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.
I wonder if this is an indication of some technology advancement at the NSA. It seems a little too good to be true, i guess...
Wow, I must say that I impressed with the speed and efficiency in which crap-posts such as this one are moderated down, although I'm a bit disturbed too by the fact that they would be wasting as much time with it as they do though.. Chingame.
The US has traditionally been such a navel-gazer that the government has always been more worried about action against it by its citizens, rather than some external agent.
I think the NSA has found a new way to crack anything up to 128-bit (maybe 512-bit for public-key encryption).
> The requirement that you send a copy of the
> source or of its location should be quite
> trivial for any software developer to
> comply with.
And it should be quite trivial for any patriot
to see that this pathetic withering wart of a
vestigial organ known as the Occupational
Government of the United States should not be
allowed to exert this control on the citizens.
We should immediately assert our constitutional
rights both to speak freely and to keep and bear
arms.
Registering with the government before posting
your speech on a web page is an unconstitutional
and gross prior restraint of your liberties.
Just say 'no' to big brother. Take your freedom,
or die deserving none. Have we learned nothing
from the examples provided by powerful
governments in (some of) our lifetimes?
Anomalous Cowherd
Considering that every article has about 30 unmoderated troll posts, it's sad that mod points are wasted on someone with a broken shift key.
http://www.theregister.co.uk/000112 -000016.html
Kiss freedom goodbye
OMG, I never would have thought I'd see this day!
If McCain agrees with this (and I'm guessing it'll get mentioned), given his budget plan, he's got my vote no matter what else he does.
You guys are so incredibly paranoid. The US gov't is doing something we've all wanted for years. Can we wait for few months and get our facts straight before slamming them?
Uh, no. The NSA's job, contrary to all popular opinion, is not to put hundreds of people in suits behind workstations chasing *you*. They aren't out to stop encryption export. At this point it's hurting the US more than it's hurting other countries.
Okay, moderate the comment this replies to. It is blatently false.
Yes, but this guy's a wannabe first-poster. He doesn't use shift because it might slow him down.
Yes, but compiled freeware may not be exempt even now. US citizens, go to http://www.bxa.doc.gov/ and (once this shows up there) make a comment saying that the changes to 740.13 need to also cover compiled open source software.
Don't worry about it. The encryption is in the software, which means the key is in your hand. It doesn't matter how strong the encryption is, because you're reverse-engineering, not cryptanalyzing. When you reverse-engineer, you look through the code and find the key (possibly by running a quick search for high-entropy regions) and now you can break the encryption. In fact, the bigger they key, the easier it will be to find.
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.
well, actually it's the NSA's job stop the spreading of encryption technology to keep their surveiling business as easy as it is now. you're right if you say they're not "chasing" *him* or *me*, they're after all of us (at least the critical thinking ones) to asure the technological lead of the US by any means necessary (industial espionage in europe, japan, etc) and getting infos for the CIA (who do the suppressing/corrupting/killing etc.) but this is getting OT, so ... it may be a small sign of progress, that open source stuff may be distributed more easily, but whenever something like that actually passes the US "security" agencies, there's something in the bush ... so let's wait and see
Yes, DeCSS would exist. It can't be encrypted without a key being stored _somewhere_. The same is true of other static storage methods.
So what if Office strongly encrypts files ? Same issue as DeCSS. Even if the user has to enter a password, same thing.
So what if QT encrypts their stream protocol ? As long as you know what algorithms they use, all it does is stop people not on an ned of the connection listening in.
Am I missing something (the key block was marked PUBLIC), or is this nonsense?
As an analogy for crypto, this does not bode well.
He was a PAID contractor, who gave PGP to one single person, as a part of his contract.
That other person is the one who released PGP. And he's the one we should all thank. Phiz Z., in fact, had to be browbeaten and bribed to actually let go of the code, because at first he refused to fulfill what he had been paid to do.
Heh. In fact, Phil Z. was the third hired gun to do this; and the first to complete the work.
As you appear to have forgotten, there were TWO people who were hauled before the Federal Grand Jury. Phil Z. was one, and he stole all the glory; everyone else has forgotten the other person, who, IMHO, deserves the main credit for actually releasing PGP.
And no, I am not he. I just wish people would wake up and give him his due credit.
You all seem to think that the United States is the only place anyone can get full strenght ecryption.
I doubt that many people here are that uninformed. The re-import/export provisions, though, do make encryption work much more difficult since nobody in the U.S. (citizen, high-tech visitor, or company) can help any serious crypto project outside the U.S. Any project inside the U.S. is not taken as seriously.
This includes quite a few distributions, and the kernel itself. These laws are one of the main reasons why OpenBSD is in Canada, for example.
If it didn't, there would be no reason to have the International Patch since it is mainly for used to add crypto support, and those parts would be "official" instead of unofficial.
The restrictions impact everyone.
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.
-E
Send mail here if you want to reach me.
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.
Wade.
Actually the NSA has some of the most advanced natural language processing algorithms to parse the semantics of what is being discussed . . . this wouldn't trip their systems in the least. Now if you developed a pattern of talking around obtaining fissionable materials, triggering mechanisms, and delivery devices . . . expect guys in dark suits and mirrorshades.
"Flame away, I wear asbestos underwear"
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...
b) Now, open source projects will be able to export without review, but RSA will not collect any money from these projects.
I'm not sure what you mean here, I may have misinterpreted you. The way I did interpret it is that open source projects can export RSA encryption and RSA won't collect their licensing fees or royalties.
That would be incorrect. You can't export RSA from the US, Open Source or not, since RSA is protected by patent. RSA chooses to charge a fee for the use of the technology so it isn't Open Source. RSA isn't ours to export. If we did do the simple job of writing an Open Source implementation (from the US) and exporting it we would be in violation of patent infringmenet and somebody would get sued.
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.
I don't know if it'll be here, but some bill will eventually pass as the big e*.com companies start lobbying. Because stong crypto=less fraud=more $.
--
How do you keep an idiot in suspense?
Tell him the next version of Windows will be faster, more reliable, and easier to use!
Care about electronic freedom? Consider donating to the EFF!
I see 64bit can be exported but not 128bit or better. And for public keys only 512 and 1024 are allowed? This looks to be fairly pointless.
On the plus side it looks like open source can be exported unrestricted.
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);}
It get the sense that this is something exclusive to the executive branch. I don't see congress getting involved except in some oversight manner, or possibly the supreme court if someone happens to bring suit against it.
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.
In this vein, what is happening with the Cryptozilla project? The mozilla site has a link to it, but the link doesn't seem to work.
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.
Hey, don't you guys remember, the suprime court a while back declared the united states encryption laws unconstitutional (spelling?)
gee, so, this would be the new law.............
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.
Lucy, Charlie Brown, and the football!
After all those years of futility, I was really hoping the final Peanuts strip would have Charlie Brown ACTUALLY KICK THE BALL! That would have been a perfect way to end the whole show.
That's what depressed me most. I've been rooting for Chuck since...umm...196-something...
I AM, therefore I THINK!
More on MS docs being encrypted--that sends shivers down my spine. I can't count the number of times that Word at work or school has choked on a document (I had it crashing within 1 second of loading a file, repeatedly, once) that has required me to open the file up in a text editor and pick out the pieces to restructure them in a new file. If they started encrypting everything, hell. I've been threatening to do all my word processing in HTML for a while now. This would cause me to do so.
Returned Peace Corps IT Volunteer
From the text of the doc at http://www.cdt.org/crypto/admin/000110cryptoregs.
Returned Peace Corps IT Volunteer
Actually since it isn't carte blanche, I would guess the NSA reported back that they could now easily crack harder keys. Seems like this is simply a way of raising the bar to keep us happy. IMHO 64 bit keys are now as insecure as 40 bit keys were when they were first allowed to be exported. We can probably expect to see the bar raised like this every year or so.
What we really need is a one line crypto policy:
"No restrictions whatsoever on export of encryption technology".
--
Quantum Linux Laboratories - Accelerating Business with Linux
* Education
* Integration
* Support
*Condense fact from the vapor of nuance*
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'?"
No matter where you embed the key we can find it... If you further encrypt the key, we can still find it. We just need to go through another layer. Even if it isn't immediatly evident how the encryption is done, people talk. The randomness of the key will also help us to find it. Even if it is built into a chip. Chips can be reverse engineered. Obscurity just dosen't work. CSS is clear proof of that.
I looked up their page a few months back when it was still around. It looks like the project never went anywhere. They didn't really say why, but I would guess a major part of the problem was that the central distribution for Mozilla was in the US and that they couldn't redistribute crypto software (or even just leave hooks for it) without being slapped down as munitions smugglers. So even with the software being developed outside the US, it would have made a unified, integrated distribution impossible. The SSL patents wouldn't have helped.
With this change, it's rather ironic that the opposite could happen. Mozilla could now incorporate a foreign developed SSL and encryption support (support for GPG e-mail encryption anyone?) and re-export it. The ironic thing is they would still need to have a separate US distribution which would NOT include SSL support, at least until September when the RSA patent runs out. You could already add GPG support for Diffie-Helmann encryption however. Hmmm.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
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
According to his talk the plans at the time involved the following: Vendors of crypto products simply needed to submit information about the algorithms that they were using. (Typically, the marketing literature was sufficient) This is the review that the document refers to. We then asked him about open source software, and he said he was hopeful of changes to help the open source community.
From what the article says, it appears that all you have to do to post open source crypto software to the net is to send an email to an address with a link inside. Boy, now that's easy!
If you go to www.doc.gov you'll see the link to the page. Furthermore, this host (204.193.246.62) is in the same subnet as www.doc.gov(204.193.246.9).
That would be a very unlikely hack.
Also where is the 'FREE KEVIN!'?
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.
Explain how is they have flourished THANKS to the GPL. They could have done the same with the BSD license. I'd think they'd flourished DESPITE the GPL.
\w0zz - OpenBSD - A Better Solution
Well, IIRC some proposal like this happened before, only to be bastardized in committee into something worse.
On the other hand, it may be passed to make Al Gore look better to all the High-tech companies that the DC whores all want to get into bed with
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
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 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.
Sure, It's a tragedy how badly the GPL has hurt RedHat, SuSE, Cygnus, Sendmail etc. etc. etc. who are flourishing companies thanks to the GPL.
Thank you for making me laugh today...
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
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.
;)
They seem more occupied collecting Pokemons already. It gives me the creeps to think that the decision-makers of the future were raised with such crap... Now I'm REALLY depressed
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
You're probably right, a BSD style license would probably have worked too. The advantage of the GPL, in my eyes, is that it prevents these companies of trying to go "the Microsoft way" (by closing off further development).
;)
The main advantage of the GPL is that it forces companies to "play fair", by providing the sources. No secret APIs, no undocumented functions... In a word, heaven
I'd think they'd flourished DESPITE the GPL.
Completely agreed. But if DESPITE means forcing companies not to act in predatory ways, I would applaud that wholeheartedly.
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
You could start exporting now, But the problem is first you have to rewrite many Aps to include Crypto. Then you have to be ready to rewrite them again if/when new regs come out. Very time consuming. I think the best bet is to lobby your representives about writting these new regs into law. Then programers can make long term decesions without worring about who will win this years election.
Quemadmodum gladius neminem occidit, occidentis telum est
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
Why would a Department of Commerce web page resolve to a cable modem user?
Okay, it *really* resolves to DOCUSER.osec.doc.gov, so it probably is a legitimate message from the Office of the Secretary for the Department of Commerce. But why does the META TAG contain "FREE KEVIN!" references?
I really, really want this to be true. I do not like having to put access controls on my unoffical Debian Kerberos packages, but at this moment in time we have a single document saying exactly what we want to hear... and it wasn't put up on slashdot until LONG after the contacts listed would be asleep.
And never forget that the US Government has a very long history of "the large print giveth, the fine print taketh away" in crypto policy. It will probably take the lawyers some time to figure out exactly what the new policy really means.
So don't pop the champagne yet... but definitely put it on ice so you'll be ready!
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
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.
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.
--
It has to work - rfc1925
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).
Well, at least there is one thing I agree with you: American citizens should indeed care about US laws, as everyone should care about the laws in their country. I'm just trying to say that US government has absolutely no way of controlling the crypto software used by other countries / individuals in other countries. The fact that Americans can't export crypto software has very little or no effect at all.
--
It has to work - rfc1925
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!
A small problem with what you wrote. 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. 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. It only weakens American citizens and business in the international market.
Frankly, I am cynical for a different reason. 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. But then I am a bit paranoid.
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
D'oh, I just saw that I have the +1 for being a good poster on /. after I posted this comment! I didn't mean to post the above comment with a +1 (no offense to Fruan, his point is very good).
Perhaps, by default, that +1 bonus should NOT be turned on....
"Don't mind me cutting myself on Occam's Razor"
I'm just trying to say that US government has absolutely no way of controlling the crypto software used by other countries / individuals in other countries.
Of course. I agree with that completely. If you inferred that I said that the US was pushing its laws onto other countries, then let me say that I did not imply that.
"Don't mind me cutting myself on Occam's Razor"
No prob, I missed it in the summary. Got to quit reading /. at 5:00am, I guess :)
Thanks!
"Don't mind me cutting myself on Occam's Razor"
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"
(1) No reporting is required for exports of:
:)
(v) Any export made via free or anonymous download
That's all I wanted to hear. Now when I'm downloading NT SP6 High Encryption from work, where our IP addresses don't resolve, Microsoft won't tell me I'm a foriegner.
Ahh, come on, so this post wasn't terribly insightful, but did it really need to be marked redundant? I mean, the guy looks like a pretty new slashdotter and I think he was just trying to add an honest sentiment to an article. No need to disrupt his karma dreams so early...
But that's just my opinion. I could be wrong.
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
The US gov. will have to relax these rules further.
I've been using RSA lately in Python, with the following script:
# Author: dj trombley
# Subject: RSA Cryptosystem
# Packages: crypto
It's a one page fully-fledged 128-bit public cryptography script that basically enables you to have secure sessions. (I've seen a Perl implementation that only takes 3 lines). You can perfectly well use it over http. You only need to store the server's public key:
(1) you generate your own public key (and private one)
(2) you encrypt your public key with the server's public key, along with your request
(3) the server sends you the results encrypted with your public key
(4) you decrypt your results with your private key.
Who the hell needs SSL or certificate authorities?
How can they make commercial products, export regulations, laws in congress, license schemes, per-user fees, other hassle, around something as trivial as that?
Or maybe this is just legal lipservice.
"You ever have that feeling where you're not sure if you're dreaming or awake?"
"You spoony bard!" -Tellah
either the NSA can crack "strong" encryption like a bitch, or they aren't doing their job in allowing the export of encryption...
The requirement that you send a copy of the source or of its location should be quite trivial for any software developer to comply with.
--SolidGold
--SolidGold
Everything you know is wrong. Or more accurately, inaccurate.
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.
Well this legislation has been way overdue. It is so easy to write a strong if not unbreakable expensive key encryption system that trying to restrict source code is silly. What I am wondering is if nonprogramming folks will be allowed to hire programmers to install encryption products that go beyond the key strengths allowed for commercial licensing? If so this would be a big boost for open source programmers, but perhaps a problem for law enforcement.
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.
This post strikes me as kinda wacko, but I have to agree that having to notify the government in any way is a free speech issue.
To me the core issue is still unresolved, and hasn't even been addressed: to what degree is code speech? Information floats through different formats completely indifferent to the format. Laws regarding encryption treat it as an object, while it is just as much pure information, to which different laws apply.
My point is that there needs to be a major legal precedent clarifying the relationship between information in a platonic state, its instantiation in different passive formats (for example as text), and embodiments of the information within machines.
Imagine a hardware system (for example, an alarm clock) where legal restrictions apply - product liability laws. Replace the hardware system with a digital controller + physical noise maker. Out of all the steps to create the object - conceptualizing, designing logic flow, implementing source code for a particular digital context, compiling the source, running the executable, steps taken within the executable itself, interfacing between the executable and the physical world (EG by assisting the program in sending i/o to devices like a bell) - which one "created" it? The implication being that, at some point, responsibility has been taken on for product flaws.
The law right now is very different for objects and ideas. But digital versions of physical machines enable us to effectively replicate the machines; disassembly converts the machine back to information. The object itself is just another, potentially less liquid, form of information.
If a programmer speaks a program into a computer which then runs the program, do speech or object laws apply?
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
It is true that the GPL doesn't require you to pay a licensing fee or royalty... so long as you give your own work away. However, if you wish to use the GPLed code to make a COMMERCIAL product, you must pay royalties or licensing fees.
The language of the regulation says that if a royalty is required to use the code in ANY commercial product (even one!), it is not freely exportable.
Maybe this was not an anticipated consequence, but this is what the current language of the regulation says.
This may be a very, very good thing. If encryption code is published under a license that allows commercial reuse, such as the MIT X license or BSD license, it will be incorporated into commercial products as well as free ones, and closed source products as well as open source ones. This will promote standardization, as did UC Berkeley's release of the BSD TCP/IP stack. (The fact that the BSD TCP/IP stack was released for commercial as well as non-commercial use is often said to be responsible for the ubiquity of the Internet today.) If we want to see encryption become ubiquitous as well, this is a highly desirable way to go.
The GPL, by contrast, promotes fragmentation and incompatibility by preventing commercial developers from using the same code base as those who are publishing open source.
So, export rules which require exported open source code to be usable in ANY commercial product, without royalties, may be the absolute best thing we can do to promote the widespread use of strong cryptography.
Even advocates of the GPL will agree, I think, that the GPL's restrictions are very counterproductive in this particular case.
I am not sure whether those who drafted the regulations understood, or cared about, the political agenda of the GPL in particular. But clearly, what they had in mind was to insist that exported open source crypto code be usable by all developers -- whether or not they publish their own source or gave away their code for free. This is the right approach.
--Brett Glass
Note the use of the qualifier "unrestricted" in the paragraph above. So, what's "unrestricted?" The text gives what appears to be an answer:
So, if I read the draft correctly, no open source crypto software that's strong enough to protect anyone's privacy against a marginally competent code cracker can be exported, even under the new rules.
--Brett Glass
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
For a little while now it has been apparent that elements high up in the NSA having been backing away from their stance on requiring backdoors into crypto; and have, according to congressional sources, been disgussing backdoors with the actual hardware vendors. However with the ever increasing influence of the private sector on government, it can be suspected that it would be difficult to upgrade gov crypto powers without undermining private sector confidence in the security of the communications networks. The gov is not interested in actions which will hamper private sector international competetiveness, and will be plowing its resources (time, manpower, money) into producing smarter crypanalysis (better collection of ciphered info, and analysis of the decrypted contents) rather than stronger (better actual decryption).
Kinda Makes me wonder. If they're loosening export restrictions, why isn't the NSA complaining?
As I understand it, they're one of the big supporters of keeping strong encryption domestic, because they can't crack it very well (or very quickly). If that's so, why aren't they complaining? Think they know something we don't? think they found a way to defeat it?
There! that should be enough paranoia for everyone...
Fish
And how much time are you wasting?
"Reality is less than television."-Brian Oblivion
The U.S. Govornment can be accused of many things, but relinquishing its grip on paranoia is definitely not among them. Wasn't there a /. article a couple of months ago about a university in Israel that managed to crack a major London bank in milliseconds? here's the link Now, if I were just a tad bit paranoid myself, I would suspect that the govornment is loosening their grip simply because they are able to crack anything out there now, based on that story. Just a little something for all you slashdotters to think about. Every silver lining has a dark cloud. -You can never go back. FREE MARS-
Drop me a line at:
Key ID: 0x54D1D809
What the fuck do guns have to do with freedom of speech?
*serving suggestion
We discussed this on the UKCrypto mailing list at least a few weeks ago!
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
Powerful encryption programs does exist outside the US, like PGP. The current US export laws does restrict export of encryption source code in ELECTRONIC form, but it does not restrict the export of source code in BOOK form. This is a very nice "back-door" which can be exploited by anyone armed with the Source code book, a scanner, and OCR software. Of couse, since the source code is currently on over 12.000 pages it does require a lot of work, but the pay-off is a legal version of PGP outside the US. The US version of the source code even have a few limitations and restrictions which is not relevant outside the US, the Non-US version have these removed and a few extra features added. The International PGP can be found at PGPi
So even though the US goverment restricts the export of encryption source code and software, I'm still able to enjoy my legal freeware copy of PGP and my 4096 bit key. :)
- BrightSide -
"Without darkness, there could be no light.
Without light, there could be no darkness"
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQGiBDgddYARBADvBTZwQ/1eUEu7w3AX1NVCshCBrrk19Np/CVersion: PGP 6.5.1i for non-commercial use
8E3AXFU6H0vD40M+9qcmJVpMof6a/0T5kB2EM34b0HPcdGiHz
HMRrk17UR0sGoEHZANKr+XzTgJ4GxBC8SNTitQH4HpGgfhxkO
G5cuNryMjTBY6BEwJgbjKNMD/09sX599N7VOFxLE08D4sfCf0
RMafqR9wThrP8lZhl/5tvo44GvSIoHN1wGidG9uPbt/FoEVmC
BKqHF9wiLr6+/4f35fWiMoBLldcvSbDHduKcq4MpOhOu/DPQ/
pJwHfri4NcjCTLjPQGZNq0CZDP/Ov0KJ9U+M4LGewo7dpt/2Z
8ShO6dKCUU6SNkWs9KEbvofN65/YDYmkfc1Y/CvOO3OaoZYBs
Z2h0U2lkZSBS+G5uZXZpayA8QnJpZ2h0U2lkZUBNeXdheS5Db
BQI4HXWABAsDAgECGQEACgkQdzhQBkmwSaaLgACcD1oDjMHB8
YokAoMEI6yM4Bd/Ej2aBS43xue96ylVMuQQNBDgddYAQEAD5G
bIeG7GHszUUfDtjgo3nGydx6C6zkP+NGlLYwSlPXfAIWSIC1F
xZYgTphluNgN7hBdq7YXHFHYUMoiV0MpvpXoVis4eFwL2/hMT
FGHjhKlP0YOEqHm274+nQ0YIxswdd1ckOErixPDojhNnl06SE
yHx5sHIdOHX79sFzxIMRJitDYMPj6NYK/aEoJguuqa6zZQ+iA
Ks4fdIRPyvMX86RA6dfSd7ZCLQI2wSbLaF6dfJgJCo1+Le3kX
S3wy9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWo
qZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSW
xUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0i
BzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040
MyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQC
n5x8vYlLIhkmuquiXsNV6z3WFwACAhAA3IxMQOaViVd9dTBXt
kpyYMuZE8o1idz0IuhT+z15Y16p+yuHsFlL/up+yR4WlGgCr5
9Q4FoRVEgkC1tCzy+ik3xUBNHWg1Td0rBJ+hB4u90hms0oxrg
4by8PSY2jxnXVx5Jl9MJ6/SYE1hbyFxts/E5OJVt+YZulK+fZ
EiRbC7ALvZxcvNphPiUFdqmUrdjw3tZxgZoPlx6ExtbIbAUTX
s8Yx2iYyuwtVAELP7YWIkpzn/R+7zq52OVvB3tHE5Jp2g4K68
4H4txFOVq8CTF5Y/XlJ9MkZqD8lfSpXv72OCB2j6lCk7aGzvk
7W5ZQNpMPkq4umeCBLzL8nqrgC5IbxZoz3qdQR0kRzQQlQXuw
j/VVvynGgNEhxNwG/rh5JWuwCqrawlz0axmwzaLTc2XdfvDwd
mOv/DbnNH6S4KpIpysVfGzIGRfyO7ybQFr2H3Yafh9I5AD+Jo
4UkyMFf4HACJAEYEGBECAAYFAjgddYAACgkQdzhQBkmwSaYeH
C8n+nFZVf7Y5l/EAoOCzFw9jXds2iCREb021UQ9eE+0a=rSUt
-----END PGP PUBLIC KEY BLOCK-----
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.
Brett,
While I understand your reasons for not liking the GPL, I cannot understand where out of this clause you got that idea. it says and I quote, "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" (anything that is derived from this, I would assume even some commercial products such as RedHat or IBM's Interjet, fall under this category) would be allowed to be released and exported without review, and be released from export control.
BSD vs GPL aside, I see this as a great advantage now to Open Source'd software within the US, this opens the playing field a bit more and gives companies a reason to use this type of software. Coupled with the advantages of BSD licensed software in general, I think that this might even give an edge to BSDL software over GPL, but your assumptions about GPL'd software not being exportable under these new "rules" is not correct. -Pat
-- FreeBSD - The Power to Serve NetBSD - of course it runs NetBSD OpenBSD - Armed to the Gills Three tools in our
Geez, Louise, everyone's on NSA's case. Rumor mill inside the Beltway sez NSA was ready to go along but it was the FBI that was holding up this necessary change. Go figure. Betcha NSA broke 512 bit dual key big-time (i.e., in bulk) years ago and didn't tell anyone.... Any takers? If Commerce put this change to the EARs out "For comment" and you like it, a favorable comment _to_ Commerce would be appropriate.
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.
as far as i am concerned relaxed crypto laws are much needed. roche
roche
Bah Humbug!
I wonder if we can store the crypto in a Linux distribution in sorce code form and have the user execute a command after install to compile and install the code?
Maybe we could have a little checkbox during install to run the command for the user?
Paragraph 3 wasn't specific in the bit sizes that it would allow, which scares me.
And would the distribution fee that is charged for Linux on CD's be misunderstood as a fee for the source code?
-- Never make a general statement.