December 2003 - cypherpunks-legacy

Evil Mail
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

WSJ, November 15, 1995 America Online to Warn Users About Bad E-Mail Vienna, Va. -- It's a case of myth becoming reality in the digital age. America Online Inc. plans to warn subscribers of a damaging piece of electronic mail that could corrupt their computers' hard drives. The existence of the destructive file follows a long-term hoax that has been dogging AOL for months. Last year, a user began circulating a warning about a "Good Times" virus that would crash users' PCs if they so much as read the piece of electronic mail. AOL, the Federal Communications Commission and the Pentagon repeatedly had to label the alleged virus a hoax. But the new file is all too real. The destructive file, attached to electronic mail, has been circulated through the on-line service and the Internet. Receiving the e-mail wouldn't harm a user's computer, but trying to run the attached file, known as AOL Gold or "install.exe," could render a hard drive inoperable, an AOL spokeswoman said. The company said it has notified various computer-security agencies about the program. AOL also plans to post a letter for its four million users strongly urging them to forgo "downloading attached files from people you don't know." Security experts fear that such Trojan Horses will proliferate as programs become easier to attach to electronic mail and the use of networks grows. -----

1 0

Re: e$: Come aaaannnndddd Get it!
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

Incidentally, I would like to apologize if I am going over (and not contributing anything new to) discussion that has already taken place. If anyone has or knows of an archive of the earlier list messages on the subject (before I subscribed), I would like to read over them. From: tcmay(a)got.net at 16-NOV-1995 13:00:29.05: At 12:18 PM 11/16/95, Robert Hettinga wrote: > >Ahhh. Next year in Jeresalem... ----------- Although I am unfortunately not completely familiar with this phrase, I believe that your meaning here may be that I may be too much of an idealist. My position is that I will not use a digital cash system with the significant deficits in privacy that the ecash system has. The only exception to this stance would be if it becomes plain that it is the only alternative to a credit card system. Admittedly, as has been pointed out to me in private email, some degree of increased privacy in the ecash system can be gotten via changing currencies using ecash. An example would be dollars to yen through one changer and back again through another. However, I will not regard a digital cash system as truly good until it has the following traits: A. Private to any combination except all three of bank, sender, and receiver. B. The bank does not know the amount transacted or owned, unless it is the sender or receiver. (Obviously, it will know the total amount of digital cash of its issuance in existence, and how much it has received from or sent to each person, but it should not need to know anything more). C. Double spending is detectable, but does not reveal the identity of the individual. Thus, the bank does not need to know the identity of the individual when issuing the digital cash. The following are desirable but not strictly neccessary characteristics: A. Offline transactions are possible. To detect double spending, a transaction with the bank will probably be necessary, but this should ideally be postponable until the goods purchased are shipped. B. Mathematical as opposed to computational authentication and privacy. Since I am neither a mathematician nor a programmer, I am uncertain about whether this last is possible. I have my doubts. -------------- >Tell me, are you actually selling something on the net yet? How many >customers do you have? -------------- If A. such a system as the above were set up and B. I had available any computer programs, etcetera necessary to use it, then I would at least _try_ selling something on the net. This something would be not data itself, but true information- data with interpretations. I am qualified to produce such a service in some areas in biology and medicine. I am currently in a Ph.D. program in Molecular Genetics and Microbiology, and my chief area of interest is gene therapy- I have thus learned some things about human physiology. Perhaps more importantly than my own knowledge and experience, I know who to ask and have such individuals available. Admittedly, I would have to fit it into the time between exams, or more likely between semesters. -------------- Bob, let me do a minor vent here. You are critical of E. Allen Smith's viewpoint, and essentially question whether he has anything to sell. Not much of an argument. --------------- Thank you. (I would say "Thank you for your support," but my name is neither Bartles (sp?) or James.) --------------- Especially when folks are urging that "people put their money where their mouth is" and get MTB accounts. Me, I don't plan to sign up for various reasons: 1. I'm not selling anything, and won't sign up just for "moral support." (I tried this once before, getting an AMIX account early on, and that system offered more of a chance for a 2-way market. Still, a waste of my time.) --------------- I tried signing up for AMIX also, but unfortunately came in too late (after it closed down). I might consider signing up for a system with the characteristics described above for "moral support," but I will not do so for a system that I hope is replaced by a better one. --------------- 2. I wish Mark Twain Bank well, but the success of the kinds of digital cash we hope to see will not likely hinge on the success of one particular operations, such as MTB. 3. The success of BankAmericard (later renamed Visa) came when real customers and real shops started to use it, not when early pioneers set themselves up as clearinghouses and whatnot. --------------- Online commerce systems can be divided into four types, of increasing level of desirability (and decreasing level of governmental approval): A. Credit-card based systems such as credit card number encryption and First Virtual. B. Partially privacy-protecting systems such as ecash. C. Fully privacy-protecting systems with the characteristics described above, based on a governmental currency. D. Fully privacy-protecting systems with the characteristics described above, based on a privately-produced currency and backed by the issuer. I suspect that the first and second will have the most aboveground chance of succeeding, given likely governmental interference in the third and fourth; lack of public comprehension of all of the digital cash systems and of privately-produced currency will impede some of them also. However, the fourth may be a possibility for an "underground" currency system, to be used among computer-literate individuals with an aversion to government. I am currently creating an idea for a system of the fourth type, and will put it on the exi-essay list when it is complete. Incidentally, I suspect a privately-produced currency system may be harder to regulate than a governmentally-produced currency system, especially if the former is set up properly. I will explain further about this idea in the aforementioned exi-essay system. --------------- I have more interesting things to do, personally, than to be a pioneer so I can then have nothing to sell, and little to buy....when "interesting markets" start to appear, I'll look at it again. In any case, I wish all the pioneers well, and am happy to see Lucky Green's involvement. --------------- I also agree in wishing the "pioneers" well. The ecash system is definitely preferable to one based on means such as credit cards. -Allen

1 0

Re: credit card conventional wisdom
by John Pettitt 17 Dec '03

17 Dec '03

At 10:48 AM 11/16/95 -0800, Vladimir Z. Nuri wrote: > ... about credit card liability Hmmm, a few words about credit card liabilty. The situation now is that in a "card not present" transaction the merchant is liable for the fraud. This means that *a lot* of internet based stores are getting eaten alive by fraud. The big issue right now is not cards being stolen from the telco switch (yes it's a risk but can anybody cite it happening?). The issue is authentication of the card user. We have a significant investment in AI / credit scoring code to defeat the wannabe crackers. This goes way beyond mod 10 checks and address verification. [ as an aside I've put two people in jail this year for card fraud ] John John Pettitt, jpp(a)software.net VP Engineering, CyberSource Corporation, 415 473 3065

3 2

Re: NSA, ITAR, NCSA and plug-in hooks.
by Rich Salz 17 Dec '03

17 Dec '03

Status: R >as a compression program, but there's a key difference: the text >compressor *doesn't* need a key. Sure, 12 14 16, etc., bits as in the classic unix compress program. >The encryption tool would have an interface like > Boolean (*)( DataSource, DataSink, void*); > >A compressor written to the same interface would never need to touch >that third argument. Therefore, the second argument is "specifically >designed" to permit an encryption tool to be used. Not at all. coyping inbuf to output is a common practice, it's quite rare that you often compress in-place. /r$

1 0

Re: Public Domain?
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

>But the researchers backed out of the idea on the advice of our patent >lawyers. The reasoning goes like this: Sending anything over the Internet >is equivalent to placing it into the public domain, since the message can >be viewed by other than the intended recipient. So, proprietary >information *even encrypted* will be rendered unpatentable if sent over the >Internet. > You may want to send these guys back to do their homework. For corporate communications, crypto is not new. Messages have been sent in cipher over telegraph lines since the civil war. Ask if a trade secret becomes exposed (in the legal sense) if it is transmitted over telegraph lines in code. I fail to see what the difference is between enciphering something in dots and dashes and enciphering it in 1's and 0's.

1 0

Crypto++ port for Macintosh
by fluffy＠shout.net 17 Dec '03

17 Dec '03

I have started to port your crypto++ librairied to mac, using metrowerks. I was just wondering if you would like a copy of it when I finished? All in all, a very interesting set of classes. Chris

1 0

Re: NSA, ITAR, NCSA and plug-in hooks.
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Thu, 16 Nov 1995, Scott Brickner wrote: > You'd need a program which not only *accepted* the additional parameter, > but also *needed* the second parameter. I confess I have some difficulty > thinking of one. How about command-line compression options. Gzip, for example, allows you to specify how good you want the compression to be, with better compression taking longer. So you could justify passing a set of options to the compression algorithm, which could also be used to pass key information to the encryption algorithm. In fact, you could pass in a void * pointer to options that had been set up in a preferences panel in the application, which would be provided by the plug-in compression or encryption code. That structure could then have anything you wanted in it. Also, I'm not sure you'd need to pass a key, surely the encryption code could do all the key-handling itself ? Mark

1 0

Re: credit card conventional wisdom (fwd)
by Simon Spero 17 Dec '03

17 Dec '03

Date: Wed, 15 Nov 1995 18:07:25 -0800 From: Tom Wills <twills(a)eit.COM> To: Simon Spero <ses(a)tipper.oit.unc.edu> Subject: Re: credit card conventional wisdom (fwd) The printed digits above the embossed account number are the first four digits of the BIN (on Visa cards) or ICA (on MasterCards). They are there to discourage re-embossing of the card with another account number. Original Message: > >Wow, you learn something every day. I've never in >my whole life (well, my American Express life, >over 15 years) noticed those four digits. I've >never been asked for them by anyone, or noticed >them being written down, either. Exactly when and >how are they used?

4 4

GHO_mac
by John Young 17 Dec '03

17 Dec '03

The Sciences, November/December, 1995 Another realm of explosive population increase is in cyberspace, a phenomenon taken up in this issue with Sherry Turkle's "Ghosts in the Machine." Here the growth comes about not only in the traditional way but also in wildly non-traditional ways. People multiply themselves on the Internet, grafting various aspects of their personalities onto distinct characters. Even more unsettling, as Turkle wittily documents the matter, is that the Net is populated with "bots": robot sentence-parsing engines that can do fair impersonations of real people, often well enough to (provisionally) pass Alan M. Turing's test for machine consciousness. Do you really know who -- or what -- you're talking to? The future of all this is murky and mind-boggling: Information-seeking bots even now can tie up sites on the World-Wide Web. Bots impersonating people share chat groups with other bots, much the way telephone answering machines now "talk" to each other. Internet chatter gets so dense that bandwidth and other Net resources become strained: the site at the Los Alamos National Laboratory now (automatically) warns robots away with a chilling threat to "initiate automated 'seek and destroy' " action against the machine from which the robot seems to be launched. A conservative reaction may already be setting in, determined to have users identify, encrypt and authenticate every packet of information they send across the Net. Net fatigue becomes a recognized medical syndrome; Net detox centers spring up; Net warfare breaks out; Net starvation becomes a recognized social problem; Net demagogues undermine local democracies.... How many people can the Net support? -- Peter Brown, Editor ----- For "Ghost in the Machine" by Sherry Turkle, a professor of the sociology of science at the Massachusetts Institute of Technology. The article is adapted from her forthcoming book, *Life on the Screen: Identity in the Age of the Internet*, which is being published in November by Simon & Schuster: GHO_mac (16 kb) ... later this evening, that is.

1 0

Re: Need advice on video
by wiltship＠iccu6.ipswich.gil.com.au 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ben wrote... <stuff deleted> >What I'm fishing for here are any suggestions for ways to present >some of this content in an interesting video setting. We've already >decided on doing some algorithm animation, and maybe some simple >moving graphics illustrating the various protocols. Any ideas you >might have would be appreciated. Firstly you will need to clearly define for yourself exactly what you want the audience to know by the end of the programme... the content. And what you want them to feel by the end of the programme too.. you obviously want them to have positive feelings about crypto. You might also consider some broader political issues to be cleanly interwoven through the script too. Then, you might like to think about the WHO, WHEN, WHERE and WHY of crypto. A bit of an historical background on cyphers would put todays crypto into context, too. Make sure that you keep giving the audience enough knowledge to comprehend stuff you will be presenting towards the end of the video... all of the information you present needs to build on what you have already presented. Closely examine your scripts for jargon. Take out any that you can't explain clearly. Too much jargon can swamp the audience and they will be distracted from important content while they try to remember what a particular word means. >BTW, once we finish this and show it locally, we are considering >doing some duplication to send out to interested bodies. Do you >think there is demand for a good, clear intro to all this in video >form? > I'm sure there is a need for this sort of programme that is produced well and is reasonably priced. Remember to get signed releases from EVERYONE involved in the project, not just ppl on camera, so you can sell the programme ANYWHERE IN THE WORLD if you choose to. Don't be misled, I'm sure there are quite a few programmes out there on this very topic. Yours needs to be significantly different and entertaining. I would suggest you have an opportunity to make a video from 'the inside', given the ppl on this list and the contacts they have. A lot of films sre good introductions to a subject without standing up and calling them such... like if I was making a video about Phil I would have to explain crypto and its use as a way of reaching a level of understanding for the audience. Hope this is of some help. >Thanks, >-- > eebmoC .L nimajneB | Benjamin L. Combee (REVERSE) > gro.doowhcet@eebmoc | combee(a)techwood.org (ENGINEERING) >\eebmoc\ten.kay.www\\:ptth | http://www.yak.net/combee/ (RESERVE) > Cheers Peter -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKu5bOvjRao+WEx9AQHKhQQAhOGT7fecYsaiwCDa6d8Ka7J6Hsgwuw5D tcknrSNVZGSf3+GCHWWVvCgsqHbgd+T9W/xFE9wlwzBmnbL9OwLb8sGr6yYDljL4 KH474GmKrax2hmu3h24J7HbsdTGDwj/KTrWnW4Kc+5TVIdhe0TM7SQBAMfWsYhuP 2YaxW3QYoTg= =zt0k -----END PGP SIGNATURE----- Flight to Quality Wiltshire Productions Pty Ltd Brisbane, Queensland, Australia Intl Voice 61 7 3376 3535 Intl Fax 61 7 3279 4027 Email wiltship(a)gil.com.au PGP Key ID 3E584C7D PGP Fingerprint 01 03 FB F4 BE F8 2B F3 5D 84 6B 69 37 80 FE 10

1 0