More New Crypto Rules (UPDATED) 143
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.
The U.S.'s policy impacts us all... (Score:1)
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.
Re:A point from OS (Score:2)
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.
----
Re:RSA patent? (was: Re:OpenBSD and re-export) (Score:1)
-E
Re:Nothings Changed.... (Score:2)
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
RSA patent (Score:2)
-E
Re:Cool (Score:2)
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 [openbsd.org], that is...).
All in all, a very positive step. Yay.
Re:Rules would allow BSD-licensed source, but not (Score:2)
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.
So my RSA T-shirt finally becomes wrong, then? (Score:1)
Wade.
Re:This is a good thing, except... (Score:1)
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.
Re:Ruling out the GPL is a good thing, IMHO. (Score:2)
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.
--
I don't like this.... (Score:2)
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...
Re:Ironic (Score:1)
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.
Open Source has it good under this: (Score:2)
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.
Why the govt cares, and why you should care (Score:2)
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.
CSS was doomed anyway (Score:2)
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 [counterpane.com], so I'll just quote him.
Another waste of time and money. (Score:3)
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?
There is hope for crypto! (Score:1)
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!
Export of only 64 bit? (Score:1)
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.
RSA patent? (was: Re:OpenBSD and re-export) (Score:2)
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,
just a mildly-ontopic reminder... (Score:2)
That's when the hated RSA patent expires [rsasecurity.com]....
I think we should organize a giant SSL installfest on that day! Any takers?
Your Working Boy,
Eh? (Re:PGP International) (Score:2)
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
Re:Like it will happen.... (Score:1)
Enough Already (Score:2)
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.
The Incorrigible Optimist asks: (Score:2)
Could it be that the US government has decided to just fscking deal with the situation and not try to rebag unbagged cats?
Maybe.
Scan for the words "open source" (Score:2)
I can live with that restriction...
Cheers,
Ben
What was that? (Score:2)
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
Bob Young thinks otherwise (Score:2)
Cheers,
Ben
Oops, attributation (Score:2)
It was Frank Hecker [hecker.org]...
Cheers,
Ben
/MUCH/ improved from earlier drafts (Score:3)
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
Here is the football (Score:4)
*sigh*
Ben
Re:Nothings Changed.... (Score:2)
But, do not take my word for it -- IANAL.
Re:OpenBSD and re-export (Score:1)
Nothings Changed.... (Score:3)
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
Dudes, What happened..... (Score:1)
gee, so, this would be the new law.............
Re:A point from OS (Score:3)
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.
Re:Cool (Score:2)
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.
Now that you mention it... (Score:1)
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...
Re:The Incorrigible Optimist asks: (Score:1)
You might notice that my public key is 4096 bits...
Re:Encryption doesn't prevent reverse engineering (Score:1)
Address to send Dept. of Commerce comments! (Score:2)
From the text of the doc at http://www.cdt.org/crypto/admin/000110cryptoregs.
Actually... (Score:1)
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
Re:A point from OS (Score:2)
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.
Re:/MUCH/ improved from earlier drafts (Score:1)
Well, it is up for further comment. Now is the time to speak up. Come up with your rational sugestions, and put them forth. Make sure you ground those sugestions in as much fact as you can. The cat may be out of the bag as far as encryption goes, but we need to get our US laws in line with the cat.
One thing I note is the relative and almost blanket exemption for E-Commerce and banking.
Re:This is a good thing, except... (Score:1)
Re:OpenBSD and re-export (Score:1)
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.
OpenBSD and re-export (Score:2)
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
I believe it! (Score:1)
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!
Probably not a hoax (Score:1)
That would be a very unlikely hack.
Also where is the 'FREE KEVIN!'?
I read it the other way. (Score:2)
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.
Re:Rules would allow BSD-licensed source, but not (Score:1)
Like it will happen.... (Score:1)
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?",
Cool (Score:5)
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?",
Re:Ironic (Score:2)
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"
Ironic (Score:3)
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.
Re:Rules would allow BSD-licensed source, but not (Score:1)
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...
Re:Hmmm.. (Score:1)
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
Re:Rules would allow BSD-licensed source, but not (Score:1)
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.
Re:Another waste of time and money. (Score:1)
They want to avoid a situation where by default all e-mail, filesystems, etc. will be protected with strong encryption. In the current state of affairs, people can encrypt all this material, but they have to be smart enough to know it. The ones that aren't smart enough become easier to investigate.
One of the key principles of playing a strategic game of chess is never to assume or hope that your opponent will blunder; instead, a chess player is supposed to rely on the strength of her own moves rather than the weakness of her opponent's. Which just goes to show you that chess and law enforcement are very different pursuits.
Re:Jerking the Football Away (Score:1)
Jerking the Football Away (Score:4)
204.193.246.62 resolves to cable modem? (Score:1)
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 [dimensional.com], 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!
This was *not* a troll (Score:3)
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!
Sigh. (Score:3)
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.
Encryption doesn't prevent reverse engineering (Score:2)
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
Re:Interesting notes about the document (Score:1)
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.
--
Re:Interesting notes about the document (Score:1)
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.
--
Re:Cool (Score:3)
That actual draft isn't wholly comprehensible without reference to current revisions of EAR and of the Wassenaar agreement, but parts of it sure sound good ... if I make assumptions about those other documents. The DOC summary of the draft is readable, though one hopes this isn't another case of the big print giveth, and the fine print taketh away (as my dad used to say :-).
There are still words about those familiar nasty restrictions to 56 bit symmetric ciphers and 512 bit keys. Due to those reference to other documents, I might be wrong ... but it sure seems to me that an exportable US Linux distribution is still stuck with miniature key sizes. Please show us I'm wrong about that!!
The agenda of export control is actually far more relevant to a distribution of, say, RedHat than to a source distribution (open or otherwise). The reason is that when the norm becomes "strong" crypto, cipher-cracking operations (Echelon and its more secret siblings) don't work any more. And there really aren't that many people who will be compiling those open source products, or installing them correctly and on systems which have been adequately hardened. The way that the norm changes is when OS distributions and their applications "norm"ally are strong, and that does not appear to be changing.
So while we can/should applaud the good words re open source (yay!), let's not forget that the real battle is about regaining our personal freedoms, not just for Open Source. We need to see restrictions on binary products go away too.
Re:Like it will happen.... (Score:1)
Re:Jerking the Football Away (Score:1)
I agree that this is true. However, isn't this a window of oppurtunity? Don't we have a chance, now to let the cat out of the bag, so that whatever regulations change later, it's too late?
Wouldn't it be a good idea to start exporting like crazy every implementation of everything you can think of related to encryption? That way if the DOC does pull the football back, it'll really be too late. Another football will already have been kicked.
thots?
A sane approach to cyberwar? (Score:3)
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...
Re:Interesting notes about the document (Score:4)
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!
Re:This is a good thing, except... (Score:1)
Re:Interesting notes about the document (Score:1)
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.
Re:Encryption doesn't prevent reverse engineering (Score:2)
Yes, but now you have to disassemble Office to get the key. If the MSOffice disk is packaged in such a way that you have to agree not to reverse-engineer it to install it, then you cannot legally disassemble it, thus no key.
To decrypt a disk, yes. However, if they had gone with an asymmetric key system (a.k.a. public key) then the data needed to encode a disk wouldn't be there. Thus, they could prevent anybody who wasn't "in the club" from creating their own content.
My choices were made to relate to current "hot" topics on
This is a good thing, except... (Score:3)
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...
Off topic (Score:1)
Perhaps, by default, that +1 bonus should NOT be turned on....
Re:Interesting notes about the document (Score:1)
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.
Re:Interesting notes about the document (Score:1)
Thanks!
Re:Interesting notes about the document (Score:2)
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?
Re:Interesting notes about the document (Score:2)
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?
Re:Interesting notes about the document (Score:2)
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.
Re:Interesting notes about the document (Score:2)
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
Interesting notes about the document (Score:4)
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*".
Re:Cool (Score:1)
Here are the magic words (Score:1)
(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.
Re:much needed (Score:1)
But that's just my opinion. I could be wrong.
Why not make your opinion known? (Score:2)
Re:A sane approach to cyberwar? (Score:1)
And your evidence for this is what, exactly?
The US government have realised that crypto is OUT THERE ALREADY (PGP etc.) and there is not a lot that they can do about it. Now the crypto/e-commerce companies want to make some money out of it, hence they put pressure on the government to change the rules. See also the comment about possible crypto rule changes in the EU - they don't want to exclude US companies from this market.
Re:A point from OS (Score:2)
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
US companies want the business ... (Score:1)
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?
Hmmn... (Score:1)
Or maybe this is just legal lipservice.
"You ever have that feeling where you're not sure if you're dreaming or awake?"
Open Source (Score:3)
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
Summary from Rules Draft (Score:2)
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.
crypto-mania (Score:2)
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.
Rules would allow BSD-licensed source, but not GPL (Score:2)
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
A point from OS (Score:5)
Another example is Fortify [fortify.net]. 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
Hmmm.. (Score:2)
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.
US & UK Crypto Regulations (Score:2)
Don't get too excited (Score:3)
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.
Source yes, but with a catch.... (Score:2)
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.