December 2003 - cypherpunks-legacy

Truth is equivalent to law?
by Jim Choate 17 Dec '03

17 Dec '03

Hi blanc, Forwarded message: > From: blanc <blancw(a)accessone.com> > Subject: RE: Truth can sometimes be harmful...(talk.cpunks.truth) > Date: Fri, 24 May 1996 12:24:23 -0700 > I understood what you meant. I appreciate the general nature of truth, = > in spite of the possibilities for misinterpretations of or = > prevarications from it.=20 What is the 'general nature of truth'? > Jim, a quote for you: > > "We are able to act at all - that is to say, we have the power=20 > to order our conduct in such a way that the ends we desire=20 > can be attained - only because the phenomena of the world=20 > are governed not by arbitrariness, but by laws that we have=20 > the capacity to know something about. If it were otherwise,=20 > we should be completely at the mercy of forces that we should=20 > be unable to understand."=20 > ~ Human Action, Ludwig Von Mises > > Substitute the word "truth" for "laws" and it makes equal sense. We = > would be at the mercy of forces that we could not control, if our = > perceptions and interpretations could not correspond to the actual, the = > real, the truth. So in your mind truth is equivalent to law? In the sense of the above quote the 'laws' that are refered to are general observed regularities that we are capable of understanding. Being a pantheist and hence seeing the entire cosmos as all there is (and hence divine in toto), I can appreciate the original intent (being a physicist helps a little bit). If I accept your equivalency (which I do) then there is no such thing as Truth in the sense of the original discussion. The laws refered to in the quote have the implicit characteristic of being disproved. A characteristic not shared by Truth. I further believe the universe is understandable, just not in toto. It is a little simplistic to believe that every system in the cosmos uses all the regularities that we observe. When followed to its logical conclusion it implies that there may (are) systems which we won't be able to understand in toto (quantum effects come to mind) simply because the system that is our brain either is not complex enough or runs into the Godel paradox. In short, if we assume that we can understand the universe in toto then we have in effect demonstrated that Godel was incorrect. I have covered the ramifications of this previously. Crypto relevancy: many assumptions that we take for granted are based upon proof and 'laws' we ASSUME to be isotropic and homogeneous. If we don't have a clear and present understanding of the 'laws', the procedures used to obtain them, and the limitations of both our 'laws' and the procedures, then we are opening ourselves up for a large dose of security by obscurity. Always question authority, it is simply another human being who does not have your best interest at heart since they have their own agenda. Jim Choate

1 0

Re: [SCARE]: "If you only knew what we know..."
by jim bell 17 Dec '03

17 Dec '03

At 12:26 PM 5/24/96 -0400, Simon Spero wrote: >Libyan embassies don't get bombed. They just have thugs shooting unarmed >WPCs from them under protection of diplomatic immunity (I used to live in >Pimlico, and went to college in South Kensington, and going past the >Yvonne Fletcher memorial always got me upset > >Anyway, they're not just state sponsored terrorists, they're the actual >terrorist state, and can thus can easily get access to whatever >crypto they want; in extrimis shipping OTPs by diplomatic pouch; it's the >smaller, unofficial groups where the case is most easily made. If the Libyans are so bad (and they probably are) then why shouldn't the public in other countries be entitled to pool their contributions and take their government down? (okay, this is a rhetorical question...) Jim Bell jimbell(a)pacifier.com

1 0

Re: PILATE SAYETH UNTO HIM...
by jim bell 17 Dec '03

17 Dec '03

At 07:43 AM 5/24/96 -0700, Sandy Sandfort wrote: >On Fri, 24 May 1996, Jim Choate wrote: > >> Sorry but the very fact that I don't agree with you is proof enough that >> there is no absolute 'Truth' as you use it. > >It isn't obvious that we DON"T agree. It was still a question. >Actually, I rather fancied Bell and May's responses. I just dragged out my copy of a book titled "A Bodyguard of Lies," by Anthony Cave Brown. It's a book on the various deception strategems used against the Germans in the latter part of WWII. This deception plan was given the code-name, "Bodyguard", because Churchill had said in Tehran that "In war-time, truth is so precious that she should always be attended by a bodyguard of lies." Jim Bell jimbell(a)pacifier.com

1 0

Re: Layman's explanation for limits on escrowed encryption ...
by frantz＠netcom.com 17 Dec '03

17 Dec '03

On Wed, 22 May 1996, Ernest Hua wrote: > Could someone with some knowledge of NSA/DoS/FBI intentions please > explain why key length limitations are necessary for escrowed > encryption? In their paper (Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure), McConnell and Appel state that they are willing to allow 80 bit GAKed hardware to be exported, but only 64 bit software. They state the reason for this difference is because it is harder to hack the hardware to defeat the GAK. Now we all know that, should this proposal be adopted, the four horsemen will use some non-GAKed cypher system, e.g. PGP, inside the GAKed envelope. When privacy is outlawed, only outlaws will have privacy. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Denning Sums Key Escrow
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Professor Dorothy Denning has an impressive accounting of 30+ key escrow systems, dated May 1, 1996, at: http://guru.cosc.georgetown.edu/~denning/crypto/Appendix.html This pointer came from "Marg's" report on a Denning seminar in February at: http://www.dstc.qut.edu.au/MSU/staff/marg/denning-sem.html Marg's site also has pointers to an impressive array of worldwide E-commerce and security links at: http://www.dstc.qut.edu.au/MSU/staff/marg/ecom.html ----- Thanks much, Marg.

1 0

Re: VIRUS ALERT: Java virus that affects Netscape 2.0 & 2.01.
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 7:45 AM 5/24/96 -0500, Adam Shostack wrote: > Hype about Java and a move to a policy based security >mechanism are not incompatible. Perry's security model will probably >be NO Java, NO Livescript. Mine might be only Java signed by McAffee >can get more than 3 seconds of CPU time, or access remote network >ports on the server it came from, no other code can run. I would like to be able to enforce a policy for Java applet CPU time which says, the applet can have as much time as it wants/needs constrained by: (1) I can always determine how much it is using. (2) I can kill it without killing other processes/threads including the browser. (3) Without interfering with 1 or 2, I can set its priority in relation to other programs running on my machine. In the long term, I would like the ability to sell CPU cycles to Java applets. (Or donate cycles to projects I support.) ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: (Fwd) Re: TCM: mafia as a paradigm for cyberspace
by pjb＠ny.ubs.com 17 Dec '03

17 Dec '03

Right, someone tells your wife that you are sleeping with someone else. The truth, does it hurt? (-: -paul > From cypherpunks-errors(a)toad.com Thu May 23 23:20:18 1996 > X-Sender: sandfort(a)popmail.crl.com > X-Mailer: Windows Eudora Pro Version 2.2 (32) > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Date: Thu, 23 May 1996 13:06:15 -0700 > To: jim bell <jimbell(a)pacifier.com> > From: Sandy Sandfort <sandfort(a)crl.com> > Subject: Re: (Fwd) Re: TCM: mafia as a paradigm for cyberspace > Cc: cypherpunks(a)toad.com > Sender: owner-cypherpunks(a)toad.com > Content-Length: 396 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > SANDY SANDFORT > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > At 12:11 PM 5/23/96 -0800, jim bell wrote: > > >Tell ya what: name a weapon that CANNOT be used to harm an > >innocent person. Go ahead, I'm waiting. > > The Truth? > > > S a n d y > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >

2 1

Re: Floating Point and Financial Software
by Bill Stewart 17 Dec '03

17 Dec '03

Did that earlier posting really mean Digicash code uses 16-bit quantities for moving money around? Yow! The API says 32 bits. 32 bits isn't enough precision; 64 bits is almost always enough. Floating point gives you about 53 bits, which is usually enough, but it fails badly for accounting. The problem is that the amount of precision in a floating-point calculation depends on the magnitude of the numbers, so A+D and B-D may have different roundoff errors, which is a Very Bad Thing when you're trying to move $D from A to B. Floating point is fine for deciding how much money to move, but you have to move the same amount in each calculation. Otherwise, if there's no clever salami-attack programmer siphoning off the roundoff error, little half-bits of salami get created or destroyed on every transaction, leaving a random-walk amount of spam or anti-spam splattered all over the accounting system, which is Not Good. And, of course, translating fractional decimal numbers of dollars into floating-point binary creates another roundoff spam event, while fixed-point systems would just use pennies or mills or microbucks and operate integrally, only doing roundoff for multiplications such as interest-rate calculation or /12s where you're deciding how much money to move from account to account.* Currency conversion is a good example - floating point may give you the most accurate number of dollars to move for a transaction of some integral number of yen, ecus, or zorkmids, which will generally be non-integral. Suppose Alice and Bob have ECU-denominated accounts, and Alice pays Bob 1 dollar, or ECU 1/1.2299=0.8130742336775 **. If Alice's account has, say, 3.1459265 million dollars' worth of ECUs, and Bob's has 2.718128459045 ECUs, it's easy to lose 4.6566e-10 ECUS in the transaction, and probably more if you didn't have decimal conversions. 64-bit integers let you use, say, millionths of a cent as your currency, with values up to +/- 8 trillion, which will handle the US Federal Debt for another couple of years, though more bits let you use the same code for anything from micropayment to hyperinflated currencies. One motivation for floating-point is historical computer power limits: bignum arithmetics on 8086s takes lots of work, especially in languages like Pascal or BASIC without abstract data types, and it's slow, while the 8087 chip was far faster, and handled big enough chunks of money for almost anybody who was doing their accounting on a PC instead of a Mainframe. [*My paycheck at AT&T often includes an Annual Penny Adjustment at the end of the year to correct for the monthly payments for salaries that aren't divisible by 3....] [** ECU value from WSJ May 13. Ukrainian Karbovanets were 183300/dollar.] # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 # goodtimes signature virus innoculation

1 0

Re: the NRC report on National Cryptography Policy
by CRYPTO 17 Dec '03

17 Dec '03

Please post widely. To whom it may concern: The Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) has completed a congressionally mandated study of national cryptography policy. The final report, Cryptography's Role in Securing the Information Society, will be released to the public on May 30, 1996 at a public briefing. A large number of the authoring committee members will attend. The public briefing will take place in the Main Lounge of the National Press Club, 14th and F Streets, N.W., Washington, D.C., from 1:00 PM to 3:00 PM, on Thursday, May 30, 1996. Committee members will respond to questions from attendees, and a limited number of pre-publication copies of the report will be available at that time. By the close of business on May 30, a summary of the report will be made available through http://www2.nas.edu/cstbweb; the full publication will be made available when final printed copies of the book are available (probably around the beginning of August). The committee also intends to conduct a second public briefing on the report in Menlo Park, California at SRI International. The briefing will be held in the Auditorium of the International Building from 10 to 11 am on Wednesday, June.5. The address is 333 Ravenswood Avenue, Menlo Park, California, 94025. For more information about the briefing at SRI, contact Alice Galloway at 415-859-2711 (alice_galloway(a)qm.sri.com) If you have suggestions about other places that the committee should offer a public briefing, please let me know (crypto(a)nas.edu or 202-334-2605). If you wish to be kept informed of various other public activities regarding dissemination of this report, you can sign up for an e-mail list by visiting the web page http://www2.nas.edu/cstbweb/notifyme.html. I apologize to you for the short notice on this invitation, but hope that you will be able to attend. Herb Lin Senior Staff Officer Study Director CSTB/NRC Study of National Cryptography Policy

1 0

Re: Is Chaum's System Traceable or Untraceable?
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"iang(a)cs.berkeley.edu" 23-MAY-1996 13:56:31.71 >Ah. I see I was misunderstood. The goal was not to make the shop anonymous, >but rather to be able to provide change to an anonymous payer. I had thought that the basic purpose of the fully anon system was just that - full anonymnity for payer and payee. Under your suggestion, the shop gives up this anonymnity under these circumstances in order to be able to make change. I'm not sure if I would call that a very good tradeoff... -Allen

3 3