September 1993 - cypherpunks-legacy

Anonymous Credentials
by Duncan Frissell 02 Sep '93

02 Sep '93

To: cypherpunks(a)toad.com Another good argument in favor of anonymous credentials... A person of my acquaintance who was long ago "seduced by the dark side of the Force" tells me that there is a lucrative market in ID copies supplied by people working in the personnel departments of companies. When new employees come with their birth certificates, SSN cards, driver's licenses, etc and their completed I-9 forms as required by the '86 Immigration Act, the clerk will take them to the copy machine, hit the button twice, pocket the extra set of copies, sell the ID package to a credit borrower or ID craftsman. All sorts of juicy info is there in one place. It's great. Duncan Frissell Who will fool them all one day (and make the former Prince jealous) by changing his name to ASCII 7 so that bells will ring whenever a database accesses it. --- WinQwk 2.0b#0

1 0

ViaCrypt export?
by felix＠hu.se 02 Sep '93

02 Sep '93

Will ViaCrypt consider exporting pgp? (well, I think I can guess the answer ;-) However, pgp is already widely used outside USA (at least as many as the US users, I suspect). It would be interesting to know what they're going to do about it. There exists no country boundaries in cyberspace, you know! ---------------------------------------------------------------------- - RealName: Felix Ungman InterNet: felix(a)hu.se AppleLink: SW0358 - - Felix gor det goda godare! - ----------------------------------------------------------------------

2 1

Chaos up and running
by Chael Hall 02 Sep '93

02 Sep '93

I know, long time, no post... Well, I have been very busy this summer. The end result is that my machine (chaos) is finally online. I will be running an anonymous remailer (maybe more than one) from this site and intend to run a pseudonymous system like anon.penet.fi here. I have implemented it and need a little help incorporating PGP encryption. The machine is in a secure area and is under the exclusive control of me. At the moment, I am prepared to provide accounts to those who are willing to help improve the system in some way. If you feel that you can contribute, there are several avenues by which you can do so. For example (this is not an exhaustive list): 1. Upload cypherpunks-related files to the anonymous FTP area. 2. Telnet or rlogin to chaos.bsu.edu (147.226.53.28) and login as guest. Follow the instructions to request an account. 3. Write me (nowhere(a)chaos.bsu.edu or root(a)chaos.bsu.edu or nowhere(a)bsu-cs.bsu.edu or chall(a)bsu.edu or 00CCHALL(a)bsuvc.bsu.edu) with a request for an account. If you choose either option two or three above, please tell me what you intend to accomplish through having this account and in what positive ways your having an account will impact my system. Odds are, you will be accepted. There is great potential in having this system on the Internet. I am creating a mail server to aid in discussion about the direction that chaos is going to head. Anyone who would like input on this please send a request to be put on the mail server and I will set it up when we get a few brains together. This is just a quick note (it's lunchtime in Indiana) so if I glossed over anything or neglected to mention something, let me know. The following addresses might be of interest to you: remailer(a)chaos.bsu.edu anon.ping(a)chaos.bsu.edu and anon.help(a)chaos.bsu.edu For a list of anon.* addresses for specific functions, finger anon(a)chaos.bsu.edu We were having some lookup problems since chaos has only been online for two days... Please mail my nowhere(a)bsu-cs.bsu.edu account if you cannot access the system for any reason. Thanks, Chael Hall -- Chael Hall nowhere(a)chaos.bsu.edu Chaos Unlimited nowhere(a)bsu-cs.bsu.edu

1 0

NY tax on info services (whatever that means)
by plmoses＠unix.cc.emory.edu 02 Sep '93

02 Sep '93

I was sloppy in stating the test for a Commerce Clause problem with this law. Hopefully this is a bit more accurate: - First ask, Does this law affect interstate commerce? How and to what extent? - Then ask, Does the law burden interstate commerce in any way? - Next, Does the law have a discrete benefit to State (ie NY State) interests? - Finally, does the benefit to NY interest outweigh the burden on interstate commerce? Is the state interest more significant? Two caveats: - This is not offered for any purpose other than mere speculation and intellectual analysis. - Free legal advice is worth exacty what you pay for it. Paul

1 0

CRM, a new remailer's utility
by astrashe＠nyx.cs.du.edu 02 Sep '93

02 Sep '93

I've just written an msdos utility called CRM that I'd like to offer to the public for testing. CRM is supposed to make use of the encrypted cypherpunk remailers as simple as possible. This is how it works: you tell crm the name of the input (plaintext file), and the address of the person you want to send it to, and crm will affix the "Request-Remailing-To:" and "Encrypted: PGP" headers to the document and perform nested encryptions with PGP. It wraps the result in a /bin/sh script that will mail the cypher text to the first remailer on the chain when it's executed. If you did one of these on your msdos computer: crm tfile astrashe(a)nyx.cs.du.edu You'd end up with a file called tfile.crm that would contain the shell script. Then if you uploaded that to your unix account, and typed: sh < tfile.crm The message would be sent to me through a chain of encrypted remailers. A random list of of of crm's features: You can specifiy the subject line in the original text file, or crm will prompt you for it. You can put the destination address in the command line, or you'll be prompted for that as well. Output (.crm) files can be concatenated to make a single long script that will send more than one letter. The subject-line is embedded in the ciphertext. The number of links in the chains and the list of possible remailers is contained in a text file that can be located anywhere on the path. Crm is writen in turbo pascal 5.5 and the source comes with it. I wrote it all yesterday (except for some recycled code fragments), so it's kind of quick and dirty. If anyone would be willing to take a look at this, I'd be grateful. Once I'm convinced it's reliable (it *seems* reliable now) I'll upload it to soda. If you're interested, email me at astrashe(a)nyx.cs.du.edu and I'll send you a uuencoded version through the mail. Please put CRM in the subject of your letter so that it doesn't get lost in the shuffle. Thanks. Alex astrashe(a)nyx.cs.du.edu

1 0

MISC: DH key xchange
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Earlier somebody (Samuel Pigg?) asked for a D-H key exchange reference. It should be in any modern crypto textbook, and is easy to follow. Alice and Bob want to exchange keys over a hostile channel. They pick a prime p, a random number a, and exchange this information. Alice picks Ra, a random number less than p, and keeps it secret. Bob picks Rb, also a random number less than p. Alice calculates Ya = a^Ra mod p, and sends the result to Bob. Bob calculates Yb = a^Rb mod p, and sends the result to Alice. To recover the common key Alice and Bob will now use with each other, they raise the result the other person sent them to their secret random number, and take the result modulo p. That is, Alice calculates Yb^Ra mod p, and Bob calculates Ya^Rb mod p. Even if an eavesdropper gets a, p, and the intermediate Ya and Yb, the final key cannot be determined (due the difficulty of the discrete logarithm). Example: 1) Alice and Bob pick a = 11, p = 347 2) Alice picks Ra = 240 Bob picks Rb = 39 Alice and Bob keep Ra and Rb secret 3) Alice calculates Ya = a^Ra mod p = 11^240 mod 347 = 49 Bob calculates Yb = a^Rb mod p = 11^39 mod 347 = 285 4) Alice sends Bob Ya = 49 Bob sends Alice Yb = 285 5) Alice calculates Yb^Ra mod p = 285^240 mod 347 = 268 Bob calculates Ya^Rb mod p = 49^39 mod 347 = 268 Now Alice and Bob can communicate using their common key. Even if an enemy intercepts a = 11, p = 347, Ya = 49, and Yb = 285, the common key cannot be calcuated. (Well, they can here since I'm using small numbers, but with large numbers the discrete log problem is intractable). -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVzxYOA7OpLWtYzAQGzvQQAltkJR3xd/5YJt1pBt2/fWmCrRGqy0RFW ZZEL5ZHUNO9glaYOA39vUlRbZX8IDwHwKSDXJt98NsHH3WT5JJ0i52hy37mcWLOx 7FbsCo8MMjg2xOye3YLLzXa6a99ad5nV7/rk2pL+9mP0lNZdFcWGnfDvz/F5gqCF qMRAYby1KI8= =6ZSd -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

KOH: disassembly
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- About the KOH virus/program: I've receive two disassemblies of the program (but not the original source code yet; I haven't had a chance to try to contact the author). I'm not sure that either person who mailed me the disassembly wants to take credit for it, publically at least :-) so I'll just thank them here for their work, and answer questions in email (although one of the disassemblies includes an email address). One person indicated that KOH really isn't a virus at all, so maybe this can be answered by folks who know more about such matters than I do! Apparently the fast encryption method is indeed an XOR; other than that I haven't had a chance to look over the code. I am interested in the IDEA implementation that KOH includes. So, if you are interested in copies of the disassembly, let me know. I had one report that KOH locked up an 8088 PC from a tester (thanks!). I'd try to post something intelligent about the code but I just haven't looked at it enough to comment. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIV0DYOA7OpLWtYzAQFP0wP+KrWx2hlne9XRdwOi/3uL//6sy7Bus69U ZvBD7OVUTa9NQEjwlSRlUHEQq/WKnPVZwGhqXLMyIXz6A+DaMTt1NgsQ/RnbHNT0 I9tDUYnSOMA84LRYPP14ZFW+1tWdPtLFI3mOumVr/RyEhz7PJnkKdFVPoCZYWZd9 a9n3yF6YKV0= =X0M4 -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

MISC: cut & choose
by Karl Lui Barrus 02 Sep '93

02 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Earlier I mentioned cut-and-choose protocols as a way of protecting from signing a message that you really don't want to (ways of forging signatures on documents). The protocols are simple and rest on a probabalistic argument (similar in some ways to the "proof" in a zero-knowledge proof) - you can be certain to any degree you wish that you are not about to sign a harmful document. Essentially, Bob makes multiple copies of the document and appends random bits on the end of each. Then, he blinds each document with a different blinding factor, and presents all the copies of the blinded documents to Alice. But before she signs anything, she demands that all documents are unblinded, except one. Bob complies and produces the unblinding factor for all the documents except one, and unblinds them. Alice looks over the documents to verify their content, and if she is satisfied, she goes ahead and digitally signs the remaining document, which is still blinded. For example, say Alice is a digital bank. Bob wants to get $10 of digital cash, so he prepares a message, blinds it, and goes to the bank. However, Alice, who has read about the notary protocol, is leery of signing random strings, so Bob goes home again and prepares 100 messages, 100 blinding factors, and blinds each message with its own blinding factor. He shows up at the bank and gives Alice all the messages. Alice picks one message and hands back the other 99, demanding that Bob unblind them. So he complies, and Alice verifies that they all are in fact messages for $10. Satisfied, she digitally signs the last message, knowing that there still is a 1% chance that Bob cheated the bank by slipping in a $100 message with the $10 messages. So Alice can feel as comfortable as she likes by just asking for more messages. Say that cash messages look like this (with random bits at the end): This is $10 of digicash legal tender from First Digital. ADF!#$%@^%&gsu$ When Bob blinds this, it becomes unreadable so Alice can't verify that it is in fact a legitimate message (Bob may be trying to get Alice's signature on another document). But Bob does need to blind the message or the bank (Alice) can note the random bits, serial number, or whatever, and thus correlate the cash with him. The solution is the above protocol, which leaves an 1/n chance of fooling the bank, where n is the number of messages. Alice can ask for n messages where n is large, but there will still be a 1/n chance that Alice picks the special message and is tricked into signing it. (Say Bob slips in a message for $1000 into a bunch of $10 messages; he may get really lucky and have Alice pick the $1000 message, demanding he unblind all the rest to reveal $10 messages). However, this can get pretty expensive to implement for high confidence levels. Again, I'm sure a document forgery can't occur with PGP or even RIPEM (in the notary protocol manner) since neither program blinds messages: they calculate hashes, compress, encrypt, digitally sign hashes, but don't obscure messages by a multiplication factor. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIVz4YOA7OpLWtYzAQH0lgQAl3QZ6GFbWntDzuk+CKrkGyealZvHXlu5 stiq3OY+svoQCNRa2TjwJKS6htWsgqeYT4YUFwFV8YtfofavKqUGpuhveC3T5kjH DyKK9Ha1IVjrl5mX4uyz089nU45lQqKJKXCiplDLezRLiB1avVZmIyhdqOyB158W WTjwedeXUVo= =nzAD -----END PGP SIGNATURE-----

1 0

new remailer
by remailer＠netcom.com 02 Sep '93

02 Sep '93

Well not _that_ new. I've been operating it since Sunday. I am operating this remailer out of my personal account. It's interface is identical to the standard cypherpunks remailer as defined by the code I ftp'd from soda.berkeley.edu. I've modified the code to fit it to my particular administrative situation, so you should consider this remailer EXPERIMENTAL. Remailer Address: catalyst(a)netcom.com Remailer PGP Key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4 YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+ =MgMa -----END PGP PUBLIC KEY BLOCK----- Any message that has a header line of the form Request-Remailing-To: somebody@somewhere -- either in the header or with the header pasting operator (::) -- will get remailer handling. If a message does _not_ include any remailer commands, then it must actually be a message to catalyst(a)netcom.com (me). The message will subsequently be delivered to me. Note: badly-formed remailer commands may be equivalent to _no_ commands at all, and thus your message will be delivered to me, instead of getting remailed! I WARNED YOU. Comments, problems, questions > catalyst(a)netcom.com. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: NY TAXES CYBERSPACE, CRAM REACTS
by George A. Gleason 02 Sep '93

02 Sep '93

Yeah, I agree the tax is stupid, and I would certainly hope that some of the affected parties get together and start some kind of lawsuit on the basis of the discriminatory preference for paper media... ...but for God's sake, let's not sink to the level of calling for the assassination of elected officials... aside from the obvious legal issues, that puts us on *their* level. -gg

1 0