December 2003 - cypherpunks-legacy

Re: SSL trouble
by Bill Stewart 17 Dec '03

17 Dec '03

Several people have suggested random keyspace selection instead of servers. The problem is that there's a high probability that the search will fail to find the correct key. If you split the keyspace into n segments, and randomly select k of them, the probability of failure p = ((n-1)/n)**k ; for k=n, p approaches 1/e (.367) as n becomes large, and 10 is close enough to large that you don't gain much by having independent groups that agree not to overlap in their own 10% of the keyspace. For k=2n (random-searching the space about twice), the probability of failure is still e**-2, about 13%. You need a coordinated search. >Why not just have the brutes pick a slave at random? >Of course, you need to give them a complete list of slaves to choose from. That more or less works, assuming you can distribute the list of slaves along with the code; you still hit the slaves' DNS servers unless you also distribute IP addresses for the slaves to use (which is probably fine as long as people get the addresses beforehand.) You could get fancy and have a DNS server hand out slave addresses round-robin for a dummy address slave.cracker.org. The main failure mode seems to have been misconfigured clients grabbing the single-threaded server for a long time; it may be worth using a multi-threaded server, or alternatively a single-threaded server that has a fast timeout for how long it will talk to a client. I gather there was some protection in the code against dishonest clients, but a malicious attack would be to falsely ACK large portions of the search space (especially the portion containing the real answer, if the attacker knows it). #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: improving the distributed computation
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:43 AM 8/25/95 -0400, you wrote: >1) Abandon the central command way of doing things. Little if any >communication is required for this computation, it should be >self-distributing to and between volenteer sites. That makes it ideal >for implementation as a safe virus. Doling out keyspace _does_ require central coordination, though the job can be delegated to _trusted_ volunteers, or delegated with redundancy to semi-trusted ones. As far as safe viruses go, I've had more free lunches than safe viruses, though I've been offered both out of "charity". Some of the lunches were good, and charitable; the viruses have been, at best, mostly harmless. Perhaps under Safe-Tele-Java-Script it will be possible to send self-modifying self-reproducing scripts around a network to unsuspecting machines, but I doubt it. >2) Give these computations a defined and limited lifetime. The problem >you have with old versions is because they don't die automatically or >even check to see if they are up-to-date and update themselves. Yeah. In this case, the lifetime of the versions was less than the expected lifetime of some of the searches. Automated version-checking would help, but the version changes made it difficult to communicate even simple requests like "Give me a number". Perhaps it would make sense for version upgrading to include changing the server's TCP port so the old versions don't hose the servers for the new versions. >3) Use randomness to break up the search space and redundantly perform >the computation. This should eliminate the problems with malicious >key-space requests, etc. Randomness doesn't help much, since it's hard to be sure you sweep the whole keyspace. Redundancy does help, but it's still tough to protect against sufficiently malicious attackers. >4) Use feedback in the form of selective survival/replication to >optimize the search and allocate search space. If a processor goes >quickly, give it more to do - if it goes slowly, give it less. This >will produce an overall system that adapts with time to the cahges in >network and system usage so as to optimize overall performance as a >function of time. You could do that. But simply asking for more numbers after you've finished the previous batch accomplishes much the same thing; special tuning may be more useful for folks with MasPars than 486s, where redundantly giving out unacked search space can do more. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

North American Crypto Archive status
by Michael Paul Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- WHAT HAPPENED TO THE NORTH AMERICAN CRYPTO ARCHIVE? The North American Crypto Archive at http://www.sni.net/~mpj/crypto.htm is rather limited right now. I have deleted everything except the few files that I contributed to the site. This was to save money, since I suddenly lost some sponsors (who wish to remain anonymous, but I appreciate them greatly) who were paying for the costs associated with the site. I am still planning to resurrect the North American Crypto Archive, but this will likely take a while. I think that almost all of the files were successfully rescued before the site went down by at least one person. Note that much of what was there can be found by following the links at http://www.sni.net/~mpj/freecrypt.htm or by using appropriate search utilities. WHY RESURRECT THE NORTH AMERICAN CRYPTO ARCHIVE? 1. To provide a place for U. S. and Canadian citizens to freely and openly exchange cryptographic information, papers, programs, etc., without fear of government reprisals. 2. To provide a friendly central repository for cryptographic libraries, code, and papers, thus making it easy to find and use such information. 3. To provide a reasonably high bandwith connection for North Americans. 4. To exercise "freedom of the press" and press towards a constitutional EAR. HOW MUCH SPACE WILL THIS TAKE? My total archive space was at about 125 megabytes, but it had been trimmed from what I would like to have. For example, downlevel versions of software were generally deleted, and some things that are historically and cryptographically interesting were not carried. I forsee usage of around 500 megabytes or more in the near future if we can make room for it. The storage need not all be at the same site, however. HOW MUCH BANDWIDTH WOULD IT TAKE? I'd like to see at least ISDN connectivity. I've seen as many as 425 files downloaded in a day from the current archive. Again, the storage and loading need not all be at the same site. WHAT DO YOU MEAN BY NOT HAVING ALL THE STORAGE AT ONE SITE? I envision a new plan for running the archive such that one master index page (like the "export controlled" one at http://www.sni.net/~mpj/na) points to hidden directories all over the continent, wherever free space can be gleaned. The only requirements on the remote sites to maintain the "export controlled" status would be to maintain a cron job that changed the name of the hidden ftp directory containing the files on the same schedule and using the same key as used at the index site. For now, http://www.sni.net/~mpj/na can remain as the password-controlled index site. This does require a slight change to the architecture of the "export control" system in that the directory name would be a function of the current time (UTC) and a secret key, instead of being truly random like it is, now. The relative loss of security in this change is inisgnificant relative to the (obvious) weak links of the system. (Yes, I know that it can be defeated, but I also believe that the system complies with the EAR as well as most do, anyway.) The gain in this approach, of course, is that the index and ftp site need not reside on the same server, as long as the system clocks are reasonably well synchronized (within a few minutes). One other advantage of having several sites is that popular files can be placed on several different servers to lower the average traffic from any one server and to make the system more robust against failures and overloads. The archive would still have a single point of failure (at least initially) in the index site, but that could also be replicated fairly easily as long as users don't mind obtaining a separate password from each index site. WHAT REMOTE SITES DO YOU PLAN TO USE? I've had several people make inquiries or make offers, some of which sound better than others. I hope that this one open letter answers all of the questions that I got. I am looking for sites that: 1. Are *nix-based (at least for now). 2. Have some free disk space and bandwidth that can be used for this cause. 3. Have GNU C++ installed (or at least are identical to a host that I have access to that does). 4. Grant me access to a shell account and an ftp account to maintain the site. 5. Grant me access to cron so that I can have the hidden-directory renaming program run at the right schedule. 6. Are likely to be available for a reasonably long term. 7. Are in the USA or Canada and controlled by a U. S. or Canadian citizen. WHAT MAKES PEOPLE THINK THAT YOU WILL GET ALL OF THESE FREE RESOURCES? The same thing that makes me think that people will donate otherwise idle CPU resources for the fun of cracking a DES key or factoring very large numbers. HOW DOES THE "EXPORT CONTROL" SOFTWARE WORK? Ahh... here is the meat of the message that keeps it on topic for coderpunks and sci.crypt: First of all, it is important to understand the design restraints. The EAR states that mere posting of cryptographic software on the internet is not an export if guests must affirm a couple of things (see the regulations) and if there is some kind of check that the "address of the receiving computer is verified to be in the USA." Strict compliance with the latter is impossible, but if the guest's email address is in a domain not commonly used in the USA and Canada (.gov, .com, .org, .edu, .mil, .net, .us, or .ca), then I suspect the guest of lying and deny access. Naturally, this is imperfect, but it is honestly the best I could figure out how to do on a normal ISP shell account that gives me no CGI script access. This really boils down to the honor system. That is OK with me if it is OK with the U. S. Government, and the way I interpret the law, it is. Given that, here is the process: 1. http://www.sni.net/~mpj/usa is an html form that asks 3 "magic" questions to verify eligibility to legally access the strong cryptographic software, as well as the guest's email address. The 3 questions all default such that the user must change each answer to be granted access. The email address must be correct, because the user name and password are sent back via email, not as a web page. The "submit" button sends this data to cgiemail, an application that Colorado SuperNet does allow me to use. This form also invites nonqualified guests to explore most of the same data via http://www.sni.net/~mpj/freecryp.htm (links to crypto sites outside of North America). 2. When cgiemail gets the data from the above form, it simply formats the data using a template I supplied and mails it to me at mpj(a)csn.net. 3. I have an incoming mail filter that checks for any automated messages from cgiemail (which all have a rather long fixed hexadecimal number for a subject line), and processes them. If the guest answered all 3 questions properly, and the email address given doesn't "look foreign," then a form letter is filled in with a valid user name and password and mailed to the given email address. (There are some other checks, like limiting the email address to one destination, etc.) Noncompliant requests are simply discarded (since the "thank you" message from the submission form really already answered them). I thought about a courteous denial letter, but most of the bogus submissions also have bogus email addresses, so I decided not to do that. 4. If our guest can spell his or her email address right (among other things), then the email message directs him or her to http://www.sni.net/~mpj/na with a valid user name and password. 5. http://www.sni.net/~mpj/na is password protected using the security features of the Apache web server (as slightly tweaked by Colorado SuperNet). This is the index of the files in the archive, which are in a subdirectory of a hidden directory with a non-obvious name. 6. The hidden directory names are changed periodically to discourage the use or posting of a copy of the page at http://www.sni.net/~mpj/na without password protection. The idea is that by the time the cheater posted it and anyone found it, the hidden directory names would have changed again, invalidating the renegade index. The index is altered on the same schedule to the same new names by a companion program. (Right now the same program does both tasks, using a truly random number based on the arrival times and CRCs of all of my mail, but this would have to change in the new distributed archive model). IS THAT REALLY GOOD ENOUGH? I think so. It is the best export control model that I have seen that doesn't lock out U. S. and Canadian citizens in the U. S. A. and Canada. I saw a little more elaborate system on a Microsoft web site for distributing some 128-bit RC2 software, but it locked me out because it didn't like the way Colorado SuperNet registered their "whois" information. It also locked me out from work, since SSL connections can't get past our firewall. My model is much less likely to lock out a duly qualified guest, and it is much better than my old "warning message only" model that I used before crypto export regulations passed from the ITAR to the EAR. WHAT ABOUT CRYPTO SITES OUTSIDE OF NORTH AMERICA? Please keep them up, and be ready to mirror any information that might suddenly become legal to export from the USA on short notice. I say this because the EAR is being challenged in court, and it is likely that cryptographic software export regulations may be struck down. It is also likely that the U. S. Government may quickly move to replace those regulations with others in a very short amount of time after the EAR is struck down. I don't want to encourage anyone to violate currently active regulations, however. If you have a good cryptographic software site outside of North America, and it isn't on my list at http://www.sni.net/~mpj/freecrypt.htm, please let me know. WHAT IS YOUR PGP KEY? RSA key for PGP 2.6.x: ftp://ftp.csn.net/mpj/mpjkey.asc (mpjA) DH/DSS key for PGP 5.0: ftp://ftp.csn.net/mpj/mpjdhkey.asc (mpj(a)ebible.org) (Note that my RSA key uses mpj(a)csn.net for an address. That old address still works.) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBM+6USm+Iqt/O4EnZAQFVFgf+IQq7oZavZxgMwT2530w7LWPkNLqlbG5z BSi1QGasmZrumAuMOG7M28prFZVg2hzExKUejlSXao7ywa3fnzLb0BF8WlDlFsS/ ysSQTB1NLzgjm3L8pqImdNGrP6ECFSFsTm3KOGxuu/NAVfEyBaoV5VEwxlUJmWBu ifsmv7aBOOfY4g2xa9XQay4+rIx4QTr6k6OJenJ0f+eLnC/JjG7Dz3n3Mh0vbu6p Vc9ib9jjkv+eawKv5+BnFUNc/hILsnw1yPQuomc7/G/YMJwbd7Ps/+LVRqmg0oxD ECLfAI/BI6KxUh8EDGH91SnSXNHAYwtA1puIrQka1zkPPTr/psA/fw== =9Zof -----END PGP SIGNATURE----- Michael Paul Johnson mailto:mpj@ebible.org (aka mpj(a)csn.net) PO Box 1151 http://www.ebible.org/bible <- Holy Bible Longmont CO 80502-1151 http://www.sni.net/~mpj/crypto.htm <- Crypto archive USA PGP RSA key fingerprint (mpjA): 3E67 A580 0DFB D16A 6D52 D3A9 1C07 4E41 PGP DSS/DH fingerprint: 28AE B775 DD65 62C7 0717 ECDA 448F E0C7 17D7 47BB

1 0

No Subject
by Black Unicorn 17 Dec '03

17 Dec '03

It's been far too long since I cleaned up the namespace clutter on alpha.c2.org. So I have deleted all reply blocks which point to remailer(a)jpunix.com, remailer(a)tower.techwood.org, usura(a)replay.com, myriad, wmono, desert, nately, and all the other dead remailers I could think of. I did this with a grep/awk script, so I hope it didn't maul any valid addresses. There are probably still a lot more dead addresses, but hopefully this cleans up the namespace somewhat. [...] THE FOLLOWING HAVE BEEN DELETED: abdul alexr alice an34267 anna avatar beaver blacknet ^^^^^^^^ bolt_thrower Uh oh! :) --- 00B9289C28DC0E55 nemo repente fuit turpissimus - potestas scientiae in usu est E16D5378B81E1C96 quaere verum ad infinitum, loquitur sub rosa - wichtig! *New Key Information* - Finger for key revocation and latest key update.

1 0

Re: SSL trouble
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > >PS3: I'd like to get the raw date in brloop (a sh script). In perl I'd just > > use "time", and I can't see a way to get "date +" to yield the raw time. > > I could use "date=`perl -e 'print time'`" but that seems OTT, and perl > > may not be on teh users PATH. Any suggestions ? > > "date '+%s'" does it under BSDI, but I'm not sure how portable it is. > This is what I got from SunOS 4.1.x $ date +%s date: bad format character - s Sounds like something my parents might have said ;-) Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Encrypted TCP, telnet, etc
by root 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just noticed this on USENET. Sorry if it's passed through cpunks lately, but ya know, sometimes I just fall asleep while the conspiracypunks drivel goes by, and don't notice when someone strays back to crypto. - ---Start Msg Newsgroups: alt.security,sci.crypt Subject: Secure Telnet: Summary Message-ID: <41q81d$22he(a)info4.rus.uni-stuttgart.de> From: zcbi1122(a)rpool4.rus.uni-stuttgart.de (Jochen Schwarze) Date: 27 Aug 1995 16:55:09 GMT Organization: Comp.Center (RUS), U of Stuttgart, FRG NNTP-Posting-Host: rpool4.rus.uni-stuttgart.de Lines: 74 Thanks to everyone who responded to my posting regarding a `secure telnet' implementation: Is there a (possibly free) implementation of something like a "secure telnet"? I'm looking for a way to login into a remote system providing secure interactive communication between the two hosts over (possibly insecure) Internet connections. Here's a summary of the implementations I am now aware of: * SSL There is a free implementation of Netscape's SSL Protocol (Secure Socket Layer) by Eric Young named "SSLeay" <ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/>. Eric Young is also the author of a popular DES Library. <ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/> SSL provides a secure authentication and encryption basis on top of which application protocols like telnet, ftp, and http may be transparently added <http://home.netscape.com/info/SSL.html>. However, the RC4 encryption using a 40 bit key, which is employed by SSL, has recently been cracked with a brute force attack, see RISKS-17.27 <http://catless.ncl.ac.uk/Risks/17.27.html#subj1>. A modified version of telnet that uses SSL-based authentication and encryption is also available <ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/>. * Deslogin Deslogin by Dave Barrett <barrett(a)asgard.cs.colorado.edu> provides a network login service much like rlogin/rlogind. Deslogin uses a `challenge-response' protocol to authenticate users. Also, all data transmitted to and from the remote host in encrypted using the DES. Deslogin also includes a command-line program `cipher' for fast DES encryption. <ftp://ftp.uu.net/pub/security/des/> * SRA Telnet This is a version of the SRA Telnet modified by the Technical University of Chemnitz. A session key is negotiated using an uncertified Diffie-Hellman-Method and used for the encryption of UID and password. The complete session text in encrypted with DES in CFB mode. <ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_tel_ftp> * Ssh Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. Among other features, Ssh is a complete replacement for rlogin, rsh, and rcp. <ftp://ftp.funet.fi/pub/unix/security/ssh-1.0.0.tar.gz> * Skey Bell Canada's `skey' free-ware implements a one-time password system, so that sniffers can get your ID and PW, but can't use the PW next time. <ftp://ftp.cert.dfn.de/pub/tools/password/SKey/> - ---------------------------------------------------------------------- I provide this information in the hope that it will be useful, but with no claim of either completeness or correctness. Thanks again to all who contributed to compile the above information. - -- Jochen Schwarze <jochen.schwarze(a)studbox.uni-stuttgart.de> - ---End Msg First question: what does anyone know about these programs. Second question: since I'm only a cyphergroupie, how can I make use of these programs? Currently, I'm trying to move as many operations as I can (mix client, mail reading, etc) to my local Linux box so that all traffic headed through my server is already encrypted. Naturally, some of these programs look interesting, the SSL telnet (but what about the other end?) for example. I noticed an announcement that DID come across cpunks: [snip] Announcing CryptoTCP beta version 0.9 CTCP is a public domain software package to do encrypted TCP sessions on unix systems. It features Diffie-Hellman key exchange with triple-DES encryption. This initial release is to be considered a beta version. Bug reports or comments on security issues are invited. [snip] Detached signature for ctcp.0.9.tar: - - -----BEGIN PGP MESSAGE----- Version: 2.71828 iQCVAgUAMBqiPf32LDYerV6NAQHUoAP/RLU0mM3ydxC9vjzay8hR5Qmb5zupHyCO klW8IYjxIt14jnBTqkVM7q+mnaAWK2Ishppe14H5K6MAn/VOe2o5Hf61wAzJuxzw wywiA9ZOdb+2cxm86YMgdbrnv430BCbSjPITV5PHyorovSqhX4RLLB1R8oOX4WUB 5WwzgLyV6Kc= =ltvK - - -----END PGP MESSAGE----- But I missed where this comes from, and I doubt I'd be able to drop it into my Linux in anything resembling a plug-and-play style. Anybody tried this? Don -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMEFQdMLa+QKZS485AQENNwMAu5du39fa8Dy5qaFCV0sq2IK4kwUVGYsP 1RndpErFYQoWC6wTmz2wB4AqeDUG6OmujFPF6as9vvl6RPT3MxKcd2St7wAGllwX p7Q0WTfPA7u2ICStsvJ/MtRMKSMQniii =fYr3 -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company *

2 1

Patient Snoop Law Coming
by John Young 17 Dec '03

17 Dec '03

NYT reports today on a patient privacy law being sent to Congress next month by the administration, the "most significant since the Privacy Law of 1974." Battles are expected over law-enforcement access to medical data, interference with commercial marketing and limitation on snooping for public benefit. http://jya.com/patient.txt

1 0

Re: SSL trouble
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> >PS3: I'd like to get the raw date in brloop (a sh script). In perl I'd just > > use "time", and I can't see a way to get "date +" to yield the raw time. > > I could use "date=`perl -e 'print time'`" but that seems OTT, and perl > > may not be on teh users PATH. Any suggestions ? > > "date '+%s'" does it under BSDI, but I'm not sure how portable it is. > That doesn't work under SunOS 4.1.x, but this does: date "+%S %M 60 * + %H 3600 * + %j 86400 * + %y 31536000 * + p" | dc This assumes 365 days/year, so if you jump from a leap year to a non-leap year it won't work right. Hey - a 1/1460 failure rate is better than most Windoze programs I've used ;-) It also isn't the "absolute" time, (as given by time()), but gives a number of seconds that constantly increases. With a little more work you should be able to adjust this to be close to time() functionality. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

e$: Carts, horses, other dromedaries, and the needle's eye of economics...
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Sender: rah(a)mail.shipwright.com Mime-Version: 1.0 Date: Sun, 10 Aug 1997 11:05:54 -0400 To: e$(a)thumper.vmeng.com From: Robert Hettinga <rah(a)shipwright.com> Subject: e$: Carts, horses, other dromedaries, and the needle's eye of economics... Sender: <e$(a)vmeng.com> Precedence: Bulk List-Software: LetterRip 2.0 by Fog City Software, Inc. List-Unsubscribe: <mailto:requests@vmeng.com?subject=unsubscribe%20e$> List-Subscribe: <mailto:requests@vmeng.com?subject=subscribe%20e$> At 5:51 pm -0400 on 8/9/97, Somebody wrote: > I couldn't imagine more depressing news. The linking of > internet + banking + fraud + organized-crime + offshore is precisely the kind > of negative publicity which will set back e$ <...> horribly. I > desperately wanna cry "Say it ain't so, Joe!" Oh, well. We move on. All > the more reason to find some topflight Swiss, Belgian, Brit or German bankers > to play. But, this will make _them_ doubly shy, too. Agreed, but this Russia/Antigua thing is *really* not a big deal. Expatriation of assets is a completely orthogonal issue to the adoption of digital commerce and financial cryptography. That's because financial cryptography is about vastly improving the financial system, and not at all about killing the nation state to save our freedom. (I knew I'd get your attention with that one... :-)) Personally, I believe that the use of strong financial cryptography is the way that the internet will bring about the death of the nation-state, and I'll be extremely happy when that happens, just like a lot of industrialists rejoiced in the decline and fall of the aristocracy. However, the nation state will adopt financial cryptography and digital bearer settlement because it *has* to, economically, the same way that aristocracy adopted industrialism of its own economic necessity, an act which ushered in the nation-state and their own political demise. Like all technological progress, strong financial cryptography should enable you to do better transactions much cheaper. Technological progress cannot be commanded or stopped with a political decision, as any student of the Spanish inquisition, or Stalin, or Mao, will attest. Clearly, politics may be why you try to invent things in the first place. Diffie invented public key cryptography and Chaum invented blind signatures for political reasons, obviously, but their technologies themselves are value neutral. They're just facts, not political opinions. Remember what happened to government mandated technologies of the past, like synthetic fuel subsidies and the 'alternative' energy debacle -- or Lysenko. Paradoxically, even though people may invent things because of their politics, the unpredictablity of invention's outcome is such that it is in fact science -- reality -- that creates politics, and not the other way around. The political cart cannot be put before the economic and technological horse. So, at the risk of using a "utilitarian" argument ;-), discussions about the "politics" -- even the constitutionality -- of technology is a waste of time. This is particularly the case in discussions about the politics of financial cryptography, and, I daresay, all cryptography. It's the economics of the technology that matters, and since financial cryptography is by its very definition an economic technology, appeals to politics are even more irrelevant in discussing it. Cypherpunks knew this a long time ago, by resisting attempts to herd them into some kind of political action committee or another. "Cypherpunks write code", and all that. Of course, it doesn't keep us all from political kibbitzing -- or writing the occasional screed. :-). Just like any successful technology, if a politician gets in the way of financial cryptography, economic progress should eventually make so much money that it simply buys him out of the way. If it can't afford to to do that, then financial cryptography on public networks won't be adopted. Cynical it may be, it's still that simple. So, to my mind, the whole question of going offshore is now pretty much immaterial. We understand now how to do the trustee/boundry-layer work at any institional trustee bank. We're pretty much at the stage where we can walk right into the front door as a customer of giant institutional banks like State Street, or Banker's Trust, or Morgan Guarantee -- or even the Fed itself. Any bank who wants to hold reserve accounts in trust and to handle the funds transfer work on behalf of digital bearer cash users on the net, which any of these kinds of banks will do now already for clients like investment banks and mutual funds. We understand things well enough now to plug the net right into the existing financial system, on simple terms that it understands completely, without any legal problems whatsoever. And, because of this, we can also turn right around and do all the things we want to do on the net completely legally: blind signatures, anonymous transactions, and all. And, frankly, we'll be cheered by the financial and business community when we do, because we'll probably reduce the cost of cash transactions by 3 or 4 orders of magnitude, or more, not to mention creating *profitable* transaction sizes, from picodollar to teradollar, never before seen in the financial community. That's because the reason for adopting blind signature technology is not that you will pay extra to use anonymous bearer certificates, absolutely not. It's that because of their very anonymity, which enables you to trust someone who you can never know, digital bearer certificates will probably be much cheaper to use than non-anonymous digital cash or book-entry settlement methods, just like cash would be cheaper to handle if it weren't physical. Which is, of course, the point of blind signatures in the first place. So, if people who sell pornography, or have illegal businesses, want to get their money onto the net under newer bearer certificate market models like trustee/underwriter, they should be able to use their own banks to do so, like everyone else would. All criminals of any real stature have banks who know them and love having them as customers anyway. In addition, people will figure out other non-bank ways to get money onto the net if they want to, especially if there's something to do with it when the money gets there. I expect that there will be lots of net.smurfs who will continually find new and better ways to convert meatcash into digital cash, and law enforcement will have to use the same methods they use now, probably at the same success rates they now have, to stop that activity. Frankly, there's no difference between all that and the status quo anyway, so I really don't anticpate the market for forensic accountants to crash anytime soon. It doesn't matter anyway. All of this concern for potential illegal uses of e$ is in fact peripheral to the main chance, the central economic fact that strong financial cryptography on geodesic public networks, anonymity and all, is going to revolutionize finance and it thus *will* end up legal in its own right, whether it is or not today in your particular jurisdiction. The potential for criminal use of financial cryptography is simply noise compared to the techtonic economic benefit derived from having a ubiquitous geodesic economy, and frankly, most people in the central bank and economic strategy business know this. Ironically, these denizens of large central bureaucracies are turning into some of the biggest behind the scenes cheerleaders of the technology of financial cryptography. They understand that a nation state which makes the mistake of criminalizing or even controlling financial cryptography (and thus any strong cryptography at all) will go the way of all the nations which ignored the very industrialism which made them the powers they are now. Just like the inquisition killed Spain as a world power when it killed science (and thus literacy) in the name of religeon, effectively exiling it's entire intellegencia to Amsterdam and London and Geneva, so too will any nation state kill itself if it ignores internet bearer settlement. Except that the "country" the money goes to will not be someplace like Antigua, but the very net itself, which is everywhere and nowhere, all at once. Fortunately, we don't even have waste our breath making that argument. We just need to develop the technology on the critical path, which means that our business as developers and sellers of financial cryptography products is to create the ability for people to spend money on the net with as little concern as possible for who they are, biometrically. The cheapest way to do that right now is to use a certificate purchaser's existing bank to authenticate them, coupled with some combination of back-channel, and eventually internet-tunneled, automatic teller network and ACH/Fedwire transactions, all of which gets meatspace money in and out of a trustee's reserve account. This will solve all our authentication issues and make the user's money convertable into digital bearer certificates, all with no great mental leaps from the banking -- or regulatory -- communities. All the underwriter sees is an authorization from the trustee to issue certificates, and then anonymous certificate exchanges after that. All the trustee sees is authorization and a promise from the purchaser's bank to wire funds to cover what for all intents and purposes is an ATM withdrawl. All the purchaser's bank sees is a request from an account holder equivalent to an ATM withdrawl or deposit. All the buyers and sellers see is money and goods. :-). Nobody knows who does what to whom, anymore than they do with handling and accounting for cash in meatspace, and every's happy. And, ironically, everyone's accountable enough to the regulatory authorities for the time being. If we let the existing banking system handle the authentication at the meat/net boundry layer in this fashion, all the feared jurisdictional and regulatory problems for digital cash and digital bearer certificate finance are instantly defined out of existance. Even FinCEN itself knows it can't police cyberspace if book entries are economically impossible there. They also know that they can do their jobs just fine for the time being by tracing money up to the net, and watching for it to come out somewhere else. Detective work will never go out of style. Fortunately for cryptoanarchists everywhere, financial assets will someday just stay on the net, because the net is where the information that feeds markets for financial assets will be in the first place, just like industrial assets ended up in cities because that's where the information to manuplate them was. The millenium will have arrived. To continue in the millenial vein, we can continue to render unto Caesar all the financial information he can force out of us in meatspace, because the "kingdom" of net is where all the real money will eventually be, and he can never go there. To beat our aforementioned and, only-apparently-defunct wagon-pulling dromedary anology with a rather large ironic stick, it will be easier to get a camel through the eye of a needle than it will be maintain a nation-state in a net economy. Even more fun, economic necessity dictates that the camel, or whatever other, say asinine, dromedary you have in mind, will have to build the needle's eye the rest of us will walk through, or they'll go out of business. Cheers, Bob ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ --------------------------------------------------------------------- Where people, networks and money come together: Consult Hyperion http://www.hyperion.co.uk info(a)hyperion.co.uk --------------------------------------------------------------------- Like e$? Help pay for it! See <http://www.shipwright.com/beg.html> Or, for e$/e$pam sponsorship, <mailto:rah@shipwright.com> --------------------------------------------------------------------- --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/

1 0

Re: Florida Drivers Permits
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:55 AM 8/29/95 +1000, you wrote: >>>Better would be to figure out the encoding scheme and post it here. >>I like this, myself. It'd be nice to be able to have the picture of my >>choosing instead of a digitized thumbprint... > >I think the officer arresting you would frown if your license dumped a nudie >picture of Cindy Crawford instead of your identification details. Yeah, but your basic thumb-shaped black smudge might look believable... #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1