- cypherpunks-legacy - lists.cpunks.org

Canon Copiers
by Duncan Frissell 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com E >The new models, the 350 and 550 do indeed have a currency recognition E >feature based on color. I was talking to a serviceman--interestingly, E >as with all crippling features, this one creates problems, as certain E >images become uncopiable if the color they use is upsetting the canon. E >The service man said that often the offending object may be copied E >simply by placing a sheet of acetate between the imaging area and the E >sheet to be copied. E > E >I used to be skeptical of this feature--someone here conjected that E >it would be based on color. they were right. Smart. E > E >Jay But what color? So does this mean I have to go to all the trouble of buying a Canon copier in Canada or the UK and importing it? Not all currency is the same color. DCF --- WinQwk 2.0b#1165

1 0

Clipper and Traffic Analysis
by Herb Lin 17 Dec '03

17 Dec '03

In the AOL debate between Barlow and Denning, Barlow asserted that Clipper increases the gov't capability to do traffic analysis. Can someone please describe the technical basis for this claim? (No rhetoric please, just the technical background...) herb

1 0

Re: Clipper and Traffic Analysis
by smb＠research.att.com 17 Dec '03

17 Dec '03

In the AOL debate between Barlow and Denning, Barlow asserted that Clipper increases the gov't capability to do traffic analysis. Can someone please describe the technical basis for this claim? (No rhetoric please, just the technical background...) The LEAF can be decrypted with just the family key; from what's been disclosed so far, local law enforcement agents will be able to do that without contacting the escrow sites. The LEAF contains the unit id of the chip, independent of what phone number it's being used from, or (in the case of cellular phones) where in the country it is. The ordinary signaling channels are (often) encrypted, and in general use a different path than the call itself.

1 0

CD-ROM software "shopping"
by m5＠vail.tivoli.com 17 Dec '03

17 Dec '03

I picked up a new Mac this weekend (a Quadra 650, on the very eve of its obsolescence :-) and with it came a CD from "Software Dispatch" (or something like that) packed with commercial software, and apparently locked with some sort of cryptographic protocol. I'm not sure whether each CD is digitally stamped with a key (seems kinda difficult) or whether the key I typed in from the cardboard envelope at the start-up screen served the purpose of identifying my disk (probably). You call up an 800 number and give them a key from the disk (I can't remember whether it was the same as the key I typed in) and after supplying a credit card number they'll "unlock" whatever packages you want by providing another key for each one. Does anybody know what sort of protocol this is using? The keys are pretty long (about 16 bytes). (Note that I'm really just curious; I don't think I have the attention span to try and "break" it. Besides, I already bought the only things I wanted off it :-) -- | 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" |

2 1

Magic Money Complaints / ATTN Warlord
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Message to Warlord: - -----BEGIN PGP MESSAGE----- Version: 2.3a hGUCOHQrXMGwavEBAsQIisQa4G1UakyzJXvV0MuEUUQT3K8y2k0ox7x6LPdfSozu V0/IRkUM1peH07i6FK7WY19MunhfkZh2K9rVR+UzuVKp4bG7w+S4bjQk3DRsjiyH 1u58JcGtVaYAAAB0FFCAeBcjzwoH4yRD8GyNyjHPhAE5HPudT1IvenINfDc0HD5I qZs1FhNctxMsukhVJvoK5xtUhBOuCR6CtVxjeVtxniR1kq2sd7RO3sg7FknIuHer l88hJYcZqFpfcb5c+7m3tKjvqzMw2keRSsydVxXQY+M= =rBux - -----END PGP MESSAGE----- Hal Finney wrote: >I hate to complain. Magic Money is something that people have been asking >for for a long time, and it's a very nice implementation. A lot of aspects >have been really well thought out, particularly the money aging and replace- >ment. But I've been playing with it off and on lately and there are some >improvements needed IMO. I'd rather have people playing with it and complaining about it, than ignoring it. I'd about given up hope that anyone would do anything with the program. Someone please set up an emailable server! >I'll just assume interested readers know how the program works and jump >right into it. > - The program handles encryption of messages to and from the bank auto- > matically, but makes the user have to handle encryption of messages to > other people. I can see some justification for this - maybe the message > (that is, a coins.dat file) will be sent via secure means like a direct > or IR connection, so encryption is not needed. But most of the time it > is needed, in which case the user has to use PGP or something as a sep- > arate step. I was lazy. To do this properly, you would have to have the ability to include a message along with the coins, and encrypt it with someone's PGP key, then decrypt it and display it at the receiving end and separate the message from the coins. You would about have to rewrite PGP within the Magic Money client. I could have written a perfect digital cash system, in which case I'd still be designing it and no code would have been written at all yet. But I was lazy. > - The program distinguishes between bank messages, which are signed blinded > coins, and user messages, which are raw coins, by whether they are in > ASCII text or not. This is not the significant distinction between these > two kinds of messages. Yes, it assumes you are going to feed it the message in the same format it was output in. A bank message is signed and encrypted, while a coins.dat is a raw binary file. User-to-user communication is left up to the users. > - Bank messages look just like other PGP messages. But the user has to > know not to try to run them through PGP and instead give them directly to > the MM program un-decrypted. The only way he can tell is to notice that > the sender address is the bank. If the bank ever sends him a real coin > file (which it may to prime the pump) then the user just has to know > to treat these messages differently. Ummm, true. What should I do about this? I wanted Magic Money messages to look just like any other PGP messages, to avoid the possibility of people using the program being singled out. Doing what you suggest would require the server having the ability to encrypt with someone else's public key, unless the bank uses PGP to encrypt a coins.dat file. > - There is no way to know which bank an incoming coin file is for. I think > this is one of the biggest weaknesses of the system. If more than one > bank is competing I have to know which bank a given coin file is > associated with and go to that directory to process that coin file. If you were using multiple banks, that would be a problem. So far there aren't any banks at all, so... but a future version could have the bank's key id in front of a coin file. Then you would have multiple bank public keys in bank.pub, and multiple coin files, and multiple elists. And you would have to know what bank the person you're doing business with uses, so you could send him the proper coins...the complexity grows exponentially. > - There is no way to put coin files directly into your allcoins.dat file. > There are a couple of cases in which you might want to do this. First, > you might pay out some coins and then change your mind before sending > them, and want to put them back. Or second, you might receive some coins > from a trustworthy person (your mum, say) and just want to add them > without going through the bank. This is easy to include, and I considered doing it, but it is dangerous. It would be easy to put coins back into allcoins.dat and then forget and send them out, thus double-spending. If you take coins out and then want to put them back, you can always exchange them with the bank yourself. > - More generally, it is difficult to use the program in a safe way which > deals robustly with errors of various types. When I was first building > the program I had some bugs which caused coins to appear to be double- > spent, to not signature-check properly, to not be found in > the proto file, > etc. The program did not appear to handle all of these errors safely, > sometimes aborting in the middle of a file. Where are these bugs? Are they still present in the latest version? I'd like to get rid of them - what did you change? Error handling is a bitch - in most cases, I just didn't know of a good way to handle an error. What do you do if a signature fails, or a coin is not in the proto-file? Ignore the coin and go on? Then you have the wrong amount of money. > In addition, the program always calls its output files coins.dat and > output.asc. If you run it twice without renaming these files you can > lose data and lose money. Then, when you send the files, you need to > manually keep backups in case the email fails. Again, otherwise you will > lose money. Should it use an incrementing name: coins.000,001,etc. so no files will be lost? This would be an easy change to make. > - The money data structures do not allow for expansion. I'd like to see a > way of adding new fields in the future which will be ignored by older > versions of the program. For example, in regard to the above, I'd like > to see a "bank email address" and possibly a bank key added to the > coins.dat file. Then you could mail the coins to someone without > including > a lot of out-of-band data about the bank they were for. It would be nice > if this could be done without totally breaking the current program. At > a minimum a version number could be stuck at the front so that old > programs > would recommend that users upgrade. Yeah, a mode byte at the beginning so later versions could be downward compatible with the earlier ones. The coins do have an identifier byte before each coin type. Later versions could use different bytes. > - The program uses PGP algorithms and data structures, but not its files. > The bank's key and user's keys are kept in separate files. There might > be advantages in putting these keys into PGP's regular files. Since the keys are only used for digicash purposes - why? See my complaint above about how these changes would require a whole PGP inside the Magic Money client. I can only write so much code. > Also, the > random number generation in PGP looks stronger than MM, since it keeps > much more state from run to run. MM seeds based on a very, very > elementary > hash on a file called rand.dat, which will tend to be fixed, and the > time of day. Ahem...this I will take issue with. Magic Money (and PGP Tools in general) uses an MD5-based random number generator which works as follows: the program takes some input random data and cyclically XOR's it through a buffer, whose size is determined at compile time. At present, it is set to 256 bytes. Then, for each 16 bytes of random data requested, the program takes the MD5 of: the time, a counter, and the 256-byte buffer. Now, if an attacker does not know the contents of the seed file, knowledge of the time and the counter value gets him nothing. The fact that the file does not change is irrelevant, because the non-reversibility of MD5 prevents the attacker from finding out anything about the file. > - None of the MM files are encrypted on the disk. The money files could > be stolen by someone with access to your computer, and your secret key > used for communications with the bank could be stolen as well. This > would be a major security flaw in some situations. Yeah, true. For serious use (real money) you would want either an encrypted filesystem (I use SecureDrive) or a passphrase on your allcoins.dat file and the secret key. The server's secret key, which is the most valuable of all, can't be encrypted because the server has to be able to read it without a user present. >Having made these complaints, let me reiterate that I am very pleased with >this program overall. I also appreciate mpd(a)netcom.com's efforts in >running a server. Is his server e-mailable? How do you access it? I have built a Mac client for MM which is not too mac-like but >lets you drag-n-drop incoming files onto the MM icon and it handles >them right. I'll tweak that a little more then upload it with the >other clients. How much trouble did you have compiling it big-endian? Magic Money was not intended for serious real-money use. For a real-world usable program, the crypto core would have been buried in many thousands of lines of support code, and the program would never have seen the light of day. It was intended to serve as a minimal but usable digicash program, so people could play with digicash. It is not perfect, but it is the best digicash system in the public domain. (It's the only digicash system in the public domain, but that's beside the point!) Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLYQjjsGoFIWXVYodAQEh+AP/eJhhTuNuf82eYvKc4Q7z8wz1wE3rkjwU K3Ca7pmggMq8bIeGmdkNJgLLDZ9llY/WaNKdT43nd9/PoTvUsQLxd4oXNAnk/4ud 4vGRKsI3bOoTmlhOepgjMAUy7w2yCu4niEh0WwZstj2t0lWLqU7YdZK5uleuvk8g fof2Ebl7PEY= =k16k -----END PGP SIGNATURE-----

1 0

Re: Magic Money Complaints
by Hal 17 Dec '03

17 Dec '03

Pr0duct Cypher writes: > I'd rather have people playing with it and complaining about it, than > ignoring it. I'd about given up hope that anyone would do anything with > the program. Someone please set up an emailable server! Mail to mpd(a)netcom.com, subject "Bank" will be processed by a Magic Money server. He calls his coins "Tacky Money". Here is his bank's public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQA/Ai1uZlUAAAEBgL95EmR/sdhCT3HQF3imtMvUjg9D4oZTgT2JMMRol1qv13h5 i2DUUUL9DKW76VcLKwARAQABtCFNYWdpYyBNb25leSBUZXN0IDxtcGRAbmV0Y29t LmNvbT4= =JDa0 -----END PGP PUBLIC KEY BLOCK----- To make things interesting, here is a $10 Tacky Token. The first person to turn it in gets it! (This is just ascii-encoded; you will have to first use PGP to unencode it then give it to your Magic Money client.) -----BEGIN PGP MESSAGE----- Version: 2.3 rHNiJU1hY2ludG9zaCBIRC9EZXNrdG9wIEZvbGRlci9jb2lucy5kYXQAAAAAwJH2 7q4+nSRosFWmppnv12cAEQEADwGAivX32iM05KNdEdcyFiOnKhWCNrZmG/4ZD6xj 1G3VmWhNOpABQWKVTlG1XIzClfxL =qUK5 -----END PGP MESSAGE----- And as a "token" of my appreciation here's a little gratuity for Pr0duct Cypher: -----BEGIN PGP MESSAGE----- Version: 2.3 hIwCwagUhZdVih0BBACbdgHXUsPpV4q6aRohbDgaEiU6oZqh70ASvuraMYi9ErAp QimzBkNJjiKFB12rBoaOi72CJp4emJO9D+iZXgkdC/5QSQBys0iTkbGIMnd/3Pg0 KqCmHC4lXHcXrJo8lp90xbPvh+fm/F84yiVFz+QKyv+1eIW5i+tgVieKxYDv1aYA AACG+2ZhjCu3gSuxuHE9JOfeW/OhfcaqY8pEMjg0/i5/Zco3g7T4d1zvtKrRTwXa fBvQzcl4O4bdOOaS6Pz168a2NkmUbO4sJe9hb6ca1ZaSx3gSR7CovaqcZ+j7fHZv TmZcsbvfQTEMVsBTFHjVziWSYKShqyadVYR3jnS7gQin+YXJ5hYNKv8= =mN42 -----END PGP MESSAGE----- Here are some more constructive suggestions for how some of the issues I raised might be addressed. - Mark Magic Money messages differently from ordinary PGP messages. (-----BEGIN MAGIC MONEY MESSAGE-----) Alternatively, allow MM msgs to be decrypted by PGP to produce binary files which can be passed to the MM client. - Make the client handle bank and user messages both as either binary or ascii files. Use internal type flags rather than ascii vs binary to distinguish them. - Allow the client to search the PGP public and private key rings for decryption and encryption keys. - Allow the user to specify a user id to encrypt for when he extracts coins for payment, search the PGP public key ring and encrypt for that user. - Check for the existence of an output file and warn the user if it already exists. Allow the name of an output file to be specified on the command line. - Save a copy of all output files in a logging subdirectory. Then if an email message is never received the user can go back and send it again. The file dates and perhaps file names can be used to help the user deter- mine which log file is the copy of the lost one. - Include the bank's key and email address with each coin file. Allow users to combine the initialization and coin-receiving steps (already these appear to be very closely related in the software). This way a user who receives MM coins for a new bank which he has never used before can begin using it in one step. These don't really imply re-implementing PGP. MM already encrypts and decrypts PGP-type messages for the bank. Adding the keyring searches is the main part of extending that capability to user-to-user communication. It also gains the benefit of encrypting the user's secret key. I don't mean to be asking Pr0duct Cypher to do all of these things. If people can agree on the usability issues, maybe other members of the community can join in and make some of these changes. Now that Pr0duct has done the hard work a lot of this is little tweaks which aren't that tough. That's what happened with PGP. BTW, I was astonished by how easily the program built for the Mac. I did #define MSDOS, #define BIGENDIAN, as well as the compatibility flags. Then there were a few of the typical header files incompatibilities. Practically once it linked it worked. Very nice. Hal

1 0

Nature of RSA's patent
by Mike Godwin 17 Dec '03

17 Dec '03

Can someone tell me whether RSA claims to hold process patents or device patents on RSA public-key crypto?

3 4

Is this list alive?
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

Is this mailing list still alive? I do not get any message for about one week. Thanks Hadmut

2 1

Re: Clipper Cracks Appear
by smb＠research.att.com 17 Dec '03

17 Dec '03

According to notes published on this list, the NSA has already admitted that the LEAF is not itself encrypted with Clipper; we don't know what it is encrypted with, but I wonder: If you're referring to the meeting at AT&T Bell Laboratories, that is *not* what we were told. Rather, we were told that a unique mode of operation was used. The motivation for using a unique mode for the LEAF itself isn't completely clear; it may be related to the lack of space to send a random IV. The traffic key has to be encrypted a bit oddly, though; 80 bits doesn't mesh well with standard modes of operation of a 64-bit cipher if you want to minimize the number of encryption operations. Obviously, games can be played with the modes of oepration to weaken the cryptosystem. But that's the sort of thing that would stick out like a sore thumb to the review panel -- much more so than any flaws in Skipjack itself. But the question is worth asking of the review panel members. I'll pass it on to Steve Kent. --Steve Bellovin

1 0

Books, Loompanics, and other weird stuff
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Branch Cypherians, At the Saturday Cypherpunks meeting (60 people there for all or part of the 6-hour meeting, not counting the remote sites), I displayed a dozen or so books. I've had a number of requests that I post the names, authors, ISBN numbers, and Department of Justice Permission Numbers. These are by no means the most important books to have. We have mentioned the crypto books _many_ times, and also such seminal books as Bamford's "The Puzzle Palace," Kahn's "The Codebreakers," Brunner's "Shockwave Rider," Card's "Ender's Game," and of course Vinge's "True Names." I shall not dwell on these further. (Except to say I did look for used copies of Bamford, for possible mailing to some in foreign countries, but couldn't find any. And I couldn't find any copies at all of "When Harlie Was One," so can't check out the issue of who first talked about worms.) Several points: * I'll list some basic info about these books. * However, these were just a bunch of books I picked to show the range of information about there, the stuff your local library is unlikely to carry. (Things like "How to Create a New Identity," "The Secret Money Market," "Getting Started in the Underground Economy." etc.). Understand that I make no claims that these are the best books available, or that their contents are up to date, useful, etc. * This is why I strongly recommend you get yourself a copy of the wonderfully wacky 280-page catalog from Loompanics Unlimited, Port Townsend, Washington. Details are below. Most of these odd and controversial books I ordered several years ago (1988) from Loompanics...no doubt more current odd books are now available. * Alternative books stores often carry some of these books. For example, the "Anubis Warpus" bookstore in Santa Cruz (across from the Taco Bell on Pacific Avenue) has many of these books, in addition to offering tattoo and peircings (ugh!, but to each their own)...I haven't had my public key tattooed on my arm yet, but I'm considering having "Poor Impulse Control" put on my forehead. * These books are not "crypto" books....I showed them at the "politics" meeting as a change of pace from the usual number theory and crypto-oriented books we pass around. So, here are brief descriptions of the books. Best that you get the Loompanics catalog, which has nice summaries of each of the books and, of course, convenient ordering information. - "How to Launder Money," John Gregg, 1982, ISBN 0-317-03306-9. A small pamphlet, undoubtedly dated material. Useful to provoke ideas, but don't rely on this. - "How to Open a Swiss Bank Account," James Kelder, 1976, ISBN 0-690-01033-8. Also dated....Swiss accounts are passe these days. (I have several of these sorts of books, picked up in various places....your library may have some). - "Getting Started in the Underground Economy," Adam Cash (right), 1987, ISBN 0-915179-46-4. More ideas, but don't rely on it for legal or current advice. Loompanics has a dozen or more titles with themes about black markets, tax avoidance, etc. - "Low Profile: How to Avoid the Privacy Invaders," William Petrocelli, 1981, ISBN 0-07-049658-7. Similarly, Loompanics sells numerous books with this theme. - "How to Create a New Identity," Anonymous, 1983, ISBN 0-8065-1034-X. (Warning: This book comes with the "Law Enforcement Access Field," so that anyone reading the book can be electronically reported to the Witness Security Program, which holds the monopoly on creating fake identities, credit histories, and other legends.) Need I say more? Things are changing especially quickly here, so the material is just a starter. Fake passports and driver's license are now buyable on the streets of major cities (especially in the colored sections) for as little as $25. - "The Enterprise of Law: Justice Without the State," Bruce Benson, 1990, ISBN 0-936488-30-1. This book I threw in to show folks that the anarcho-capitalist system many of us favor does have some strong underpinnings in legal theory. There are several dozen good books on libertarian theory. Most are available by mail order from Laissez-Faire Book in San Francisco. (Dial 800 Info, or SF Info.) - I also showed a book on American Intelligence agencies (NSA, NRO, DIA, State Dept., etc.) by Jeffrey Richelson, but Whit Diffie has already borrowed it, so I can't provide the relevant info right now. Richelson has written several books on foreign intelligence agencies (BND, Mossad, MI5 and 6, etc.) and U.S. intelligence agencies, and is a good "post-Bamford" source. Enjoy finding and reading these. But your first priority should be to get the Loompanics catalog...other books may spark your interest more. I think the catalog is still $5 (well worth it), unless you order another book first, as described below. Good luck! --Tim May From: solmaker(a)pt.olympus.net (Stephen Schumacher) Newsgroups: misc.books.technical,rec.arts.books,alt.books.reviews,soc.libraries.talk,comp.security.misc,alt.politics.libertarian,alt.zines,alt.wired Subject: review: Secrets of a Super Hacker Date: 7 Mar 1994 11:17:44 -0800 Message-ID: <2lfuko$6rd(a)olympus.net> SECRETS OF A SUPER HACKER by The Knightmare, introduction by Gareth Branwyn, 205 pp., 8 1/2" x 11", ISBN 1-55950-106-5, March, 1994, Loompanics Unlimited, Box 1197, Port Townsend WA, 98368. Price: $19.95 plus $4.00 for shipping (includes a copy of their must-have 280 page catalog of unusual books). Credit card orders to 206-385-2230 (phone) or 206-385-7785 (fax). This is a very good practical book on breaking into computer systems. It's readable, interesting, informative, balanced, and accurate, with a nice spirit of fun and swashbuckling! Here's the contents: Introduction: Hackers: Heroes or Villains? I: The Basics II: The History of Hacking III: Researching the Hack IV: Passwords and Access Control V: Social Engineering VI: Reverse Social Engineering VII: Public Access Computers and Terminals VIII: On-Site Hacking: The Tresspasser-Hacker IX: Hacking at Hope: Dialing Up Computers With Your Modem X: Electronic Bulletin Board Systems XI: Borderline Hacking XII: What To Do When Inside XIII: This Lawful Land XIV: Hacker Security: How To Keep From Getting Caught XV: Conclusion Further Reading Glossary 8 Appendices The Knightmare covers lots of clever technical tricks for gaining access, but he shows most glee with scores of hilarious "Social Engineering" scams for seducing legitimate users into revealing their passwords. The striking thing about these spoofs is, just reading them, you realize through the laughter how often these simple Social Engineering techniques will produce results and how the credulity of non-security- minded naive users is the weak point of any security system. Sometimes while reading, I wished the book provided more specific info about phone numbers, brand names, specific techniques that work on specific bulletin board systems, etc. But I recognize that such information would go quickly out-of-date, or would be fixed in response to the book's publication, or could implicate the author. The Knightmare is presenting concepts that won't go out-of-date soon, giving the interested non-hacker a comprehensive and comprehensible survey of the field, and tipping off the potential hacker with just enough details to get him/her started and steered in the right direction and minimize the chance of getting caught. On this final point... a few times during the early chapters I thought The Knightmare was being cavalier about personal safety, favorably reporting (for example) Social Engineering advertizing scams that would likely bring the cops to one's doorstep. But The Knightmare was saving his warnings for 2 chapters towards the end, 22 sobering pages that make very clear the risks involved and what definitely NOT to do. A very balanced presentation. As usual with Loompanics books, this one can be read backwards, and pages 167-168 are directed specifically to System Administrators interested in beefing up security. I also appreciated all the hacker philosophy and pragmatic do-no-damage hacker ethics. The Knightmare disdains and derides "crackers" who break into a system in order to wreak havok; for him, "hackers" are peaceable, non- destructive puzzle-solvers and liberators of information. In a world where the govco is ever working to extend and centralize its control over financial data, encryption techniques, cyberspace, and every aspect of people's lives, the hacker may emerge as a modern-day Robin Hood. -- Steve (solmaker(a)pt.olympus.net)

2 1