- cypherpunks-legacy - lists.cpunks.org

Re: Crippled Notes export encryption
by aba＠atlas.ex.ac.uk 17 Dec '03

17 Dec '03

Lucky Green <shamrock(a)netcom.com> writes: > At 4:17 1/24/96, Timothy C. May wrote: > > >The usual issue: That if a foreign-originated product even appears to be a > >standard (so far, none have been), and includes strong crypto, then the NSA > >and other agencies will simply change the rules. Thus, if extremely strong > >crypto from "Netscape-Zurich" starts to have a significant market presense > >in the U.S., then some law will be passed to restrict it. > > I agree. The reason for enforcing ITAR is to keep good crypto of the > *domestic* market. If ITAR no longer accomplishes that, new laws will be > passed. No need for any new laws or regulations, all that needs to be done is to add crypto to the import list (the opposite, and currently not so widely discussed counter part to the export list). In fact I wouldn't be suprised if the ODTC and NSA could interpret ITAR and the current import list to allow this. (Anyone have an electronic copy of the import restricted list?) Of course this wouldn't be a very popular move, so I'd guess that it wouldn't be tried until a) foreign crypto apps become a significant obstacle to the NSA, and b) other methods have been exhausted. Adam -- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length$n&~1)/2)

1 0

Re: Crippled Notes export encryption
by Dan Weinstein 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- m5(a)dev.tivoli.com (Mike McNally) Wrote: > Dan Weinstein writes: > > >By the way, I really think Netscape should simply ship Jeff and other > > >people to the Amsterdam office... > > > > Wrong, this would be a violation of ITAR. > > I don't understand; are you saying Jeff's brain is a munition under > the ITAR? > > (Is it a citizenship thing? If so, that's an easily solved problem: > hire Dutch (or Egyptian or Bangali or whatever) engineers.) I forget how it is termed in ITAR, but expertise can't be exported either. Another thing to remember is that Jeff and the others at Netscape aren't writing the encryption algorithms themselves, they implement the code that they get from RSA. Though most of the code they get from RSA is already available abroad, if they wanted to import it they would face serious copywrite problems with RSA. Also, like I suggested before any programers who gained their knowledge of crypto programing in the U.S. and then went abroad and developed crypto software would be in danger of prosecution under ITAR if they ever returned to the U.S.. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMQbINb6vSB2TMALlAQG8zAf9FFlCiiYS86Q/ZsiycSXN0w7hT+NdVHI5 8fBVaT+w+OP5DZAbEMg7gM37ryujuDXnRO12WJTa8HTT5+W81TDf6vzgK2yWqShZ kCM6j48nUttwYsXVGUpK2uSSBhLs1+y7lLPObs0I9BNZ9QZ3o/68jpRXnsph3+Oc J4XEe6Yf1u/V4wM58hO8v1fClcCHSyeIFZL+i8NdhcO+BO71qBhOntsGWuVu+sM0 jN7/hix1do+xA856EkRzPoqv0LPcJkCjF3qw+iCKdI7y6LWljA91LJvrYedONu9V cigMrsQF4QFJ2CHrxulolzMPuz4ZNg9K/ZjWoY2t8wgs57dDiojKTQ== =ehWV -----END PGP SIGNATURE----- Dan Weinstein djw(a)vplus.com http://www.vplus.com/~djw PGP public key is available from my Home Page. All opinions expressed above are mine. "I understand by 'freedom of Spirit' something quite definite - the unconditional will to say No, where it is dangerous to say No. Friedrich Nietzsche

2 1

Crypto Exports, Europe, and Conspiracy Theories
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:49 PM 1/24/96, Alex Strasheim wrote: (quoting me) >> The usual issue: That if a foreign-originated product even appears to be a >> standard (so far, none have been), and includes strong crypto, then the NSA >> and other agencies will simply change the rules. Thus, if extremely strong >> crypto from "Netscape-Zurich" starts to have a significant market presense >> in the U.S., then some law will be passed to restrict it. > >But what would they restrict? The use of strong crypto between two >domestic points, or strong crypto where one end is within the US and the >other without? We already have the former -- wouldn't it be hard for them >to take it away? Especially if the software already has a large installed >base, which is your premise? Specifically, I believe--though obviously cannot prove, given the nature of time--that a cryptographically strong version of Netscape developed outside the borders of the U.S. would not be freely importable into the U.S. I don't know what form such a law would take, to answer the point raised in another post by Peter Junger. Nor am I saying either State or NSA passes the laws...the ITARs have worked largely because they have never been challenged; if they were to be successfully challenged and stricken, as even some folks inside the NSA think is likely if tested in a proper case, then a Four Horseman-scared Congress will likely step in with some restrictions. >I'm not denying that there are people in the NSA who would want to react >that way, but I don't think they'd be able to pull it off. > >It is true that the National Security establishment has a lot of power >and influence here. But there are other groups with power as well, and >the security types don't have the ability to do whatever they want >without regard to the opinions and interests of those other groups. And now here's where I will speculate openly, although my speculation is informed by having followed these debates (and even contributing to them) for many years. You have to ask yourself this question: "Why are there no cryptographically strong products--finished products, not specific ciphers or chunks of code--developed in Europe and freely imported into the U.S.?" More specifically, given that the situation with crypto exports being limited (the so-called $60 billion a year problem...even if inflated, still a lot of money) has been known about for a long time, and given that Europe, and to a lesser extent Japan, India, etc., has a strong software infrastructure, you have to ask why "Netscape-Zurich" is not now being imported into the U.S., as a core module that then (for example) the American developers could add additional stuff to. Or why Lotus Notes-Tel Aviv is not being imported, with at least an 80-bit work factor. Or why Digicash is not taking the relatively trivial step of offering extremely strong ciphers (maybe something like Haval?) and blitzing the U.S. market? ("Only Digicash is offering _all_ of our customers the same level of communications security.") (I'll get to some of the practical issues, that the culture of Europe is not quite as conducive as the culture of the U.S. to startups, such as Netscape, Spry, Intuit, etc., but I don't think this gets at the main point of why strong crypt is not being _imported_ into the U.S.) If the business losses are anything really close to $60 billion a year, then companies wishing to have strong crypto should be *screaming* for Europe-developed products to be brought back in to the U.S. There are of course two components to the alleged $60 B a year losses, broadly speaking: * the losses of companies not in the crypt tools business who are losing out because the crypto they are allowed to export weakens their product's attractiveness. * the losses of crypto tool makers who are losing out because their products are not attractive to non-U.S. buyers (Does anyone else out there see a disconnect in the logic here? If Company A is losing business to a non-U.S. Company B, then why is whatever Company B is providing (such as stronger crypto) not being imported into the U.S. For example, if Netscape is losing out to "CERNScape," the hypothetical browser company out of the CERN WWW groups, then why is CERNScape not selling here? In fact, where _are_ the products that are winning out over the crippled American products?) (Understand that I'm not claiming there are no losses, that the $60 B a year figure is not accurate (though I think it inflated a bit), I'm just trying to figure out what's really going on here.) Let's review some points that may be relevant to why "offshore development" has not become a reality, even though one might think it would (given the $60 B figure...that pays for an awful lot of overseas programmers!). First, the "crypto hooks" point we discuss so often. Merely having hooks that link to offshore crypto is a problem, as the ITARs make clear. Thus, Lotus cannot simply say to its non-U.S. customers, "We are shipping a version overseas that contains only 40-bit crypto; you are advised to download 80-bit crypto from http://defeat-itars.lotus-geneva...." I don't know precisely how the NSA and State would react, and what law would be cited (beyond a reading of the ITARs), but pretty clearly this would not fly in the current climate. Lotus might get visits from the NSA, might be threatened with conspiracy to violate the Munitions Act charges, might have its shipments seized, etc. Second, folks at RSADSI told me several years ago that it even violates the ITARs to send cryptographic knowledge out of the country (especially, in this context, with the intention of the folks with the knowledge being the "Geneva" operation of RSADSI, for example). [Note: This is really where all the stuff about exporting code comes from, and why the debate about exporting the RSA-in-Perl t-shirt is not really hitting the main point. The NSA and State have no real concern about copies of Schneier's book going out, given that they know they can't stop it anyway and the stuff in it has already been published worldwide. No, their real concern is ensuring that Lotus does not skirt the whole crypto exports issue by sending a team to an overseas location to develop a core module _there_. Before someone like Duncan protests that this strategy is ultimately--and maybe even soon--doomed to fail, for the many reasons we discuss often, I agree. But for the nonce, NSA and State are trying to fight a holding action, and keeping U.S. companies from distributing strong crypto is currently within their powers in a way that domestic control of crypto is not.] Third, even _interoperability_ is disliked by the NSA. Thus, if Lotus Notes says that it will support an open standard such that its package can communicate easily with Europe-developed crypto modules, the NSA will consider this to be a means of skirting the ITARs. (This was actually the main strength of PGP, as I saw it, that a "standard" could be supported on many platforms, and once the program was proliferated to many countries, all could interoperate. Note that there are very few other such interoperable crypto programs---Lotus Notes talks to other Lotus Notes sites (a chokepoint in controlling distribution), MicrosoftMail and other products talk to other MS products, RSADSI's own standalone crypto program, Mailsafe, talks to other Mailsafe users (again, a chokepoint for distribution), and so on. [Side note: this situation is changing as standards are adopted, as the Web takes on a more prominent role. But I believe it to still be true that strong crypto in the U.S. cannot easily talk to strong crypto in Europe and Asian, except via things like PGP. If I'm wrong, I'd appreciate hearing about some examples.] Fourth, bizarre as it may sound, _imported_ strong crypto may face the same restrictions if attempts are made to _export_ it! Even if the code is unchanged. (The only justification for this position is that the U.S. is trying to create a chokepoint for control...there is no logical reason for a product imported from Israel to then not be allowed for export back to Israel, except that NSA and State hope to interfere with markets and thus have more control over things.) The effect of this restriction is that companies planning to import crypto from, say, Switzerland, and integrate it into their products will still face the ITARs when they try to export the product. And even having _two_ versions, one developed in the U.S. and one developed in Switzerland, will then run into the issues already cited: skirting the law by having hooks, (maybe) engaging in a conspiracy to export cryptographic talent for the purposes of skirting the ITARs, and having interoperable versions. Fifth, there are cryptographically-competent companies and programmers in Europe. Companies such as Crypto AG, companies in Israel, programmers in the U.K., Slovenia, Romania, and all over. (Many on this list, in fact.) And programmers and very competent crypto folks in Australia, New Zealand, etc. Given the relatively small teams that built capable browsers, and given the capable programmers, and given the (alleged) huge losses American companies are suffering for lack of secure products, why are there no Europe-developed browsers with strong crypto? I promised conspiracies. My points above implicitly involve some behind-the-scenes pressuring (and I know this to be the case from first-hand accounts), but here are some more: -- maybe even the European companies have been threatened, perhaps by their own crypto-fearful intelligence agencies (recall the many reports of key escrow talk in Germany, France, Sweden, etc.) -- maybe, as some have claimed, the European crypto companies, such as Zug-based Crypto AG, are actually controlled or influenced by the NSA. (This was a recent thread here, dismissed by the list.censors as "off-topic," but, I think, in actuality a terribly important topic to consider.) -- maybe the Europeans just don't want a piece of the Web browser market, maybe the prospect of a software company reaching a capitalization of $5 billion in less than two years doesn't excite them. (Maybe Clinton didn't inhale.) In a kind of variant of the Fermi Paradox ("Why aren't they here?," referrring to alien visitors), my question is this: "Why aren't we able to solve this pressing problem of not being able to export strong crypto by _importing_ it?" I don't think it's an accident, or laziness on the part of European and Asian companies, that we haven't gotten around the U.S.'s laws about exporting crypto by getting our crypto from competent programmers and companies outside the U.S. Comments? --Tim May Boycott espionage-enabled software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

9 11

Legality of *non*-encryption
by Sparkes, Ian, ZFRD AC 17 Dec '03

17 Dec '03

I heard an interesting new slant on the legality of encryption today. I was talking to a colleague who is employed in a law firm here in Germany. It appears that under the current interpretation of German law, communications of a confidential nature (for example, contracts, medical records and so forth) over an insecure network *MUST* be encrypted to protect the Client. It is therefore a breach of German law to send unencypted eMail, unless it can be proved that every stage of the transmission happens over internal (secure?) paths. I will dig further on this - perhaps there is a useful precedent to be established here. At very least we might be able to keep lawers (and doctors) off the net ;-)

1 0

Top Ten Things to Give to Law Enforcement
by Tim May 17 Dec '03

17 Dec '03

At 3:09 PM -0700 9/18/97, Declan McCullagh wrote: >I just got off a phone with an industry lobbyist. The conversation went >something like this. > >"Can there be a compromise?" I asked. "I don't think there can be one that >will satisfy all three or four parties involved." (I was thinking: law >enforcement, national security, business, and privacy interests.) > >The answer: "I don't think compromise is the right word. But we need to >give something to law enforcement." > Top Ten Things to Give to Law Enforcement: 10. Our first-born children. 9. A lifetime supply of toilet plungers. 8. The Master GAK key Craig Livingstone was able to snarf off the IBM PROFS system before being fired at the White House. 7. A napalm strike called on their chief critics in Congress. 6. An 80-pound suitcase from Tajikistan, to be opened only by Lous Freeh. 5. .... etc. The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Crippled Notes export encryption
by Rich Salz 17 Dec '03

17 Dec '03

>So where exactly do they draw the line? You can still construct your >software in such a way that there is a clean boundary between the >crypto stuff and the rest. Right. However, if you call things like "keysize" as oposed to "state" then they will look askance. >How exactly are crypto-hooks defined? On a case-by-case basis. /r$

1 0

Lotus Notes
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Thu, 18 Jan 1996 20:54:33 -0500 >From: daw(a)beijing.CS.Berkeley.EDU (David A Wagner) >Subject: Re: Hack Lotus? >Hack Lotus? Please do. Perhaps in this case, c2.org could have a "patch Lotus" contest, instead. Help us patch this dumb security hole, by which we're leaking 24 bits of each session key. >I would love to see the internals of how Lotus Notes does the escrow. >Every conceivable way I can see to do it seems very vulnerable to attack. > >If the receiving Lotus Notes program doesn't check whether the high 24 >bits have been escrowed correctly in the LEEF-like field, then a simple >hack to the sending Lotus Notes program to not send the LEEF field >should give foreigners true 64 bit encryption. I think this is the case. The guy who spoke at the RSA conference made reference to the fact that this new version would interoperate with full-strength domestic versions. Getting domestic versions to check for LEAFs only from foreign users is possible, but it would seem to require that Lotus was working on this idea several versions back. Otherwise, when an old domestic version gets a message from a new foreign version, it's going to accept the message without a LEAF. Depending on how Lotus Notes does their key exchange protocol, it may be possible to graft this kind of checking on, so that the older programs will work with it, too, but this doesn't seem likely at all. >If the receiving Lotus Notes program does verify that the high 24 bits >are escrowed correctly, then anyone can verify that, so in 2^24 trials, >I can recover the high 24 bits, and with 2^40 more trials, I can recover >the high 40 bits. Therefore 2^40 + 2^24 trials should suffice to hack >Lotus if this is how it works. This problem is solvable, though I doubt they've bothered. Two ways come to mind--both using information that third parties won't have to fix the problem. 1. Put another 64 bits of random salt into the RSA key exchange blob. Use this to pad the LEAF, so that it's not feasible to dictionary search the LEAF. 2. Define the LEAF as part of the RSA key exchange blob. Pad the LEAF with random bits, unknown to the receiver. Sign the whole key exchange blob. Note that #2 can be countered by hacking the software's copy of the public key. I don't see a way of countering #1 on the sender side only. (Once you get the sender and receiver working together, key escrow seems to become really hard to do.) Now, I'm very interested in whether they thought about this as a potential problem, and thus padded their LEAF intelligently, or left themselves vulnerable to a dictionary-style attack on the LEAF. This translates, roughly, to "was someone with a basic understanding of cryptography involved in this design?" Clearly, IBM has some really good people, and I suspect Lotus did/does, as well. But were they involved enough in the implementation to ensure that this was done intelligently? - From what I heard at the conference, though, I don't think they're even checking to ensure compliance. This implies that the security patch can be pretty simple--clobber the LEAF field with a bunch of random-looking bits. Of course, this tells us nothing about the other possible weaknesses. How well does Notes generate key material? How big are the RSA keys? How well do things like the key exchange protocols work? It looks to me like there are a lot of programs with encryption out there that are lucky to manage even 40 bits of actual security, even if they're allowed 64- or 128-bit keys. >Waiting to hear the technical details of how it works, >- -- Dave Wagner Note: Please respond via e-mail as well as or instead of posting, as I get CP-LITE instead of the whole list. --John Kelsey, jmkelsey(a)delphi.com / kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMQUVGkHx57Ag8goBAQHaRwP/er3/94io/Aa5MQyyluVqohHGyLcP5JBr ZGZMoMydeGnWp5HJ5oGO4WuWDmmqk1NNiHNFd3z8Yxt9S73LR7PvGtoyoucMkX69 f9p4DMED+bJoMWtfukxhtWufeTKDE136eUi/V8155869nAZSHngIF3WLaQCBWFqe 01WEP/GbZtg= =IDZU -----END PGP SIGNATURE-----

1 0

Re: Ultimate Paranoia
by Dagmar the Surreal 17 Dec '03

17 Dec '03

At 05:35 PM 1/22/96 -0500, you wrote: >For the ultimately paranoid: > Don't forget to keep all sensitive info on your standalone >machine on an encrypted filesystem. You never know who might show up >with guns and a search warrant. But this is truly paranoid. And _what_, may I ask exactly, is worng with this sort of security? ----- "In the vacuum of cyberspace, no one can hear the pedestrians scream." -- Dagmar the Surreal (as sold on TV!)

1 0

Crypto Exports, Europe, and Conspiracy Theories
by John Young 17 Dec '03

17 Dec '03

Responding to msg by tcmay(a)got.net (Timothy C. May) on Wed, 24 Jan 4:59 PM A welcome inquiry, Tim. Is it not likely that the best crypto in many of the countries is kept off the market in the national interest, cloaked in the greatest secrecy like other crucial weapons of survival? Especially to defend it from NSA-like predators. Was this not the practice in the US before public key genie escaped? And is surely still the case for the very best US crypto -- not that which can be readily purchased or purloined. The market, and PGP, are probably condoned as a cloak for the best, in the US and elsewhere. Or bait. Or traps.

1 0

Re: Stego-empty hard drives... (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Tue, 22 Sep 1998 08:54:57 -0500 > From: Mark Hahn <mhahn(a)tcbtech.com> > Subject: Re: Stego-empty hard drives... (fwd) > As I recall, this thread is about customs officials booting your laptop > from *their* floppy and scanning your hard drive. I suggest two > practical solutions to avoid this incursion: That's where we started, we're miles away and deep in the woods now.... ____________________________________________________________________ The seeker is a finder. Ancient Persian Proverb The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0