One thing to bear in mind is that the CryptoAPI does not encrypt. Rather, it's a "method-independent" API for calling encryption modules. Microsoft uses the CryptoAPI so that they can ship weak encryption modules for export, and strong ones for U.S. use, without any programs having to be recompiled to, e.g., compensate for the fact that 3DES uses 168-bit keys rather than 56-bit keys like the export DES (assuming MS got permission to raise it from 40 bits).
It is possible for a "middleware" product like the CryptoAPI to be insecure, but not likely. I still wouldn't trust Microsoft's own encryption modules though (the ones actually CALLED by CryptoAPI). For one thing, a good PRNG to get randomly-distributed keys is VERY hard to write. I just finished writing one because every distributed PRNG that I came across produced predictable keys (meaning that you don't have to brute force all possible keys to break the encryption, just the keys produced by the pseudo-random number generator, which proved not to be so random!). I seriously doubt that Microsoft got the PRNG right, and Bruce Schneier's own "Yarrow" PRNG is perfect proof of that (Bruce has a paper on his site, www.counterpane.com, detailing attacks on a PRNG that will let you crack encryption in MUCH less time than a pure brute-force attack).
Nice if you want to be an admin all your life. I prefer a little variety. Yes, I've done the "rebuild a company network from the ground up" -- then gone on to do other things, like the networking software that I'm currently working on.
There's plenty of interesting things to do within my current employer's walls, and not enough hands to do them all. I don't have to go elsewhere to get variety.
Yep, when I was an employee of a consulting firm I found that, strangely enough, if an employee at a client had a good idea it didn't get listened to, but if I came in and said "okay, I've evaluated your needs and you need this, and this, and this," the executives holding the money bags took my words as if they'd been handed down on Mount Ararat.
Disconcerting, to say the least.
I think the tendency amongst the non-computer-types who manage IT nowdays is to view their entire staff as toy-happy ne'erdowells always looking for new ways to spend "their" money. If their staff says they need to upgrade their 10baseT network to a switched 100BT network because the current network is completely saturated, they have the same response as if the staff says that they need to buy top-of-the-line SGI workstations for all of the developers' desktops -- both requests are treated the same, as "frivolous techies just want new toys". After all, these IT managers came from finance or sales, they wouldn't know a network switch from a light socket.
An outside consultant, since he is not going to be the one playing with the "new toys", is viewed as more dispassionate by the PHB. Which, in turn, discourages employees, who then contribute to that turnover problem by going elsewhere or going contract...
No no, the point was that if the H1 visas guys are filling the higher-paying/higher level positions, that means the less qualified "kiddies" are going to hang around Screw You Insurance longer getting paid peanuts because there will be fewer higher-level job openings where managers are desperate enough to hire these kids.
In short, the H1B's reduce this insurance company's expenses even though they'll never hire an H1B. Simple supply and demand -- if the supply is higher and the demand is constant, then the price of the commodity (the fresh-out-of-technical-school kids that they hire) gets cheaper. (And yes, they view these kids as a commodity -- "human resources", you know, just resources like any other resources used by the business, except for the little nit that they happen to be human).
The point is that the design work that means so much to a piece of code looks an aweful lot like random diddling, and there is intense pressure on contractors to get the job done ASAP because every time the client sees your face, he sees $$$. The guy hiring you as a contractor usually isn't a coder and really doesn't care what the code looks like (sad but true, I saw contractors turn in TERRIBLE code and they got paid the same as me), they just want a working product as quickly and cheaply as possible. If they see you leaning back in your chair reading a book, they think that's not what they're paying you to do and they tend to get upset -- NOT the kind of referral you want for your next job.
As you said, "Manage them properly and make some deliverables like documentation and archives of buildable code". Deliverables are what people pay contractors for -- not thoughtful design. They want deliverables in as little time as possible, which is not always the way to produce great code (though I was always careful to turn in good enough code, i.e., that did the job and was reasonably maintainable, but there was no time for the kind of polish that would make the code base shine).
Sorry about your experience with hiring an employee. But he would have been the same way as a contractor. Blaming an entire group of people for the actions of one bad apple is not a rational thing to do in any event.
Don't get me wrong, my contract work was always good work, at least as good as any other contractor did on that code base and usually better than most of the employees. But it was also very rushed work, because the whole point of hiring a contractor is to get the job done ASAP. The client is sitting there and seeing $$$ every time he sees your face, and there's a lot of pressure there to give him his money's worth. Spending an entire day doing nothing but pondering the best design for a CPRNG and tossing possible designs out onto sci.crypt to see if someone will burst them is not something measurable and visible and not what will get you good references in the future. In fact, it looks an aweful lot like just diddling around on the Internet all day long while reading some books -- NOT the impression I would want to give a client that I wanted to give me a referral in the future. But as an employee, I can do that because they know it's an occasional thing, and that good code follows. There's history there, in other words, that a contractor does not have. Some contractors may be able to social-engineer their way around that, but I've never been the social-engineer type, alas.
For example, company-provided health and dental insurance is not counted as part of your income for tax purposes as an employee, but if you are self employed, you pay taxes on the money used to pay for your health insurance (forget dental insurance!).
At least when I was contract on a 1099, I couldn't figure a way to expense my health insurance. Tax law treated it as a personal expense, not as a business expense, and personal expenses are not deductible.
The turnover rate is caused by corporate policies, such as by not paying employees enough to make it worth their while to stay there. A coworker of mine inquired at a major insurance company based in San Antonio for an IT job. They said "Your skills look great, we'll pay you $20,000 a year." He said "You have GOT to be kidding!"., because his military salary was quite a bit more than that (and the military pays like crap). The hiring manager sighed, and said "Yeah, I know, I can only get kids fresh out of vocational school and I'm tired of training them and then seeing them go to work at other places."
Point being that it was corporate POLICY to hire kids for peanuts in full expectation that after putting a year of work, those kids would go elsewhere. They figured they got "good enough" work out of their cheap employees, and it saved them money. Their response to the IT shortage is illustrative -- they were one of the biggest enthusiasts for increasing the number of foreign IT specialists that could be imported on special visas. They figured that'd let them hold on to their kids for a few months longer, since there would be fewer higher-level jobs open to them (since the kids are woefully underqualified compared to the typical Indian programmer). That's how corporate snakes think, y'see.
Point: Employers who give a **** about their employees don't have those kinds of turnover problems. You can bet that employers who have those kinds of turnover problems typically have fascist environments that monitor everything, office politics rather than ability detirmines advancements, they require regular piss tests, have dress codes that are more conservative than Wall Street, and require two reams of paperwork to requisition a stapler. Sometimes these guys even pay well, but it just isn't worth the hassle of working there.
I've been both contractor and employee. When contractor, I turned in my hours and produced lots of "good enough" code, but felt no obligation to do anything better than that.
As an employee, I know that I'm going to be sticking around and probably MAINTAINING that code at some time in the future (even if I move to another project, I always find myself getting pulled back to patch up older projects to deal with unexpected contingencies), and thus I'm more likely to put the code together right in the first place. Take as an example the encryption code that I'm working on right now. I could have just taken any crappy old pseudo-random number generator and got good enough code that worked well enough for marketing purposes (albeit not cryptographically secure, but hey, it's a marketing checkbox). Instead, I took the time to put some DESIGN into it (if you look at sci.crypt you'll see part of the thought processes underlying that design). I wouldn't have done that if I was a contractor. I would have grabbed any old PRNG and rammed it in there, because the whole point of being a contractor is to go in, get the job done, and get out.
Anyhow: Contractors are hit'n'run, employees stick around. You need them both -- the project that I am working on could very much benefit from some contractors for a three-month time period, I have partitioned it off into a number of smaller projects that I can get a contractor working on in a jiffy. (Thank you Unix, "many small tools chained together" works!).
Think of it as the Microsoft approach ("good enough" code) vs. the ideal approach (code that is designed for expandability and maintainability, code that has some DESIGN behind it).
Microsoft has hired trolls (whoops, "online evangelists") in the past to bash competitors, what makes you think they have changed their stripes?
My own guess is that they have at least two and probably around five people in their anti-Linux squad (which had around 30 people in it the last time a Microsoft insider posted the number here) whose sole job is to make the rounds of the pro-Linux sites trying to disrupt them. This would put their anti-Linux efforts onto a similar scale to their past anti-OS/2 efforts along those lines. These jobs are in the marketing department, by the way -- do you seriously doubt that MS has plenty of money to hire marketroids?
I'd still log out and go through a trusted anonymous redirector before posting to Slashdot anonymously. And even then it's possible they'll find you, via traffic analysis (hmm, request goes into redirector from X at time T, request goes out from redirector to Slashdot at time T+1, voila!). If you think the NSA is not monitoring traffic going to and from the overseas redirectors, you're nuts.
Of course, the overseas redirectors are safe from ADM, be that as it may, so don't get too paranoid. Of course, U.S. and Canadian redirectors aren't. A court order can grab their log files. Bletch.
Err, block ciphers of 128 bits or greater are safe for the time being. The output of known good block ciphers, such as the five AES candidates, is statistically indistinguishable from random noise. The only real attack that can be made is differential attacks, and that appears to be a problem only for DES, which is why the NIST is retiring DES in favor of a new American government encryption standard (the AES candidates). If you use Bruce Schneir's "TwoFish", a derivative of "Blowfish" and the best known of the AES candidates, you can pretty much be assured that you're safe -- all of the five AES candidates have been extensively cryptanalysed (especially by their competitors, all of whom are looking for a weakness in the others' algorithms!). RSA public key encryption, on the other hand, could be succeptible to new solutions to the underlying "factoring problem". (Public key encryption uses the product of two large strong primes and relies on the difficulty of factoring very large numbers to provide its strength). There are varieties of public key encryption which use exponential equations distributed over a field (ElGamal) or elliptic curves (see http://www.certicom.com/ for info there) as the underlying "hard problem" rather than the factoring problem, but they have not been as widely cryptanalysed. Actually, elliptic curve cryptography is just now getting to the point where I think it's been analysed enough to be safe, but any public key encryption algorithm implicitly has a relationship between the public and private keys, so public key encryption is always succeptible to new revelations in mathematics, and the NSA has some of the best. Which won't help them crack a message encoded with 256-bit TwoFish! But I would say that 512-bit RSA is toast, and 1024 bit probably would take the NSA spooks only a few days at most on their big specialized RSA cracker machines. (But note that someone "inside" has stated that the NSA doesn't even need to crack RSA for the most part, because people's computer security is so bad that usually they can walk right in and intercept the cleartext BEFORE they're encrypted).
Keypunching or scanning the code in off of a printed research paper (note that a printed "book" with a few lines describing the algorithm and the rest being the algorithm qualifies as a "research paper" as far as the US DOJ is concerned) is okay, and the USA cannot put you in jail for doing so since you are not a US citizen. You can in fact put your code up for grabs on the Internet. See http://www.replay.com for an example.
On the other hand, while you will not be prosecuted for using false pretenses to gain access to U.S. code and then putting U.S. code on international servers, the authors of that code may very well be prosecuted. Phil Zimmerman (PGP) spent years with the hounds of the US Government on his tail. In addition, many countries do have recipricol agreements with the US that they will not re-export US code in exchange for various special favors. Canada is an example, that is why only a version of Kerberos 4 re-coded from the "bones" by foreign nationals is part of OpenBSD, even though Kerberos 5 is available from the worldwide crypto archives (via the same print-out-then-scan-back-in mechanism). The difference is that Kerberos 5 was not re-coded from the "bones" and thus qualifies as U.S. code as far as Canada is concerned.
Academic discourse is protected under the First Amendement, according to the DOJ, and thus will not be prosecuted under the regulations even if foreign nationals can see it. Bernstein is trying to get source code classified as academic discourse (see the EFF home page).
Atomic bombs are export-controlled, but as a U.S. citizen you cannot go to Pakistan and help them with their atomic bomb project. The notion is that this is like yelling "Fire!" in a crowded theatre -- i.e., that the purpose of the speech counts, you can yell Fire! all you want to in the privacy of your own home or in a cow pasture, but not where it can harm others.
The RSA incident may be from "The Codebreakers", I don't remember it in Schneier (though I have not memorized Schneir -- yet -- so it may be in there).
The fiction is that publishing papers is "academic discourse" and thus is protected by the First Amendment, while source code in electronic form is a "mechanism" and thus covered by the commerce clause. Actually, even publishing papers internationally would technically be against the law that prohibits "technical assistance" to foreign nationals, if I'm reading the draconian CFR correctly, except that the Justice Department has issued a directive that they won't prosecute cases that clearly are First Amendment cases.
See the EFF site for the Bernstein case, which is trying to get source code classified as academic discourse too.
I don't personally care. If the Federal Government wants to prosecute me because I've been fuddling around on sci.crypt and posted some thoughts about Diffie-Hellman in a place where foreigners could see, it, screw them.
But dozens of people rely on my employer for their living, and he's not going to jeopardize his company by saying "screw you!" to the government. So he's not going to export a product containing strong encryption in violation of the regulations, because they could fine him millions of dollars and throw the whole executive staff in jail, in which case the company is kaput and everybody who's not in jail is out of a job. So he cannot compete with European companies who CAN sell products with strong encryption.
So the final status is that we will have two products: A US/Canada product with strong encryption, and an overseas product which does not have encryption (because the export regulations also require that we track where each copy is sold to make sure it's not re-exported to a company on the "forbidden" list -- hell, we ship these things en-masse to distributors, how'n'hell do we know where they've been sold to?!). So we will be at a disadvantage compared to European competitors. Pisses me off, personally, I think I have great code in one utility that I'd love to release as Open Source, but nobody will ever be able to see it because of those @#$% export restrictions:-(.
-- Eric (EST's crypto expert "because somebody had to do it").
Other countries do have their own crypto. That's the problem. American companies are at a disadvantage because they cannot put strong crypto into their products, while foreign companies can.
The most beloved product by all Unix system administrators is 'ssh', which does encrypted rsh/telnet connections instead of sending passwords in plain text. It was done in (guess what!) Europe, and in fact is illegal to use in the United States unless you buy it from a licensed vendor (because it incorporates the RSA algorithm, which is patented, though only in the United States).
Of the candidates for the AES data encryption standard, a 128-and-256-bit-key encryption standard which will be required to be used by all government agencies and contractors as the replacement for 56-bit DES, three of the five finalists were coded entirely outside of the United States. We may soon be using foreign encryption code to run the U.S. Government!
Not exactly. Source code AS ACADEMIC DISCOURSE is free speech -- in one particular circuit court, and the decision is being appealed. Source code outside of academic discourse is another story altogether. See http://www.eff.org for more info on the Bernstein case.
This is the Bernstein case, and was about posting the source code that went with an academic paper. See the EFF home page (http://www.eff.org ) for more info.
As far as I know it's still tied up in court. I'll just note that the regulations allow academic discourse but unless it takes place on paper and ink the USG doesn't believe it's academic discourse. Bernstein is trying to pry a hole in the rule to say that academic discourse can take place over the Internet too. That still won't help Red Hat export a product that incorporates encryption. (SuSE, on the other hand, has no such problem, since they are not an American company -- in other words, the USG is putting American companies at a disadvantage).
The problem is that most strong authentication mechanisms depend upon public key encryption, which IS export controlled. So, for example, let's say you want to only run binaries which are signed by Red Hat Software or by your Corporate Information Center. They would "sign" the binary by encrypting the MD5 of the binary using their private key, then before you run the binary you check the binary to make sure its MD5 matches the MD5 decrypted using their public key. Thus you can insure that you got a trusted binary and not some barfled one. The problem is that even though this would recieve an export license if you applied for one (because it is an authentication scheme, not an encryption scheme), you cannot include source code, because the source code would be capable of being "misappropriated for non-authorized uses". The GPL means that thus this capability won't go into the kernel.
In other words, the US Government is propping up Microsoft here, since Microsoft can include this capability in their OS. (If they gave a damn, which they apparently don't). But that figures, the US Government is also giving Microsoft huge export subsidies too, at the same time that they're suing Microsoft for monopolistic acts. Quite a government we have, eh?
Flee the USA if you wish, but expect that if you peeve the USG enough, they'll go out and kidnap you in order to bring you back to trial. Heck, Noreiga was president of his whole damned country and you saw how well he fared when the USG decided to kidnap him in order to bring him to trial in Miami (for acts legal in Panama, that occured within the borders of Panama). What makes you think that a little pipsqueak like you or me stands a chance if they get peeved?
The regulation says that if you're an American citizen overseas and working on a product that would require export permission here in the 'States, you're breaking the law. For that matter, an American citizen re-keying the code into a system upon arrival overseas would be breaking the law (since he would be providing technical assistance). For that matter, even printed on paper it's technically against the regulation, except that the regulation allows "academic discourse" and if you print a few academic notes to go with the code it slips through that loophole in the regulation. But don't think you can add a few academic notes and post the source to the USENET, the requirement is that it be printed on paper in order to qualify as "academic discourse", though the Bernstein case is trying to qualify source code in electronic form distributed as part of a book as "academic discourse" too (and he has a good case, but the USG will drag this out forever).
Anyhow, it's all a blatant violation of the First Amendment, but the U.S. government doesn't believe in the Constitution anyhow (see the RICO statutes, which violate the 5th Amendment, for another example), so it doesn't matter.
You're breaking the law even to contribute technical assistance. However, the USG has a "gentleman's agreement" not to prosecute where it feels that they'd lose on First Amendment grounds. But where is the border line? Do YOU want to be the test case who spends the next five years in jail waiting for trial?
Check DejaNews, the appropriate portion of the regulation is posted to sci.crypt and crossposted later (by me) to talk.politics.crypt. U.S. citizens are prohibited from exporting crytography, and are prohibited from providing technical assistance, and if overseas are prohibited from working on products that would require an export permit within the U.S.
Regarding sovereignty the United States Government holds that if you are a U.S. citizen, you must obey U.S. law no matter where in the world you are. The USG has been known to kidnap U.S. citizens in foreign countries in order to bring them to trial here in the U.S. if they peeved the USG enough. Heck, they don't even have to be U.S. citizens -- anybody remember Manuel Noriega, who was (quite illegally) kidnapped and brought to trial in Miami for crimes that did not violate Panama law and that were committed within the borders of Panama?
Slashdot Mirror
It is possible for a "middleware" product like the CryptoAPI to be insecure, but not likely. I still wouldn't trust Microsoft's own encryption modules though (the ones actually CALLED by CryptoAPI). For one thing, a good PRNG to get randomly-distributed keys is VERY hard to write. I just finished writing one because every distributed PRNG that I came across produced predictable keys (meaning that you don't have to brute force all possible keys to break the encryption, just the keys produced by the pseudo-random number generator, which proved not to be so random!). I seriously doubt that Microsoft got the PRNG right, and Bruce Schneier's own "Yarrow" PRNG is perfect proof of that (Bruce has a paper on his site, www.counterpane.com, detailing attacks on a PRNG that will let you crack encryption in MUCH less time than a pure brute-force attack).
-E
There's plenty of interesting things to do within my current employer's walls, and not enough hands to do them all. I don't have to go elsewhere to get variety.
-E
Disconcerting, to say the least.
I think the tendency amongst the non-computer-types who manage IT nowdays is to view their entire staff as toy-happy ne'erdowells always looking for new ways to spend "their" money. If their staff says they need to upgrade their 10baseT network to a switched 100BT network because the current network is completely saturated, they have the same response as if the staff says that they need to buy top-of-the-line SGI workstations for all of the developers' desktops -- both requests are treated the same, as "frivolous techies just want new toys". After all, these IT managers came from finance or sales, they wouldn't know a network switch from a light socket.
An outside consultant, since he is not going to be the one playing with the "new toys", is viewed as more dispassionate by the PHB. Which, in turn, discourages employees, who then contribute to that turnover problem by going elsewhere or going contract...
-E
In short, the H1B's reduce this insurance company's expenses even though they'll never hire an H1B. Simple supply and demand -- if the supply is higher and the demand is constant, then the price of the commodity (the fresh-out-of-technical-school kids that they hire) gets cheaper. (And yes, they view these kids as a commodity -- "human resources", you know, just resources like any other resources used by the business, except for the little nit that they happen to be human).
-E
As you said, "Manage them properly and make some deliverables like documentation and archives of buildable code". Deliverables are what people pay contractors for -- not thoughtful design. They want deliverables in as little time as possible, which is not always the way to produce great code (though I was always careful to turn in good enough code, i.e., that did the job and was reasonably maintainable, but there was no time for the kind of polish that would make the code base shine).
Sorry about your experience with hiring an employee. But he would have been the same way as a contractor. Blaming an entire group of people for the actions of one bad apple is not a rational thing to do in any event.
-E
-E
At least when I was contract on a 1099, I couldn't figure a way to expense my health insurance. Tax law treated it as a personal expense, not as a business expense, and personal expenses are not deductible.
-E
Point being that it was corporate POLICY to hire kids for peanuts in full expectation that after putting a year of work, those kids would go elsewhere. They figured they got "good enough" work out of their cheap employees, and it saved them money. Their response to the IT shortage is illustrative -- they were one of the biggest enthusiasts for increasing the number of foreign IT specialists that could be imported on special visas. They figured that'd let them hold on to their kids for a few months longer, since there would be fewer higher-level jobs open to them (since the kids are woefully underqualified compared to the typical Indian programmer). That's how corporate snakes think, y'see.
Point: Employers who give a **** about their employees don't have those kinds of turnover problems. You can bet that employers who have those kinds of turnover problems typically have fascist environments that monitor everything, office politics rather than ability detirmines advancements, they require regular piss tests, have dress codes that are more conservative than Wall Street, and require two reams of paperwork to requisition a stapler. Sometimes these guys even pay well, but it just isn't worth the hassle of working there.
-E
As an employee, I know that I'm going to be sticking around and probably MAINTAINING that code at some time in the future (even if I move to another project, I always find myself getting pulled back to patch up older projects to deal with unexpected contingencies), and thus I'm more likely to put the code together right in the first place. Take as an example the encryption code that I'm working on right now. I could have just taken any crappy old pseudo-random number generator and got good enough code that worked well enough for marketing purposes (albeit not cryptographically secure, but hey, it's a marketing checkbox). Instead, I took the time to put some DESIGN into it (if you look at sci.crypt you'll see part of the thought processes underlying that design). I wouldn't have done that if I was a contractor. I would have grabbed any old PRNG and rammed it in there, because the whole point of being a contractor is to go in, get the job done, and get out.
Anyhow: Contractors are hit'n'run, employees stick around. You need them both -- the project that I am working on could very much benefit from some contractors for a three-month time period, I have partitioned it off into a number of smaller projects that I can get a contractor working on in a jiffy. (Thank you Unix, "many small tools chained together" works!).
Think of it as the Microsoft approach ("good enough" code) vs. the ideal approach (code that is designed for expandability and maintainability, code that has some DESIGN behind it).
-E
My own guess is that they have at least two and probably around five people in their anti-Linux squad (which had around 30 people in it the last time a Microsoft insider posted the number here) whose sole job is to make the rounds of the pro-Linux sites trying to disrupt them. This would put their anti-Linux efforts onto a similar scale to their past anti-OS/2 efforts along those lines. These jobs are in the marketing department, by the way -- do you seriously doubt that MS has plenty of money to hire marketroids?
-E
Of course, the overseas redirectors are safe from ADM, be that as it may, so don't get too paranoid. Of course, U.S. and Canadian redirectors aren't. A court order can grab their log files. Bletch.
-E
Err, block ciphers of 128 bits or greater are safe for the time being. The output of known good block ciphers, such as the five AES candidates, is statistically indistinguishable from random noise. The only real attack that can be made is differential attacks, and that appears to be a problem only for DES, which is why the NIST is retiring DES in favor of a new American government encryption standard (the AES candidates). If you use Bruce Schneir's "TwoFish", a derivative of "Blowfish" and the best known of the AES candidates, you can pretty much be assured that you're safe -- all of the five AES candidates have been extensively cryptanalysed (especially by their competitors, all of whom are looking for a weakness in the others' algorithms!).
RSA public key encryption, on the other hand, could be succeptible to new solutions to the underlying "factoring problem". (Public key encryption uses the product of two large strong primes and relies on the difficulty of factoring very large numbers to provide its strength). There are varieties of public key encryption which use exponential equations distributed over a field (ElGamal) or elliptic curves (see http://www.certicom.com/ for info there) as the underlying "hard problem" rather than the factoring problem, but they have not been as widely cryptanalysed. Actually, elliptic curve cryptography is just now getting to the point where I think it's been analysed enough to be safe, but any public key encryption algorithm implicitly has a relationship between the public and private keys, so public key encryption is always succeptible to new revelations in mathematics, and the NSA has some of the best.
Which won't help them crack a message encoded with 256-bit TwoFish! But I would say that 512-bit RSA is toast, and 1024 bit probably would take the NSA spooks only a few days at most on their big specialized RSA cracker machines. (But note that someone "inside" has stated that the NSA doesn't even need to crack RSA for the most part, because people's computer security is so bad that usually they can walk right in and intercept the cleartext BEFORE they're encrypted).
_E
Keypunching or scanning the code in off of a printed research paper (note that a printed "book" with a few lines describing the algorithm and the rest being the algorithm qualifies as a "research paper" as far as the US DOJ is concerned) is okay, and the USA cannot put you in jail for doing so since you are not a US citizen. You can in fact put your code up for grabs on the Internet. See http://www.replay.com for an example.
On the other hand, while you will not be prosecuted for using false pretenses to gain access to U.S. code and then putting U.S. code on international servers, the authors of that code may very well be prosecuted. Phil Zimmerman (PGP) spent years with the hounds of the US Government on his tail. In addition, many countries do have recipricol agreements with the US that they will not re-export US code in exchange for various special favors. Canada is an example, that is why only a version of Kerberos 4 re-coded from the "bones" by foreign nationals is part of OpenBSD, even though Kerberos 5 is available from the worldwide crypto archives (via the same print-out-then-scan-back-in mechanism). The difference is that Kerberos 5 was not re-coded from the "bones" and thus qualifies as U.S. code as far as Canada is concerned.
-E
Academic discourse is protected under the First Amendement, according to the DOJ, and thus will not be prosecuted under the regulations even if foreign nationals can see it. Bernstein is trying to get source code classified as academic discourse (see the EFF home page).
Atomic bombs are export-controlled, but as a U.S. citizen you cannot go to Pakistan and help them with their atomic bomb project. The notion is that this is like yelling "Fire!" in a crowded theatre -- i.e., that the purpose of the speech counts, you can yell Fire! all you want to in the privacy of your own home or in a cow pasture, but not where it can harm others.
The RSA incident may be from "The Codebreakers", I don't remember it in Schneier (though I have not memorized Schneir -- yet -- so it may be in there).
-E
The fiction is that publishing papers is "academic discourse" and thus is protected by the First Amendment, while source code in electronic form is a "mechanism" and thus covered by the commerce clause. Actually, even publishing papers internationally would technically be against the law that prohibits "technical assistance" to foreign nationals, if I'm reading the draconian CFR correctly, except that the Justice Department has issued a directive that they won't prosecute cases that clearly are First Amendment cases.
See the EFF site for the Bernstein case, which is trying to get source code classified as academic discourse too.
-E
I don't personally care. If the Federal Government wants to prosecute me because I've been fuddling around on sci.crypt and posted some thoughts about Diffie-Hellman in a place where foreigners could see, it, screw them.
:-(.
But dozens of people rely on my employer for their living, and he's not going to jeopardize his company by saying "screw you!" to the government. So he's not going to export a product containing strong encryption in violation of the regulations, because they could fine him millions of dollars and throw the whole executive staff in jail, in which case the company is kaput and everybody who's not in jail is out of a job. So he cannot compete with European companies who CAN sell products with strong encryption.
So the final status is that we will have two products: A US/Canada product with strong encryption, and an overseas product which does not have encryption (because the export regulations also require that we track where each copy is sold to make sure it's not re-exported to a company on the "forbidden" list -- hell, we ship these things en-masse to distributors, how'n'hell do we know where they've been sold to?!). So we will be at a disadvantage compared to European competitors. Pisses me off, personally, I think I have great code in one utility that I'd love to release as Open Source, but nobody will ever be able to see it because of those @#$% export restrictions
-- Eric (EST's crypto expert "because somebody had to do it").
Other countries do have their own crypto. That's the problem. American companies are at a disadvantage because they cannot put strong crypto into their products, while foreign companies can.
The most beloved product by all Unix system administrators is 'ssh', which does encrypted rsh/telnet connections instead of sending passwords in plain text. It was done in (guess what!) Europe, and in fact is illegal to use in the United States unless you buy it from a licensed vendor (because it incorporates the RSA algorithm, which is patented, though only in the United States).
Of the candidates for the AES data encryption standard, a 128-and-256-bit-key encryption standard which will be required to be used by all government agencies and contractors as the replacement for 56-bit DES, three of the five finalists were coded entirely outside of the United States. We may soon be using foreign encryption code to run the U.S. Government!
--E
http://www.access.gpo.gov/nara/cfr/index.html
-E
Not exactly. Source code AS ACADEMIC DISCOURSE is free speech -- in one particular circuit court, and the decision is being appealed. Source code outside of academic discourse is another story altogether. See http://www.eff.org for more info on the Bernstein case.
-E
This is the Bernstein case, and was about posting the source code that went with an academic paper. See the EFF home page (http://www.eff.org ) for more info.
As far as I know it's still tied up in court. I'll just note that the regulations allow academic discourse but unless it takes place on paper and ink the USG doesn't believe it's academic discourse. Bernstein is trying to pry a hole in the rule to say that academic discourse can take place over the Internet too. That still won't help Red Hat export a product that incorporates encryption. (SuSE, on the other hand, has no such problem, since they are not an American company -- in other words, the USG is putting American companies at a disadvantage).
-E
The problem is that most strong authentication mechanisms depend upon public key encryption, which IS export controlled. So, for example, let's say you want to only run binaries which are signed by Red Hat Software or by your Corporate Information Center. They would "sign" the binary by encrypting the MD5 of the binary using their private key, then before you run the binary you check the binary to make sure its MD5 matches the MD5 decrypted using their public key. Thus you can insure that you got a trusted binary and not some barfled one.
The problem is that even though this would recieve an export license if you applied for one (because it is an authentication scheme, not an encryption scheme), you cannot include source code, because the source code would be capable of being "misappropriated for non-authorized uses". The GPL means that thus this capability won't go into the kernel.
In other words, the US Government is propping up Microsoft here, since Microsoft can include this capability in their OS. (If they gave a damn, which they apparently don't). But that figures, the US Government is also giving Microsoft huge export subsidies too, at the same time that they're suing Microsoft for monopolistic acts. Quite a government we have, eh?
-E
Flee the USA if you wish, but expect that if you peeve the USG enough, they'll go out and kidnap you in order to bring you back to trial. Heck, Noreiga was president of his whole damned country and you saw how well he fared when the USG decided to kidnap him in order to bring him to trial in Miami (for acts legal in Panama, that occured within the borders of Panama). What makes you think that a little pipsqueak like you or me stands a chance if they get peeved?
-E
The regulation says that if you're an American citizen overseas and working on a product that would require export permission here in the 'States, you're breaking the law. For that matter, an American citizen re-keying the code into a system upon arrival overseas would be breaking the law (since he would be providing technical assistance).
For that matter, even printed on paper it's technically against the regulation, except that the regulation allows "academic discourse" and if you print a few academic notes to go with the code it slips through that loophole in the regulation. But don't think you can add a few academic notes and post the source to the USENET, the requirement is that it be printed on paper in order to qualify as "academic discourse", though the Bernstein case is trying to qualify source code in electronic form distributed as part of a book as "academic discourse" too (and he has a good case, but the USG will drag this out forever).
Anyhow, it's all a blatant violation of the First Amendment, but the U.S. government doesn't believe in the Constitution anyhow (see the RICO statutes, which violate the 5th Amendment, for another example), so it doesn't matter.
-E
You're breaking the law even to contribute technical assistance. However, the USG has a "gentleman's agreement" not to prosecute where it feels that they'd lose on First Amendment grounds. But where is the border line? Do YOU want to be the test case who spends the next five years in jail waiting for trial?
-E
Check DejaNews, the appropriate portion of the regulation is posted to sci.crypt and crossposted later (by me) to talk.politics.crypt. U.S. citizens are prohibited from exporting crytography, and are prohibited from providing technical assistance, and if overseas are prohibited from working on products that would require an export permit within the U.S.
Regarding sovereignty the United States Government holds that if you are a U.S. citizen, you must obey U.S. law no matter where in the world you are. The USG has been known to kidnap U.S. citizens in foreign countries in order to bring them to trial here in the U.S. if they peeved the USG enough. Heck, they don't even have to be U.S. citizens -- anybody remember Manuel Noriega, who was (quite illegally) kidnapped and brought to trial in Miami for crimes that did not violate Panama law and that were committed within the borders of Panama?
-E