December 2003 - cypherpunks-legacy

radikal update 17-9-1996
by tank 17 Dec '03

17 Dec '03

URL of the main radikal-site has changed: ********************************* * http://www.xs4all.nl/~radikal * ********************************* We need more mirrors to stop Germany censoring the radikal and the internet. As you can see, free speach is not a gift, but something you have to fight for. Join the struggle ! If you got a mirror up and running let it know. Send your url to: tank(a)xs4all.nl *********************************************************************** ** Radikal Mirrors ** ** *********************************************************************** Receive Radikal 154 by email: Send a empty message to radikal(a)xs4all.nl and you receive issue 154 by mail. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Read the radikal by calling the netherlands (25 numbers). All telefonnr. are listed at the end of this mail. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Download the radikal archive: http: http://www.xs4all.nl/~bslash/radikal.tar.gz Radikal-site unix http://www.xs4all.nl/~bslash/radi.zip Radikal-site dos-zip archive ftp: ftp://utopia.hacktic.nl/pub/replay/pub/incoming Radikal 154 in plaintext ASCII http://www.xs4all.nl/~radikal/radi154.tgz Radikal 154 unix http://www.xs4all.nl/~radikal/radi154.zip Radikal 154 dos-zip If you got your mirror up and running let us know +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Special mirror: de.soc.zensur de.org.politik.spd http://www.altavista.digital.com usenet-search for radikal.zip +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Radikal-sites: 1.http://www.xs4all.nl/~radikal 2.http://burn.ucsd.edu/%7Eats/RADIKAL/ Arm the Spirit statement "Radikal Mirror Site At ATS WWW Page" 3.http://www.jca.or.jp/~taratta/mirror/radikal/ 4.http://www.serve.com/~spg/ 5.http://huizen.dds.nl/~radikal 6.http://www.canucksoup.net/radikal/index.html 7.http://www.ecn.org/radikal 8.http://www.well.com/~declan/mirrors/ 9.http://www.connix.com/~harry/radikal/index.htm 10.http://www.ganesa.com/radikal/ 11.http://www.denhaag.org/~radikal 12.http://www.knooppunt.be/~daniel/radikal 13.http://emma.unm.edu/radikal 14.http://www.tacacs.com/radikal/" 15.http://www.dsvenlo.nl/~vvd/radikal/ 16.http://www.why.net/home/static/radi 17.http://users.abcs.com/dockmstr/mirror/radikal/index.htm 18.http://www.xs4all.nl/~jeroenw/radikal/ 19.http://home.ipr.nl/~radikal/ 20.http://www.dreamy.demon.co.uk/occam/ 21.http://www.ibmpcug.co.uk/~irdial/live_free/ 22.http://zero.tolerance.org/radi/index.htm 23.http://www.meaning.com/library/radikal/ 24.http://www.xs4all.nl/~irmed/radikal/ 25.http://www.walli.uwasa.fi/~tviemero/radikal 26.http://www.sko.it/~sfede/radi/index.htm 27.http://www.bart.nl/~sz/index.html 28.http://bellp.med.yale.edu/index.htm 29.http://www.euronet.nl/users/funest/radi/index.htm 30.http://fine.com/~rsr/radikal 31.http://www.lab.net/radikal 32.http://www.charm.net/~gbarren/radikal 33.http://login.datashopper.dk/~pethern/radikal/ 34.http://www.interlaw.com 35.http://hyperreal.com/~rich/radikal/index.html 36.http://www.citinv.it/iniziative/info/radikal/ Phone: Call and login as "new". So first dail the international number +31 (hollands international code) and than one of these numbers. Amsterdam Zoetermeer Maarssen 020 5350535, V.34 079 3611011, V.34 0346 550455, V.34 020 4223422, UUCP 079 3600800, ISDN PPP 0346 553613, ISDN PPP 020 6265060, ZyXEL 079 3630569, ISDN X.75 0346 555285, ISDN X.75 020 4229700, ISDN PPP 020 4206782, ISDN X.75 Hoorn Geleen Leeuwarden 0229 212177, V.34 046 4789478, V.34 058 2157815, V.34 0229 219717, ISDN PPP 046 4230555, ISDN PPP 058 2130910, ISDN PPP Goes Assen 0113 252900, V.34 0592 331531, V.34 0113 270110, ISDN PPP 0592 331278, ISDN PPP Willemstad Deurne 0168 472472, V.34 0493 323344, V.34 0168 476472, ISDN PPP 0493 351566, ISDN PPP

1 0

RE: Workers Paradise. /Political rant.
by Dustbin Freedom Remailer 17 Dec '03

17 Dec '03

jbugden(a)smtplink.alis.ca wrote: >> By spreading the risk you minimize the cost. <...> >Canada has a single payer system Translation: a more palatable term for "socialised medicine" >and we spend about two thirds as much as the >U.S. on health care as a percentage of G.N.P. We manage to insure all Canadians >while about 35% of people in the U.S. have *no* health insurance. So why in the world do those crazy Canadians keep coming here for medical care, when they can get it from your compassionate bureaucrats? What could be their compulsion to spend money they don't need to spend? Charitable impulses toward our impoverished medical profession? BTW, looking at historical costs of medical care and the level of government involvement, it is safe to say that the US has too much socialism in our medical system right now, and that it what's making the best system (ours) so expensive when it would not be otherwise. >Yes, the insurance premium is not optional. True. >Yes, it *is* cheaper. *False.* It is cheaper for _SOME_, and more expensive for others (in terms of either money, or waiting with pain, or both) and has an _ultimately high cost [the death penalty] for still others, who are forced to wait for the "compassionate" bureaucrats [who naturally know more about what patients' bodies need than the patients do themselves] to give them permission to get medical care they would otherwise purchase before death.

2 1

Re: Assassination Politics, was Kiddie porn on the Internet
by Michelle Thompson 17 Dec '03

17 Dec '03

>From: kwheeler(a)intellinet.com >Date: Tue, 17 Sep 1996 10:54:35 -0500 >X-Sender: kwheeler(a)intellinet.com >To: Michelle Thompson <mthompso> >Subject: Re: Assassination Politics, was Kiddie porn on the Internet Interesting information from a friend of mine- >An american can not serve for pay for a position in another military >that could be filled by local populace. I may have my jurisdiction >wrong tho, this could be an international law not a US law. >Basically, you can't go be a grunt or an assasin in another country, >because they can find their own, but one can, however, fly P-40 Warhawks for >China in 1941 because there were no chinese planes/pilots. Guys from soldier >of fortune (tho they do volunteer work) could be hired as 'experts' at >whatever, removing mines, etc... It's very touchy. But, the worst thing about >it all, is that the geneva convention doesn't protect mercenaries....so awful >things could be done to them, and the world wouldn't see that as war crimes. > >-Keith I believe that with the breakdown of the traditional sense of sovereignty, mercenary activity, whether military or commercial in nature, will increase. Engineering seems to be quite mercenary already, and very international. Marketing and advertising, to a novice (me), seem to be going the same way. Hence my interest in cryptography. Data security is essential in international engineering projects. Michelle Thompson

2 1

RE: Risk v. Charity (was: RE: Workers Paradise. /Politica...
by jbugden＠smtplink.alis.ca 17 Dec '03

17 Dec '03

Subject: RE: Risk v. Charity (was: RE: Workers Paradise. /Political rant) Black Unicorn <unicorn(a)schloss.li> >On Mon, 16 Sep 1996 jbugden(a)smtplink.alis.ca wrote: >> Specifically, that anyone can "save for a rainy day" and still not be >> able to provide for events that can always happen: Heart attack, >> stroke, car accident, pinched nerve that leaves you in excruciating >> pain and unable to work for several years. > >Understand what it is you are saying. > >You are saying that everyone on the planet has a right to health > insurance and disability insurance whether they can afford it or not. > This is folly. The result is serious moral hazard problems. Almost, but not quite. I'm saying that within our two countries at least (Canada, U.S.) everyone could have access to medically necessary procedures because the *society as a whole* can afford it. I understand moral hazard and risk pool seperation. I also understand that the insurance bureacracy required to manage much of the U.S. health care system absorbs much of the money going into the system. Managing risk pool seperation proves to be expensive, or perhaps just very profitable. > Social safety nets prevent rioting by the lower classes, revolution and > general civil disorder because they appease the masses. Indeed this > is a form of health and life insurance for the middle and upper classes. Absolutely. And it is a scheme that many of the lower classes pay into. Since it is to our mutual benefit (yours and mine), I choose not complain about it. > Spreading the risk, by itself, does NOT reduce cost. > You must properly PRICE risk. Agreed. But there is a balance between accurately pricing the risk and minimizing the cost of the bureacracy that polices this pricing. There are also many ways to modify behaviour, not all of them direct. We only need a correlation here, not causation. For example, high taxes on smoking and drinking or spot checks for drunk driving. All of these correlate with a reduction in high risk behaviour and a reduction in health costs. Yes, there are people who will engage in high risk behaviour. Yes, they will still receive treatment. No, it is not worth tracking down all of these people. You may also get better privacy because no insurance company is collecting personal data in order to minimize their risk. A Suspicious Persons List is only one manifestation of this type of intrusion. This privacy issue may only increase as genetic screening becomes widespread. There is much potential for moral hazard when the PRICE for your insurance is affected by the accuracy of your disclosure. How will they ever know... Fact: Canada spends less than the U.S. per capita on health care, while covering more people in percentage terms. Ciao, James, qui pete les bretelles du Canada. And he brought the present unto Eglon king of Moab: and Eglon was a very fat man. [Judges 3:17] "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ "A foolish consistency is the hobgoblin of little minds." - Emerson

2 1

Re: Workers Paradise. /Political rant.
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> tcmay(a)got.net (Timothy C. May) writes: > > Crypto Anarchy means getting rid of deadwood the old-fashioned way. > > Starting with the lying old fart himself. The Vilus bot is at it again, I suggest a 2 line cypherpunks FAQ along the following lines: Q> What do it do when I join the list? A> Killfile *(a)bwalk.dm.net Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Http://www.fatmans.demon.co.uk/crypt/ "Don`t forget to mount a scratch monkey" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53 6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3 sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/ 9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90 En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2 YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi mUqFH41Z7NkyO8ZFdi5GGX0= =CMZA -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: 10 minute delay considered inconsequential
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Wed, 11 Sep 1996 22:50:22 -0700, Timothy C. May wrote: >>I've always wondered if the makers of mailer software couldn't include a delay >>option, so that, say, a message might be held for 10 minutes and then sent. >>Imagine how many of the "Sorry about x; I meant y" posts we'd never see. > >I expect there would be little effect. I suspect most of us write articles, >send them out, and only notice the mistakes, typos, whatever when they are >pointed out. True. I guess what we need is an AI mailer that would do something like "Message #324 is rather confusing - did you really mean x?". Oh well. . . # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Child pornography -- Expert witness for Federal jury trial
by Declan McCullagh 17 Dec '03

17 Dec '03

Folks, I just got a call from two Federal Public Defenders whose client is charged with possession of child pornography stored in the /tmp directory of a Unix system, in a zip'd file. (These lawyers seem to be reasonably cyber-savvy, and told me they're following what I've been writing about cyber-liberties.) There's evidence saying that other people were using the account at that time, and the attorneys have the relevant wtmp/utmp files. There's also no evidence saying an actual child was exploited -- given the nature of the images, they may have been morphed. I don't think the defendant is accused of *making* them; he's only accused of *possessing* them. The case goes to jury trial soon in a Federal District Court. If anyone is interested in testifying as an expert witness in this case about Unix tech foo (and is qualified to do so), please let me know and I'll pass along your info. I believe at least your expenses would be paid. Here's an opportunity to ensure justice is done and not just rant in cyberspace... :) -Declan (Note I have no idea if the guy is indeed guilty of possessing JPGs the government has banned. What I do know is that any defendant deserves a fair trial and the government must prove that he's guilty of the crimes for which he's charged. And if anyone does molest a child, I say lock 'em up for a good long time.)

1 0

Re: common sense
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Thu, 12 Sep 1996 16:04:14 -0700, HipCrime wrote: >> And rather than "dispensing drugs in clinics," why not simply >> scrap the drug laws entirely? People have a *right* to do as >> they please with their bodies. >Let's hear it for common sense. It's the first decent posting I've >seen to this list. Tell me, how do you walk with that huge chip on your shoulder? # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

CU foward post, netcopped again!
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> >what is being punished here is not the exploitation of children, which is > > wrong and must be prevented, but the private thoughts of those who > > produce and recieve this material, which are totally private and > > legitimate. > > There is nothing "legitimate" about fucking children, fantasising about > fucking children, or looking at pictures of people fucking children. > > The dangers of this debate are all too apparent, and if this sort of > quote were to reach the tabloid audience I hardly think it would be a > positive contribution to the image of CommUnity... Oh no! - I`ve been netcopped on the CommUnity list *AGAIN*, long live cypherpunks, the last bastion of free speech on the net!!!! ;-) But seriously, this does highlight what we are up against, when CommUnity (for US readers CommUnity, abreviated CU sometimes, is like a UK version of the EFF), supposedly a free speech and online liberties organisation, has posters (and this one is pretty typical) like this which clearly cover all debate on a subject area as "padophilia" if they try to explore the issues any more deeply than saying that fucking children is wrong... Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Http://www.fatmans.demon.co.uk/crypt/ "Don`t forget to mount a scratch monkey" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53 6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3 sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/ 9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90 En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2 YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi mUqFH41Z7NkyO8ZFdi5GGX0= =CMZA -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: really undetectable crypto
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Thu, 12 Sep 96 19:26:56 -0700, Jim Miller wrote: >Most everybody on the list is familiar with the technique of hiding >encrypted messages in the LSBs of image files. Personally, I would not >use such a technique because don't I believe it's really undetectable. I >assume, without proof, that the LSBs of images files have statistical >properties that are sufficiently different from encrypted data that a >clever person could determine whether or not an image file contained an >imbedded encrypted message. Actually, if you use only a few bits - and not, say, bit 15 of *every* pixel - you can feel secure *IF* you are writing truly encrypted data. A regular PGP message has a bunch of header material that most certainly is not random-looking. OTOH, if you only write the raw data, then there is no way to differentiate from the random noise added by any scanner - in most cases, the last couple bits in each RGB triplet of a truecolor image are random. # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

DIMACS Trust management workshop, Sept 30 - Oct 2.
by Matt Blaze 17 Dec '03

17 Dec '03

------- Forwarded Message Received: from amontillado.research.att.com (amontillado.research.att.com [135.205.42.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id LAA24206 for <mab-local(a)nsa.research.att.com>; Tue, 17 Sep 1996 11:52:51 -0400 (EDT) Received: from research.research.att.com (research.research.att.com [135.205.32.20]) by amontillado.research.att.com (8.7.5/8.7) with SMTP id LAA14378 for <mab(a)issr.research.att.com>; Tue, 17 Sep 1996 11:52:30 -0400 (EDT) Received: from ns.research.att.com by research; Tue Sep 17 11:48:17 EDT 1996 Received: from henson.rutgers.edu by ns; Tue Sep 17 11:06:01 EDT 1996 Received: (from bquigley@localhost) by henson.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id LAA26298; Tue, 17 Sep 1996 11:02:41 -0400 Date: Tue, 17 Sep 1996 11:02:41 -0400 From: Barbara Quigley <bquigley(a)dimacs.rutgers.edu> Message-Id: <199609171502.LAA26298(a)henson.rutgers.edu> To: dimacs-members(a)dimacs.rutgers.edu, local-list(a)dimacs.rutgers.edu, dimacs-dimacs(a)dimacs.rutgers.edu, dimacs-current-postdocs-industry(a)dimacs.rutgers.edu, dimacs-current-postdocs-univ(a)dimacs.rutgers.edu, dimacs-current-visitors(a)dimacs.rutgers.edu, rutgers-list(a)dimacs.rutgers.edu, theorynt(a)vm1.nodak.edu, finite-model-theory(a)informatik.rwth-aachen.de Subject: DIMACS Workshop on Trust Management in Networks, Rutgers University, September 30 - October 2, 1996 DIMACS Workshop on Trust Management in Networks September 30 - October 2, 1996 DIMACS, Rutgers University - ---------------------------------------------------------------------------- Organizers: Ernie Brickell brickell(a)btec.com Joan Feigenbaum jf(a)research.att.com David Maher dpm(a)allegra.att.com Theme: The use of public-key cryptography on a mass-market scale requires sophisticated mechanisms for managing trust. For example, any application that receives a signed request for action is forced to answer the central question ``Is the key used to sign this request authorized to take this action?'' In certain applications, this question reduces to ``Does this key belong to this person?'' In others, the authorization question is considerably more complicated, and resolving it requires techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. This workshop covers all aspects of the trust management problem. Relevant topics include but are not limited to: * General approaches to trust management * Languages, systems, and tools * Certificates and public-key infrastructure * Formal models and analysis * Trust management in specific application domains; including but not limited to: o Banking o E-mail o Internet commerce o Licensing o Medical information systems o Mobile programs and ``code signing'' o Revocation of cryptographic keys For more information: Information about local arrangements, travel, lodging and registration can be found at http://dimacs.rutgers.edu/Workshops/Management. Those without WWW access can contact Pat Pravato at 908-445-5929 or pravato(a)dimacs.rutgers.edu. This workshop is part of DIMACS Special Year on Networks. Information about the Special Year on Networks can be found at DIMACS WWW site: http://dimacs.rutgers.edu or by contacting the center. __________________ Program: Monday, September 30, 1996 8:15 Continental breakfast 9:00 Welcome to DIMACS Fred Roberts, DIMACS Director 9:15 What is "Trust Management," and what are the Workshop Goals? Joan Feigenbaum, AT&T Laboratories 9:45 Let a Thousand (Ten Thousand?) CAs Reign Stephen Kent, BBN Corporation 10:45 Break 11:00 The PolicyMaker Approach to Trust Management Matt Blaze, AT&T Laboratories (Joint work with J. Feigenbaum and J. Lacy) 12:00 Lunch 1:15 SDSI: A Simple Distributed Security Infrastructure Butler Lampson, Microsoft (Joint work with R. Rivest) 2:15 SPKI Certificates Carl Ellison, Cybercash 3:15 Break 3:45 Panel Discussion Moderator: David Maher, AT&T Laboratories Panelists: Blaze, Ellison, Kent, and Lampson 5:30 Wine and cheese Tuesday, October 1, 1996 8:15 Continental Breakfast 9:00 Using PICS Labels for Trust Management Rohit Khare, World Wide Web Consortium 9:30 Managing Trust in an Information-Labeling System Martin Strauss, Iowa State University (Joint work with M. Blaze, J. Feigenbaum, and P. Resnick) 10:00 Trust Management in Web Browsers, Present and Future Ed Felten, Princeton University (Joint work with D. Dean and D. Wallach) 10:30 Break 10:45 IBM Cryptolopes, SuperDistribution, and Digital Rights Management Marc A. Kaplan, IBM Watson Research Center 11:15 Requirements and Approaches for Electronic Licenses David Maher, AT&T Laboratories 11:45 PathServer Michael Reiter, AT&T Laboratories (Joint work with S. Stubblebine) 12:15 Lunch 1:30 Inferno Security David Presotto, Bell Labs -- Lucent Technologies 2:00 Transparent Internet E-mail Security Raph Levien, University of Calfornia at Berkeley (Joint work with L. McCarthy and M. Blaze) 2:30 Secure Digital Names Stuart Haber, Bellcore (Joint work with S. Stornetta) 3:00 Break 3:30 Untrusted Third Parties: Key Management for the Prudent Mark Lomas, Cambridge University (Joint work with B. Crispo) 4:00 Distributed Trust Management using Databases Trevor Jim, University of Pennsylvania (Joint work with C. Gunter) 4:30 Distributed Commerce Transactions: Structuring Multi-Party Exchanges into Pair-wise Exchanges Steven Ketchpel, Stanford University (Joint work with H. Garcia-Molina) Wednesday, October 2, 1996 8:15 Continental Breakfast 9:00 Policy-Controlled Cryptographic Key Release David McGrew, Trusted Information Systems, Inc. (Joint work with D. Branstad) 9:45 An X.509v3-based Public-Key Infrastructure for the Federal Government William Burr, Nat'l. Inst. of Standards and Technology 10:15 Break 10:30 The ICE-TEL Public-Key Infrastructure and Trust Model David Chadwick, Salford University 11:00 A Distributed Trust Model Alfarez Abdul-Rahman, University College, London (Joint work with S. Hailes) 11:30 On Multiple Statements from Trust Sources Raphael Yahalom, Hebrew University and MIT 12:00 Lunch 1:00 Off-line Delegation in a Distributed File Repository Arne Helme, University of Twente (Joint work with T. Stabell-Kul) 1:30 Operational Tradeoffs of Aggregating Attributes in Digital Certificates Ian Simpson, Carnegie Mellon University 2:00 Trust Management for Mobile Agents Vipin Swarup, Mitre (Joint work with W. Farmer and J. Guttman) 2:30 Break 3:00 Trust Management in ERLink Samuel Schaen, Mitre 3:30 Linking Trust with Network Reliability Y. Desmedt, University of Wisconsin at Milwaukee (Joint work with M. Burmester) 4:00 Trust Management Under Law-Governed Interaction Naftaly Minsky, Rutgers University (Joint work with V. Ungureanu) 4:30 Tools for Security Policy Definition and Implementation Polar Humenn, Blackwatch Technology, Inc. ------- End of Forwarded Message

1 0

Re: (fwd) Email Robot draws fire from CypherPunkz
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Fri, 13 Sep 1996 09:02:19 -0700 (PDT), Declan McCullagh wrote: >The Cypherpunks gang has apparently attacked a San Francisco artist's ^^^^ No wonder the Feds want to close us down. Look at all the dangerous things we've done this week: 1. Shot the bull 2. (see #1) 3. (see #1) et cetra # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: J'accuse!: Whitehouse and NSA vs. Panix and VTW
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Fri, 13 Sep 1996 11:33:09 -0700, stewarts(a)ix.netcom.com wrote: >Anybody for an Internet Driver's License? *Surfer's* license. The newsies love to refer to "net surfing", because to the highly unknowledgable reader it makes it sound as if they have a clue about what they're writing on. # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: Fed appellate judge remarks re anonymity, free speech on the net
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Fri, 13 Sep 1996 07:47:27 -0700 (PDT), Z.B. wrote: >> At 09:24 PM 9/12/96 -0700, zachb(a)netcom.com wrote: >> >> (Also in today's news, the 9th Circuit upheld a CA statute forbidding sales >> >> of material considered "harmful to minors" from vending machines.) >> > >> >Even if this statute is meant only to apply to cigarette machines, which >> >would seem to be the case given all of the anti-cig stuff going on now, >> >what good will it do? >> >> Whoops. Sorry. Wrong context. What I should have said was "the 9th Circuit >> upheld a CA statute forbidding sales of *printed* material considered >> 'harmful to minors' from unsupervised vending machines". The publication(s) >It's still mostly the same thing. I've never seen the type of machine >that you're talking about, and I don't think anyone would be dumb enough >to install one in a store that is near a school, or frequented my >minors. This law just does not seem like a very good idea. Where did you live? I used to walk home from school (in Ventura, CA - about 1 hour away from LA) and see a vending machine selling copies of "LA X-Press" (Or something like that) right next to the vending machines for the Star-Free Press and the LA Times. This was on the curb by a busy shopping center, on the block opposite of the County of Ventura's government center. Hypothetically, it was even plausibly deniable (the watchword of the Clintons) - "I was just buying this copy of the newspaper." And before someone asks, no, I wasn't buying them. # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: Workers Paradise. /Political rant.
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Sat, 14 Sep 1996 21:08:58 +0200 (METDST), Asgaard wrote: >>The 70% already _are_ cutting the throats of the other 30%. It's called a >>60%+ tax rate. This is the sum of: federal income tax, state income tax, >Most of these taxes are not used for feeding the poor but to support >the Nomenclatura of the Bureaucracy and we all want to get rid of that. Quite true; I'd love to see the government run as a business, where some departments might run out of money 6 months early if they aren't careful. It'd be hard at first, but they'd have to change to survive... >standalone women to make babies to get benefits was very bad. The >Chinese system - less benefits the more children you have - is the >way to go. ++agree (Orwell also contributed other conventions. . .) >>(The point being that people want more than "basic food and shelter," but >>are often unwilling to make the commitments and sacrifices in their lives >>to gain the wherewithal to earn significant salaries.) >This is where we disagree. The real lazy ones are satisfied with a roof >over there heads, a microwave oven for cooking pizza, a six-pack and >a soap opera. Most people really do want to achieve something more in >their lives. How many of them are willing to go pick grapes for below minimum wage, since they've carefully avoided learning anything remotely useful? We have a ton of illegal immigrants who are quite willing to do so. The market is there, so why aren't they working? >>There is a basic error here, one that I see often. Who says that the >>"anarcho-capitalists" will freely give away, say, some vast fraction of >>their profits so as to subsidize the overall society? Any more so than the >Not a vast portion, if the above_basics capitalistic economy blooms. >Probably 10% would suffice - what was once paid to the church, the >institution that traditionally has supported the ill and poor. traditionally *raped* the ill and poor. Nothing wrong with true charity, but do you really think all the gold and art that (for instance) the Vatican acquired, much of it during the dark ages, was from giving contributions to the poor? Most of the time, they were the problem: "Give us money to buy absolution or your loved ones will rot in Hell forever!" # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: Erasing Disks
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Sat, 14 Sep 1996 20:11:45 -0500 (CDT), Douglas R. Floyd wrote: >> >But shredding the floppy? No need to classify that, no secrets leaked >> Burn after shredding, or you have a puzzle fan reassembling the shredded disk. >Actually, taking the cookie portion out, putting it on an inverted cup so >its in the center of the microwave, then letting it cook for 30 seconds >does the job quite well =) I've always been a fan of applying lighter fluid in a fashion similar to the way the allies applied napalm to Dresden. It's more satisfying... <g> # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: SPL -- Suspicious Persons List
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Sat, 14 Sep 96 17:36:49 EDT, Dr.Dimitri Vulis KOTM wrote: >> unjust if the company was bought out and the new owner decided to sack >> all black people and people called "Perry". You were the one who brought >> up the issue of fairness. >The owner should be able to do that without interference from any gubment. Yes. If they manage to survive economically while snubbing a productive chunk of the general population in addition to a loon, good for them. If their product still sells, inspite of negative publicity it's probably the market leader. OTOH, I think there should be some basic safeguards against the formation of 'company towns' or similar constructs. A free market is rarely a given. # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Dealing with junk mail
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ To: cypherpunks ## 09/17/96 09:26 am ## Subject: Dealing with junk mail ] There has been a bunch of stuff in the news lately about junk e-mail, including the recent judge's ruling that AOL must allow known junk-mail through to its subscribers while the judge hears arguments from AOL and the junk-mailers. I'm a little divided on the whole issue of whether or not it's wise policy for ISPs to, in general, refuse to deliver suspected junk mail. The obvious problem is that it puts ISPs in the position of deciding whether or not some piece of e-mail is worthwhile. (To clarify, I certainly *don't* think that ISPs should be prohibited by law from blocking delivery of or access to anything they choose to--there are plenty of ISPs to choose from, and users can move if they don't like their current ISPs' policies. I just don't think I'd like Delphi to start filtering my e-mail without asking me for permission and instructions first.) I've been thinking about an alternative approach to blocking commercial spam. It has some potential technical problems, but I think it could be made into a workable 95% or so filter. Many people are already filtering messages locally, and now some providers are getting into the act, as well. Unfortunately, because of the economics of junk e-mail, I think that this, by itself, will probably lead to people refusing to accept almost all e-mail from people they don't know. This is a really bad outcome. What I'm proposing is an extension to this, in which many peoples' filters coordinate their actions to detect and block spam. Each user has a mail filter with a set of rules written either by or for that user. The mail filter does one of four things with each piece of e-mail it receives: a. It lets the e-mail through immediately. (E-mail from friends, employers, employees, family members, etc. would probably be in this category.) b. It discards the e-mail immediately. (E-mail from people you really didn't like, and from people who have spammed you in the past would probably be in this category.) c. It puts the e-mail on hold in some storage area. d. Send e-mail back to the sender, informing him of conditions under which the user is willing to accept this e-mail. This might be things like requiring anonymous users to provide some minimal kind of identity, or telling senders ``I'll read your e-mail for one dollar in digicash,'' or ``I'll read your e-mail if you carry out this computationally expensive calculation, or some other thing. For e-mail in the third category, some kind of summary report is sometimes generated, to be sent to a server. The server collects these reports, and uses some kind of system (maybe rule-based, but probably involving scores to estimate probability of spam or other unwanted e-mail) to determine what is and is not spam, and with what probability. It then sends to each of its subscribers, every day or so, a report indicating scores for users' messages. (These should be individualized.) The mail filters then do one of four things to each piece of mail rated, based on the scores: a. Pass the message through immediately. b. Discard the message immediately. c. Add the message to a list of low-priority messages, to be read when the user has some spare time. d. Send e-mail back to the sender, informing him of conditions under which the user is willing to accept this e-mail. This might be things like requiring anonymous users to provide some minimal kind of identity, or telling senders ``I'll read your e-mail for one dollar in digicash,'' or ``I'll read your e-mail if you carry out this computationally expensive calculation, or some other thing. The junk e-mailers can try various countermeasures to this. The most obvious are: a. Try to hit people who aren't using a good junk-mail filter. b. Try to make it against the law to use a junk-mail filter. (Perhaps this would be the case only for PSA spams?) c. Try to disguise their e-mail to make it not obviously junk e-mail, and simultaneously to alter each message to avoid detection by the servers, by making changes to each message, timestamp, and claimed sender ID. I think (c) will be somewhat difficult for the junk e-mailers, if the people who run the servers are reasonably clever. The servers should run indexes that find many identical or similar sentences, paragraphs, etc, in messages sent to many people. I think either the junk e-mailers would give up on these filters immediately, or there would be an endless arms race between advertisers and filter servers. There are some potential problems with this approach, though. The servers will be getting a lot of information about what e-mail is coming to each of their users. There will be serious privacy concerns, especially if the filters work after decrypting public-key encrypted messages. (Note that if the user's public key is reasonably long, PK encrypting the message will actually be pretty hard for thousands or millions of messages at a time. Also, there will be various denial-of-service attacks, where I know Alice is getting ready to send Bob some e-mail I don't want him to get, so I intercept Alice's e-mail and forward it to 10,000 other people--thus ensuring that it will be classified as spam. Comments? 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 / kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMj7vzUHx57Ag8goBAQGUbgQAsP62f0HDO4L0cs3DjCh9ppX3IgQUX8l6 W4JtH3WPfaHrzftD4UMGZ3D41kCjvGht/s62dPtq4lzDbqSpSB81oh4RVuyEw/kD CZ4L0q2q6jFkTdnIp2mvP1WNlCTTpw2BBKY5U4tYCcthq8y30YmOGSqpKouK4l9S gCV3Nd6C/Ig= =Dent -----END PGP SIGNATURE-----

2 1

Wealth Tax vs. Capital Gains Tax Reduction
by tcmay＠got.net 17 Dec '03

17 Dec '03

I've been thinking a lot about the prospects of a "wealth tax," or "asset tax," in the U.S. With the stock market averages at record levels (and, hey, Intel has gone up $6 just so far today, to an unheard of $94.5 level), and with increasing fractions of people's overall net worth tied up in equities, bonds, houses, property, etc., it may be that the looters will take a more serious look at taxing people's overall wealth, e.g., the 5% of net worth per year that some countries have. (At the same time, there is also a chance that the tax on capital gains will be greatly reduced or even possibly eliminated, also as some countries such as Japan have already done.) The conundrum is this: so long as stocks, bonds, and other holdings are not taxable while unsold, and so long as large amounts of private pension funds and whatnot are flowing into equities, this wealth is "unreachable" to the government tax collectors. Further, much of this wealth is "locked" by the high marginal tax rates on capital gains (35-40%, depending on which state one lives in, on so-called "tax preference items," etc.) Many people will not sell assets if they have to pay 35-40% to the tax man if they sell, but nothing if they just sit on the asset and watch it go up in value. (Obviously, the assets get sold eventually. But many people will choose to simply not worry about the heavy taxes _this_ year, and delay selling 'til some future date. They may also think the capital gains rates will go down, or may have visions of taking their stock certificates and simply moving to Anguilla :-}.) If this trend continues--more money in equities and investments, and a higher overall valuation (as prices are driven up by more folks getting in, and by other conventional factors)--the government would seem to have two main choices: 1. Start taxing the overall wealth, e.g., 5% per year. 2. Reduce capital gains taxes so that the "locked assets" will at least come to market and generate some income from capital gains, even if at a reduced level. At 6:38 PM 9/17/96, Duncan Frissell wrote: >Note too the recent article in the Economist about how European firms are >raising capital in the UK and the US because it is available there in >private pension savings while European government retirement systems suck >loads of capital out of the system leaving nothing but massive government >debts. The flow of capital into equities is truly astounding. Some fraction of Americans are really preparing themselves well for retirement, emergencies, vacations, etc. Of course, a distressing fraction of Americans have no savings plans to speak of, and will essentially have no money as they age. Needless to say, I despise the idea of a "wealth tax," and I can see various loopholes and workarounds. I'd also expect a lot of folks to simply move out of the country if this were to happen. In the current political climate, I'd say the chance of a wealth tax in the next several years is small. Ditto for a capital gains tax rate reduction. As with selling assets, "doing nothing" is often the likeliest path. --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

5 4

DCSB: Putting a Stock Exchange on the Net
by Robert Hettinga 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE-----BY SAFEMAIL----- The Digital Commerce Society of Boston Presents Philippe Le Roux Associe de V(DL)2 Inc. "Putting a Stock Exchange on the Net" Tuesday, October 1, 1996 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Philippe would like to talk about putting the Montreal Stock Exchange on the Web - building the Net strategy, the implementation, the management tools, and the impacts on the organization. If we can get a connection and digital projector, he'll demo the project. <If we can't, he'll just *talk* about it. ;-), -RAH> Philippe Le Roux has worked for more than 15 years implementing new technologies and analizing their socio-economic impact. Extensively involved in the launching of Minitel in France and then Alex in Quebec, he has worked with many groups involved with the Internet and On-Line Services. For more than 10 years he's been giving conferences on telematique and information highways in Europe, North and South America. He is the North American correspondent for Planete Internet (France) and regularly publishes articles in France, Quebec and the U.S. He is co-author with Carol Baroudi and John Levine of Internet Secrets (IDG Books 1995), and, under the direction of Pierre Musso and Jean Zeitoun, the book Le Metafort D'Aubervillers (Editions Charles Le Bouil (France) 1995). This meeting of the Digital Commerce Society of Boston will be held on Tuesday, October 1, 1996 from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, One Federal Street. The price for lunch is $27.50. This price includes lunch, room rental, and the speaker's lunch. ;-). The Harvard Club *does* have dress code: jackets and ties for men, and "appropriate business attire" for women. We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, September 28, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston". If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Planned speakers for DCSB are: November Philip S. Corwin Regulatory Barriers to Internet Commerce December "Black Unicorn" Money Laundering: The Headless Horseman of the Infocalypse January TBA 1996 in Review / Predictions for 1997 We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, rah(a)shipwright.com . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to majordomo(a)ai.mit.edu . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to majordomo(a)ai.mit.edu . Looking forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE-----BY SAFEMAIL----- Version: 1.0, engine e19 iQCVAwUBMj79w/gyLN8bw6ZVAQGXkgQAi0nFz95uK6rBGSCvsP8hAvcolHKbRrFw dwOmt97TxvWTYgEczZQiEFwS+WFgo6yGkQGO8jkmYWDKIuyf/JLGr46YaH5GH/rS pKrWzgWnhRjX1vqesRrurcS3KuCK6EStZWLwJeRZzPc+s0fp0nv5p8mK2KaHxtRD 0eL3obNyUUk= =HTUA -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "'Bart Bucks' are not legal tender." -- Punishment, 100 times on a chalkboard, for Bart Simpson The e$ Home Page: http://www.vmeng.com/rah/

1 0

Electronic cash, not letter boxes, stupid (darkside) hackers
by Declan McCullagh 17 Dec '03

17 Dec '03

9/16/96 HAMBURG, Germany (Reuter) - A German student who used the Internet for long-distance theft of computer data from a U.S. company was arrested and charged with extortion for demanding ransom for the return of the data, police said Monday. The student, from the city of Muenster in northern Germany, sent the ransom letter through electronic mail (e-mail), demanding that the firm pay $30,000 to a letter box in a Hamburg post office. Police declined to identify the company. A police spokesman said the student and two accomplices had illegally logged into its computers and stolen the data. Police said they were waiting at the letter box and detained a 19-year-old, who later led them to the 26-year-old ringleader.

1 0

Snakeoil FAQ edit/comments
by gee 17 Dec '03

17 Dec '03

Matt: Thanks, and good work. My comments are indicated by [your text] in brackets, my comments >>> set off by >>>'s. To help separate, look for "-----------------------------" --------------------------- snake-oil-faq ---------------------------- Snake-Oil Warning Signs Encryption Software to Avoid $Id: snake-oil-faq.html,v 0.4 1996/09/16 13:52:26 cmcurtin Exp $ Distribution Please do not distribute this beyond the circles of cryptographic competence yet. This is an incomplete work-in-progress. Feedback is greatly appreciated. The Snake Oil FAQ is (to be) posted monthly to cypherpunks, sci.crypt, alt.security, comp.security, and comp.infosystems. We're targeting those who have influence over or direct involvement in the purchasing decisions of computer security software and equipment in the corporate and academic worlds, as well as individual users who wish to assert their privacy through the use of good cryptography. ----------------------------- >>> I wonder what a good assumption is about level-of-expertise. I should think rather low, since a more experienced person will not be in as much need of the doc in the first place. Think moderately-informed user: like the readers of InfoWorld, eh? Given that, there are several places where knowledge of the subject is assumed that the real consumer of the FAQ doesn't have. ----------------------------- Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves, based on our own experiences, etc., etc., etc. This is a general guideline, and as such, cannot be the sole metric by which a security product is rated, since there can be exceptions to any of these rules. ----------------------------- >>> Actually, I think there are some rules in here that there are no exceptions to. Check; nothing comes immediately to mind tho. ----------------------------- ----------------------------- [(But if you're looking at something that sounds familiar on several of the 'things to watch out for,' you're probably dealing with snake oil. ] >>> But if many of the items on the "Things to look out for" list seem to apply to a product, the product is very likely weak. ----------------------------- ----------------------------- >From time to time, a reputable and decent vendor will produce something that is actually quite good, but will use some [braindead] marketing technique, so be aware of exceptions. >>> "Braindead", eh, hmmmmm. Too dignified ;)----------------------------- Every effort has been made to produce an accurate and useful document, but the information contained herein is completely without warranty. If you find any errors, or wish to otherwise contribute, please contact the document keeper, C Matthew Curtin <cmcurtin(a)research.megasoft.com> Introduction Good cryptography is an excellent and necessary tool for almost anyone. However, there is a multitude of products around. Many good cryptographic products are available, both commercial (including shareware) and free. However, there are also some extremely bad cryptographic products (known in the field as "Snake Oil"), which not only fail do their job of providing security, but are based on, and add to, the many misconceptions and misunderstandings surrounding cryptography and security. ----------------------------- >>> They also prey on the inexperience of the consumer, rely on the mystery and mystique of mathmatical-sounding jargon, to make poorly engineered products seem to be something they are not. ----------------------------- Superficially, it is difficult for someone to distinguish the output of a secure encryption utility from snake oil: both look garbled. The purpose of this document is >>> to <<< present some obvious "red flags" [so that] >>> which <<< people unfamiliar with the nuts and bolts of cryptography can use as a guideline for determining whether they're dealing with snake oil or the Real Thing. For a variety of reasons, this document is general in scope and does not mention specific products or algorithms as being "good" or "Snake Oil". When evaluating any product, be sure to understand what your needs are. For data security products, what do you need protected? Do you want an archiver that [supports strong encryption? ] ----------------------------- >>> Problem: what is "Strong Encryption" ??? From a user's point of view this term is too fuzzy. Try: "that will keep data secure from your kid sister? A rogue government? For 5 minutes? Etc. etc. " ----------------------------- ----------------------------- [An E-mail client? Something that will encrypt on-line communications? Do you want to encrypt an entire disk or partition, or selectively some files? Do you need on-the-fly (automatic) encryption and decryption, or are you willing to select when and which files you want encrypted? ] >>> I'd leave that out: not pertinent to snake-oil vs. Good Stuff, but is about the kind of application user requires. How secure is "secure enough?" Does the data need to be unreadable by third parties for 5 minutes? One year? 50 years? 100 years? >>> see above. ----------------------------- ----------------------------- [Different products will serve different needs, and it's rare that a product will serve every need. (Sometimes a product won't be needed: it may be better to use a utility to encrypt files, transmit them over a network using standard file transfer tools, and decrypt them at the other end than to use a separate encrypted utility in some cases.)] >>> I don't understand: "sometimes a product won't be needed?" I think this paragraph could be left out. After all, OS utility or Snoop-Dooper-Doggy-Doo-Ware product, ya still gotta know what you're doing, right? So you everthing in the FAQ still applies; or maybe I'm missing the point here. ----------------------------- Some basics The cryptography-faq (found at ftp://rtfm.mit.edu/pub/usenet/cryptography-faq/) is a more general tutorial of cryptography, and should also be consulted. In an effort to make this FAQ more complete, some very basic topics are included below. Conventional vs. Public Key Cryptography ----------------------------- There are two basic types of cryptosystems: symmetric (also known as "conventional," [sometimes also called] >>> or <<< "private key") and asymmetric (public key). Symmetric ciphers require both the sender and the recipient to have the same key. That key is [applied] >>> used by the cryptographic algorithm <<<to encrypt the data >>> originated <<< by the sender, and again by the recipient to decrypt the data. Asymmetric ciphers are much more flexible, from a key management perspective. Each user has a pair of keys: a public key and a private key. The public key is shared widely, given to everyone, while the private key is kept secret. If Alice wishes to mail Bob some secrets, she simply gets Bob's public key, encrypts her message with it, and sends it off to Bob. When Bob gets the message, he uses is private key to decrypt the message. Asymmetric [cryptosystems] >>>algorithms<<< are much slower than [their symmetric counterparts.] >>> symmetric algorithms, and are almost exclusively used to encrypt short "session keys," which are then used to encrypt a message using the speedier symmetric algorithms. This use of public key cryptography is called "key exchange." ----------------------------- ----------------------------- [Also, key sizes must be much larger.] >>>I agree with one comment that discouraged comparing the 2 algo types.----------------------------- See the cryptography FAQ for a more detailed discussion of [the topic.] >>>these topics.<<< Key Sizes ----------------------------- Some ciphers, while currently secure against most attacks, are not considered viable in the next few years because of relatively small keysizes and increasing processor speeds [(making a brute-force attacks feasible).] >>> Again, I maintain that the audience for this stuff can't be relied upon to even know what that means. Try: "which makes the cipher vulnerable to breaking by trying every possible key combination (called a brute-force attack)." --- or something like that. ----------------------------- The tables below should give some general guidelines for making intelligent decisions about the key length you need. If the key is too short, the system will be easily broken, even if the cipher is a good one. In [1] and [2], we're presented with some guidelines for deciding appropriate key length. (It is important to note that this is based on the ability to predict computing power 40, 65, and 100 years from now. Major breakthroughs in computing power 30 years from now might render everything on this chart kiddieplay.) Security Requirements for Different Information Type of Traffic Lifetime Minimum [Symmetric] Key Length Tactical military information minutes/hours 56-64 bits Product announcements, mergers, interest rates days/weeks 64 bits Long-term business plans years 64 bits Trade secrets (e.g., recipe for Coca-Cola) decades 112 bits H-bomb secrets >40 years 128 bits Identities of spies >50 years 128 bits Personal affairs >50 years 128 bits Diplomatic embarrassments >65 years at least 128 bits U.S. Census data 100 years at least 128 bits ----------------------------- >>> Where is the attribution for the table?----------------------------- As mentioned earlier, asymmetric ciphers require significantly longer keys to provide the same level of security as their symmetric cipher counterparts. Here is a comparison table, again, from Applied Cryptography, second edition. Symmetric and Public-Key Lengths With Similar Resistance to Brute-Force Attacks Symmetric Key Length Public-key Key Length 56 bits 384 bits 64 bits 512 bits 80 bits 768 bits 112 bits 1792 bits 128 bits 2304 bits ----------------------------- >>> BEWARE, Danger: comparing public/private key cryptosystems again. I think if you really want to do so, then the comparison should really be explained. ----------------------------- Some Common Snake-Oil Warning Signs The following are some of the "red flags" one should watch for when examining an encryption product * Technobabble The vendor's description of the product may contain a lot of hard-to-follow use of technical terms to describe how the product works. If this appears to be confusing nonsense, it may very well be (even to someone familiar with the terminology). Technobabble is a good means of confusing a potential user and masking the fact that the vendor doesn't understand anything either. A sign of technobabble is a descrption which drops a lot of technical terms for how the system works without actually explaining how it works. Often specifically coined terms are used to describe the scheme which are not found in the literature. * New Type of Cryptography? Beware of any vendor who claims to have invented a "new type of cryptography" or a "revolutionary breakthrough". Truly "new break-throughs" are likely to show up in the >>> scientific <<< literature, and [many in the field] >>> professionals won't <<< [are unlikely to] trust them until after years of analysis, by which time they are not so new anymore. Avoid software which claims to use 'new paradigms' of computing such as cellular automata, neural nets, genetic algorithms, chaos theory, etc. Just because software uses to different method of computation doesn't make it more secure. ----------------------------- >>> As a matter of fact, these techniques are the subject of ongoing cryptographic research and nobody has published successful results based on their use yet. ----------------------------- Anything that claims to have invented a new [public key] cryptosystem without publishing the details or underlying mathematical principles is highly suspect. Modern cryptography, especially public key systems, is grounded in mathematical theory. The security is based on problems that are believed, if not known to be hard to solve. ----------------------------- >>> There are some other comments in cpunks on this last bit. I defer.----------------------------- The strength of any encryption scheme is only proven by the test of time, >>> involving exhaustive analysis by cryptographers<<<. New crypto is like new pharmaceuticals, not new cars. * Proprietary Algorithms Avoid software which uses "proprietary" or "secret" algorithms. Security through obscurity is not considered a safe means of protecting your data. If the vendor does not feel confident that the method used can withstand years of scrutiny by the [academic] >>> professional and academic cryptographic <<< community, then you should be wary of trusting it. (Note that a vendor who specializes in the cryptography may have a proprietary algorithm which they'll show to others if they sign a non-disclosure agreement. If the vendor is well-reputed in the field, this can be an exception.) ----------------------------- >>> How can you tell a well-reputed vendor? I am thinging of one co. that promises to release their algo. details upon NDA, but at least in my case the details never showed up! This is slippery here! ----------------------------- Beware of specially modified versions of well-known algorithms. This may intentionally or unintentionally weaken the cipher. The use of a trusted algorithm, >>> availability of <<< [if not with] technical notes explaining the implementation ([if not availability of] >>> and preferably <<< the source code for the product) are a sign of good faith on the part of the vendor that you can take apart and test the implementation yourself. A common excuse for not disclosing how a program works is that "hackers might try to crack the program's security." While this may be a valid concern, it should be noted that such 'hackers' can reverse engineer the program to see how it works anyway. If the program is implemented properly and the algorithm is secure, this is not a problem. (If a hypothetical 'hacker' was able to get access you your system, access to encrypted data might be the least of your problems.) ----------------------------- >>> Add: The strength of a cryptosystem should depend ONLY on the security of the keys involved, and not the security of the algorithm. ----------------------------- * Experienced Security Experts and Rave Reviews Beware of any product claiming that "experienced security experts" have analyzed it, but it won't say who (especially if the scheme has not been published in a reputable journal). Don't rely on reviews in newspapers, magazines or television shows, since they generally don't have cryptologists (celebrity hackers who know about telephone systems don't count) take the software apart for them. Just because the vendor is a well known company or the algorithm is patented doesn't make it secure either. * Unbreakability Some vendors will claim their software is "unbreakable". This is marketing hype, and a common sign of snake-oil. Avoid any vendor that makes unrealistic claims. ----------------------------- >>> The reader is not qualified to evaluate realistic/unrealistic.----------------------------- No algorithm is unbreakable. Even the best algorithms are breakable using "brute force" (trying every possible key), but if the key size is large enough, this is impractical even with vast amounts of computing power. One-time pads are unbreakable, but they must be implemented perfectly, which is, at best, very difficult. See the next section for a more detailed discussion. ----------------------------- >>> Add: Avoid products that use huge numbers to impress you that it would take massive amounts of time to break them. This is ONLY true under the assumption that the only way to break the system is by exhaustively trying every possible key, and this assumption hass to be proved before the claim is valid. A cryptosystem using a keylength of 50,000 bits theoretically would take 2 raised to the 50,000th power to break (a ridiculously large number) if, AND ONLY IF the algorithm had no weaknesses. The hard part of cryptosystem design is making an algorithm with no weaknesses, such that exhaustive brute-force search is the only method of breaking it, not using long keys. ----------------------------- * One-Time-Pads A vendor might claim the system uses a one-time-pad (OTP), which is theoretically unbreakable. That is, snake-oil sellers will try to capitalize on the known strength of a OTP. It is important to understand that any variation in the implementation means that it is not an OTP, and has nowhere near the security of an OTP. A OTP system is not an algorithm. It works by having a "pad" of random bits in the possession of both the sender and recipient. ----------------------------- >>> Explain what you mean by a "pad" --- using a term which to the newbie may not usually be associated with crypto. Origin being the pads of paper that they used to use etc.etc. ??? ----------------------------- ----------------------------- The message is encrypted using [the next n bits in the pad as they key, where n is the number of bits in the message] >>> as many bits from the key as there are bits in the message. That is, for each bit in the message, there is a random bit from the one-time-pad.<<< ----------------------------- After the bits are used from the pad, they're destroyed, and can never again be used. The bits in the pad must be truly random, generated using a real random source, such as specialized hardware, radioactive decay timings, etc., and not from an algorithm or cipher. Anything else is not a one-time-pad. The vendor may confuse random session keys or initialization vectors with OTPs. * Algorithm or product XXX is insecure Be wary of anything that makes claims that particular algorithms or other products are insecure without backing up those claims (or at least citing references to them). Sometimes attacks are theoretical or impractical (requiring special circumstances or massive computing power running for many years), and it's easy to confuse a layman by mentioning these. * Keys and Passwords The "key" and the "password" are often not the same thing. The "key" generally refers to the actual data used by the cipher, while the "password" refers to the word or phrase the user types in, which the software converts into the key (usually through a process called "hashing" or "key initialization"). >>> Other comments addressed this paragraph. I defer. The reason this is done is because the characters a user is likely to type in do not cover the full range of possible characters. (Such keys would be more redundant and easier for an attacker to guess.) By hashing a key can be made from an arbitrary password that covers the full range of possible keys. It also allows one to use longer words, or phrases and whole sentences as a "passphrase", which is more secure. Anything that restricts users' passwords to something like 10 or 16 or even 32 characters is foolish. If the actual "password" is the cipher's key (rather than hashing it into a key, as explained above), avoid it. If the vendor confuses the distinctions between bits, bytes and characters when discussing the key, avoid this product. Convenience is nice, but be wary of anything that sounds too easy to use. ----------------------------- >>> Instead, try: be wary of any product that overly emphasizes ease-of-use without due attention to its cryptographic strength. ----------------------------- Avoid anything that lets anyone with your copy of the software to access files, data, etc. without having to use some sort of key or passphrase. Avoid anything that doesn't let you generate your own keys (ie, the vendor sends you a key in the mail, or it's embedded in the copy of the software you buy). Avoid anything by a vendor who does not seem to understand the difference between public-key (asymmetric) cryptography and private-key (symmetric) cryptography. * Lost keys and passwords If there's a third-party utility that can crack the software, avoid it. >>> Which - the utility or the crypto? If the vendor claims it can recover lost passwords (without using a key-backup or escrow feature), avoid it. If there is a key-backup or escrow feature, are you in control of the backup, or does the vendor or someone else hold a copy of the key? * Exportable from the USA If the software is made in North America, can it be exported? If the answer is yes, chances are it's not very strong. Strong cryptography is considered munitions in terms of export from the United States, and requires approval from the State Department. Chances are if the software is exportable, the algorithm is weak or it is crackable (hence it was approved for export). If the vendor is unaware of export restrictions, avoid the software: the vendor is not familiar with the state of the art. Because of export restrictions, some legitimate (not-Snake Oil) products may have a freely exportable version for outside of the USA, which is different from a separate US/Canada-only distribution. Also note that just because software has made it outside of North America does not mean that it is exportable: sometimes a utility will be illegally exported and posted on an overseas site. Other Considerations Interface isn't everything: user-friendliness is an important factor, but if the product isn't secure then you're better off with something that is secure (if not as easy to use). No product is secure if it's not used properly. You can be the weakest link in the chain if you use a product carelessly. Do not trust any product to be foolproof, and be wary any product that claims it is. Contributors The following folks have contributed to this FAQ. Jeremey Barrett <jeremey(a)forequest.com> ----------------------------- >>> OK, you can use my RealName:Gregg Weissman <geeman(a)best.com> <<< ----------------------------- Jim Ray <liberty(a)gate.net> Robert Rothenburg Walking-Owl <wlkngowl(a)unix.asb.com> References 1. B. Schneier, Applied Cryptography, second edition, John Wiley & Sons, 1996 2. M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E. Thompson, M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security," available via ftp://ftp.research.att.com/dist/mab/keylength.ps ---------------------------------------------------------------------------- C Matthew Curtin Last modified: Mon Sep 16 09:51:41 EDT ---------------------------------------------------------------------- -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin(a)research.megasoft.com http://research.megasoft.com/people/cmcurtin/

1 0

Re: 56 kbps modems
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Sun, 15 Sep 1996 01:31:19 -0700, Bill Stewart wrote: >and still get the original 56kbps back out. But if they can, well, >yee-hah, ISDN is nearly dead :-) (Not totally dead; the signalling is >still useful for some applications, the convenience of two channels on >one wire pair is nice, and the fact that people can get 56kbps without Also, can't you add ISDN b-channels ? (I.e. get another 64kps channel) >the phone company's help will pressure them into offering ISDN for >a lower price in areas where the Phone Company's idea of "all the market >will bear" is substantially higher than voice pricing.) ISDN is more elegant; this sounds like a 'kludge' of sorts. OTOH, we've all seen how well a cheap kludge can do, right? # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # cadams(a)acucobol.com | V.M. (619)515-4894 "I have never been able to figure out why anyone would want to play games on a computer in any case when the whole system is a game. Word processing, spreadsheets, telecoms -- it's all a game. And they pay you to play it." -- Duncan Frissell

1 0

Re: Diffie Hellman - logs in Galois fields
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> I think polluting this mailing list with trivial questions such as this is > just as bad as polluting it with personal attacks. Read the FAQs. Get a fucking life, seeing as you haven`t yet posted anything relating remotely to the technical aspects of cryptography to this list I think you need to take a long hard look at what your saying loser.... Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Http://www.fatmans.demon.co.uk/crypt/ "Don`t forget to mount a scratch monkey" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53 6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3 sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/ 9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90 En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2 YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi mUqFH41Z7NkyO8ZFdi5GGX0= =CMZA -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: Assassination Politics, was Kiddie porn on the Internet
by azur＠netcom.com 17 Dec '03

17 Dec '03

>On Mon, 16 Sep 1996, Steve Schear wrote: > >> Someone wrote: > >> >The problem is that assasination rarely leads to the installation of >> >a government that is any better. In most cases it gets worse. > >[...] > >> We've all heard these arguments, but are they true? Who says so, and how >> can they be certain? Jim's suggestion has never, to my knowledge, been >> tried on a consistant, large, scale. When all conventional alternatives >> have been tried and fail, what have we or the starving children got to >> lose? > >I think "Lord of the Flies" answers this question quite well. Does it? LOTF was fiction. Can you identify a recent instance in which a non-governmental organization attempted to influence political/military events via a concerted AP? > >> Is it legal for citizens of the U.S. to engage in contract killing of >> foreign military, politations, etc? How about U.S. or foreign non-profits? > >As to the first, yes. (There are several anti-mercenary statutes on the >books) As to the second, I don't understand the question. > So, you're saying it is legal for citizens? The second question was whether a non-profit org. could raise tax-deductible funds to conduct such operations. PGP Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 --------------------------------------------------------------------- Snoop Daty Data | Internet: azur(a)netcom.com Grinder | Voice: 1-702-655-2877 Sacred Cow Meat Co. | Fax: 1-702-658-2673 7075 W. Gowan Road, #2148 | Las Vegas, NV 89129 | --------------------------------------------------------------------- Just say NO to perscription DRUGS.

2 1