- cypherpunks-legacy - lists.cpunks.org

License plates
by TO1SITTLER＠APSICC.APS.EDU 25 May '93

25 May '93

My understanding is that in many states, the Department of Motor Vehicles Records indexed on license plate number, and containing the name, address, and other information about the owner, is public or semi-public. How would an interested party go about finding this information? How difficult or costly is it? And what all is actually listed in the record? How about medical records? How private are they? How about other records which are, to me, private or appear to be private, but can actually be read by anyone without my consent? Kragen

1 0

Noise on the list
by Marc Horowitz 25 May '93

25 May '93

Would it be incorrect to say that people flailing randomly on the list trying to invent the next great encryption scheme is both a waste of bandwidth, and inappropriate to the list? I guess what I'm trying to say is that I see cypherpunks as a gathering of people trying to encourage privacy via technology. As such, technical discussions of how to implement a remailer would be appropriate, but it seems that garbage about how to make MacBeth decrypt into your plaintext should be reserved for sci.crypt.flame. There's also a lot of other inappropriate traffic, like the recent "espionage" thread. Save it for talk.bizarre. Should I crawl back into my hole, or am I not the only one who thinks that a lot of the random spewage on the list is just that? (flame off) I think this is a valuable list. I like being on it, most of the time. But we've already seen many people remove themselves because they were drowning in email. Can we please try to keep the messages appropriate, and the signal-to-noise ratio high? Marc

2 1

No Subject
by kelly＠pleiku.netcom.com 25 May '93

25 May '93

>From kelly Tue May 25 16:34:55 +0000 1993 remote from pleiku To: netcomsv.netcom.com!toad.com!gnu (John Gilmore) cc: whscad1.att.com!kqb, toad.com!cypherpunks, toad.com!gnu, kelly Subject: Re: Steganography and Steganalysis In-reply-to: Your message of "Tue, 25 May 1993 08:46:27 MST." <9305251546.AA17642(a)toad.com> Priority: urgent Date: Tue, 25 May 1993 16:34:55 +0000 From: "Stop the Big Brother CHip" <pleiku!kelly> Received: from pleiku by pleiku.netcom.com; Tue, 25 May 1993 09:34 PDT Content-Type: text Content-Length: 1907 Hi John, In addition I suggest still some more tools newsclip(by clarinet... provides for news clipping) newsfind(on soda.berkley.edu for searches of NNTP servers) agrep(Fuzzy set searches) expn(expanding mail aliases) addr-check(expanding and tracing mail aliases) netfind(email address searches) Xmosaic(hypertest gui... has some useful location features) whois(standard NS prog) For tracing that mysterious person on the end of the line... cypherpunks may want to consider "How to investigate by computer" by Ralph D Thomas In-detail explanation of commercial access to xcross, criminal justice/public records/postal forwarding/ credit info... And the infamous "How to get everything on anybody" Vols 1 and 2 by Lee Lapin and Scott French "The Big Brother Game" same "Ninja 1990" same... -- Parts of this .sig borrowed with permission from T.C.May. Perhaps it will indeed get me busted also. .......................................................................... Kelly Goen | Crypto Anarchy: encryption, digital money, kelly(a)netcom.com | anonymous networks, digital pseudonyms, zero Intelligence Systems | knowledge, reputations, information markets, Specialists Inc. | black markets, face banks, data havens, dark | tech, covert channels, shared secrets, | alt.whistleblowers, collapse of governments. Technical Monkeywrench | Public Key: PGP 2.2. | .......................................................................... PGP 2.2 Key available from PGP Keyservers on the Internet. pub 1024/1BA573 1992/09/09 kelly <kelly(a)netcom.com> Key fingerprint = EF 7A 38 99 22 84 E3 3B 90 2A DB 80 DC 65 DA 31 STOP THE WIRETAP CHIP(Clipper Chip)!!

1 0

Digital cash issues...
by Hal 25 May '93

25 May '93

Reading the article in the Whole Earth Review reminded me of our discussions several months ago about digital cash. I would be interested in seeing an implementation of digital cash suitable for email or Internet use. Chaum is working on "off-line" cash systems, where you don't have to check with the bank for every transaction. But I think there are problems with this in the network environment. The big issue in digital cash is double-spending. Someone could send the same piece of cash to more than one seller. (We say "double-spending" but really it could be triple- or worse.) Each seller can check that the cash was properly signed by the bank and not a forgery, but if they honor the cash only one of them can be reimbursed by the bank. On-line systems require the sellers to check with the bank to make sure a particular piece of cash has not been spent before. As long as the bank handles such queries sequentially, and adds each piece of cash to a database of "spent cash" as it sends an "OK" response back to a seller, then each piece of cash can only be spent once. Double-spending is prevented. Off-line systems are more complicated. They are designed so that the anonymity of the spender is lost if the cash is double-spent. This is achieved by having an exchange of messages between seller and spender, in which the seller specifies some random information and the spender responds based on the seller's message. Chaum's fancy mathematics guarantees that the spender's anonymity is protected if he only uses each piece of cash once. But if he uses it twice, the random information will be different for each transaction, and this will cause him to reveal more information about himself, enough information that the bank can deduce his identity. This process is problematical in the Internet environment, though. The need for a protocol between spender and seller might be tolerable for systems with direct TCP connections, but the universe of potential users of cash is much larger than this. I think it will be necessary for cash to work just via email. And in that case the requirement for three messages (spender to seller, seller to spender, spender to seller) for every transaction will be very cumbersome. Also, if double-spending is discovered it's not clear what you do about it. Ideally, if the customer has a large enough bank balance to cover the extra spending the bank can just dip into the account (once the customer's anonymity is broken by Chaum's algorithms) and pay off the sellers. But if this is not the case then it isn't clear who would take the loss or what legal redress the bank would have against the customer. All this seems to require some legal infrastructure which would delay the acceptance of digital cash. In an on-line system, transactions are somewhat easier. Customers send cash to sellers, sellers check the cash with the bank, and proceed with the sale. There are still three messages, but two of them are with the bank, so it is simpler because these always go to the same place. Spenders have it especially easy as they just send off their cash. So, I would think an on-line system would be more appropriate for the net environment as it exists today. Another big issue is the legality of cash. How legitimate does an initial implementation of digital cash need to be? PGP's acceptance has been hampered by its infringement of patents. Digital cash would have a worse time of it, probably; it infringes on RSA (for the bank signatures) as well as Chaum's patents. In the Whole Earth article Chaum indicated that he had the whole field pretty well locked up with patents. With PGP we can at least make a moral argument that non-commercial, personal use should be OK, but it's not clear that the concept "non-commercial" can really apply to digital money. Even if it could, RSAREF does not provide at all the functionality that is needed since it is the direct mathematics of RSA that provides the basis for blind signatures. So one would need to get permission to call the "pure RSA" entry points in RSAREF. Then some kind of agreement would be needed with Chaum. This is quite a daunting list. Whether you satisfy the patent lawyers or just decide to go with an under- ground approach, you then have the issue of backing the cash and the tax consequences. When I looked into this several months ago it looked to me like a digital cash system would be much like the "barter exchanges" which have been tried from time to time, and which have stringent tax reporting requirements, with associated serious penalties. England is apparently less strict about this than the U.S., with several cases of barter exchanges having been publicized recently. Perhaps that would be a better forum for launching a cash system. As for backing, I believe that the best way to give digital cash value is to make it possible to exchange it for regular cash. If you know that you can take received digital cash, email it to the bank, and receive a check in the mail a few days later for that amount, you will be likely to accept it. I have a Disney Dollar on my desk for which it is possible to take it to a Disney store and exchange it for a regular dollar. If the same thing can be done for digital cash then I think it will be accepted. All told, there are a lot of obstacles standing in the way of digital cash. The technology is complicated, patent issues arise at every turn, and the complexity of the tax and banking laws will have to be faced. It's not clear how soon we can expect to be able to tackle these problems. Hal

2 1

Steganography...
by Hal 25 May '93

25 May '93

-----BEGIN PGP SIGNED MESSAGE----- Kevin Brown makes some interesting points about steganography and steganalysis. The issue of recognizing whether a message has or might have a hidden message has two sides. One is for the desired recipient to be clued that he should try desteganizing and decrypting the message, and the other is for a possible attacker to discover illegal uses of cryptography. Steganography should be used with a "stealthy" cryptosystem (secret key or public key), one in which the cyphertext is indistinguishable from a random bit string. You would not want it to have any headers which could be used to confirm that a desteganized message was other than random noise. This would allow some public standard to be used for steganizing messages. Ideally, the standard would be chosen so that typical real messages, when desteganized by the standard technique, would produce close to a random bit pattern. Maybe Kevin's idea about taking the parity of each (four- letter or greater?) word in the message would work. With stealthy cryptography and a "random" standard steganographic technique people could use steganography without much fear that their messages will attract attention, or that they could be proven to be using this technology just by analysis of their messages. Only the desired recipient would discover the hidden message by achieving success in decrypting the random bit string that comes from the desteganography. He would have to try this on all messages and it would only work on those fraction with hidden messages aimed at him. A big problem right now is that none of Kevin's proposed approaches seem to be capable of being fully automated. I don't think that word substitution can be done safely, at least not by some simplistic algorithm. Words have many meanings and it is not easy for software to choose an appropriate synonym. This is a similar problem to machine translation, and I think those systems still require a lot of human supervision. In the olden days, spies used the "window" method of steganography. They had a piece of paper with randomly-scattered holes in it. They would put it on top of another piece of paper and write their secret message in the holes. Removing the "window" paper left a sheet of paper with some widely scattered letters. The spy then wrote a cover message among the letters, choosing his words so that the letters fit in. The recipient then had a paper with the same window positions so that he could read the message. We could do a similar thing - position the letters of a hidden (and encrypted) message at every 5th (or 10th, or whatever) position, and have a special word processor that let you compose a message but allowed you to see the forthcoming stega letters so that you could try to make your words fit around them. This might be harder than for the paper case because we have no ability to change the spacing of our letters in order to fit around the fixed letters more easily. Steganography will be more labor-intensive than ordinary encryption. You have to write two messages: the encrypted one you want to send, and a cover message that is five to ten times longer. Plus you may need to massage the cover message to one degree or another depending on how automatic the stego insertion is. This might be reasonable if crypto is outlawed and you are part of an underground group fighting the government, but for ordinary use I don't see how to make it both easy and safe. Hal -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAIau6gTA69YIUw3AQFW6wQAk5r3TVkn3VI4LS+9103J/yQMNs1kypkt qkdX3FRHll7O9KeIipYdDvJUGeIfFzQobyBy6pGvSQZKV0tdb+ZM+3BG9LlpUFZZ Y1wGX0aJChvY+/L2RugxxLGROYOdZJzeijBj5L6swgmtsschHnsfo7j7A3md6gDq rJyFvOaU5ms= =g99M -----END PGP SIGNATURE-----

1 0

VinCrypt
by fergp＠sytex.com 25 May '93

25 May '93

Has anyone heard of this product or know how to get in touch with its authors/developers? 8<-------- Snip, Snip ----------- Journal: Computerworld March 1 1993 v27 n9 p6(1). -------------------------------------------------------------------- Title: Hackers switch sides, offer security package. (includes related article on the VinCrypt data security application) (Product Announcement) Author: Daly, James Abstract: Notorious computer hackers introduce their $159 VinCrypt encryption package, which enhances data security. The DOS-based application has been created by highly skilled underground systems programmers. Co-developer Ian Murphy, who is president of Secure Data Systems Inc, also will distribute the application. He indicates that VinCrypt has not gained the approval of any government agency, but he does not seek government approval. Murphy believes that data encryption packages based on the Data Encryption Standard or RSA Data Security Inc's standards are not secure because their basic algorithms have been given to the National Security Agency. VinCrypt's source code will not be passed around, but some experts suggest that it then will be difficult to evaluate the package's real security effectiveness. ----------------------------------------------------------------------- Type: product announcement Product: VinCrypt Topic: Data security Software Packages Product Introduction Computer hackers Encryption Standards 8<----- End of plea for assistance -------- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp(a)sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip.

1 0

re:pi compression
by Do you know what's in the trunk? 25-May-1993 0917 25 May '93

25 May '93

> >>Since all possible finite bit strings are, by definition, contained >>in the unending cavalcade of bits in pi, > >Definition? I have seen not this asserted even by theorem. Not >surprising, since the statement is patently false. There are >2^{\aleph_0} finite bit strings, and only \aleph_0 of those are >subsequences of pi. Um, it doesn't follow to me that it's _obvious_ that 2^Aleph_0 is larger than Aleph_0. It might be- but I'd like to see the proof. Now, Aleph_0 ^ Aleph_0, on the other hand... -Bill (wondering why this thread of recursively nonenumerable transfinite ordinal stuff keeps cropping up in *all* his mailing lists)

1 0

UUDecode
by jslee＠well.sf.ca.us 25 May '93

25 May '93

Where can I get the source code for UUEncode/UUdecode for the Mac or UNIX. Either would be great! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +"The community can rest assured that their interests are very much my own,+ + and that anything I can do to maintain the security of the citizens, will+ + be my primary objective. Be seeing you. b-|" - Number Six->The Prisoner+ + + + from the village of jslee(a)well.sf.ca.us - a still tongue spills no beans + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: Caller ID Question
by George A. Gleason 25 May '93

25 May '93

Caller ID in California: the question you need to ask is regarding ANI, Automatic Number Identification. That is available on 800-numbers and can be delivered in realtime if you have enough traffic to justify a T1. And of course you can get it from any carrier you wish. ANI is *not* Caller ID, they work differently, use different signalling systems. -gg

1 0

my menu sys.
by J. Michael Diehl 25 May '93

25 May '93

After I posted my menu batch file for pgp, I realized that I hadn't put my name on it, which I felt I should do. So, here it is, with with my copyleft message attatched. I hope someone enjoys it. rem This is the PGP menu system by Mike Diehl version 0.0. This program rem requires 4dos command.com replacement to run. It may run under norton's rem N-dos. Since I wrote this program for my own use, and in an effort to help rem with the cypherpunk cause, I am releasing this program into the public rem domain. I ask that this message not be removed, and that you do not rem distribute modified copies of this program. Further, I hope that, if you rem think this program makes pgp easier to use, you will send me an (encrypted) rem email message telling me so. It helps my ego to think someone likes my rem program besides me. ;^) I have enclosed my pgp 2.2 public key at the end rem of this file. Take care, and enjoy. Mike Diehl. rem @echo off setlocal break on :main cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 4 29 16 49 2 red on black scrput 1 27 blue on black Mike's PGP shell ver. 0.0. scrput 3 35 blue on black MAIN MENU scrput 5 32 red on black Encrypt a file. scrput 7 32 red on black Decrypt a file. scrput 09 32 red on black siGn a file. scrput 11 32 red on black Wipe file. scrput 13 32 red on black Next menu. scrput 15 32 red on black Quit. scrput 18 5 white on black Select an option by typing the corisponding capitalized letter. scrput 19 5 white on black For example, to encrypt a file, you would press the E key. inkey /K"EeDdGgWwNnQq" %%in goto menu1-%in :menu1-q screen 17 26 pause cls endlocal quit :menu1-e cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of a file to be scrput 19 5 white on black encrypted. Then you will be asked for the names of scrput 20 5 white on black the people who should be able to read the file. scrput 21 5 white on black Enter them all on the line separated by a space. scrput 7 5 red on black Enter the name of the file to encrypt. screen 7 52 input %%file if exist %file goto menu1-e-good scrput 15 10 red on black That file is not in the current directory! screen 16 10 pause goto menu1-e :menu1-e-good drawbox 10 3 12 74 2 red on black scrput 11 5 red on black Enter the name(s) of the recipients. screen 11 52 input %%in cls rem I never claimed that this would be elegent.... drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black scrput 18 5 white on black Here you are asked if you want to mark this message "For Your Eyes Only," scrput 19 5 white on black and if you want to sign the message. If you reply 'y' to the first scrput 20 5 white on black question, the recipient will only be ablt to display the message. He scrput 21 5 white on black won't be to save it. If you reply 'y' to the second question, the scrput 22 5 white on black recipient will know for certain that the message is from you. drawbox 6 3 8 74 2 red on black scrput 7 5 red on black Would you like to mark this "For Your Eyes Only?" inkey /K"ynN" %%f drawbox 10 3 12 74 2 red on black scrput 11 5 red on black Would you like to sign this message? inkey /K"ynN" %%s if "%f" == "y" goto f if "%s" == "y" goto s cls pgp -pe %file %in goto encrypted :f if "%s" == "y" goto sf cls pgp -mep %file %in goto encrypted :sf cls pgp -mesp %file %in goto encrypted :s cls pgp -pes %file %in :encrypted echo %(a)name[%file].asc is the name of the encrypted file. pause goto main :menu1-d cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of a file to be scrput 19 5 white on black read. Then you will be asked if you want to save the scrput 20 5 white on black plaintext file. If you do, you will be asked for a scrput 21 5 white on black new filename. scrput 7 5 red on black Enter the name of the file to read. screen 7 52 input %%file if exist %file goto menu1-d-good scrput 15 10 red on black That file is not in the current directory! screen 16 10 pause goto main :menu1-d-good cls pgp -m %file goto main :menu1-g cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of a file to be scrput 19 5 white on black signed. If you sign a message, it can be proved that scrput 20 5 white on black it came from you. There is no "Plausible Deniability." scrput 7 5 red on black Enter the name of the file to signed. screen 7 52 input %%file if exist %file goto menu1-g-good scrput 15 10 red on black That file is not in the current directory! screen 16 10 pause goto main :menu1-g-good cls pgp -s %file echo %(a)name[%file].asc is the name of the signed file. pause goto main :menu1-w cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of a file to be scrput 19 5 white on black wiped. Remember, after a file is wiped... scrput 20 5 blink white on black There is no way to retrieve the file! scrput 7 5 red on black Enter the name of the file to wiped. screen 7 52 input %%file if exist %file goto menu1-w-good scrput 15 10 red on black That file is not in the current directory! screen 16 10 pause goto main :menu1-w-good cls pgp -w %file goto main :menu1-n cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 4 29 16 49 2 red on black scrput 1 27 blue on black Mike's PGP shell ver. 0.0. scrput 3 35 blue on black SECOND MENU scrput 5 32 red on black Add a key. scrput 7 32 red on black Extract a key. scrput 09 32 red on black View a key. scrput 11 32 red on black Fingerprint. scrput 13 32 red on black Next menu. scrput 15 32 red on black Quit. scrput 18 5 white on black Select an option by typing the corisponding capitalized letter. scrput 19 5 white on black For example, to add a key to your ring, you would press the A key. inkey /K"AaEeVvFfNnQq" %%in goto menu2-%in :menu2-q goto menu1-q :menu2-a cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of a file that scrput 19 5 white on black contains the keys to be added to your public key ring. scrput 7 5 red on black Enter the name of the file to read. screen 7 52 input %%file if exist %file goto menu2-a-good scrput 15 10 red on black That file is not in the current directory! screen 16 10 pause goto main :menu2-a-good cls pgp -ka %file pause goto main :menu2-e cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the key ID to be extracted. scrput 19 5 white on black Then you will be asked for the names of the file to scrput 20 5 white on black put the key in. scrput 7 5 red on black Enter the key ID to extract. screen 7 52 input %%in drawbox 10 3 12 74 2 red on black scrput 11 5 red on black Enter the name of the file that is to hold the key. screen 11 59 input %%file if not exist %file goto menu2-e-good scrput 10 10 red on black That file already exists in the current directory! screen 16 10 pause goto main :menu2-e-good cls pgp -kx %in %file echo %(a)name[%file].asc contains the key for %in. pause goto main :menu2-v cls pgp -kv pause goto main :menu2-f cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of the person who's key fingerprint you scrput 19 5 white on black want to examine. scrput 7 5 red on black Enter the name of the person. screen 7 52 input %%in cls pgp -kvc %in echo Remember to write this information down! pause goto main :menu2-n cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 4 29 16 49 2 red on black scrput 1 27 blue on black Mike's PGP shell ver. 0.0. scrput 3 35 blue on black THIRD MENU scrput 5 32 red on black Generate a key. scrput 7 32 red on black Remove a key. scrput 09 32 red on black Disable a key. scrput 13 32 red on black Next menu. scrput 15 32 red on black Quit. scrput 18 5 white on black Select an option by typing the corisponding capitalized letter. scrput 19 5 white on black For example, to generate a new key, you would press the G key. inkey /K"GgRrDdNnQq" %%in goto menu3-%in :menu3-g cls pgp -kg pause goto main :menu3-r cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of the key to be scrput 19 5 white on black removed. scrput 7 5 red on black Enter the name of the key to remove. screen 7 52 input %%in cls pgp -kr %in pause goto main :menu3-q goto menu1-q :menu3-d cls drawbox 0 0 23 78 2 red on black drawhline 17 0 79 1 red on black drawbox 6 3 8 74 2 red on black scrput 18 5 white on black Here you will be asked for the name of the key to be scrput 19 5 white on black either disabled or re-enabled. scrput 7 5 red on black Enter the name of the key. screen 7 52 input %%in cls pgp -kd %in pause goto main :menu3-n goto main I may be reached by any of these addresses. mdiehl(a)triton.unm.edu, al945(a)cwns9.ins.cwru.edu Or, in care of Rory McManus at r.mcmanus4(a)genie.geis.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQA9Aiu/jVAAAAEBgM2F5mSlCA+KRd6TXIrqmPfiiAEytwSttZs7Yua939GMu2mP JL+5Qpi/ZKqF2nAJAwAFEbQsSi4gTWljaGFlbCBEaWVobCwgMSwgPG1kaWVobEB0 cml0b24udW5tLmVkdT4= =lyvx -----END PGP PUBLIC KEY BLOCK-----

1 0