December 2003 - cypherpunks-legacy

Re: COE Recommendation No. R (95) 13
by smithmi＠dev.prodigy.com 17 Dec '03

17 Dec '03

>>9. Subject to legal privileges or protection, most legal systems permit >>investigating authorities to order persons to hand over objects under >>their control that are required to serve as evidence. In a parallel >>fashion, provisions should be made for the power to order persons to >>submit any specified data under their control in a computer system in the >>form required by the investigating authority. >>________________________________________________________________________ > >>Is this 'what we would want'? It clearly means that one can be ordered >>to reveal the password to encrypted data and punished by law if one >>refuses. Forgive me if this point has already been raised, but couldn't an objection to such laws be based on the protection against self-incrimination? Maybe this all depends on whether the legal context is a civil or a criminal proceeding. If I'm being sued and they ask me at a deposition whether I did such-and-such, I can't take the Fifth (or can I?). But if I'm accused of murder, the police can't make me tell them where I've buried the knife. However, if I have a wall safe and they get a warrant to search it, can I be jailed for contempt if I don't give them the combination? This seems to be a case where existing legal paradigms ought to extend rather naturally. Whether the existing paradigms are any good or not is of course a separate question. --Michael Smith smithmi(a)dev.prodigy.com

3 2

Mbone seminar 21st Nov 16:15UTC: FIREWALLS AS A NETWORK SECURITY TOOL
by Piete Brooks 17 Dec '03

17 Dec '03

Executive summary ================= Any non UK site interested in seeing an MBone transmitted seminar on 21st November at 16:15 UTC entitled "FIREWALLS AS A NETWORK SECURITY TOOL" should contact me to get the IP address and TTL changed. Plug, caveat, etc ================= To enable "lone" security reseachers (i.e. not enough people in the dept to have regular Security Seminars) in the UK to "keep in touch", we transmit our departmental Security Seminars on the MBone each week, with a low TTL and administratively scoped to the UK (so we don't have to worry about clashing with other events. The AC.UK MBone is fully pruning, and typically has spare bandwidth). These are not big formal events, but typically have a dozen or two members of the department and other "locals" present. The termly program is available on the Web in http://www.cl.cam.ac.uk/Seminars under "Security seminars" [ That way you can see our more formal "Departmental Seminars" listing at the same time :-) ] It's run as a "DIY" service (i.e. members of the group set things up) so things may go amiss. However, if they do (or there are time zone problems) it is fairly simple to retransmit later (during UK office'ish hours -- unless someone has some magic to start up vat and vic or nv without using X) from the tape we make ... Full details ============ As Firewalls are of interest to both these lists (sorry for cross posting!) I thought I might take this oportunity to draw your attention to this particular seminar. See http://www.cl.cam.ac.uk:80/Seminars/mbone.html for the latest info (e.g. slides will appear when I get them), but here is the announcement (roughly) as I received it: *** *** *** *** *** University of Cambridge Computer Laboratory SECURITY SEMINAR SERIES SPEAKER: Alec Muffett, Sun Microsystems DATE: Tuesday 21st November at 4.15pm PLACE: Room TP4, Computer Laboratory TITLE: FIREWALLS AS A NETWORK SECURITY TOOL The "Firewall" - taking the (quite broad) definition of a firewall's being any device designed (in some manner) to restrict "soft" access to a network - has migrated from being a tool of the paranoid systems administrator, into being a standard part of modern network infrastructures. This seminar will review why this situation has come about, what modern firewall architectures (both basic and advanced) look like, examine what they can/cannot accomplish, and will speculate upon the future potential of firewalls as access-security devices. *** *** *** *** *** As noted above, by default these are normally restricted to UK MBone sites, so let me know in advance (the M/C IP address changes !) if it wanted further afield.

1 0

Corrections about Bob Noyce and Intel
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:55 PM 11/17/95, attila wrote: > 2. most were pioneers: a specific example is Bob Norris who walked > out of a Fairchild board meeting being being rejected for his > eighth try at replacing Germanium because the first seven had > failed. A couple of VCs, among them Arthur Rock and Bob Perring > said: "...we believe you, let's try silicon..." and we have Intel. Bob Noyce was already making silicon devices at Fairchild. The "planar process" was developed by him in the late 50s. It is not the case that Fairchild was stuck making germanium, nor that Intel was the first to use silicon. I could go on about the actual history, but this is far from the themes of this list, and many books cover the history very well. What Intel pioneered the development of was _silicon-gate MOS_, where the aluminum gates of traditional silicon devices is replaced with polysilicon gates. Intel did this by hiring the silicon-gate gurus from Fairchild (Vadasz, Grove, Faggin, etc.). > But, who drives Intel today? --Grove, who is labelled as the > founder. Grove made the _business_ -the brains have been > forgotten. Norris was the darling of the VCs for a couple years > until they figured he couldn't spot a _financial_ success. Grove remains a technologist--I studied semiconcuctor physics from his wonderful 1967 book, "The Physics and Technology of Seminconductor Devices"--and the group that leads Intel is highly technical. Gordon Moore remains connected, materials scientist Craig Barrett (who hired me into Intel in '74, ironically) is next-in-line to be President, Gerry Parker is a top technologist, and so on. As to Bob Noyce being the "darling of the VCs for a couple of years until they figured he couldn't spot a _financial_ success," I should just let that one pass. Noyce of course has been dead for several years. When he was alive, though, he "spotted" several financial successes. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

RE: nnets & crypto
by grdawe＠toad.com 17 Dec '03

17 Dec '03

IMHO etc., *any* time there is an application involving pattern-matching and analysis of complex in->out relations/functions there is a possible application of NN's. That's not to say that a particular application would be a panacea, but designed properly I think an NN could be of value in differential crypto, discovering crypto-weak (i.e. strong) correlations between in->out, etc. My intuition says there is or can be value as a tool for the cryptanalyst. I would also not discount the use of NN's in ENcrypting, given the capability of NN's realizing (almost) any arbitrary, nonlinear function from in->out. Caveat: practical considerations not accounted for in these opinions. >Date: Fri, 10 Nov 1995 11:52:41 -0800 >From: Bill Stewart <stewarts(a)ix.netcom.com> >Subject: Re: coding and nnet's >Schneier's 2nd edition says "Neural nets aren't terribly useful for >cryptography, primarily because of the shape of the solution space. >Neural nets work best for problems that have a continuity of >solutions, some better than others. This allows a neural net to >learn, proposing better and better solutions as it does. Breaking an >algorithm provides for very little in the way of learning >opportunities: You either recover the key or you don't. (At least >this is true if the algorithm is any good.) Has anyone tried using neural nets or similar techniques for searching for useful nonrandom properties of the round functions of block ciphers or hash functions? This might be useful in trying to prepare some new kind of attack, find a balanced binary function that is useful in using the generalization of linear cryptanalysis discussed by Harpes, Kramer, and Massey at Eurocrypt '95, find a better "difference" function for use in a differential attack, etc. >Neural nets work well >in structured environments when there is something to learn, but not >in the high-entropy, seemingly random world of cryptography." And he >doesn't give any references. Merkle's paper on Khufu and Khafre addresses this idea, I think. Merkle comments that it's not going to be useful against a full cipher, but that it might be useful against (say) Khufu with one or two octets. ># Thanks; Bill ># Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com ># Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 Note: Please respond via e-mail as well as or instead of posting, as I get CP-LITE instead of the whole list. --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKhv1UHx57Ag8goBAQE5IAQAtV3GTqZO08WwHDJSI3Dj2NgIu7rQPrUH V5vBCWTCvRsVNt07K8FbKMxPhF+QmXINPlOEMn4qZbhph0oyf/zAj3uV+6yzO3Eg FMXrZzc1zOOdcfp9IcMvoXvd/av9zq/jH6Sn6yZB3jTO42ENeSSLNbxtaBrzgABl zPklYWOnDrw= =x3kP -----END PGP SIGNATURE-----

1 0

Re: e$: Come aaaannnndddd Get it!
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>> I will as soon as someone comes up with a _fully_ private digital >> cash system and starts using it for something. As I understand it, Chaum's >> ecash system is not one (i.e., non-privacy to the sender and of amounts to the >> bank). If I'm incorrect, please tell me and I'll set up an account with MTB >> immediately (if there's a text-based interface). > > ecash provides full payor anonymity. Payee anonymity is >currently not possible, but that is being worked on. > > If you used ecash to pay for a c2.org account, neither I nor >the bank would be able to trace the payment into the c2.org account to >an actual account at mark twain bank. >sameer Voice: 510-601-9777 >Community ConneXion FAX: 510-601-9734 If you've been following my idea, "assassination politics," you know that there is an excellent use for payee-anonymous digital cash. It seems to me that this should be possible, within limits, if the potential payee could generate a "blinded" note to be delivered to the payer by anonymous means. The payer could get the note certified by the bank, possibly given an extra "blind" if necessary (is this possible? Desirable? Why not?) and then the resulting still-blinded but certified note is posted (in encrypted form, I supposed) to the 'net so that only the payee can decrypt and unblind it.

2 1

Re: credit card conventional wisdom
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 15:22 11/16/95 -0500, Arley Carter wrote: >3. I'm getting tired of seeing posts this list about what is more dangerous >cyberspace or restaurantspace. Let's focus on the real mechanics of how >the ground rules of credit card clearing will operate in cyberspace. The >credit card consortiums can advance the cause of electronic commerce by >stating in unambigous terms what their views are of these ground rules. >Developers, cardholders and merchants can then make a judgement on whether >those risks are acceptable to each party respectively. I agree. I doubt we can completely eliminate the risk by technical fixes. I do think we may be able to reduce the risk below what it is in non-cyberspace commerce. (e.g. phone orders and in-person card presentation). If we can do that, and a significant part of commerce moves to cyberspace, then we can see a reduction in the fraud premium that we all pay (no matter who "offically" pays for it). While cash-like instruments will be an important part of cyberspace, I think that credit arangements may be more important. In non-cyberspace commerce, almost all big-ticket purchases are made with time-payment credit. Whether the total of the "candy bar" transactions will exceed the total to the big-ticket transactions, I don't know. Certainly if we are dealing with tangable goods, shipping costs encourage large orders. Bill ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

1 0

Re: COE Recommendation No. R (95) 13
by smithmi＠dev.prodigy.com 17 Dec '03

17 Dec '03

> >>Forgive me if this point has already been raised, but couldn't an >>objection to such laws be based on the protection against >>self-incrimination? > >There is no such right in most (if not all) european countries. In >France there is not even the presumption of innocence. [Further depressing news deleted] Yes, this was my understanding. I guess the point I was groping toward was that while we could hardly expect that our rights vis-a-vis electronic privacy would be any _better_ than our rights in obviously analogous non-electronic areas, they might well be worse; it's important to be clear, and to make clear, that what rights we have left have obvious extensions to our net.activities, and try to prevent the thin end of the wedge from being inserted in our portion of the perimeter. Of course, this only applies to the set of people who live in countries where people _have_ any rights, and as Phill implies, that may soon be the null set. --Michael Smith smithmi(a)dev.prodigy.com

3 2

Re: Corrections about Bob Noyce and Intel
by John Young 17 Dec '03

17 Dec '03

Worth magazine of Dec/Jan has a lubricious article on "The Super Investors of Silicon Valley": " 'Rise of the Silicon Patriots,' by Donald Katz. If their egos and paychecks are oversized, so is their impact on the economy and culture. It's not for nothing that California's venture capitalists think they're at the center of the universe." It traces some of the mauling by rapacious VC tigers of unwary techno-bambis and gleefully vaunts winner-take-all when the chips are down (multiple puns there) -- commensurate with the flatulent flattering flummoxing of this "financial intelligence" oilslicker. For more FFF FinInt organ-grinding the monkeys, see "Downloading Warren Buffet's Brain."

2 1

No Privacy Right in Indonesia ?
by James M. Cobb 17 Dec '03

17 Dec '03

Cypherpunks assume privacy is a good thing and wish there were more of it. --Welcome to cypherpunks Friend, An 11 17 95 Reuter Information Service newsstory headlined Politics, not sex, is Indonesian Internet's concern reports that In Indonesia, the quiet Internet revolution has not gone un- noticed by the armed forces. Here are more excerpts from the newsstory: Armed forces spokesman Brigadier-General Surwarno Adi- wijoyo told Reuters the military had suggested to the com- munications ministry the need for some sort of "toll gate" to "black out" news which could damage culture or affect security. It has also suggested registering uses and users, he said. ...nobody doubts the military is watching. Activists in Indonesia who use the Internet say it is a power- ful tool for distributing information in a society where self- censorship abounds, newspapers are tightly controlled, jour- nalists are jailed and unlicensed magazines banned. Internet users doubt the Indonesian government can legis- late or control the Internet, short of pulling the plug on the nation's soon-to-be-privatised phone system. Please note that the expression "legislate or control" means control by either fraud or force, whichever the military finds most convenient. If the military does one day pull the plug, will that validate or invalidate the statement in the "Welcome to cypherpunks" document-- Cypherpunks know that a widely dispersed system can't be shut down. A tangential answer is supplied by Indonesian activists: Despite the technical and administrative hurdles with cen- soring an increasingly large volume and web of contacts, Internet users point out such a scheme [of censorship, not plug-pulling] would not stop the increasing distribution of material within the country. For there are private as well as commercial networks in the country. Commercial providers' estimates suggest there are around 10,000 registered local users, with popularity of the Internet growing among Indonesia's technological and edu- cated elite.... Please note the expression "registered local users," and re- call the military's suggested registering [of] uses and users Uses? Perhaps that means those nominally private networks. Cypherpunks hope that all people desiring privacy will learn how best to defend it. --Welcome to cypherpunks Cordially, Jim NOTE. NandO News, which posted the above newsstory, can be accessed at: http://www.nando.net The story's online filename is: info733_8.html It's datelined: JAKARTA (Nov 16, 1995 - 01:06 EST)

2 1

CANADIAN PRESS REPORTS (was Re: CSE gets flak on TV)
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Fri, 17 Nov 1995 anonymous-remailer(a)shell.portal.com wrote: > > Hmm, actually the news tape is reading a little strange here in Canada. > > Not AP, or REUTERS, but simply the Canadian Press newswire. [snip] > Taking three successive news stories from three days ... (press stories, > I've since pulled for my own reference) and pasting them together to > indicate some type of Machiaevellian?? (sp) exercise is simply "not done." I still feel such a sense of violation with what LD did, such an utter sense of helplessness at the character assassination I've suffered at his hands, that I feel that I must take some token action to "set the record straight". Something which clears my name. Here is the TRUE unedited story for the list which Deitweiler felt he had to TWIST to the nth degree. His attempt at making mountains out of mole hills will not succeed with this one. I won't have him attack me, and attack everything I'm trying to achieve on this list, through his games. It's a non-starter from the get go, LD. Here's what was truly written ... let the list decide for itself. COMMUNICATIONS SECURITY ESTABLISHMENT Canada spied on allies: ex-agent Top secret security agency accused of eavesdropping on South Koreans by former analyst The Canadian Press TORONTO Canada's electronic espionage agency has spied on friendly countries such as South Korea, Mexico and Japan despite Ottawa's denials, a former agent has told CTV News. "I have lived with this information for so long and I just think that it is time that Canada knows what CSE is doing, " Jane Shorten said in a report for broadcast late Sunday. Shorten, 38, worked as an analyst from 1986 to 1994 -- when she was laid off -- for the Communications Security Establishment (CSE), CTV reports. A separate entity from the better known Canadian Security Intelligence Service, CSE can be described as a technological peeping tom. It specializes in electronic espionage, monitoring radio and other transmissions for useful information. The Soviets and their allies were once the prime targets of such surveillance, but after the thaw in the Cold War, CSE shifted its attention to friendly countries, Shorten told CTV. The agency spied on Canada's allies and trading partners, eavesdropping on friendly embassies, consulates, diplomats in Canada and around the world, she said. Ottawa denies it. "Countries like Canada have understandings that they don't carry out these activities against each other, " Solicitor General Herb Gray said earlier this year in response to claims that the U.S. Central Intelligence Agency had spied on the Japanese delegation during auto trade talks in Geneva. Replies Shorten: "He does not know what's going on because CSE is certainly doing that ... I spied on the (South) Korean government for the Canadian government." CSE is part of the Defence Department but Shorten insists senior officials at the Foreign Affairs Department were fully aware of its activities and anxious for its information. "I know my reports went to the Ministry of Foreign Affairs," Shorten told CTV. "My reports were classified as Top Secret Umbra and that's as high as you can get, and these people were cleared to get that kind of information." Shorten, once described by a superior as a gifted intelligence analyst, told CTV she was aware her revelations could result in prosecution under the Official Secrets Act but felt the risk of prison was worth it. "I feel so strongly that it's time that people learned what CSE is all about," she said.

1 0

Re: NSA, ITAR, NCSA and plug-in hooks.
by jimbell＠pacifier.com 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. > >It's not too hard to think of a compression scheme that needs extra >information to be passed from client to server; the obvious example is >some sort of dictionary compression with external dictionaries (can be >very effective for short messages where LZW etc never get a chance to get >going). > >Another, more likely case, is where the object could have been compressed >by several schemes, and a scheme ID is needed to determine which >alogorithm to use. > >The real issue would appear to be intent, though. If it's obvious that >the real intention for the hook is to allow encryption to be added, >the State department can jump on it. I'm not a programmer, but it seems to me that if the goal is to minimize the "obviousness" of the provision for cryptography, the calling program could call the called program (which might be an encryption program, maybe not) and ask for a text header that is to be listed in a Windows-type window. Thus, the calling program would not have any references to "encryption" or "key" in its program or documentation; it would get that the first time it calls the called program. BTW, one function which obviously needs an additional argument to work is a CRC program, in which the particular polynomial to be used must be specified. And I guess that a CRC is basically the same type of thing as a hash function, too.

1 0

Re: COE Recommendation No. R (95) 13
by viking＠pacifier.com 17 Dec '03

17 Dec '03

>>MS> However, if I have a wall safe and >>MS> they get a warrant to search it, can I be jailed for contempt if I >>MS> don't give them the combination? >> >> Well, IANAL, but yes, I believe that you can be. Or, worse, >>obstruction of justice. Especially if they cut it open and find that >>the knife was in the safe. > >So presumably the same would apply to the password that unlocks my >PGP private key. But there's an interesting twist. Once they open >up the wall safe, they can see for sure what is and isn't in it. This >ain't necessarily so for an encrypted file. Suppose my software has the >fiendish sophistication to disgorge different keys depending on what >password was given, and different pieces of cleartext depending >on what key was used. (Again, I apologize if this notion has already >been extensively discussed.) Is there a way to set it up such that >the cops couldn't be sure -- even using a logic analyzer -- that I >hadn't given them the complete set of keys, so as to read all the >cleartexts in the file? Assume that cyphertext files are guaranteed >to be larger, by some random factor, than the sum of all the cleartexts >in them, so the mere fact that a smaller quantity of cleartext was >disgorged than cyphertext supplied would tell them nothing. I guess this >is a kind of steganography, isn't it? Or at least something similar -- >the point would be that they couldn't tell genuine cyphertext from >camouflaging noise, without the key that tells them where to look. > >Which brings us, in turn, to the bottom line: the only things we >can be certain the bad guys _won't_ do, are the things they _can't_ >do. > > >--Michael Smith The interesting thing about PGP is that any incriminating cypher text one might have on his or her hard disk would, most likely, be in someone else's public key. So, even if they had your secret key the only thing that could be uncovered would be cyphertext that someone else had written to you. Granted, that this could be incriminating but, then again, not necessarily. I'm sure that for the purposes of conducting a criminal investigation, your own cyphertext would be far more incriminating than someone else's. (The above is only true unless you use the single key encryption option offered for personal files in which case your files would be readable.) What one should be more concerned with is sloppy handling of plain text files used prior to encryption. A good example of that is if you're using Windows based applications such as MS Winword. It has an auto-store function that generates a "Temp" file. Such files aren't wiped in the same fashion that PGP uses when it wipes a text file prior to encryption. I think that the paramount thing to consider is if you have something to hide then it is best to store it is inside your head. Any computer based storage system is bound to have certain limitations that may be bridged by a determined government agency. The other alternative is to ensure that potentially incriminating files be purged regularly to avoid such potential problems. Robert East viking(a)pacifier.com

1 0

Re: COMMUNITY CONNEXION BECOMES FIRST INTERNET PROVIDER TO ACCEPT ECASH
by Jay Campbell 17 Dec '03

17 Dec '03

>COMMUNITY CONNEXION BECOMES FIRST INTERNET PROVIDER TO ACCEPT ECASH > >Community ConneXion today announced that it has become the first and >only Internet Service Provider in the world to allow for payment using >ecash, a digital cash system developed by DigiCash bv, of Amsterdam, And, er, we're second. Ditch that 'only' part :) -- Jay Campbell edge(a)got.net - Operations Manager -=-=-=-=-=-=- Sense Networking, Santa Cruz Node Jay(a)Campbell.net got.net? PGP MIT KeyID 0xACAE1A89 "On the Information Superhighway, I'm the guy behind you in this morning's traffic jam leaning on his horn."

1 0

Re: credit card conventional wisdom
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Alice here ... On Wed, 15 Nov 1995, Howard Melman wrote: > Vladimir Z. Nuri wrote: > > attempts to get secure credit card number transfer on the internet are > > not an end in themselves. they are the first steps toward an entirely > > new transaction system. those who see a single step and criticize it > > as feeble in the context of past systems are missing the point and > > apparently can't think past the present nanosecond of their lives. My grandfather used to say, that the first horse to break from the gate, isn't necessarily the first to cross the finish line. Often, he'll be pulling up the rear. > You'll have a hard convincing folks that they need something > better than what works perfectly well today. In my humble opinion, the present system can't really be characterized as "working perfectly well". Far from it. While not as familiar with the US system as the Canadian, I can give as a simple example, the bank clearing system for paper checks. In Canada, we can clear a check from one side of the country to the other overnight. We have 24 hour clearing. While this is far from "perfect", our existing paper systems allow for a degree of efficiency which I don't believe is engineered into the US clearing system. Perhaps someone can correct me, if I have erred but I think it takes far longer than 24 hours to clear a check drawn on any US bank, and deposited to any other bank's credit in the United States. It may work "functionally" ... but certainly far from "perfectly" nor "efficiently". > Here's another point that I didn't see in your list. Today it might be > just as safe to send your CC# over the internet as giving it to a clerk, > etc. This is mostly because the number of CC#'s sent over the net vs > the whole traffic is small. It is therefore not very cost effective to > try to steal credit card numbers over the net vs other means (searching > through dumpsters, taping a phone line near LL Bean, etc.). A very good point. But then, dumpster-diving attacks could be moderated by simply implementing carbonless forms. No carbon, reduces a lot of the risks. It's basic risk management. All of this becomes a part of the cost/benefit analysis, and is part of the function of security policy. It's very much like all the talk on another thread on this list about Java security. There is no point in even discussing Java security in Netscape, when Netscape PRESENTLY has existing security holes written into the very fabric of the existing installed codebase. Holes which Netscape and AT&T refuse to address, correct or even comment on. Sun's security approach misses the point. Putting dead-bolts on houses while leaving all of the windows open, just doesn't address the problem. It really misses the mark. > If CC# purchases became common over the net, it would become much more > valuable to try to steal them from the net and more people would. It > would then become much less secure, not for any technical reason but > because there will be more crooks exploiting the existing flaws. This is also unfortunately true. Information on how to "break" a system does propagate. As more people know how to exploit a system, or as more people learn how to utilize the "letter of the rules" (the "code") rather than the "spirit" (the "intent") the degree of exploitation grows. Ask any executive in the Gaming Industry about this. Black-Jack card-counting went through an evolution in exactly this fashion. Many casinos lost a veritable "fortune" to good card counters. They lost to organized "teams" of card counters. Counters who literally broke the bank. Systems always have exploitable features. And new systems will always present new opportunities for exploitation. A completely new set of risks which are additive to those already in place, even those which may not yet be in a state of active exploitation. A pertinent network example: credit card numbers. Credit card numbers are not just a set of random digits. Only particular patterns of numbers can be valid. This existing "security provision" -- check digits -- actually ends up opening a security hole when we look at transmitting credit card numbers via the Internet. The security feature on one side of the ledger makes it far easier to differentiate between what is a random set of numbers, and what is in fact a valid CC number. Simple pattern analysis allows to search for valid numbers. It makes the potential "crooks" job much easier and its already engineered into the system. The "credit card number" risk though is accidental, while the Netscape Navigator risk isn't accidental at all, it's willful. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: credit card conventional wisdom
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Alice here ... On Thu, 16 Nov 1995, Vladimir Z. Nuri wrote: > but one distinction I do realize has to be made in all this is the > difference between "fraud" and "breaking a system". the latter is > a far more potentially serious problem with cryptographic security than > the former. in fact cryptographic security attempts to deal with all > fraud by making "breaking the system" impossible, and succeeds to the > degree it accomplishes this. I think this is extremely important to consider. The functions which define relationships between large numbers of variables, (such as say the world economy) -- these functions are not "idiot proof". They can collapse. And, yes Virginia, the system can be "broken". To suggest that cryptography can address this issue is to misunderstand the problem, and is part of this whole mindset that "security" is cryptography. Our economies are, if anything, less resilient than they were in the not to distant past. They are far more vulnerable. The introduction of new business practices, such as the reduction in most firms inventories, and the ever greater reliance on "just in time" approaches has made us far less able to sustain any interruption. The headlong introduction of "new variables" and new vectors into an unstable system has never been "sound policy". I guess it's sort of like what happened when rabbits were introduced into Australia. An eco-catastrophe. Perhaps, we can all agree that existing systems are best "not destabilized". Then again, I'm not the one who gets his jollies by rocking the boat. I get mine elsewhere. I guess here then is the real question, what is the fallback plan when something does go catastrophically wrong?? What then, hand-wringing, and saying that it "exceeded our theoreticians predictive capabilities" just does not suffice. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: NSA, ITAR, NCSA and plug-in hooks.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Wed, 15 Nov 1995, Bill Stewart wrote: > >>Does anyone know the ostensible justification for this? > > Isn't the NCSA government-funded? If so, they've probably got > less slack in what they can get away with than private citizens; I think that government-funding does give a certain degree of control -- the control that comes with the budget axe. Private citizens alternatively, get to face a different type of tool. They get to face stuff like RICO provisions, which "effectively" -- as they are presently used, rather than as they were written and intended to be used -- tend to allow the government to "influence" private citizens. > the NSA's got more leverage over their funding, especially if > "Supercomputer Applications" are often military or civilian-govt. I doubt that the NSA approves the NCSA's budget. Far more likely would be for the NSA to use a rogue programmer at the NCSA. Someone who might hide some very damaging code into one of the existing applications without anyone (else) knowing about it. I could even see an independent doing this simply to profit from it. I could see someone doing something like that. It's no different really than the "free" programs that were given away years ago which appeared to be useful but actually contained "poison code". > Not only do they have to worry about ITAR as law, they have to > worry about their continued cash flow. Like I said, I don't believe in the "grand conspiracy" model. I tend toward "contained" enterprises. All the more reason though, NEVER to use black-box code, and all the more reason for public open review of code. NSA and ITAR aside ... safe computing is safe computing and is in everyone's collective interest. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: No Privacy Right in Indonesia ?
by Bill Stewart 17 Dec '03

17 Dec '03

At 05:54 PM 11/17/95 -0500, "James M. Cobb" <jcobb(a)ahcbsd1.ovnet.com> wrote: >An 11 17 95 Reuter Information Service newsstory headlined > Politics, not sex, is Indonesian Internet's concern ... > Activists in Indonesia who use the Internet say it is a power- > ful tool for distributing information in a society where self- > censorship abounds, newspapers are tightly controlled, jour- > nalists are jailed and unlicensed magazines banned. The primary difference between Indonesian and Singaporean censorship is that the Singaporeans are a lot more urbane about it, and generally don't have crowds of protestors to shoot at. Reporting on the East Timor activity is an especially good way to get kicked out of the country; I know people it's happened to. Uncensorable communications can be a substantial help, though rubber-hose cryptanalysis is still fairly effective, and it's the type of place that would use it. A certain amount of US activism on the East Timor problems is Internet-based; I don't know how connected it is to Indonesia or East Timor, which is too underdeveloped to be very active on the net, and has the added problem that activists are heavily watched. The Indonesian military recruitment process is unfortunately not something that crypto can affect much, except by keeping political activist's identities private so they're not targets. Basically, the draft board knocks on your door and says "Uncle <whoever> wants _you_", and they're authorized to shoot you if you don't cooperate, though they're also authorized to not shoot you. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

[BOOK] "SPYWORLD" (was: Re: CSE gets flak on TV)
by Dave Del Torto 17 Dec '03

17 Dec '03

In Reply to the Message wherein it was written: >On Tue, 14 Nov 1995 s1113645(a)tesla.cc.uottawa.ca wrote: > >> Electronic snooping part of the game >> >> OTTAWA (CP)--Intelligence experts say it's no big secret that Canada's >> high-tech spy agency snoops on friendly countries for financial gain. > >No big secret?? It was news to me. ;-) [elided] Dear Alice, To the few on the list who have not already had the pleasure, I'd put "SPYWORLD" in the "Puzzle Palace" category of must-reads. Before recently leaving our own Wunderland for a course in advanced bird-watching off in the Canary Islands, Michael Sattler was kind enough to loan me his hardcover of this pithy little 1994 history/expose on the Canadian spook community by one of their first key propeller-heads, "Mike Frost." After being unceremoniously dumped by the Canucks a few years back, he decided to "share" about it all to work out his frustrations. Though I assume it was 'tidied up' by various government censors in pre-publication, and according to the inside page was printed and "bound in the U.S.A." ;), I must say it was nevertheless an arousing read, albeit a bit nit-sloppy with the ghost writing/editing here and there. It paints a colorful picture of the TLA gang-bang that resulted in the conception of the Canadian black budget intercept operations. The potent schtuppingvermachen of the American and British, each waiting patiently for sloppy seconds is, to say the least, pruriently fascinating. "Frost" manages to (un)cover, in pleasurably lurid detail, some of the tools used, and policies openly violated, during such intercepts as "Stephanie" in Moscow. There are even some descriptions of the scenes behind the green doors of the NSA and CIA. Frankly, all it really lacks is a nude picture of the American Ambassador in Ottowa pulling his pants up _before_ drawing the shades for the last time. If you do read it, use protection. ;) "SPYWORLD" Subtitle: Inside the Canadian and American Intelligence Establishments By: "Mike Frost" as told to Michel Gratton ISBN 0-385-25494-6 Publisher: Doubleday Canada Ltd. 105 Bond Street Toronto, Ontario M5B 1Y3 dave PS: Don't worry, Mike, none of the pages stick together. :) _______________________________________________________________________ "If you're ever robbed of your virtue, trust me: it was an inside job."

1 0

Dec 5th KE meeting details
by Carl Ellison 17 Dec '03

17 Dec '03

Date: Mon, 13 Nov 1995 13:15:32 -0500 From: Elaine Frye <frye(a)micf.nist.gov> November 8, 1995 To: Key Escrow Distribution Lis From: Ed Roback, NIST Subject: Planning for December 5th Meeting At the September 6-7, 1995 key escrow issues meeting, I received a number of comments that the government presentations should have addressed more topics in greater detail. To respond to this concern, I would like to request submissions of any specific questions/issues related to the draft criteria that you would like to see addressed on December 5th. I cannot guarantee we can meet all requests, but your suggestions will greatly help in planning the meeting agenda and government presentations. Please forward your questions/issues/ideas to me via e-mail at "edward.roback(a)nist.gov", fax at 301-948-1784 or telephone on 301-975-3696. FYI, the current outline for the December 5 meeting is as follows: A. Government presentation of draft criteria, followed by Q&As B. Industry presentations on draft criteria C. Breakout sessions on criteria (a suggestion has been made to also have one on policy issues) D. Reports from breakout sessions E. Wrapup Remember, also, that if you would like to make a presentation at the meeting, you are asked to contact Elaine Frye at "elaine.frye(a)nist.gov". You may also bring written comments to the meeting for distribution (our estimate is that 250 copies are necessary.) Thank you. ***************************************************** Elaine Frye Computer Systems Laboratory, NIST Bldg. 225/Rm.B154 Gaithersburg, MD 20899-0001 Voice: 301/975-2819 Fax: 301/948-1784 *****************************************************

1 0

Re: credit card conventional wisdom
by wiltship＠iccu6.ipswich.gil.com.au 17 Dec '03

17 Dec '03

You wrote... >While not as familiar with the US system as the Canadian, I can give as a >simple example, the bank clearing system for paper checks. In Canada, we >can clear a check from one side of the country to the other overnight. We >have 24 hour clearing. While this is far from "perfect", our existing >paper systems allow for a degree of efficiency which I don't believe is >engineered into the US clearing system. Here in Australia most banks take 5 working days to clear a cheque.. even if it's deposited at a bank just up the road from drawer's bank. cheers Peter 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

Re: NSA, ITAR, NCSA and plug-in hooks.
by ahupp＠primenet.com 17 Dec '03

17 Dec '03

>From: Scott Brickner <sjb(a)universe.digex.net> >Date: Thu, 16 Nov 1995 15:13:27 -0600 >Subject: Re: NSA, ITAR, NCSA and plug-in hooks. >The problem is that the non-encryption program must use the same >interface as the encryption program. Text compression is often cited >as an example of a non-encryption program that can use the same hooks >as a compression program, but there's a key difference: the text >compressor *doesn't* need a key. > >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. > >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. > PKZIP allows encryption (other's ?). How about a hook to that? _____________________________________________________________ "We work in the dark We do what we can We give what we have Our doubt is our passion And our passion is our task The rest is the madness of art." --Henry James ___________________________________________________________

2 1

RealAudio website TEMPORARY PASSWORD
by RealAudio Welcome Wagon 17 Dec '03

17 Dec '03

This is an automatic response to your request for a free user account on the RealAudio site. Welcome to the world of RealAudio. Please do the following: 1. Go to http://www.RealAudio.com/welcome.html 2. Enter the following: Username: cpunks TEMPORARY Password: New.Norfolk 3. Choose your personal, PERMANENT password for the World of RealAudio If you have trouble with the software, please refer to the RealAudio FAQ and Technical Notes available at http://www.RealAudio.com/help.html You can also contact us through http://www.RealAudio.com/comments.html Thanks for using RealAudio! Progressive Networks, Seattle, Washington, USA

1 0

Re: e$: Come aaaannnndddd Get it!
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>jim bell writes: [re: payee anonymity] >> It seems to me that this should be possible, within limits, if the potential >> payee could generate a "blinded" note to be delivered to the payer by >> anonymous means. The payer could get the note certified by the bank, >> possibly given an extra "blind" if necessary (is this possible? Desirable? >> Why not?) and then the resulting still-blinded but certified note is posted >> (in encrypted form, I supposed) to the 'net so that only the payee can >> decrypt and unblind it. > >This sounds like a version of "Hey, I'll pay you $10, if you give me a ten >dollar bill first." As I understand your protocol, Bob gives Alice an enote, >then Alice gives Bob an enote. Alice isn't paying Bob in any meaningful sense, >since Bob ends up with the same amount of e$ with which he started. Perhaps >you could clarify what you meant. It sounds like you understand even less about the details of digital cash than I do. First, read the August 1992 issue of Scientific American, the article by David Chaum. He explains, with a certain amount of detail, how blinded digital cash operates. To become validated and worth money, it first has to be electronically "written," blinded, and then signed by the bank. Then it is unblinded, at which point it can be spent. What I was saying is that the notes would be written by the payee, then blinded by the payee, given to the payer, and then signed by the payer's bank. At this point, they are worth money, and they are then returned to the payee, possibly by encrypting them and publishing them in encrypted form on a publicly-accessible portion of the Internet, so "anyone" could read them. Only the intended payee would be able to decrypt them, however, and only the payee would be able to unblind the notes.

1 0

Re: Ecash account
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Fri, 17 Nov 1995 don(a)cs.byu.edu wrote: > So who here is going to use their ecash account to set up a money > lau^H^H^Hexchange service? Oh boy. Not this argument again. The one that says that if someone makes "change" that its money laundering. *Sigh* I suppose it is, if that's the way you're going to look at it. On that basis, every time I go to the corner grocery, I'm "laundering" my money. So be it. And I suppose if I put aside a small "nestegg", that then I've got something to hide as well?? > Ob Cyphernoise: Would Dr Fred, Alice, and any other names LD has set up > for himself lately please keep the noise limited to email? Please? I too am tired of LD spoofing me. But I am not going to actively "deny" every one of his posts. It's just not worth it. Hopefully the people on this list can tell the difference between what I stand for, and what certain people would like to paint me as standing for. As I've said, and repeated, my only interests lie in E-cash, and in removing code from the Internet which opens up security holes. Software, like Netscape Navigator and Java. The rest ... or anything else that someone tries to paint me as "standing for" is simply juvenile antics. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

[NOISE] Review: GoldenEye
by David E. Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just got back from the new Pierce-Brosnan-as-007 flick. It had a few typical "hacker" stereotypes, and a couple of interesting crypto relevant references. * Boris, the stereotypical hacker, was hacking through American banks. A screen had the words "Department of Justice" and the DoJ logo; underneath were the words "Clipper Chip" and a list of banks. * The archvillian's plan involved a massive money transfer and an EMP pulse; he very briefly explained the effects of what would happen if every computer in London were rendered non- functional. Possible crypto-anarchy bits. * Boris should learn the value of strong passphrases. His password for the massive mainframe which will be used in the archvillain's scheme is a five-letter dictionary word, which didn't change (and it was used on two different computers), and he revealed it indirectly (it was a word puzzle). * A few on-computer-screen references to "encryption". * Boris and the mastermind kept bantering about "breaking codes." * Boris' computer in Russia - in his apartment - has a domain ending in ".comp.math.edu"; when his screen lights up with the words "INCOMING EMAIL" he goes into a live chat (complete with graphics). Above-average action/adventure flick. The technical mistakes are forgiveable in the interest of dramatic license. Don't watch it for the techno/crypto bits, though. Watch it because lots of things blow up :) Dave----- David E. Smith, c/o Southeast Missouri State University 1210 Towers South, Cape Girardeau MO USA 63701-4745 +1(314)339-3814, "dsmith(a)midwest.net", PGP ID 0x92732139 http://www.midwest.net/scribers/dsmith/ - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMK1btCoZzwIn1bdtAQFmOgF/ZLYc3sT1L5sQS+wqmS5U6wsx9jL86job Ie6DU65FIuSZF6vFDBDNZFxZxs0HuaR6 =5PGz -----END PGP SIGNATURE-----

2 1