- cypherpunks-legacy - lists.cpunks.org

ITAR/real law, copyright
by Greg Broiles 17 Dec '03

17 Dec '03

Sorry for the rushed character of this note - am working on another project which is eating up my available time. I just wanted to respond because I think Tim and Marshall are talking about different ends of the same process. At 03:37 PM 10/16/96 -0800, Tim May wrote: >At 10:56 AM -0700 10/16/96, Marshall Clow wrote: >>A) This is not a change in the law. There is no law regarding export of >>encryption software. >>Congress has never passed any such law. These are State Department >>regulations, and presidential decrees. These regulations, which have the >>force of law to you and me, were never debated or voted upon by our >>elected representatives. They can be changed tomorrow the same way. In >>fact, they can be changed and the public need not even be notified. > >Actually, as Greg Broiles pointed out in an article (on the Cypherpunks >list) several weeks ago, Congress deliberately chooses to delegate much >regulatory authority to other agencies. As I understand the export-license process, there are multiple steps: 1. Commodity jurisdiction request: State Dept decides if ITAR controls the export of the item (e.g., is it a "defense article" or a "defense service" or "technical data", and not public domain, etc.)? 2. If ITAR does control the export, the State Dept decides (based on the characteristics of the item and the identity/location of the foreign recipient and the opinion(s) of other agencies consulted) whether or not to allow the export. The fact that these steps must be taken (and the general procedure for doing so) is a product of the Arms Export Control Act (passed by Congress, at 22 USC 2778 and thereabouts) and the ITARs (22 CFR 120 et seq), administrative regulations promulgated by the Dept of State. (To change the ITARs themselves, State Dept must publish notice of the proposed changes and solicit public comments, as well as make the final regs public in the CFRs and via the Federal Register). So the ITARs are "real laws", at least as real as any others. But the process by which these steps (deciding what will be a "munition", deciding whether or not a particular item is within one of those defined as munitions, deciding whether or not to allow an export) are taken involves policy choices whose motives and processes are not entirely clear, and which can be (and are) changed by the executive branch without notice or opportunity to comment. What I'm thinking of here are the rules like "40-bit RC4 is OK" and "3DES is never OK" and "56-bit DES with GAK is OK" and "disk bad, OCR text OK" which we're discovering through trial & error but are not, to my knowledge, part of the ITARs or elsewhere in the CFR or the USC. Also, Dept of State's decisions about individual exports and items are not subject to judicial review, by 22 USC 2778(h), an interpretation which is being challenged in the appeal in _Karn_. Interested readers might take a look at the district court's opinion in _Karn_ at <http://venable.com/oracle/oracle7.htm> and Stewart Baker's analysis of it at <http://www.us.net/~steptoe/summary.htm>. I think my understanding of the ITAR process is mediocre at best, I certainly welcome correction or clarification, although Jim Bell's predictable and wholly incorrect assertion that administrative regs only apply to government employees would be funny but for the fact that I know ordinary people (not government employees) who have been convicted of violating federal admin regs and the fines they paid (or are still paying), jail time spent, etc were all too real. My summary of admin law is deliberately vague because frankly admin law isn't my strong suit. Perhaps another list member with a superior understanding will fill in the gaps in my summaries. Also, Sean Sutherland wrote to ask (re the SPA's position on copyright liability): >I'm curious, do the Contributory Infringment >and the Vicarious Liability for Infringment By Another Person claims have any >legal basis, or are they just the inane rantings they appear to be? I sent a long message to the list a few days ago (Sunday?) discussing contributory infringement. The short version of the message is "Yes, contributory infringement is valid, but not necessarily in this particular case". And ditto for vicarious liability, although I think vicarious liability isn't even plausibly arguable. They are neither novel nor especially remarkable facets of copyright law, although as Sean notes they do not have explicit textual support in the Copyright act. Vicarious liability is an extension of the legal doctrine of "respondeat superior", e.g., an employer/principal is liable for the actions of an employee/agent for actions taken within the scope of employment/agency. Contributory infringement is an extension of the principles of enterprise liability, where (very generally) people who undertake a common purpose/project will share liability, even where only one party directly caused the actual harm. _Sony v. Universal City Studios_ 464 US 417, 435 (1984). Nimmer on Copyright 12.04[A] notes that it's possible to read 17 USC 106's grant of the exclusive right to "authorize" the exercise of the other exclusive rights as excluding the authorization of infringement by third parties (making the illicit authorizer a direct infringer). But that reading seems awfully technical, and Nimmer cites no cases which rely on it (and later describes it as "overly facile"). In any event, yes, vicarious liability and contributory infringement are viable theories of recovery, but neither seems especially promising. Matt Ghio wrote and asked if a direct infringement must exist before a third party can be held liable for infringement. Nimmer (a relatively authoritative treatise on copyright) argues that it should not be possible to have third party liability without a direct infringement, with a reference to cases I haven't had time to look at yet. (at 12.04[A][3][a], if anyone's fortunate enough to have a copy of Nimmer at hand) -- Greg Broiles | "We pretend to be their friends, gbroiles(a)netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |

1 0

EC patent
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Thu, 17 Oct 1996 14:03:34 +0800 From: James Lee <jlee(a)ccl.itri.org.tw> Reply-To: jlee(a)ccl.itri.org.tw Organization: Internet Tech Div, Computer & Communication Lab, Indudtrial Technology Research Institute Mime-Version: 1.0 To: set-discuss(a)commerce.net Subject: EC patent Sender: owner-set-talk(a)commerce.NET Precedence: bulk +----------------------------------------------------+ Addressed to: set-discuss(a)commerce.net +----------------------------------------------------+ I heard that CitiBank has filed for a patent in Japan with 140+ claims covering many aspects of electronic commerce, security electronic transaction, etc. Does anyone know more about it? What impact will it bring to all SET members? James Lee Director, Internet Technology Division Computer & Communication Laboratories Industrial Technology Research Institute W000/CCL, 195 Chunghsin Rd., Sec. 4, Chutung, TAIWAN 886-3-591-4533(W) 886-3-582-0085(Fax) jlee(a)ccl.itri.org.tw ------------------------------------------------------------------------ This message was sent by set-discuss(a)commerce.net. For a complete listing of available commands, please send mail to 'majordomo(a)commerce.net' with 'help' (no quotations) contained within the body of your message. --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/

1 0

Re: Anonymous Auth Certificates [was: Re: Blinded Identities]
by Hal Finney 17 Dec '03

17 Dec '03

From: Carl Ellison <cme(a)acm.org> > >> >Steve Shear <azur(a)netcom.com> writes: > > > >[much cut] > >> > >> I've been charged with developing an Internet service which needs to assure > >> its clients of anonymity. However, we fear some clients may abuse the > >> service and we wish to prevent the abusers from re-enrollment if > >> terminated for misbehavior. (In your example, it would be the person(s) > >> trying to discover the service host via flood). > >> > >> My thought was to base enrollment on some sort of 'blinding' of their > >> certified signature (e.g., from Verisign) which produces a unique result > >> for each signature but prevents the service from reconstructing the > >> signature itself (and thereby reveal the client's identity). I'm calling > >> this negative authentication. > > The mistake is to think of using ID certificates (like those from Verisign) > in the first place. They don't mean anything. > > You want an authorization certificate, such as produced by SPKI. You need > to know what a key is authorized to do, not what name is associated with > the key. (Sorry about quoting so much, but I liked Steve Shear's succinct problem statement.) I don't see how authorization certificates solve this problem. How would you determine if someone was qualified to receive an authorization certificate? And what would you do to make them stop using the service if they abuse it, and to stop them from getting new authorization certificates? Thanks, Hal

2 1

European Commission on "Illegal and harmful content on the Internet"
by wfgodot＠iquest.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A recently released European Commission Communication on "Illegal and harmful content on the Internet" may prefigure the nature of coming European Union regulatory initiatives concerning the net. This Communication was in response to a 27 September resolution by the Telecommunication Council on "preventing the dissemination of illegal content on the Internet, in particular child pornography." The document reportedly reflects what will be ongoing work to "present practical measures in time for the next Telecommunications Council on 28 November 1996." The Communication describes its aims as: firstly to describe briefly the different types of illegal and harmful content, secondly to examine the technical context in which action can be taken to deal with illegal and harmful content, and finally to suggest a number of practical measures designed to be rapidly implemented Among the points of interest, it states with emphasis that "additional international cooperation is required to avoid 'safe havens' for documents contrary to general rules of criminal law." With respect to anonymous communications it discusses proposed "measures to close known loopholes and improve traceability and that anonymous remailers record details of identity." As is typical of these agendas, the devil will be in the evolving details of enforcement. It looks like 1997 will be a busy year for proponents of greater state control over internet content both here and abroad. If they can conjure up enough sufficiently compelling bogeymen, it could be a very successful one for them as well. The HTML version of this document can be found at: <http://www2.echo.lu/legal/en/internet/content/communic.html> Links to RTF and Word versions along with the accompanying press release and related documents can be found at: <http://www2.echo.lu/legal/internet/html> - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 iQCVAwUBMmaw0tGJlWF+GPx9AQGMLgP+JC5Lyd0NZDukq8AWipUNcDUgb6m16iUN 3smYcPdPYvsUDSWznx7ZQsklQV0oz9u5Ru7s8VoOQfA2wqSoiai3LiUiJg5WkfOg HTAbvVQCeoUaRmkmmbFJSzfqVzGB4VkJRCE4htPmmqYhCwwmMjooTi3bAClySGTD 7YcLjv0pC5w= =4EZY -----END PGP SIGNATURE-----

1 0

Re: DES cracker.
by Adam Back 17 Dec '03

17 Dec '03

[cc'd to cypherpunks] Michael Johnson <mikej2(a)Exabyte.COM> writes: > On Thu, 17 Oct 1996, Ted DiSilvestre wrote: > >... > > As someone posted a few weeks ago, rather than find one message to crack we > > should work on ten or a hundred simultaneously if possible. This seems to > > be the easiest way (assuming we can find this many "good" messages) to > > increase cracking efficiency by orders of magnitude. > > Hmmm... I don't see that this increases cracking efficiency. The suprising > (to me) result is that it doesn't really hurt it any. The increase in > average expected time to find a particular key is offset by the fact that > more keys are tried at once. We could crack just as many keys per year, on > average, but we become less sure of which keys will be cracked first. You do save something: you only need one key schedule per key that you try. You can try the key against multiple ciphertexts. A negative effect is that you might loose cacheing opportunities as code and data are increased. For timings you're likely to get for DES, you suffer from the law of diminishing returns quickly, and the additional keys/sec from doing more keys tapers off asymptotically. The number of keys it would be most efficient to use (say where adding another key speeds things up by less than 1%, or whatever) hinges heavily on the actual balance between how fast the key schedule can be made to go as compared to a CBC block operation (or whatever mode you're attacking). Also the protocol you are attacking, and the position of the known plaintext in this block affects things greatly, the further along the plaintext, the more blocks you have to cycle through, and more data you have to move around. To illustrate the effect, here's some quick cacluations based (loosly) on the timings being quoted. With Peter Trei's projected DES block timing from pentium 90 to pentium 133, and approximate equivalence of ecb and cbc demonstrated by Eric's code (this set of figures is hand-waving: I'm not at all sure like is being compared with like, and we are now extrapolating from extrapolations), combining with Eric's keyschedule timing: keyschedule 12.2us (Eric Young's) DES cbc block = 0.47us (from Peter Trei's extrapolated pentium 133Mhz) n keys | key | DES | elapsed for | elapsed per | at a time | sched | cbc | n key tests | key test | keys/sec ----------------------------------------------------------------------- 1 12.2us 1.4us 13.6us 13.6us 73.5k keys/s 2 12.2us 2.8us 15.0us 7.5us 133.2k keys/s 4 12.2us 5.6us 17.8us 4.5us 224.2k keys/s 8 12.2us 11.3us 23.5us 2.9us 340.7k keys/s 16 12.2us 22.6us 34.8us 2.2us 460.3k keys/s 32 12.2us 45.1us 57.3us 1.8us 558.3k keys/s 64 12.2us 90.2us 102.4us 1.6us 624.8k keys/s 128 12.2us 180.5us 192.7us 1.5us 664.3k keys/s 256 12.2us 361.0us 373.2us 1.5us 686.0k keys/s So 256 keys gives ~9x improvement in keys/sec with these even less accurate guestimates, and using more keys won't increase that improvement all that much, asymptotically tailing off around 9.5x for reasonable numbers (< 64k keys). Improving the key schedule in the second table doesn't add hardly anything, because it is basically irrelevant when you get to 256 keys. (However, a faster key schedule _is_ significant for 1 key at a time). I think that Peter Trei / Phil Karn are fairly close to the limit, and if anything the resulting figure will be a fair bit short of what I have extrapolated because I suspect their peak Mb/s figure will go down when you start doing practical things with the addition of extra data shifting, etc. So it all depends on what corners can be cut in the key schedule, and how much you gain by coding the keyschedule in hand optimised assembler, and all the other factors discussed above, in summary: - keyschedule / CBC block timings ratio - how far into the message is the known plaintext (how many blocks to cycle) - cache limits (additional restriction on optimal number of keys) - extra code overhead over peak cache Mb/s (moving data, extra code) - extra code size and complexity (for multiple key code) Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 1

Re: EC patent
by jim bell 17 Dec '03

17 Dec '03

At 04:53 PM 10/17/96 -0400, Robert Hettinga wrote: >--- begin forwarded text >Date: Thu, 17 Oct 1996 14:03:34 +0800 >From: James Lee <jlee(a)ccl.itri.org.tw> >Reply-To: jlee(a)ccl.itri.org.tw >+----------------------------------------------------+ >Addressed to: set-discuss(a)commerce.net >+----------------------------------------------------+ > >I heard that CitiBank has filed for a patent in Japan with 140+ claims >covering many aspects of electronic commerce, security electronic >transaction, etc. Does anyone know more about it? What impact will it >bring to all SET members? >James Lee >--- end forwarded text Maybe Japanese law is different, but don't I recall reading somewhere that "methods of doing business," business practices in general, are not patentable? Not that it would surprise me if the Patent Office idiots were to change their minds, like they did concerning software, algorithms, and mathematics in general... Jim Bell jimbell(a)pacifier.com

1 0

Netscape Show - Security API
by Ray Arachelian 17 Dec '03

17 Dec '03

I was at the Netscape show and attended the Security API. Looks pretty impresive. The slides for this should be available a week from now on www.develop.netscape.com (?) for those interested. This will be available in Netscape 4.0 Everything is a plug in module, and you can even replace the crappy DES and crippled RSA mods with stronger ones and even write a PGP signature checker/signed/encryptor, etc for both server and browser. Very cool stuff. PGP was actually mentioned! Catch is this: the international version is again crippled, however it is interesting to note that they got a module loadable crypto API to pass ITAR. They did this by having the international versions check modules for signatures that say "US Export Allowed" :) Possibilities around this (not that I am advocating any, just restating what was said): export the USA version (of course breaking the ITAR), modifying the code that checks the signature and allow it to load any module, making a DIFF file between versions and exporting that (would this be legal?) They mentioned (someone asked) that the signature authentification methods that check a module are part of the same API, but hinted that they couldn't be overridden. This could of course be tested, and hopefully they can be disabled. :) But time will tell. There was also some talk of expiring signatures - not sure if it was regarding modules or mail or key certificates. If module signatures expire every six months that would make an interesting situation. In the USA, you can write any module to do anything! Would be cool to have a Netscape Mail PGP set of modules!!! This could indeed solve the problem of having software that's secure and yet also easy to use. What sucks is that someone in England couldn't write their own plug in modules to get better crypto for use in the international versions. Perfectly legal in the point of view of international laws and ITAR, but crippled! Netscape says they won't sign non-USA produced crypto modules for the international versions -- or at least that was the message they gave. The folks at Netscape said that the US Government (NSA wasn't mentioned) did not want the situation to exist that someone from outside could build stronger crypto and have it be imported to the USA... Looks like we have an Iron (Crypto) Curtain situation here. In the end the USA suffers since we are only one country, but I won't start ranting on that here since it's been discussed to death already. :) Several folks from outside the USA, one guy from England actually did express concerns at this problem. Some of the authentification methods they were showing were smart cards and such, and one of the comapnies there was giving eval models out! Litronic had a couple of models - one a serial port one (9600 only with 512 bit RSA, also 768 bit, 1024 bit models will be due out in mid '97) the other plugs right into the keyboard grabbing your keystrokes before they reach the application! If you need eval models for your company to do development call'em at 714-545-6649 or go to contact them at litronic.com, whatever. :) The serial port model is likely to be the most useful since it (should?) work on PC's (Running Linux too!), Suns, Macs, and even C64's. :) Not sure if the API for this is software or an RS232 protocol, if the latter, these will work with pretty much anything. Not sure how trustworthy they are, after all you can't disassemble the smart cards and check their properties to make sure there are no holes, but possibly a dual method would work. That is, send a message to the card, have it sign or encrypt the message with the private key, take that signature/encrypted message, and also ask the user to type in a second passphrase (or use the same hashed differently) that's handled on the local machine. If the user has both, even if the card is crippled, you are secure, and even if someone finds the card they won't be able to use it. (I won't go into rubber hose key recovery here or any other details, see Tim C. May's excellent Cyphernomicon if you need background info on that.) Over all, the message I got from this is that Netscape is doing the right thing, they are for strong crypto - but are forced to abide by the ITARs. They are for voluntary key escrow for companies, NOT mandatory key escrow. They'd like to provide strong crypto functionality to all and would if not for the ITARs. ============================================================================= + ^ + | Ray Arachelian |FL| KAOS KERAUNOS KYBERNETOS |==/|\== \|/ |sunder(a)brainlink.com|UL|__Nothing_is_true,_all_is_permitted!_|=/\|/\= <--+-->| ------------------ |CG|What part of 'Congress shall make no |=\/|\/= /|\ | "A toast to Odin, |KA| law abridging the freedom of speech'|==\|/== + v + |God of screwdrivers"|AK| do you not understand? |======= ===================http://www.brainlink.COM/~sunder/========================= If the Macintosh is a woman... Then Windows is a Transvestite! ActiveX! ActiveX! Format Hard drive? Just say yes!

3 2

Re: Anonymous Auth Certificates [was: Re: Blinded Identities]
by azur＠netcom.com 17 Dec '03

17 Dec '03

>> >> >Steve Schear <azur(a)netcom.com> writes: >> > >> >[much cut] >> >> >> >> I've been charged with developing an Internet service which needs to >>assure >> >> its clients of anonymity. However, we fear some clients may abuse the >> >> service and we wish to prevent the abusers from re-enrollment if >> >> terminated for misbehavior. (In your example, it would be the person(s) >> >> trying to discover the service host via flood). >> >> >> >> My thought was to base enrollment on some sort of 'blinding' of their >> >> certified signature (e.g., from Verisign) which produces a unique result >> >> for each signature but prevents the service from reconstructing the >> >> signature itself (and thereby reveal the client's identity). I'm calling >> >> this negative authentication. >> > >(Sorry about quoting so much, but I liked Steve Schear's succinct problem >statement.) > >I don't see how authorization certificates solve this problem. How >would you determine if someone was qualified to receive an authorization >certificate? And what would you do to make them stop using the service >if they abuse it, and to stop them from getting new authorization >certificates? > >Thanks, >Hal It seems that one crux of the problem revolves around the CA and its method of certificate issuance. A CA which uses biometric data to reduce/eliminate the chance that an applicant could get several, unrelated, certificates issued would provide a basis for negative authentication (similar to a negative credit file). A one-way function performed, by the client, on their certificate from this CA would yield a token which unambiguously binds it to a valid certificate of the CA (and therefore uniquely identifies them) w/o revealing the certificate itself. -- Steve

1 0

Re: European Commission on "Illegal and harmful content on the Internet"
by azur＠netcom.com 17 Dec '03

17 Dec '03

>-----BEGIN PGP SIGNED MESSAGE----- > >A recently released European Commission Communication on "Illegal >and harmful content on the Internet" may prefigure the nature of >coming European Union regulatory initiatives concerning the net. >This Communication was in response to a 27 September resolution >by the Telecommunication Council on "preventing the dissemination >of illegal content on the Internet, in particular child >pornography." The document reportedly reflects what will be >ongoing work to "present practical measures in time for the next >Telecommunications Council on 28 November 1996." > >The Communication describes its aims as: > >firstly to describe briefly the different types of illegal and >harmful content, > >secondly to examine the technical context in which action can be >taken to deal with illegal and harmful content, > >and finally to suggest a number of practical measures designed to >be rapidly implemented > >Among the points of interest, it states with emphasis that >"additional international cooperation is required to avoid 'safe >havens' for documents contrary to general rules of criminal law." >With respect to anonymous communications it discusses proposed >"measures to close known loopholes and improve traceability and >that anonymous remailers record details of identity." > >As is typical of these agendas, the devil will be in the evolving >details of enforcement. It looks like 1997 will be a busy year >for proponents of greater state control over internet content >both here and abroad. If they can conjure up enough sufficiently >compelling bogeymen, it could be a very successful one for them >as well. > It looks as if a functioning AP system can't be here any too soon. I can't wait to bet that these sorts of thought-crime restriction won't be seen as reasonable.

1 0

[NOISE::SECURITY] Disabled ports in Navigator
by Rick Osborne 17 Dec '03

17 Dec '03

I was thinking about how to fix a sendmail program for our server when the (most likely unoriginal) thought cam to me: why not use your web broser as a telnet tool? You could embed CRLFs into the request field and the receiving program would just throw the GET /[etc] out like I messed up or something. I could then add subsequent logins & commands to my heart's content (or the string length of that particular browser's request field). Being behind a firewall, I tend to think of these things. The only problem would be with the fact that no EOL is ever sent, but with a good browser that displays as content is streamed, you wouldn't have to worry about that. Like I said, I doubt it's original because when I tried to do it in Navigator I get a Sorry, Access to the port number given has been disabled for security reasons. error dialog. I got this for all of the obvious ports (21,25,110, etc). I only have 3.0 on my machine, so I don't know if it works with previous versions. MSIE3 doesn't disable the ports, but it doesn't start displaying anything (it suffers from the stupidity of not displaying as it streams). Has anyone else personally tried this? My original idea was to see my home email, with something like: http://mail.here.com:110/user%20me%0D%0Apass [... etc] Any comments, suggestions, etc? Rick Osborne / C++ VB Pascal HTML VRML Java / osborne(a)gateway.grumman.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NSA is now funding research not only in cryptography, but in all areas of advanced mathematics. If you'd like a circular describing these new research opportunities, just pick up your phone, call your mother, and ask for one.

2 1