Current State of Exporting Open-Source Encryption?

Jay Maynard asks: "The project team is getting ready to release a new version of the Hercules IBM mainframe emulator. Part of the update is support for new instructions IBM added in their latest z/990 system, and two of those do encryption. The Bureau of Industry and Security (formerly the Bureau of Export Administration) changed their regulations on June 6, 2002 to grant a license to export open-source encryption code to anyone but the usual suspects (denied persons and banned countries). They went on to recently clarify that putting up code for download did not in itself constitute exporting to those banned countries or persons. There are many open-source projects that still host encryption code outside the US because of past rules. Is there still a reason for doing so?"

Comments

No.

[molo]

No. Next question?

Seriously, you just answered your own question. This doesn't mean that Debian can get rid of its non-US archive. It still contains things that are patented in the US or illegal due to the DMCA.

-molo

Yes, very much!

[shfted!]

There are many open-source projects that still host encryption code outside the US because of past rules. Is there still a reason for doing so?" DeCSS is the obvious example. Without code based on it, I could not watch DVDs I rent on Linux. As DeCSS is made illegal by the DMCA, the only choice for projects using that code is to host outside the US.

It is hopeless.

[Mensa Babe]

The current state of exporting free software encryption is so "wonderful" that I have to manually type each and every sample program from Schneier's Applied Cryptography book listings to try it out, because a disc with exactly the very same software would be illegal and, by ex tention, evil. We all know that terrorists cannot type, so thank god we are entirely safe that way. I just love it. I feel like in the days, when I was typing C64 games in BASIC from '80s' computer magazines. *sigh*

Re:It is hopeless.

[andfarm]

Um...

Unless I'm mistaken, there's a card in the back you can send in to have a disk sent to you. The only reason you don't get the software on a disk to begin with is because that would increase production costs.

Re:It is hopeless.

[jhunsake]

What do you expect from someone (claiming to be) in Mensa?

Re:It is hopeless.

[Methuseus]

Absolutely correct. And I'd rather just download the code each time it's updated off the newsgroups anyways, since they change it every once in a while anyways.

Re:It is hopeless.

[MattCohn.com]

I know I'm going to be modded into oblivion for this but...

Karma: Excellent (Better then positive) (But who fucking cares? Get off your high horse, get some therapy for your self-esteem issues, and get the fuck out of our faces. Everyone is tired of you acting like a more evolved person. It's old, and especially irritating considering you:

1. Don't have a clue what you are talking about most of the time,
2. Are plainly less intelligent then most of the people on this site,
3. and are BLIND TO SEE HOW IRRITATING YOU ARE

Note to mods: Please see MensaBabes posting history before you mod me; her pathetic past and present is the only redeeming quality of my post.

Re:It is hopeless.

[Anonymous Coward]

Ha ha, you got trolled! Badly!

Re:It is hopeless.

[MattCohn.com]

Yah, but now in MY window it showes her as a freek, which is true...

and in HER window it shows me as a foe. Also true.

off the top?

[mikecarrmikecarr]

"There are many open-source projects that still host encryption code outside the US because of past rules. Is there still a reason for doing so?"

uhm... why should anyone outside the US believe that the US will continue with its current position? Does the current political climate of the US, as observed by other nations (i.e. Canada), suggest that open-source encryption (read: tools to aid and abet terrorists) will continue to enjoy the lack of restrictions?

i dunno, it seems like a whole shwack of 'once bitten, twice shy' to me.

not trying to flame, i just can't see anything (from this side of the border) to suggest that we should be trusting the US not to change their position. *shrugs*

one good reason to continue

[nurb432]

The rules will change again.. trapping the code inside the borders.

its just a matter of time.

Re:one good reason to continue

[SETIGuy]

The rules will change again.. trapping the code inside the borders.

It's even worse than that. The change is an administrative change, not a change to the law. (IANAL, but I have worked under ITAR exemptions in the past and so have made myself familiar with the implications.) Should the administrative change be reversed at some time, and you have exported encryption technology, you have suddenly become guilty of a crime.

Because the law didn't change, it's not a case of ex post facto. It's uncertain whether the appeals courts would uphold a conviction in such a case. However, the DOJ could make your life unpleasant for quite some time.

In other words, if you choose to export, don't get on Ashcroft's bad side.

US policy on exporting Encryption is stupid.

[saden1]

Everyone possess the know how. I mean, if you can remotely attempt to build an atomic bomb or an ICBM you possess the know-how to encrypt/decrypt data. Plus, there are a lot of papers out there that give you all the info you need to write your own algorithm. Hardware encryption I can understand, but software? Come on, get real. Foreigners are not stupid.

Re:US policy on exporting Encryption is stupid.

[joto]

if you can remotely attempt to build an atomic bomb or an ICBM you possess the know-how to encrypt/decrypt data.

Hrmm, ehh, well. If you only worry about the peple capable of building nukes, than your point is valid. But there are plenty of others to worry about, people that could do damage, even if they don't have the resources available to create nukes.

The US, and other large governments, probably all have a few tricks up their sleeve that they don't want to tell the world. Problem is, these are already secret, and there is no way for me or anyone else without security clearances towering up to a mountain to "export" what we don't know. Elementary cryptography is not breathtakingly hard, however.

Hardware encryption I can understand, but software?

Huh, what's the difference? If you can do it in software, you can do it in hardware. If you can do it in hardware, you can do it in software (although possibly much slower). It's the methods that needs to be kept secret, not their particular implementation. There are two things that are stupid, the artificial difference between a software "device", and a method written on paper, and the attempt at hiding what is common knowledge, and can be gained by reading any textbook. But as the original poster already pointed out, this has already changed.

Of course. BSD.

[mirabilos]

The BSD spirit means we want to make stuff available
to anyone, free to use. This does include Microsoft,
Irak, Afghanistan and others.

Please don't feel offended - this is just the way
the BSD spirit works, and it's intended.

From an European's viewpoint, the US is one of the
most unfree countries around the world.

Re:Of course. BSD.

[necrognome]

From an European's viewpoint, the US is one of the most unfree countries around the world.

Similar things could be said about Europe, you know (and this is from a leftist), given the following European phenomena:

1. Oppressive gun control laws.
2. Useless anti-hate speech laws
3. Identity cards and a love of surveillance

Anytime you cross the Atlantic (in either direction), it seems you trade in some freedoms in exchange for others.

I doubt it will be a problem

[randombit]

If you are concerned about the export laws, there are two factors to consider:

1) It's unlikely that these two new instructions would even count as encryption technology. Unfortunately Google couldn't find me anything about the z/990 extensions, but I rather suspect that if it's just those two codes, they're going to be so low-level as to be almost meaningless. The NSA and etc mostly cares about preventing people from getting their hands on useable applications, rather than the base algorithms - seems they didn't realize when they created the restrictions back in the day, that nobody knows how to make a user-friendly crypto app anyway.

If you could specify what these two instructions did, that would make it a little easier. For example, an instruction to fill a register with random bits, or to compute some special function that would only be useful in implementing multiple precision integers, would be very useful to crypto software, but not considered encryption on it's own.

2) They're extensions - only the latest (still unreleased?) S/390 system supports them, and it's likely that it will take at least 6 months to a year before any software uses these codes. So, implement them, test them, but don't release them until you feel sure that you're safe from the long arm of the fedz (whatever that may take).

Honestly though, the odds of a problem in this case seems nil to me (but after all IANAL).

Re:I doubt it will be a problem

[Jay Maynard]

I was mistaken: it's five new instructions. They provide DES and 3DES symmetric cryptography, and SHA-1 message digest functions. The PDF introduction to the z/990 I found at IBM's Redbooks site doesnt' go into a lot of detail, but it does say that much in chapter 5. The biggest omission, and one that may prove critical, is the key lengths supported (the BIS site is unclear as to whether crypto with keys longer than 56 bits falls under the open source exemption).

We may find ourselves holding off for now, mainly because we'd like to get the 2.18 release out the door in the next couple of weeks, and this issue is likely to take longer than that to resolve. Still, it's a matter of pride for the Hercules team that we implement IBM's announced architectural extensions faster than any other emulator (this won't be the first time), and having to delay for nontechnical reasons is a bit irritating.

Re:I doubt it will be a problem

[randombit]

I was mistaken: it's five new instructions. They provide DES and 3DES symmetric cryptography, and SHA-1 message digest functions.

Wow, screwy. I've never heard of any chip that did something like this on an instruction level. I don't know about the key length limitations, but I can tell you that I have distributed 168-bit 3DES for years as part of a crypto library and never heard a peep from anyone related to the export laws (many other people continue to host well-known crypto projects out of the US, as well). I am fairly certain the DES and RSA stuff mentioned in the PDF is full strength (ie at least 2048 bit RSA and 3 key 3DES), as one of the options looks like they basically just include an IBM 4078 (? can never remember the number, that looks right) cryptocard with the system.

Re:I doubt it will be a problem

[Jay Maynard]

I've never heard of any chip that did something like this on an instruction level.

That's why it's a mainframe. :-)

The crypto coprocessors are beyond the scope of Hercules, at least as it stands now (although I wouldn't rule out adding it in the future). Even so, however, I get from my reading of 740.13 that the key length doesn't matter. (Am I wrong there?) I doubt that part will become an issue anytime soon, but the five instructions are rather more of an immediate problem. It looks like the message digest stuff isn't an issue, so it comes down to what the DES/3DES instructions actually do. I haven't seen the code in question.

yes. these are just rules

[Russ Nelson]

The current set of rules are just rules. The government agency (whatever it's called) can change those rules any time it wants. The NSA (or whoever) cleverly ensured that the Bernstein case didn't set a precedent, so a crypto project basically has no legal protection whatsoever.
-russ

Re:yes. these are just rules

[rplacd]

What happened to that case? The web site doesn't have any recent updates.