December 2003 - cypherpunks-legacy

Cypherpunk Press <sarcasm>
by Michael Wilson 17 Dec '03

17 Dec '03

<sarcasm alert> Perhaps we should start suggesting to members of the press that they ask the U.S. Congress members how far they take the position of key escrow. After all, the primary government utilization of cryptography is in the military and intelligence community. Given the long, colourful history of rogue operations and criminal actions hidden under the cover of secrecy (including the usage of strong cryptographic systems), we might propose that the U.S. and other governments escrow their own keys--how about the UN, with the Security Council members having the right to decipher messages, or InterPol, or the World Court. After all, if individuals have no right to privacy, why should any organization have one? Is the right to privacy and secrecy something that comes from additive rights? Does it come from possession of military force, up to and including nuclear weapons? What's the line? I personally wouldn't mind knowing the threshold I need to cross to have a 'right' to privacy. It gives me a goal. What is not good for the swarm is not good for the bee. --Marcus Aurelius Antoninus Michael Wilson http://www.7pillars.com/

1 0

"random" number seeds vs. Netscape
by karlton＠netscape.com 17 Dec '03

17 Dec '03

Let me start off by saying that I speak for me and not Netscape. I also tend to be UNIX centric since I know very little (nothing?) about the internals of PCs and Macs. I want to address the bug Netscape has with its currently released product with respect to seed generation. For the most part this is not a crypto issue, but rather a system issue. Those bits of entropy can only be gathered in a system dependent manner. Assumption: We are relying on the MD5 hash algorithm to gather the string of potentially unpredictable sequences. I am assuming that feeding known bits along with the unknown will not compromise the "randomness" of the MD5 state. The basic idea is to feed a sequence of information into the MD5 hash, expecting that some of the bits for each sub-sequence would be only be guessable. If we get enough unguessable bits into the mix, then the weak link in the chain would not be the seed generation. Here is what the client will soon be doing: Netscape is available on Macs, Win-16 and Win-32 versions and 8 different UNIX platforms. The exact details for each platform are quite system specific. The basic idea is to feed a sequence of information into the MD5 hash, expecting that some of the bits for each sub-sequence would be unguessable. At program start On all platforms: Start with the contents of the highest resolution clock we can find on the system. [For instance, an R4000 MIPS processor has a free-running instruction counter. At 100 Mhz this gets incremented every 10 nano-seconds. There are probably a good 20 bits of unguessable value there.] On Macs and Win* systems there are "tick" counters that update 60 (or maybe only 16) times a second. We then push through the time of day, beacause on some sytems, the microsecond part of a time_val has some bits that are only guessable. For UNIX we feed the following into the MD5 hash: ps (-el or aux depending upon system) netstat -ni & netstat -na the user's environment. (We will certainly use this as well in the 2.0 release. The truly paranoid will be able to run whatever seed generator they want and stick the result into their environment. How you protect your environment from attack is up to you. ;-) System specific info such as hardware serial number or system id. If you have specific suggestions for any particular OS/hardware pair, please let me know. For PCs Cursor position Global memory status FreeSpace Drive configuration Number of running tasks Environment strings UUIDCreate if there is an ethernet card Clipboard owner and contents Current process, processID and window Free clusters on the disk For MACs: Machine location (longitude and latitude) User name Mouse location keyboard time threshhold last key pressed audio volume current directory current process process information for every task on the system stack limits zones scrap sizes and counts event queue And then on all platforms The stat (file access, creation, modify times, size, inode equivalent) and contents of a number of "interesting" files. [Where is the PGP random number state file stored?] A portion of the contents of the screen. And finally, the contents of the highest resolution clock we can find. Each time the client goes idle Reinitialize the seed with the most recent user event (probably a button or key down) along with the mouse position, and and relatively high resolution clocks. Known weaknesses: If your X display is not the local machine then the X protocol can be watched. Given that, the data for the reseeding of the MD5 hash will be compromised. [Any scheme that relies on random user input to generate a seed suffers from the same problem.] This is not quite as bad as it might be. The exact time of the client becoming idle can only be guessed. We should be able to get a few unguessable bits from the microsecond part of the time-of-day clock each time. Enough cycles of user actions should help to make the hash less subject to a brute force attack. In fact, the entire X protocol issue is one that could take up another 3 pages. An SSLized version of the server would help, but how would anybody export it? You "xhost +" fans are doomed. If the user launches the client to a secure home page then there will be no user actions involved before the first need for a seed. Thoughts on guessing: If Eve has root access to the user's workstation, all bets are off. Replacement of one of the system libraries or patching the client executable are among the attacks that would make it trivial to breach any part of the security. Specific measures (like computing a hash over the text of the program) could help against some of these attacks, but it is not realisitic to believe that we can prevent the attack from a sophisticated person with root access. Multi-user Unix machines present a special problem. There are those at Netscape that argue that anybody who has login access to your machine may as well be considered to have root access. There are enough known attacks that this is true to a large extent. However, I think we can do better than just giving up. Unfortunately most of the sources of entropy available to the client are also available to the attacker. For instance, the output of "ps" is not much help against this form of attacker. As Jeff Weinstein said earlier and I echo here: specific suggestions are more than welcome. When Eve has access to the wire for all of the packets into and out of the user's workstation, then some of the networking information can be guessed. See above about known weaknesses if Eve has access to the X protocol stream. I am most comfortable about the "randomness" of the generated seed if Eve is outside a fire wall sniffing packets. The difficulty in guessing what processes/tasks are running on the target machine is quite a bit of help here. What I would like: Any OS has access to a number of real-world physical sources of randomness. This information is not made available to a user level process. How long did that last seek take? Was there any noise on the microphone? It would be good if the OS could gather that information and make some set of bits available to any process that asks. Having this be part of all OSes would make my job easier. More specifically: A "getnoise()" system call in UNIX could be better than anything I can do and easier. Can we convince the UNIX vendors to start providing that? My life would have been simpler if this attack had been done after the 2.0 version of the client had been released. :-) Believe it or not, we were beginning to beef up the seed generation a couple of weeks ago. The time spent on patching the current release will not all go to waste, but it has cut down on my limited opportunities to sleep. For those that curious: being responsible for helping to fix a bug that is getting front page coverage in major newspapers is not nearly as much fun as it sounds. PK -- Philip L. Karlton karlton(a)netscape.com Principal Curmudgeon http://www.netscape.com/people/karlton Netscape Communications Corporation

6 6

RSAC shelves news rating, bowing to criticism from journalists (fwd)
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Thu, 11 Sep 1997 14:51:57 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> To: fight-censorship-announce(a)vorlon.mit.edu Subject: RSAC shelves news rating, bowing to criticism from journalists --- http://www.news.com/News/Item/0,4,14139,00.html RSAC shelves news rating By Tim Clark and Courtney Macavinta September 10, 1997, 5:55 p.m. PT WASHINGTON, D.C.--The Recreational Software Advisory Council, which has created an Internet ratings system for Web sites, has put its controversial plan to create a special label for news-oriented sites on hold. RSAC's decision came after resistance from news organizations, particularly from established players in offline media, which raised First Amendment concerns about the so-called "N" label. "We are not aggressively pursuing the 'N' label at this time," RSAC executive director Stephen Balkam told CNET's NEWS.COM. Earlier this year, RSAC asked the Internet Content Coalition (ICC)--whose members include technology, entertainment, and online news companies--to develop guidelines outlining who should be able to use the label, which was designed to circumvent browsers that screen violent or sexual Net sites by "reading" the voluntary ratings. (See related story) But during an August 28 meeting organized by the ICC, most news sites declared that they wouldn't rate their content or use a news label. With the ICC votes in, RSAC essentially lost its market for the label. "We will pursue discussions with other potential partners," Balkam said. "We might talk to mainstream press, we might talk to international press. We are conducting a thorough review of the issue." [...]

1 0

Re: Patents and trade secrets was: Encryption algorithms used in PrivaSoft
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Historical example time... >(0) Alice invents a snaffleblort. Some Other Guy invented telephone >(1) Bob invents a snaffleblort. A.G. Bell invented telephone. >(2) Bob files for a patent on a snaffleblort. A.G. Bell files 6 hours earlier. Actually happened. We know what happened... ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

[COMMERCIAL] Scars and stripes forever
by Firebeard 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- http://www.diamdcom.com/previews/premier/unclesam_feature.html Scars and stripes forever UNCLE SAM "There's nothing we can do for you." The dismissive doctor's words echo in the old vagrant's head as he's ejected from a hospital. Moments later, the other voices return. They're about to take him on a journey to the dark heart of America in UNCLE SAM, a two-issue Prestige Format VERTIGO miniseries, fully painted by award-winning painter Alex Ross (KINGDOM COME) and written by Steve Darnall (the Eisner Award-nominated Empty Love Stories). Clad in star-spangled rags, a man named Sam wanders city streets, struggling to remember his true identity. As the voices in his head begin to make a terrible kind of sense, they set off time-traveling visions that drag him through the worst of his nation's history, while hinting that he may have a violent past of his own. Is he Uncle Sam - or one of U.S.? Through it all, a mysterious woman keeps appearing, staying just out of reach. Is she Sam's lover, ally, or just, in the end, a madman's dream? He won't have all the answers until he reaches "a white city by the unsalted sea" - and a most formidable foe. Darnall and Ross team up for a multilayered look at the failed dreams and fallen heroes of a nation under siege...from itself. Told through a mystery man's eyes, UNCLE SAM sweeps from the Revolutionary War to the Dust Bowl and beyond. In his VERTIGO debut, Alex Ross takes his remarkably realistic style to new heights, using spectacular splash pages and a wide-ranging palette to bring America's darkest historical moments - as well as a hallucinatory parade of other American icons - to life. - -- #include <disclaimer.h> /* Sten Drescher */ Unsolicited bulk email will be stored and handled for a US$500/KB fee. "A well-regulated population being necessary to the security of a police state, the right of the Government to keep and destroy arms shall not be infringed." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNBh2PPCBWKvC9LiRAQH6fgH/c7oOvSs9ArNDFTbz/VHYBYqEzY7teHPQ 3YP7l6P+O5RAo9aUcPxgVRsnWG91iB4vUqwws1WRVholtIcKZ3DP8A== =4hBM -----END PGP SIGNATURE-----

1 0

Re: first virtual "security" (!!) (was Re: Security Flaw Is Discovered InSoftware Used in Shopping)
by Jiri Baum 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hello Laurent Demailly <dl(a)hplyot.obspm.fr> and "NSB's Portable (via RadioMail)" <nsb(a)radiomail.net> and cypherpunks(a)toad.com "NSB's Portable (via RadioMail)" <nsb(a)radiomail.net> writes: > At 4:32 AM 9/21/95 +0200, Laurent Demailly wrote: ... > >financial insecurity never was a problem as > >long as it remains under a small %. > > This is an amazing statement, Laurent. ... It's not an amazing statement. As long as the cost of insecurity is less than cost of security, there's no problem. ... > We're not opposed to cryptography, by the way. There are some obvious > places where the use of digital signatures could directly enhance our ... Okay, so what's stopping you from starting right now with PGP? You could simply have that as an alternative to the current system (on a per-ID basis, ie new customers specify PGP or not). Quite a few people both have PGP and would think well of you if you started using it. How about "The safest Internet payment system just got safer."? Jiri - -- If you want an answer, please mail to <jirib(a)cs.monash.edu.au>. On sweeney, I may delete without reading! PGP 463A14D5 (but it's at home so it'll take a day or two) PGP EF0607F9 (but it's at uni so don't rely on it too much) -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMGITYCxV6mvvBgf5AQGN0wP8DxZ50ZMR3H+W6LCc0vhFZ6GMrTRZPSM4 XULabVj4w59aEDUWj2wbueXaPJUMHpAgYK83oMGLtlu1Hrxzo9/SXT/WzcMUZp7q qajmCXRY9q3b+OXznTLavrF5qISlPY8NU/HbSi/nCF8kbT6eEf8rXc/uZgPCyV6j RuvE2VDWaCc= =J4iR -----END PGP SIGNATURE-----

2 1

Netscape bug update
by Ray Cromwell 17 Dec '03

17 Dec '03

I just verified in GDB using a stack trace that the Netscape overflow bug I mentioned is indeed a static stack buffer overflow. It trashes the stack. What this means is that in theory, it is possible to get a simple URL, if clicked on, to execute some code on someone's browser. Now the hard work begins... Happy Hacking, -Ray

3 2

Re: Project: a standard cell random number generator
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

These supplement JG's post on CAPSTONE -- which is itself available with related crypto papers at csrc.ncsl.gov: ------------------ URL: http://csrc.ncsl.nist.gov/nistgen/clip.txt CLIPPER CHIP TECHNOLOGY CLIPPER is an NSA developed, hardware oriented, cryptographic device that implements a symmetric encryption/decryption algorithm and a law enforcement satisfying key escrow system. While the escrow management system design is not completely designed, the cryptographic algorithm (SKIPJACK) is completely specified (and classified SECRET). The cryptographic algorithm (called CA in this paper) has the following characteristics: 1. Symmetric, 80-bit key encryption/decryption algorithm; 2. Similar in function to DES (i.e., basically a 64-bit code book transformation that can be used in the same four modes of operation as specified for DES in FIPS 81); 3. 32 rounds of processing per single encrypt/decrypt operation; 4. Design started by NSA in 1985; evaluation completed in 1990. The CLIPPER CHIP is just one implementation of the CA. The CLIPPER CHIP designed for the AT&T commercial secure voice products has the following characteristics: 1. Functions specified by NSA; logic designed by MYKOTRONX; chip fabricated by VLSI, Inc.: manufactured chip programmed (made unique) by MYKOTRONX to security equipment manufacturers willing to follow proper security procedures for handling and storage of the programmed chip; equipment sold to customers; 2. Resistant to reverse engineering against a very sophisticated, well funded adversary; 3. 15-20 MB/S encryption/decryption constant throughout once cryptographic synchronization is established with distant CLIPPER Chip; 4. The chip programming equipment writes (one time) the following information into a special memory (called VROM or VIA-Link) on the chip: a. (unique) serial number b. (unique) unit key c. family key d. specialized control software 5. Upon generation (or entry) of a session key in the chip, the chip performs the following actions: a. Encrypts the 80-bit session key under the unit key producing an 80-bit intermediate result; b. Concatenates the 80-bit result with the 25-bit serial number and a 23-bit authentication pattern (total of 128 bits); c. Enciphers this 128 bits with family key to produce a 128-bit cipher block chain called the Law Enforcement Field (LEF); d. Transmits the LEF at least once to the intended receiving CLIPPER chip; e. The two communicating CLIPPER chips use this field together with a random IV to establish Cryptographic Synchronization. 6. Once synchronized, the CLIPPER chips use the session key to encrypt/decrypt data in both directions; 7. The chips can be programmed to not enter secure mode if the LEF field has been tampered with (e.g., modified, superencrypted, replaced); 8. CLIPPER chips will be available from a second source in the future; 9. CLIPPER chips will be modified and upgraded in the future; 10. CLIPPER chips presently cost $16.00 (unprogrammed) and $26.00 (programmed). 4/30/93 ------------------- URL: http://csrc.ncsl.nist.gov/nistnews/esc_key2.txt February 4, 1994 AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO FISA The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to the Foreign Intelligence Surveillance Act (FISA), Pub. L. 95-511, which appears at Title 50, U.S. Code, Section 1801 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) In the event that federal authorities discover during the course of any lawfully authorized interception that communications encrypted with a key-escrow encryption method are being utilized, they may obtain a certification from an agency authorized to participate in the conduct of the interception, or from the Attorney General of the United States or designee thereof. Such certification shall (a) identify the agency participating in the conduct of the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key-escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the agency participating in the conduct of the interception for decryption of the intercepted communications. 4) This certification shall be submitted to each of the designated key component escrow agents. If the certification has been provided by an agency authorized to participate in the conduct of the interception, a copy shall be provided to the Department of Justice, Office of Intelligence Policy and Review. As soon as possible, an attorney associated with that office shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification, each key component escrow agent shall release the necessary key component to the agency participating in the conduct of the interception. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification, as well as the subsequent written confirmation of the Department of Justice, Office of Intelligence Policy and Review. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications shall terminate, and such agency may not retain the key components. 8) The Department of Justice shall, in each such case, (a) ascertain the existence of authorizations for electronic surveillance in cases for which escrowed key components have been released; (b) ascertain that key components for a particular key-escrow encryption chip are being used only by an agency authorized to participate in the conduct of the interception of communications encrypted with that chip; and (c) ascertain that, no later than the completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications is terminated. 9) Reports to the House Permanent Select Committee on Intelligence and the Senate Select Committee on Intelligence, pursuant to Section 108 of FISA, shall, with respect to any order for authorized electronic surveillance for which escrowed encryption components were released and used for decryption, specifically note that fact. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. ------------------

1 0

Re: Cypherpunk Press <sarcasm>
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Michael Wilson wrote: > After all, if individuals have no right to privacy, why should any > organization have one? Is the right to privacy and secrecy something > that comes from additive rights? Does it come from possession of > military force, up to and including nuclear weapons? What's the line? > I personally wouldn't mind knowing the threshold I need to cross to > have a 'right' to privacy. It gives me a goal. toto(a)sk.sympatico.ca is currently offering a suitcase, for a mere $1,000,000 which should guarantee your privacy. simply let the proper authorities know that you have the suitcase in your possession, and they will recognize you as a compatriot and leave you alone.

1 0

e$: Non-Repudiation
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Dr. May said: >the >"ontology" of digital money, the instruments and forms it can take, are >_impoverished_ compared to the real world. Ah... Someone's playing my song... Sorry I took so long, but I wanted to give this excellent post some serious attention, which is hard to come by when you're a person like me (praise the lord and pass the Ritalin ;-) ). >In my eight years of following digital cash work, I've been struck with how >little _economics_ enters the fray. I think you're right, Tim. More and more people are finally realizing that digital commerce *is* cryptography: cryptography as it's applied to economics on a network of microprocessors. After all, Netscape plans to make its money on servers, most important, its commerce servers, the servers that require the most cryptography. A major leader on this front, to my mind -- that is, someone who has been barking on the end of his chain ;-) the longest and loudest about all this, and who has gone out and *learned* how the clearing of transactions happens in the capital markets and elsewhere -- is Eric Hughes. Eric, who, along with Tim May, founded this group to begin with, who has worked with David Chaum, and who designed and built the first anonymous remailers. One of the reasons we don't see much of Eric around here these days is because he's out there putting some rubber to the road in his consulting business, where he's focusing on the very issue of cryptography and its applications to digital commerce, and I wish him well. That is *not* to slight others in this group who are also thinking about this stuff. Not at all. In addition, most of us are looking at other issues in cryptography, like remailers, like keeping the state out of our face, like pithing SSL, and, frankly, most of the rest of us are too busy making a living to do anything but lurk here. Cryptography is huge, and digital commerce is a small conceptual subset of the whole field, no matter how important some of us think it is. Nonetheless, the fact that both of the founders of this group are focusing on cryptographic financial objects and/or their network infrastructure speaks volumes its importance anyway. Having laid down that as covering fire ;-), let's talk about creating an ecosystem of autonomous financial objects on public networks, and why I think that Tim's post is particularly important. The reason we have the multiplicity of financial instruments out there to begin with is because there is money in creating them. But the reason there's money in it is because of the fall of the price of networked computer-based communication. The market they're traded in exists in computers. The decisions made to buy and sell them are at least facilitated by computers. The clearing and settlement of these instruments are done on computers. However, these systems are all centralized, closed, private systems. For that reason, the very accelleration of processing cost-effectiveness which created them is going to sweep them away someday. The bleeding edge of all this is the so-called 'synthetic' security, something which exists as a software manifestation of the most recent financial theory, sometimes only experimental and a few hours old, sometimes sold to an investment bank's clients just like any other security, secondary markets and all. A combination of purchases and short sales of put and call options on a particular bond, which behaves like the bond in price, for example, without having to hold the bond itself. This is usually done because the liquidity or the transaction cost of holding these instruments is lower than that of the bond. In addition, since unwinding of the synthetic security should yield the price of the bond after transaction costs, any discrepancies between the two yields an opportunity for arbitrage. Of course, in the early days, all of 10 years ago, theory held somewhat more promise than reality. The great "portfolio insurance" fiasco of the early 80's arose from the fact that the options trades which were supposed to offset the fall of the price of a security in this fashion turned out to be not very liquid after all. When the time came to unwind these positions in a hurry, they got stuck. That's not as much of a problem these days, as evidenced by the proliferation of increasingly sophisticated securities based on the same idea, which trade and settle just fine, Note that we're talking about book-entry entities here. That is, these modern securities are creatures of an environment where software "applications" reside on a particular computer on a particular local or private network, to manipulate centralized accounting entries on that computer or elsewhere, in order to reflect the expected or traded value of a security. Things that live "on" a computer. It's controlled completely from the outside, with the exception of the behavior of the market. Not "in" it, or "in" the network the computer's hooked into. Notice how different all that is from a digital certificate like Chaumian digital cash. When you get a digital certificate, you receive it through a cryptographic protocol which ensures that it is what it says it is. If the certificate is traded on-line, then the certificate's issuer vouches for it right then and there. If it is traded off-line (someday, I hope...) the certificate speaks for itself, just like a dollar bill's supposed to. As such, it can reside anywhere, not as a book-entry "on" a central computer somewhere, but "in" the network. Notice also we are backing down a level of abstraction from the status quo. A certificate is what it says it is, it is not book-entry, which is a pointer to something which is what it says it is. That's the paradox of modern book entry systems. A book entry used to just "point" to a physical certificate, which in turn points to a cash-flow or a series of cash-flows of some kind. Of course, the term "book entry" is almost exclusively used to describe clearing capital market trades without the physical exchange of certificates for other pieces of paper (receipts, checks, signature guarantees, etc.). The institutional ideal in this environment is a clearing-house wire clearing the trade in exchange for a bank wire transfer settling the trade. The book entry becomes the primary abstraction, not any certificate it is supposed to represent. The problem with book entries, of course, is the problem with any database. You have to manipulate that database, and to do that, you have to get access, and to do that you need permission... you get the point. In a capital market, that costs money, and it's costing more and more as a percentage of the revenue derived from the transaction, because to get access, you need human permission and intervention. If a human isn't supervising things, people take advantage of their access. Mr. Leeson of Barings was a classic case in point. Meanwhile, Moore's law keeps lowering the cost of the rest of the production cycle. Another problem, closer to the heart of this list, is that of anonymity. The ultimate authority to modify that particular line item or database field derives from the "owner" of that entry, since it is usually modified by someone else, "a chain of custody" is needed: audit trails, and of course, True Names are necessary somewhere, even with numbered accounts. The primary point for inventing double-entry bookeeping was so owners could control accountants, after all. When electronic book entries started replacing paper ones, the resulting economies of scale caused great centralization to occur. As I've said here before, lines were cheaper than nodes, and things got bigger and bigger. The advent of the microprocessor has been continually eating away at these large control hierarchies, and making them harder and harder to maintain. Things are getting out of control again. In an out of control environment, like that found on public uncontrolled networks like the internet, software has to be autonomous. A certificate, like a piece of digital cash, is an autonomous entity. As we said before, it is what it says it is. Because of a cryptographic protocol, you trust the thing because of the way it behaves, not because you trust the people who gave you access to it. Now, Tim is talking about another type of autonomous entity, an agent, basically, a "friendly" virus. A piece of code which is launched or launches itself on one machine, crosses a network, runs itself on another machine, and returns with a result. Our current concept of software agents implies that there's something on another machine needs to be "got", usually a database requiring access and permissions, which is why people who manage centralized repositories of information are nervous about them, just like microcomputers made their mainframe predecessors nervous. On the other hand, it's easy to see a scenario where two agents arrange to meet somewhere on a *public* network, in the presence of another "impartial" agent to exchange certificates, trading, settling and clearing all in one shot. Unsupervised. Out of control. Because the agents are engaging in a cryptographic process which "breaks" if the entities behave improperly, fraud is supposed to be prevented. Which brings me to something which goes right to the heart of one of our most cherished ideas here on cypherpunks, the idea of crypto-anarchy: with the right cryptography, agreements become uninforceable because perfect anonymity disconnects the "pointers" between digital and physical identity. Crypto-anarchy means that states don't know who to force to do what. Technology does this, it's reality, it's not optional, so we better get used to it. The catch to all of this is a curious conceptual double negative called non-repudiation. I had trouble remembering the name for a while, I kept wanting to say "plausible deniability", in the spirit of Admiral Poindexter. But I've had to remember the real name, because the idea's so damned important. Right now, the canon of commercial law for the entire free world (just so I can't be accused of quibbling here :-) ) is completely based on the concept of non-repudiation, that is, you can't repudiate an agreement, or a trade, or you or you face legal sanction. Force, in other words. Ultimately, the state can send you to jail, or worse. About a year ago, when www-buyinfo had active discussion on it, (and had not yet been turned into cyphe$rpunks by my reflexive redirection there of all the e$ cheezy-bits from cypherpunks ;-), ) I got into an interesting discussion there about non-repudiation and I didn't even know I was involved in one. We were arguing about a familiar dichotomy in the concept of digital cash, the difference between on-line and off-line protocols. I was arguing that on-line cash was better because it was a more "peer-to-peer" proposition than an online system, which required access to a network connection, and high-bandwidth processing at the certificate issuer so the issuer could participate in *every* *single* *cash* *settlement*. That invasive participation struck me as antithetical to the whole concept of a hyper-distributed geodesic economy that I thought that digital commerce was going to become. The technology which made it possible for anyone, anywhere, to sell anything digitable -- music, movies, information, teleoperator control sequences, professional services, and financial instruments -- to anyone else, while using the cheapest possible transaction protocol, that is, cash, a protocol which immediately and finally clears and settles a transaction, will win out in the end. So, I was finding myself twisting in the wind about all of this, trying to figure out how offline cash was going to have to work if double-spending was possible, how could be kept to managable levels. I found myself saying things like (forgive me), "Well, if they double-spend, put 'em in the airlo- er, throw 'em in jail!". In other words, we have the key of the double spender, even if she's anonymous, so we could use snitches, subpoenas of bank records, and plain old detective work, to send her to jail should she repudiate the agreement to not double-spend. It's hard to see how that would happen in a perfect world with perfect anonymity, much less in a world where nation-states couldn't collect income to pay for judges, courts, and LEAs. Nick Szabo was gleefully slapping me around the head and shoulders about this, and I retired from the field. So, no matter how much the idea refuses to leave my thick Frisian head, I'll leave that big, red, dog ("Hey, baby...") sleeping on the front porch for the time being. This without even *touching* the other problem with digital cash in general, Nathaniel Borenstein's favorite anti-digital-cash 2-by-4 -- which threatens *all* digital cash systems on- or off- line -- the prospect of someone *inside* a certificate issuer stealing the private key for an entire issue, and printing all the money she wants. To that I say, use multiple issues, and distribute keys, but I see that big red dog's waking up, so we'll move on... So, you can see we're talking about the alleged inability of cryptography to deal with the repudiation of digital cash trades. It cannot currently keep transactions either the way cypherpunks want, utterly anonymous, and the way I want them, off-line. In fact, at the moment, I'm very close to holding the strong form of this argument, that is, the concept of non-repudiation is the *only* reason we're being forced into true-name trades right now. It's not the long arm of the law, it's the market, which makes sense. If it was just a legal obstacle, and really contrary to market forces, it should have collapsed under a barrage regulatory arbitrage attempts. No threat of legal force would have prevented people from trying to make money issuing digital cash. The War on Some Drugs is a good example of this. If we could get digital cash trades, or trades of any kind of financial instrument for that matter, to trade on public networks without the ability to repudiate them, it probably won't matter whether they're illegal, which is interesting, to say the least, but it's no different from what happens with paper certificates. Now, as usual, all this is no brilliant insight on my part. A few days ago, I didn't know what "non-repudiation" meant. On Wednesday, I had a very interesting over-coffee conversation with Yet Another Professional Who Wants To Remain Anonymous. I must be a magnet to these people for some reason, at least until they figure out I'm not *that* useful. Or maybe because it's because I need so much help. Anyway, people who were on cypherpunks last summer remember my previous anonymous legal informant, the esteemed councellor Vinnie "The Pro" Bono, not to be confused with his second cousin, the Honorable Sonny. "Vinnie" wanted to remain anonymous because he was afraid of being deluged with requests for free legal advice, among other things. I still won't tell you who he was, but he has since "come out", and, of course, we *aren't* choking his POP server with requests to get our various relations out of the slammer, or anything else for that matter, even though he talks freely here under his True Name. I expect my new friend will figure this out soon enough. The other reason he gave is that he's so damn busy he doesn't have time to do much but lurk. Unfortunately, this guy lurks not here, but on www-buyinfo, having signed on to cypherpunks and deciding *not* to drink from a firehose, thank you very much, and since I've been spamming it lately with the aforementioned cypherpunks e$ cheezy bits, he seems to prefer it there. I have to admit myself that as much as *I* like it here, it is an acquired taste... Now, our friend Vinnie has very some serious credentials, but this new guy is just plain scary because he's so focused on the commercial law of EDI and electronic commerce. This hypercredentialed gentleman shows up on the program committee of various "suit" conferences on electronic commerce, sponsored by various international legal entities and TLAs, and seems to be up to his elbows in the Current Fantasy according to the Powers that Be, in particular, its legal armature: legal sanction, non-repudiation, True Names, and all. Which leads me to *his* moniker. I thought I was going to be civil about this, and just refer to him in the third person singular, but I had this amazing brainstorm. Remember the comedian "Professor" Edwin Corey, who died recently? His schtick was a variant on the nutty professor, obfiscatory language, lab coat, Converse high-tops and all, and he called himself the "The World's Foremost Authority". Didn't say on what, which was the point. As a philosophy major at Mizzou who really loved his informal fallacies, one of which was the Appeal to Authority, this particular example always made me laugh. So, I've dubbed this particular informant "Edwin Corey", or "Mr. Corey" in true Oxfordian fashion, not to be at all uncharitable, but because, in truth, this guy is probably the world's foremost authority on this stuff, if anyone is... He's going to give me pointers to some of this proposed "legal armature" from time to time, the first of which is a report by one Michael Baum entitled, deep breath, "Federal Certification Authority Liability and Policy: Law and Policy of Certificate-Based Public Key and Digital Signatures". This 500+ page monster can be obtained from, who else, The Feds, in particular, another big breath, the United States Department of Commerce, Technology Administration, National Technical Information Service, Springfield, VA, 22161; (703) 487-4650. The cost is $61, plus $6 for shipping and handling, plus $2 for orders sent outside the U.S., Canada or Mexico, plus rush charges if you call 1-800-553-NTIS, and if you *don't* jump up and down three times *before* you write the check or read them your credit card over the phone, the trade will be repudiated. ;-). Oh. It says something here about being able to get it through a web-site called FedWorld, http://www.fedworld.gov . So, it's very important to work on financial objects and agents. However, I should really try to concentrate on the issue of non-repudiation, because it is a necessary, and maybe (strong form) necessary and sufficient, criteria for the development of digital commerce on public networks. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0