December 2003 - cypherpunks-legacy

Re: How to legit encryption
by Jeff Gostin 17 Dec '03

17 Dec '03

tim werner <werner(a)mc.ab.com> writes: > This is a neat way of expressing a good idea, but I wouldn't count on it. > A language can probably be construed as something that can be understood by > anyone who learns it. Even though I speak PGP, I still can't understand > what you say without a key. There's probably no legal precedent for that > yet, but look what they've done with the rest of the Constitution so far. Ok, what if PGP-encyphered text were argued to be COMPILED? In that case, the original SOURCE CODE was being shared, and the COMPILER being held secret. Source-reading keys are available upon request. Or some twist like that. :-) What do you think? All of a sudden, we have compiled source code being pushed around that is VERY difficult to reverse engineer without the proper authorization. --jeff

1 0

e$ : NetBank legality
by Hal 17 Dec '03

17 Dec '03

I'm curious about the legality of NetBank in the context of our earlier discussions about demand deposits and Chaum cash. These people will take your money and give you electronic tokens, and they will take the tokens and give you cash (minus 20%). Does this sound legal? Are they a bank? I wonder what their tax liabilities are. Sales tax on selling the tokens? Is this a barter system? If so, they're supposed to get SS#'s and such. Maybe you have to give that information if you sign up as a vendor, but legally I'd think ordinary users would have to be reported to the IRS as well, and it doesn't sound like they're doing that. This whole thing sounds pretty questionable legally. It will be interesting to see how it comes out. Hal

1 0

e$: NetBank
by rah＠shipwright.com 17 Dec '03

17 Dec '03

There's an outfit called NetBank, which is selling e-cash-like *certificate numbers*, through a dial-up BBS on a 900 line, in any denomination you want, which you can e-mail to vendors to buy stuff with. In fact all the interactions with the bank (deposits, breaking "bills" into smaller denominations, etc.) are done with switch codes in e-mail. It's extremely ungainly, and it looks userous too, to the extent that they charge 20% (each way?) to cash you in and out. I hoovered out all the stuff in their infobot (netbank-info(a)agents.com) and I really haven't plowed through it all yet. If you folks are interested I'll summarize it for the group and/or redirect my dumpster-divings on the subject to you individually in e-mail. Just let me know. 'Course you're welcome to play with their infobot yourselves, I suppose ;-). It looks like someone did some serious work on this, folks. That's just a philosophy major from Missouri talking, of course. I wonder who they are? I heard some discussion about them here, but I can't seem to find the thread in my e$ article stash.... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

List Dead Again!??
by j.hastings6＠genie.geis.com 17 Dec '03

17 Dec '03

Wow man. No letters waiting? No way. Could be GEnie, or majordomo again. Anyone get this? Please respond. Kent - j.hastings6(a)genie.geis.com

1 0

Re: Voice/Fax Checks
by Jonathan Rochkind 17 Dec '03

17 Dec '03

> I had the impression from that paper that with transferred ecash, a person > earlier on the trail could always recognize the cash even at a later point. > This followed, Chaum claimed, from the need to detect double-spending. That makes sense, and I don't see it as being too much of a problem either. Physical cash works that way too; if I write down the serial numbers of all money that goes through my hands, then if it ever comes back into my hands I'm going to recognize it. It would be nice if ecash could not have this "flaw", but it doesn't seem vital, or even particularly important, to me.

2 1

Re: e$ : NetBank
by analyst＠Onramp.NET 17 Dec '03

17 Dec '03

>There's an outfit called NetBank, which is selling e-cash-like *certificate >numbers*, 8 digit numbers only. No internal checksums or verification. Merchants must send an email message to verify that the money is previously unspent and receive fresh bills. >It's extremely ungainly, and it looks userous too, to the extent that they >charge 20% (each way?) to cash you in and out. I hoovered out all the >stuff in their infobot (netbank-info(a)agents.com) >Bob Hettinga > Agree about ungainliness. They aren't yet set-up with PGP or PEM, although they say they are looking into it, so they currently suggest that if you want to send encrypted mail, that you generate a key to be XOR'd with all messages to and from. They do provide the C code for the encryption, though ;) >From reading all of the info from the above infobot, it looks like they only charge the 20% once, to the merchant when he tries to redeem e-certificates for $USD, which they will pay out at the end of each month. They claim in their docs that the 20% is the cost of their 900 number service, so I suppose their business plan is to make money on the float, since they are not charging transaction fees for making change, verifying e-cash, etc. If they accepted credit cards they might be in much better shape. I would much rather see real Chaum-style electronic money, but have not yet received a response after signing up for their beta test. I wonder if NetBank's style of serialized e-certificates provide the 75% of the functionality that most people need to ignore better alternatives, especially if, as with Pr0duct Cypher's money, their is a big learning curve to go up before they can use it. Any pointers to other near-term e-cash systems? I am very interested in setting this up for relatively small transactions (<$50) in the not-to-distant future. Thanks for info. -- Benjamin McLemore <analyst(a)onramp.net>

1 0

Re: My anonymous remailer
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Still, though, I think this would do more harm than good. I get about : 20 to 40 messages a day through my remailer, and only 5 or 10 of those are : encrypted. Switching to a policy that would require chaining and encrypt- : ing to make it useful would make it a lot harder to use the remailer. If Agreed, but it would also force us to get off our butts and make integrated remailer-aware mailers work properly, as opposed to the broken kludges we have at the moment. In the long term it would be for the better. (Every single time I've tried anything fancy with chaining and encryption, it hasn't been delivered. And I don't consider myself incompetant.) : The other problem I see with Graham's idea is that I'm not sure the : technology is there to provide good security in the face of this much : information. Not many of the remailers add delay, and a lot of people don't : like it when they do. In that case it may be easy to figure out what Again, fixing this up would be for the better good. You can just imagine that the FBI is already watching all remailers closely under arm-twisting from the Software Publishers Association, not to mention the NSA doing likewise for their own reasons. I think we *should* force ourseles to make traffic analysis visibly impossible. If we can crack an anon posting path with the same information available to an attacker who can monitor all the lines, our system is broken. We should put it up for peer-group testing just like a new encryption algorithm. I believe the security of current remailers is a joke against a real attack. It's *only* good enough to hide identity from other usenet readers. We might as well all use only one-hop remailers and stop kidding ourselves that the multi-hop stuff does any good at all. (I don't believe the anti-traffic analysis support of the current remailers is any good, which is why any postings I've made through remailers have been single-hop in clear. I just don't post anything that would get me in legal trouble. OK, maybe a couple of posts I've made would be personally embarrassing if I were outed, but I wouldn't be by any LEAs that were watching. They'd just be able to use logged postings in criminal cases) : path even a chained encrypted message took. Even the delaying remailers, : if they published message sizes, would usually reveal their in-to-out : correspondance. So I think it is premature to do this. Until we have : remailers which can support cryptographically strong message padding : with standard message sizes, running on un-hackable systems with delays : and batching to confuse the in-out relationships, it would be counter- : productive to do what Graham suggests. Precisely my point. Except I see it the other way - as long as we're not forced to implement these measures properly, they'll never happen. : service it's hard to know what features to provide. In particular, if : cleartext output is prevented, how much does that impair the usefulness of : the network? My instinct is that it hurts a lot, although it would be nice : for the operators since it would eliminate most sources of complaints. I meant that cleartext *input* should be prevented. Cleartext output however can be 'outed' in accordance with policy, even if it's personal mail. Also it can be silently dropped on the floor by the last-hop admin without any comeback, for whatever egregious reason he chooses, or even randomly. It's up to the sender to pick a route that works. If some remailer admin (like JGdeA, or was it John Stanley?) choses to allow M.M.F postings, then he can take the heat for them personally. It's impossible to tell an email recipient apart from a mail to news gateway, so we can't enforce encrypted output only, if we allow posting. However, the 'outing' policy makes it in people's best interests to encrypt to the destination user if they can. Unencrypted *mail* as well as news is also fair game for the last-hop remailer admin to delete on his personal whim. G PS When I say we should out all information, I'm only talking about information that's visible going in and out. If we ever get my earlier idea of chained encrypted reply-addresses to work, with time-sensitive keys that are deleted after a few days, I'm not suggesting publishing those keys. Certainly, we should assume that a few sites will be broken into, or even many sites, but as long as one site remains uncompromised, there's a strong link in the chain that holds up the entire chain.

2 1

legally circumvent the Sept 1,94 Legal Kludge, Program Part 000
by 0x7CF5048D＠nowhere 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- released to the public domain. The legal kludge makes output from PGP 2.6 from an Eastern University incompatible with earlier versions after Sept 1 1994. A Usenet article has documented a discovery by Paul Elliott that the pgp 2.6 legal kludge can be disabled by invoking it with the following parameters: pgp +CERT_DEPTH=0 +LEGAL_KLUDGE=OFF +CERT_DEPTH=real_desired_value others This program invokes pgp with the above parameters. "real_desired_value" is taken from the CONFIG.TXT file. This will cause the legal kludge that makes PGP from an Eastern University incompatible with earlier versions of PGP to be turned off. This program does not address the incompatible signature format problem. This does not modify the code or the executable of PGP in any way. It simply invokes it with unusual parameters. Therefore it should be legal. The program searches your config.txt file for the default value of CERT_DEPTH. It will run slightly faster if this variable is at the top of that file. The program to be invoked may be controlled by the environment variable "PGPEU". EU stands for Eastern university. This variable may specify the file name or a complete path. If this variable is undefined, the program indicated by the hard coded string "PGPEXE" will be invoked this string may be defined with a -DPGPEXE= flag at compile time. By default (that is if PGPEU is undefined) PGPNOKLG.EXE will search your path for a program called "PGP.EXE". Thus the command: PGPNOKLG -e file will call PGP 2.6 in a way so that the result will be compatible with earlier versions of PGP. The program PGPNOKLX.EXE invokes (by default) a program called "PGP26.EXE". So you could take the original program "PGP.EXE" from an Eastern University and rename it to "PGP26.EXE" somewhere in your path. You could the rename "PGPNOKLX.EXE" to "PGP.EXE" then when PGP is invoked normally it will really be PGPNOKLX which will invoke the original pgp (AS PGP26) in a way that output will be compatible with earlier versions. Thus scripts, shells and mail programs that are designed to invoke pgp could continue to work, but in a way that the output is compatible with earlier versions of PGP. This program has been ported to MSDOS and OS/2. Somebody please port to all other platforms. I have posted a zip file which contains source, makefiles and binaries as a pgp signed binary, in 3 posts. The following is the source for the programs pgpnoklg and pgpnoklx. - ---------------------------------------------------------------------- /* Released to public domain! works dos os/2, please port to all other platforms It has been recently discovered by paul elliott that the PGP26 (eastern University) legal kludge can be disabled by invoking pgp with the following parameters: pgp +CERT_DEPTH=0 +LEGAL_KLUDGE=OFF +CERT_DEPTH=real_desired_value others This program invokes pgp with the above parameters. "real_desired_value" is taken from the CONFIG.TXT file. This will cause the legal kludge that makes PGP from an Eastern University incompatible with earlier versions of PGP be turned off. This program does not address the incompatible signature format problem. The program to be invoked may be controled by the environment variable "PGPEU". EU stands for Eastern university. this variable may specify the file name or a complete path. If this varriable is undefined, the program indicated by the hard coded string "PGPEXE" will be invoked this string may be defined with a -DPGPEXE= flag at compile time. The program searches your config.txt file for the default value of CERT_DEPTH. It will run slightly faster if this variable is at the top of the file. deveolped for borland c++ compilers for msdos and os2 to compile bcc pgpknolg.cpp */ // necessary include files. #include <stdlib.h> #include <string.h> #include <dir.h> #include <iostream.h> #include <fstream.h> #include <strstrea.h> #include <iomanip.h> #include <process.h> // define executable path to invoke pgp. #ifndef PGPEXE #define PGPEXE "pgp" #endif #if defined(__OS2__) || defined(__MSDOS__) #define SEP '\\' #define SEPSTR "\\" #else #define SEP '/' #define SEPSTR "/" #endif int main(int argc,char *argv[]) { // path to invoke pgp. char pgpexe[MAXPATH]; // if environment variable PGPEU is defined use it // as the program to invoke as pgp! char * pgpeust=getenv("PGPEU"); if (pgpeust) strcpy(pgpexe,pgpeust); else *pgpexe=0; // If no such environment variable use hard coded PGPEXE macro! if (*pgpexe == 0 ) strcpy(pgpexe,PGPEXE); char path[MAXPATH]; // get the path where the config.txt file is supposed to be strcpy(path,getenv("PGPPATH") ); // and get its length int len=strlen(path); #if defined(__OS2__) || defined(__MSDOS__) // convert all '/' to backslashes for dos os/2 char *w; for(w=path;*w;w++) if(*w=='/') *w=SEP; #endif // if there some chars and last one is not \ then add one. if (len) { if ( path[len-1] != SEP ) strcat(path,SEPSTR); }; // add the filespec. strcat(path,"CONFIG.TXT"); // default value if can not get from config.txt file // this is the value in the pgp26 executable int cert_depth=4; // parse the config file for the value of CERT_DEPTH { // open the file ifstream config(path); if ( config.good() ) { // read till eof while( !config.eof() ) { char buf[512]; // read a line config.getline(buf,sizeof(buf)); // if not commented. if ( *buf != '#' ) { istrstream line(buf); char field[80],equ[80]; int depth; // parse line to first field equal char and value line >> field >> equ >>depth; if ( line) { // upcase the field strupr(field); // if we have a "CERT_DEPTH=val" LINE if ( (strcmp(field,"CERT_DEPTH") == 0) && (strcmp(equ ,"=") == 0 ) ) { // save stored depth cert_depth =depth; // abort search of rest of file // this program will go faster if CERT_DEPTH is // at top of file! break; } } } } } } // create a parameter string fo the form "CERT_DEPTH=val" // where val was found in the config.txt file! char reset_par[20]; { ostrstream reset_file(reset_par,sizeof(reset_par)); reset_file << "+CERT_DEPTH=" << cert_depth << ends; } typedef char * string; // list of arguements! string list[200]; // leading arguemnts int out_idx = 0; // name of program list[out_idx++] = "PGP.EXE"; // we do this to set the variable "value" in pgp 2.6 to =0 // the value of CERT_DEPTH is not really needed to be 0 list[out_idx++] = "+CERT_DEPTH=0"; // this will set pgp varriable "legal_kludge" =value=0 // works because value is zero because of above. list[out_idx++] = "+LEGAL_KLUDGE=OFF"; // set value of CERT_DEPTH back to its proper value. list[out_idx++] = reset_par; // add all the rest of the parameters from the command line! for( argc--, argv++; argc; argc--,argv++,out_idx++) list[out_idx] = *argv; // termintate the line! list[out_idx]=NULL; // replace the current program with an execvp call // never returns from execvp return execvp(pgpexe,list); } -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLi2sYw2Gnhl89QSNAQFAGwQAsYh2fCaK9y9ssONU6k9VMDKQLmc5Qz9L 7FdNOl3Qj5Kd7mudMLU/e0tsSPL9Sr4i629bKVFOlFXUXloYn5xRBsz+Ura4pgZD X2H5bzMAldrwdSN0zfjYX6G8NnvkcpXAZ0BFqw7tBWsflSx3wOjOXLxRDrfKvVvC DNx7M3uD3vg= =xdD6 -----END PGP SIGNATURE-----

4 4

Gore's "new and improved" key escrow proposal
by mpjohnso＠nyx10.cs.du.edu 17 Dec '03

17 Dec '03

Just think how easy it would be to comply with software key escrow requirements: imagine a new PGP option -- +encrypt_to_escrow_agents=on The escrow agent's PGP public key could be shipped with every copy of PGP... naturally, every PGP user will be required by law not to override this option if the Vice President gets his way. --- sound of tongue being removed from cheek --- I have tried to think of a positive use for key escrow. The only thing that I have come up with so far is kind of like having local key escrow within one company, or something like that. Kind of like having a master key that fits all the offices in one wing of a building, or something like that. That could be good in some business uses, provided you could pick your own trusted master key holder. I don't think that is what Al Gore has in mind.

10 9

Re: GUT and P=NP
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

>berzerk(a)xmission.xmission.com writes: > > One last word on this. Try and represnet a continum of states by an > > infinite turing machene. Go ahead, I dare you. You can't.<=big period. >Could I not let each position on the tape represent a real value in >[0...1]? >| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | >| TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | >| (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" | HAHAHAHAHAHAHAHAHAHAHA ROFL HAHAHAHAHAHAHAHAHAHAHA Okay. So I should be so rude. People please. When someone, especially like berzerk or tcmay makes a strongly definitive statement, PLEASE try not to show your ignorance to the whole group. Cantor demonstrated, near the turn of the century, that no such system can represent all reals in [0,1]. Boring technical explanation follows. Let f be a function from the integers to [0,1]. Note that the Turing tape has precisely one space for each integer, so this function cooresponds to your idea. I claim that f is not onto. (ie: you cannot represent all reals this way.) Write a decimal expansion for each elment in the range of f, and order them as follows: f(0) = .d(1,1) d(1,2) d(1,3) d(1,4) .... f(1) = .d(2,1) d(2,2) d(2,3) d(2,4) .... f(-1)= .d(3,1) d(3,2) d(3,3) d(3,4) .... f(2) = .d(4,1) d(4,2) d(4,3) d(4,4) .... f(-2)= ..... construct a, in [0,1], as follows: let g be a function from {0,1,2,3,4,5,6,7,8,9} to {5,6} s.t. g(x) = 5 if x>5, g(x) = 6 if x < 6. Let a = sum for i = 1 to infinity of g(di,i)/10^i. I claim that a is not in the range of f. Is f(0) = a? No, the first digits differ. Is f(1) = a? No, the second digits differ. Is f(-1)= a? No, the third digits differ. You get the picture. There are a couple of small details left out, you should be able to fill them in. Historical note: I believe that is the original construction. Further historical note: You can see the germ of Godel's work here. Nathan

4 3