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.

Comments

Another waste of time and money.

[Zemran]

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?

/MUCH/ improved from earlier drafts

[tilly]

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

Here is the football

[tilly]

The following appeared on a mailing list:

(I wrote:)

Take a look

http://www.cdt.org/crypto/admin/000110cryptoregs.s html

Skip down to the words "open source".

"3. Also in 740.13, to, in part, take into account the "open source" approach to software development,
(snip)
Looks good to me! :-) Am I missing anything?

Yes. To start with, 740.13(e) applies only to source code. I don't see anything in the regulations which gives special dispensations to
binaries generated from such code, so if you wanted to host compiled binaries on your (U.S.) site along with the source code, then I believe
you would have to formally apply to BXA and request classification of your software; based on the results of that request you might be able to
export the binaries under the ENC license exception (e.g., using 740.17(a)(2) or 740.17(a)(3), depending on whether the products get
"retail" status or not). However you might have to implement access controls on the binaries beyond what you have on the source code, for
example to prevent download requests from "government end-users" and the "T7" nations (North Korea, Iran, Iraq, etc.)

If your source code implements an "open cryptographic interface" (e.g., something like the RSA PKCS#11 API) then your binaries are even more tightly controlled, and it looks as if you might have to apply for a formal export license (as opposed to using a license exception); see
740.15(f). (But again, this restriction does not apply to the source code, just the binaries.)

Next, there's the issue of prohibitions against "technical assistance", per 744.9. These prohibitions appear to be moot in the case of
assistance with source code, based on the language in 744.9(a) that says it doesn't apply when you're already "entitled to export the encryption commodities and software in question to the foreign person(s) receiving the assistance." However 744.9 appears to still apply in some cases like where the person you're providing the assistance to is a national
of North Korea, etc.

(The new regulations don't give you any blanket exemption from "knowingly exporting or reexporting" stuff to the "T7" nations;
740.13(e)(2) only gives you a specific "safe harbor" to put stuff up for public download without triggering the "T7" prohibitions. However
that doesn't cover cases like export or assistance via email.)

Then there's the issue of combining U.S. and non-U.S. open source encryption source code, both in the U.S. and elsewhere. Based on 740.17(d), "foreign products" including U.S. encryption source code don't require BXA review or classification, and can be freely exported
from the U.S. However there still might be issues here due to language elsewhere in the regulations. The prior regulations had some complicated "de minimis" language which in effect made it illegal for non-U.S. code imported into the U.S. to then be exported out again, even if the non-U.S. code had no U.S. content at all, and I'm not sure yet if vestiges of that might not be lurking somewhere.

740.17(d) also states that "foreign products" incorporating U.S. source code are "subject to the EAR". This I'm sure will alarm some people
outside the U.S., but I don't know if this actually would cause any problems in practice. It may be directed at persons under U.S. jurisdiction, to alert them that they still have to follow U.S. regulations when exporting such "foreign products"; it may also be intended to give the U.S. government leverage over non-US persons or companies who might export such products to "T7" nations.

So at least in my opinion the effect of the new regulations on FSBs is not entirely straightforward, and I think we'll have to wait for further public review of the regulations to see if some of this becomes clearer.

*sigh*
Ben

Nothings Changed....

[trims]

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

Re:A point from OS

[Detritus]

You all seem to think that the United States is the only place anyone can get full strenght ecryption.

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.

Cool

[delmoi]

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?",

Re:Cool

[Big Jojo]

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.

Ironic

[jonathanclark]

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.

Jerking the Football Away

[thales]

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.

This was *not* a troll

[coyote-san]

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!

Sigh.

[spiral]

The authority citation for part 734 continues to read as follows:
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.

A sane approach to cyberwar?

[Ungrounded Lightning]

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...

Re:Interesting notes about the document

[konstant]

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!

This is a good thing, except...

[wowbagger]

First, I want to say that, in general, removing export restrictions is a great thing. I work in the telecom industry, and not being able to export encryption code it a galloping bitch.

However (there's always a however)

• Would DeCSS exists if the DVD companies had been able to use strong encryption?
  
• What if MacroSloth could use strong encryption in the document format on the next verion of Orifice?
  
• What if QuickTime V5.0 uses strong encryption on the streaming protocol?
  

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...

Interesting notes about the document

[DoomHaven]

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*".

Open Source

[SolidGold]

The following is an excerpt from the page answering the question we're all asking:


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

A point from OS

[1DeepThought]

You all seem to think that the United States is the only place anyone can get full strenght ecryption. I hate to tell you this but encryption work is being done all around the world. There are many full strenght products that were not developed in the United States. Even some that were are available elsewhere, ie PGP. 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.

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

Don't get too excited

[�nubis]

"a one-time product review by BXA continues to be required"

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.