December 2003 - cypherpunks-legacy

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: Runtime info flow in Java
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:09 AM 5/24/96 -0700, Lucky Green wrote: >At 20:06 5/23/96, Norman Hardy wrote: > >>I am interested in your paper because you define the problem as we do. >>There are some who think that capability architectures are the solution. >>There is little information on how to solve these problems with >>capabilities. I am trying to find time to address some of these issues. > >I walked away from your presentation of KeyKOS with the impression that a >capability system to be secure it would have to be implemented at the OS >level. >Can you build a such a system on top of an insecure OS, as Java would have >to do? Let me take a couple of stabs at this question. A lot of the answer depends on what you mean by secure. For example, if the Java run-time can successfully contain Java applets so they can't access any of the unsecured portions of your OS, then it doesn't matter that those OS holes exist as far as protection from the applets is concerned. The proof that the Java run-time actually can do this containment is left as an exercise for the student :-). Capabilities could be used to give specific Java applets access to specific resources on your computer system. e.g. You could give an applet the capability to read a file. In the Java world it would appear as an object with only one method (read). The specific applet object instances which had access to that object could read the file. Others could not. A slightly different view of where capabilities might fit in is on a network of mutually suspicious actors (e.g. the global Internet). Start by assuming that each machine is strongly resistant to attack through the network. (Ironically, Mac/Wintel platforms may be easier to secure in this manner than Unix platforms because they have fewer of the compromised network daemons running. Firewalls already allow Unix networks to approach this level of security.) In this model, you must either trust or contain all the code you run on your machine. We can use certificates (ref: SPKI) to implement network capabilities. These certificates make statements of the form: The holder of the secret key which corresponds to this public key is permitted these specific forms of access to this specific resource on this location (e.g. a URL). These certificates can act like capabilities. They can be passed by creating a new certificate for the receiver which gives it the privileges implied by the old certificate. They can be rescinded in any of a number of ways. Capability certificates allow you to give access to specific resources on your machine with public key authentication to prevent spoofing. Because they support one or more techniques for the holder to pass the capability to others, they allow subcontracting computation to other machines in the network. I will note in passing that ACLs do not allow for subcontracting. Regards - Bill ------------------------------------------------------------------------ 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: FTC online workshop on privacy
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"declan+(a)CMU.EDU" "Declan B. McCullagh" 23-MAY-1996 09:57:37.53 >More to the point, the left and the right come together on privacy issues. >Remember the Christian Coalition's take on national ID cards? "Mark of >the Beast!" (Does anyone have an original cite for this? I also recall >the CC opposing Clipper...) Yes, even the CC types can get some things right. Take a look at the opposition to the Anti-Terrorism bill, for instance. Quite a few militia organizations are Christian fundamentalist in orientation (unfortunately); they were in alliance with the ACLU in opposing it. However, the objection to banning address lists of interference with private business still stands, so long as the addresses are not gotten from governmental or quasi-governmental (e.g., allowed/regulated monopoly/ogliopoly) sources. -Allen

1 0

Re: Long-Lived Remailers
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"hendersn(a)zeta.org.au" 23-MAY-1996 11:35:09.98 >I really like this idea. How about instead of a full-scale remailer being >the final jump of the message, you have a _very_ simple remailer set up >along the lines of anon.penet.fi. No encryption, just strip off the headers >and send the message to its final destination. Sorry for being clueless in >how this works(I'm learning as fast as I can), but wouldn't this kind of >system be incredibly easy to start up and fold? You could have a host of >such final emanation points winking in and out of existence while the actual >encrypting remailers remain relatively safe. Well, an anon.penet.fi one has the disadvantage of not encrypting between the final sendings.... which means that it's relatively easy to trace back a given message to whatever remailer sent it, via traffic monitoring. A forwarding remailer that decrypted mail according to a published key would get around this, especially if it were being run out of a POP or other email forwarding account (otherwise, the operator of the system could just look and see what the private key was, and thus be able to trace back). -Allen

1 0

Please Post Widely -- The NRC Cryptography Policy Report
by CRYPTO 17 Dec '03

17 Dec '03

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: An alternative to remailer shutdowns
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"sunder(a)dorsai.dorsai.org" "Ray Arachelian" 23-MAY-1996 16:51:17.15 >One flaw in this is that some systems (my isp, dorsai, included) shut off >the finger daemon for security reasons. In this case, the remailer >should store the anonymous message on its hard drive for upto a week and >send a notice message to the target asking them if they want to receive >the email or not, and how to deal with future anonymous requests The >remailer then has to keep a table of those recipients for whom finger fails. One other reason to have such a voluntary message is to account for users/nyms who wouldn't want that they receive anonymous messages to be made public. For instance, that would clue in someone that they might have a nym at a nym-server, thus narrowing down the field for traffic analysis and forensic stylology. >While this is going to eat up a bit of space on the remailer, space could >be limited for the user, etc. If the space on the server runs out, what >do you do? The remailer should still inform the target, but again a >policy question rises - does the remailer send the message anyway, does >it delete the message but inform the target that "Sorry dude, you had an >anonymous email, but I had no room to store it and so I delted it. IF >you don't want it delted the next time around, activate finger tags >thusly, or send a reply to this message with "Accept Anonymous Email" or >"Reject Anonymous Email" as the subject and I'll respect your wishes from >now on"??? The latter has the advantage of preventing spamming via flooding the remailer. >Another thought is that we could set up some universal remailer allow >fingering service where the remailers can use some server somewhere or a >list of servers somewhere to look up a user's email address and see if >they are willing to receive anonymous email. Sort of like PGP key servers. The possible problem of improper information going out (as per the finger idea) is also the case with this one. -Allen

1 0

Re: FYA: "The ANOREV INTERCEPTS" [Usenet censorship] (fwd)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"llurch(a)networking.stanford.edu" "Rich Graves" 24-MAY-1996 01:09:35.99 (quoting tallpaul) >Because of the role I played in the campaign to get people to VOTE NO >on "rec.music.white-power" many people have sent me e-mail asking about >the vote results on several political news groups on the internet. The >following is the latest data available as posted in the official USENET >news group called "news.groups". Oh? And were you, tallpaul, behind the mailing to uninvolved mailing lists of politically-biased pleas to vote "no" on that group, sans a copy of the CFV? If I had had time, I would have voted in favor of it on those grounds. >R. Graves was the original proponent of TPN-S. He had opposed the >earlier RMW-P group but on technical, not political reasons, and he >does, as he once put it, "not consider [himself] anti-racist." Rather >Graves opposition centered on whether the nazi news group had >demonstrated sufficient interest as a music group, whether it had been >properly proposed in terms of proper USENET/uunet electronic paperwork >at the like. I have read over the proposal in question, specifically its latter version. It has a robomoderator that attempts to reach the laudable goal of reducing inappropriate crossposting by persons arguing on this issue. While I have my doubts about how effective this is likely to be (looking for whether approximately identical posts with the same subject line had been posted to the excluded groups would probably be necessary, to prevent spamming tactics from being used), it is a valid goal. >Highly skilled technically, Graves seems quite clueless about the >nature of fascism as a political tendency off the internet in the real >world. He has opposed individual cybernazi dirty tricks in cyberspace, >including some first-class technical tracking of cybernazis using >anonymity and other devices to hide their identities. On the other >hand, he has announced, for example, that there are only some one-to- >two thousand hardened nazis in the entire world. To my knowledge, Rich has not opposed anonymnity; indeed, he has praised anonymnity as needed on groups such as alt.revisionism. I would be interested in hearing whether tallpaul supports anonymnity; it appears to be on-topic for cypherpunks. (Interestingly, the address from which various non-political mailing lists were sent the aforementioned improper email was either quickly shut down or the product of email header faking, according to the results I got when I emailed the person back with a letter of protest.) I would also suspect that tallpaul may be biased on his estimates of the number of full-blown nazis in existence, although this admittedly depends on definitions; activists are prone, often innocently, to overinflate the problems with which they deal. (I refer interested parties to the statistics on rape customarily used by those promoting action against it; they typically include such occurrences as sexual harrassment - a usage of free speech. While I disapprove of sexual harrassment and tend to regard rapists as proper subjects for the death penalty, I wish activists would be more accurate in their statistics.) >Graves's new view threatens additional ominous organizing by cybernazis >on the net as they go for an additional news group even before the >results of their previous organizing effort is announced. Cybernazi organizing is an inevitable consequence of the ability of all minority political groups to organize better thanks to the Internet. They have as much right to organizational activity as anyone else - including anti-fascist activists such as tallpaul. I would suggest reading over some issues of CuDigest with my contributions in them for further discussion on this matter. -Allen

1 0

middleman remailer available on hacktic
by Flame Remailer 17 Dec '03

17 Dec '03

The middleman remailer software is now available for download. The file middleman.tar.gz can be found on ftp.hacktic.nl in /pub/replay/pub/incoming and /pub/replay/pub/remailer. Installation instructions are included. middle-man-admin(a)alpha.c2.org

2 1

Re: Children's Privacy Act
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:45 AM 5/24/96, Rich Graves wrote: >I recognize that criminalizing the free flow of information is like trying >to stick your finger in a dike, but every little bit has an effect. In >this case, I'd call it a positive effect. > >I was certainly disappointed to hear a couple of cypherpunks the other day >discussing for-profit offshore data havens full of personal information >that is illegal to collect in the US as a business opportunity *they* were >interested in pursuing. I just can't see myself doing that, for anybody. >Gubmint or private, doesn't matter. These off-shore data havens, possibly in Anguilla, possibly elsewhere, have long been a motivation for crypto anarchy. "Illegal to collect in the U.S." is the operative phrase. (P.S. Cf. the sections in my Cyphernomicon for a discussion of how the main U.S. credit-collecting agencies (TRW Credit, Transunion, and Equifax) have various cozy relationships with the U.S. government and intelligence agencies. Many of the laws about collection of data are ignored when needed. Ask the credit agencies why and how they willingly participate in the falsification of credit histories, and even the creation of credit histories out of thin air.) --Tim May Boycott "Big Brother Inside" 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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

3 2