December 2003 - cypherpunks-legacy

Anonymous Auth Certificates [was: Re: Blinded Identities]
by Carl Ellison 17 Dec '03

17 Dec '03

P.S. you might also check out http://www.clark.net/pub/cme/usenix.html for more on why ID certificates are useless in any case. - Carl +------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2| | "Officer, officer, arrest that man! He's whistling a dirty song." | +-------------------------------------------- Jean Ellison (aka Mother) -+

1 0

SKIP cryptanalysis?
by Adam Shostack 17 Dec '03

17 Dec '03

Has anyone looked into SKIP key management? I'm aware of Jeff Schiller's statement about OAKLEY/ISAKMP being the more flexible, useful system to be the main standard for IPsec. Adam -- "Every year the Republicans campaign like Libertarians, and then go to Wasthington and spend like Democrats." Vote Harry Browne for President. http://www.harrybrowne96.org

1 0

Re: YES OR NO?
by Alan Olsen 17 Dec '03

17 Dec '03

At 08:45 AM 10/17/96 -0700, you wrote: >On Thu, 17 Oct 1996, Dr.Dimitri Vulis KOTM wrote: > >> It is a great honor to meet a net.legent in person. > >I hope Dimitri will stop hidding behind his computer and "honor" >us with his presence at an SF Bay area Cypherpunks meeting. I've >got pledges for nearly $1200 to bring him out here to speak. All >we need now is a serious response from Dimitri. I guess when the >going gets tough, the "net legends" get yellow. What are you >afraid of Dimitri? I can understand what he has to be afraid of. It is one thing to be a harassing bastard on the net. It is another to have to defend your actions to those people face to face. Dimitri has made insulting remarks about myself and good friends. He has been abusive and obnoxious all over the face of the net. I can see how some people might take that personally. (I would not do him personal harm. Ask him why he feels he needs to be a flaming asshole maybe...) I killfiled Dimitri because there was no use talking to him and no use listening to him. Currently he has taken the tact of posting news when his reputation capitol reaches into the heavy negative numbers. (And I still filter them all into the trash because I cannot trust him to not forge the posts into something containing something the author did not write or intend.) There are others I do not argue with for other, similar, reasons. It is pointless to debate with the closed minded and the compulsive flamers. (If I wanted to listen to compulsive juvenile flame I would go hang out on WWIV BBSes. It least there you know the people are probably fourteen, not just acting like it...) The only purpose such debate will ever serve is to influence the onlookers. The point is probably moot anyways. I doubt if I will get to any of the California meetings any time in the near future. (Work is hell, but at least it pays something. Unlike the regular brand of hell.) --- | "Remember: You can't have BSDM without BSD." - alan(a)ctrl-alt-del.com | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | alano(a)teleport.com |

1 0

EUP_hem
by John Young 17 Dec '03

17 Dec '03

10-17-96. WaPo: "U.S. Considers Slugging It Out With International Terrorism" Officials contend that the main threat now comes from a murky network of home-grown, privately financed and largely independent groups forming a kind of international "terrorists' Internet." That network is proving extremely difficult for U.S. intelligence agencies to locate and penetrate. "Today's terrorists don't have to depend that much any more on states for access to financing or the technological means." "Postal Service Plans to Leave Its Mark on Electronic Mail" Cylink is developing a system for electronically postmarking and encrypting computer messages and Sun and Enterprise Productivity are developing software that will allow bulk mailers to calculate the price of mail shipments on the Internet. The Postal Service predicted that the new system ultimately will account for $5 billion in postage a year, about 9 percent of all postage. ----- http://jya.com/euphem.txt (18 kb for 2) ftp://jya.com/pub/incoming/euphem.txt EUP_hem

1 0

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