- cypherpunks-legacy - lists.cpunks.org

Creating commercial acceptability for remailers?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

How can we convince _lots_ of people to run remailers, assuming it can be made technically painless? How can we spread remailer-operations beyond the cypherpunks and fellow travellers and the privacy/paranoia businesses like tax reduction and pharmaceutical retailers? Suppose you were in the "Get Connected To The Net" consulting business, and you wanted to include a remailer in the outside-the-firewall part of the mail handler - how would you get companies to accept it? What kinds of other businesses could benefit from providing anonymous service? Some ideas for non-mundane businesses - - Shrinks-r-us or other on-line recovery groups, beyond the current use in a.s.a.r.? - Tax advice - one-shot anonymous returns so you can ask questions from the IRS or whatever without much risk of audit? - Anonymous tips (the D.A.R.E. hotline?) Arrrgh. - Whistleblowers.com? (Who'd trust whistleblowers.gov?) - For one-way anonymity, perhaps MTV could run an "email from Beavis" server, letting you send rude comments to your friends. Digitally signed, with optional MIME noises! Sending mail through it might put your address in an email junk-mail marketing list, but without tying it to the outgoing message? But what about mundane businesses? I've seen suggestion boxes operated with minimalist anonymization for internal use (no attempt to obscure the time or prevent logging, just header-zapping.) University ombudsman's offices could be a good approach, and might help get around the occasional reactive sysadmins. But that's inside the firewall, though I suppose you could use them for outgoing mail as well. Another use for inside-to-outside remailers is to preserve the privacy of internal addresses, though that's more likely to need a service which replaces the originating headers with the real user's name, using some authentication to prevent forged email from the company president, etc. Any suggestions on getting companies to accept outside-to-outside-capable remailers on their gateways, or outside-to-inside? Anonymity is cool, heh,heh.. Beavis

1 0

Mixmaster supports PGP
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just wanted to officially announce the Mixmaster supports pgp encrypted messages. I also want to plug using it as a second generation remailer (that is why I wrote it). If you use a sun (that means you netcom folks), get the front end from my home page. Raph, please change the "mix" entry in your list to reflect pgp support. Here is the Key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy8y6PAAAAEEAJF05HUUQM4n9G5wHOZ+bHZbF6yFmeX5wBGElssHqUnbb4PQ S/f8jWvJyfiZkjlOkzOEJ47fZ++x+yYWgzKGUKp2ejIKu2MvnzgLfIkwKfxioPXq xgBpLcFaDrbM52Mi4MEpEYW4DJqxk9TrAnHZBwXmxpOZQ57UcgbmF1BLzawNAAUR tC5NaXhtYXN0ZXIgUmVtYWlsZXIgPG1peG1hc3RlckBuYXRlbHkudWNzZC5lZHU+ iQCVAwUQLzLpflVkk3dax7hlAQH2GQP9FGBU7uGako4YghrUNzyb3tcdwZwsGkBx Gy9MGojOSwWgXQ0CRLD9+IWgkZnRY902pU65C3IZhFB7erXBk5eyGOXhbahHv07o mhHRiE2v4Z9hNapWVHHeDo0F2AoL7B8kkiFjXI2fVYzofB6gmXd7X8Wzh/9AEQsz 63U8X9cbajyJAJUDBRAvMulXBuYXUEvNrA0BAQOkA/9QfgNGLp6MX1Qwk55uLiHG ajeT+Rtgruaj9DPOoZFVj9w0pImBkCQNw5eA6iZTgiAqkbSG7RaR9yKMU27Gf/O+ yz3cWAx4slFmCpVDlEl5qSa1Bd+2LuneN4EvnxfeI7TLUIFKlPcIOnx9zsu5Ny0I SCtHVHBaGw43OT1OYmLjgA== =Zr4D - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzXU7lVkk3dax7hlAQHsrgP9G0NyW4RDvWOXa5BiWnr9gk6+Yq0bW0v8 gXZcn3tyzy3VAarmk09JLZOCnIADP9/zZXVEhJsXGDH/2O2j8IzBCCewCv9DnFcq VnGtzwTHUdeLROSiOZYgwvhdtUgLdhB76c0akJhlNcVv7xMVEPRMqGtSMC/BPbTd d9xUaQz/ibk= =/0EA -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: The SKRONK protocols (version 0.6)
by strick -- henry strickland 17 Dec '03

17 Dec '03

THUS SPAKE Network Security Observations <NSO(a)delphi.com>: # Henry, # I would like to publish the working doc. in the next available issue Go ahead; I place the document in the public domain. # of Internet Security Monthly. Obviously with a request to respond. It would be kind if you sent me a copy of the issues that discuss it. I'm not familiar with the journal. If it's on paper, ask for my USPS address. # Do you have any further material that you prefer to go along with it ? Nope, that says what I have to say right now. The followup discussion on Cypherpunks has been helpful to me; the punks mostly made good points and correct observations. best regards, strick

1 0

Remailer msgs ideath -> rebma don't work.
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Remailer messages sent via remailer(a)ideath.goldenbear.com to remailer(a)rebma.mn.org are failing; the system which handles my mail upstream can't seem to connect to rebma. I'm going to try to get things ironed out, but until then the ideath -> rebma path should be avoided. Sorry for any inconvenience; the bounced messages have been discarded. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzXb4X3YhjZY3fMNAQErKgP+ND8r1sqXs3PXv87rL8IGTJ8j7FB4gmXI YwDC3jNWHdOimVoK0zJS8utCAk9VlUDW7azXjBuXs+1qpMiygG9Nr7Up8iGaejM4 sV8906vU/+Hq+Dvd/fZn1tkfL7dB8qKUMpi7aNFz0YbadCvE79MYzLBuzUVKCJTm j17jVq6tpX4= =C3mW -----END PGP SIGNATURE-----

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.30.tar.gz For the PGP public keys of the remailers, as well as some help on how to use them, finger remailer.help.all(a)204.95.228.28 This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"vox"} = "<remail(a)vox.xs4all.nl> cpunk pgp. post"; $remailer{"avox"} = "<anon(a)vox.hacktic.nl> cpunk pgp post"; $remailer{"extropia"} = "<remail(a)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"rebma"} = "<remailer(a)rebma.mn.org> cpunk pgp hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash"; $remailer{"soda"} = "<remailer(a)csua.berkeley.edu> eric post"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub"; $remailer{"usura"} = "<usura(a)replay.com> cpunk pgp. hash latent cut post"; $remailer{"desert"} = "<remail(a)desert.xs4all.nl> cpunk pgp. post"; $remailer{"nately"} = "<remailer(a)nately.ucsd.edu> cpunk pgp hash latent cut"; $remailer{"myriad"} = "<remailer(a)myriad.pc.cc.cmu.edu> cpunk pgp hash latent cut ek"; $remailer{"xs4all"} = "<remailer(a)xs4all.nl> cpunk pgp hash latent cut post ek"; $remailer{"flame"} = "<tomaz(a)flame.sinet.org> cpunk pgp hash latent cut post ek"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash"; $remailer{"mix"} = "<mixmaster(a)nately.ucsd.edu> cpunk hash latent cut ek"; $remailer{"q"} = "<q(a)c2.org> cpunk pgp hash latent cut ek"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp"; $remailer{"tower"} = "<remailer(a)tower.techwood.org> cpunk pgp"; $remailer{"eniac"} = "<vanklava(a)eniac.ac.siue.edu> cpunk pgp hash latent cut"; $remailer{"charon"} = "<charon(a)styx.jpunix.com> cpunk hash latent cut ek"; $remailer{"bonafide"} = "<remailer(a)bonafide.jpunix.com> cpunk hash latent cut ek"; $remailer{"ford"} = "<ford(a)prefect.jpunix.com> cpunk hash latent cut ek"; $remailer{"aegis"} = "<aegis(a)athena.jpunix.com> cpunk"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. JPUNIX.COM offers a domain hiding service for remailers. Send email to perry(a)jpunix.com for more information. NOTE: JPUNIX.COM itself does not run a remailer. All subdomains of jpunix.com on this list are remailers that are not physically located on jpunix.com Use "premail -getkeys remailer.help.all(a)204.95.228.28" as a stopgap to get PGP keys for the remailer, at least until Matt Ghio gets his machine situation straightened out. Fingering this address works too. Last ping: Mon 6 Feb 95 6:00:01 PST remailer email address history latency uptime ----------------------------------------------------------------------- rahul homer(a)rahul.net -*+****#-*+# 19:19 99.88% alumni hal(a)alumni.caltech.edu +****-*##* # 9:02 99.87% eniac vanklava(a)eniac.ac.siue.edu #***+#***# 6:06 99.88% penet anon(a)anon.penet.fi *+**+*+++-+* 1:40:22 99.99% tower remailer(a)tower.techwood.org *********# 7:38 99.88% mix mixmaster(a)nately.ucsd.edu --*-++++++++ 43:06 99.85% nately remailer(a)nately.ucsd.edu --++++++++++ 41:00 99.85% portal hfinney(a)shell.portal.com +***#-*##* # 6:53 99.85% xs4all remailer(a)xs4all.nl **-*+++**+** 16:46 99.75% charon charon(a)styx.jpunix.com #-++-* 26:06 99.78% bonafide remailer(a)bonafide.jpunix.com ##**** 6:39 99.68% ford ford(a)prefect.jpunix.com ++-+++ 27:13 99.67% soda remailer(a)csua.berkeley.edu .--.._..... 9:02:42 99.56% myriad remailer(a)myriad.pc.cc.cmu.edu +***-****** 37:47 99.37% vox remail(a)vox.xs4all.nl ...---..-- 22:10:50 99.51% usura usura(a)replay.com *+-****+ *** 15:05 98.98% aegis aegis(a)athena.jpunix.com 15:55 99.07% c2 remail(a)c2.org +++ - ++-+++ 1:44:28 97.95% syrinx syrinx(a)c2.org *** +++-* 30:09 97.85% q q(a)c2.org --+--+++-++ 1:13:16 97.75% flame tomaz(a)flame.sinet.org +***-****** 59:14 97.51% bsu-cs nowhere(a)bsu-cs.bsu.edu ***+ *--**-* 1:38:08 96.72% ideath remailer(a)ideath.goldenbear.com --------- -- 2:04:17 95.12% desert remail(a)desert.xs4all.nl .-___.-_.- 48:16:44 68.02% rebma remailer(a)rebma.mn.org _.-_--- 21:10:27 41.53% extropia remail(a)extropia.wimsey.com 5:04:09 6.34% For more info: http://www.cs.berkeley.edu/~raph/remailer-list.html History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). Options and features cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. oldpgp Remailer does not like messages encoded with MIT PGP 2.6. Other versions of PGP, including 2.3a and 2.6ui, work fine. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. special Accepts only pgp encrypted messages. ek Encrypt responses in relpy blocks using Encrypt-Key: header. Raph Levien

1 0

CFP'95 Program/Registration Information (fwd)
by Michael Froomkin 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Sun, 05 Feb 1995 12:43:36 -0500 From: Carey Heckman <ceh(a)leland.Stanford.EDU> To: Multiple recipients of list <cyberia-l(a)birds.wm.edu> Subject: CFP'95 Program/Registration Information The Fifth Conference on Computers, Freedom and Privacy Sponsored by: * ACM SIGCOMM, SIGCAS, SIGSAC, and * Stanford Law School 28 - 31 March 1995 San Francisco Airport Marriott Hotel Burlingame, California CONNECT WITH OTHERS WHO ARE DETERMINING HOW COMPUTERS AND TELECOMMUNICATIONS WILL AFFECT YOUR FREEDOM AND PRIVACY... JOIN US AT CFP'95. We have reached the crossroads of the Information Age. No longer is the electronic frontier inhabited solely by a small band of technical pioneers sharing a common code of conduct. Computer and telecommunications technologies have become part of mainstream living, conversation, and politics. These changes compel us to reexamine the definition of our rights and the processes by which those rights are being defined. The Fifth Conference on Computers, Freedom and Privacy will assemble experts, advocates and interested people from a broad spectrum of disciplines and backgrounds in a balanced public forum to explore and better understand the definition of our rights at this crossroads. Participants will include people from the fields of computer science, law, business, research, information, library science, health, public policy, government, law enforcement, public advocacy, and many others. Featured speakers include: John P. Morgridge, Chairman, Cisco Systems Esther Dyson, Release 1.0/EDVenture Holdings, Inc. Roger W. Wilkins, Professor of History and American Culture at George Mason University and commentator, National Public Radio Margaret Jane Radin, Professor of Law, Stanford University Willis H. Ware, RAND Some of the topics in the CFP'95 program include: FREEDOM AND RESPONSIBILITY OF ELECTRONIC SPEECH -- Exploring recent controversies in online free speech, including a Socratic forum that will ask whether the Constitution can indeed be viewed through a technologically transparent lens. HIS MASTER'S VOICE... -- Probing the future for "net propaganda" from governments, government officials, and politicians, and who will pay so whose message will get to whom. STUDENT DATABASES: FOR EDUCATION AND FOR LIFE? -- Looking at how gaining the benefits of nationwide information about K-12 students could also spell serious privacy problems. CAN THE NET SURVIVE COPYRIGHT? CAN COPYRIGHT SURVIVE THE NET? -- Delving into the controversies surrounding copyright protection that throttles freedoms and copyright protection that protects just rewards for creativity. INTELLIGENT TRANSPORTATION SYSTEMS: PAVING OVER PRIVACY -- Examining the privacy implications of tracking and surveillance technologies now being planned for vehicles and roadways nationwide. "IT OUGHTA BE A CRIME..." -- Debating with law enforcement representatives about who should set the rules for governing the net and when should bad manners become a crime. WHEN DO THEY NEED TO KNOW 'WHODUNNIT'? -- Discussing the right time and places for identified, anonymous, and pseudonymous transactions. TRANSACTION RECORDS IN INTERACTIVE SERVICES: WHO WATCHES THE SERVERS? -- Looking at the issues raised by the collection of personal information as part of the new interactive home entertainment, telecommunications, and online services. DEFINING ACCESS PARADIGMS: LIBRARIES, RURAL AREAS, AND INTERNATIONAL ASPECTS -- Evaluating the differing models of "open access" to Internet and computer-mediated communications in the library, rural, and lesser-developed country contexts. THE CASE AGAINST COMPUTERS: A SYSTEMIC CRITIQUE -- Daring to discuss whether computers may be doing our world more harm than good. A NET FOR ALL: WHERE ARE THE MINORITIES? -- Examining how and to what degree minority groups participate on the net and asking whether social class is relevant to net participation or non-participation. WHO OWNS THE LAW? -- Reviewing the debate over legal citation form and online databases, and what it means to all of us. CAN WE TALK LONG-DISTANCE? REMOVING IMPEDIMENTS TO SECURE INTERNATIONAL COMMUNICATIONS -- Covering export and import controls, outright prohibitions, and other technical and policy obstacles to secure international communications. The Fifth Conference on Computers, Freedom, and Privacy will also offer a number of in-depth tutorials on subjects including: * Inside Washington: The New Congress and Secrets of Advocacy * National ID Card Initiatives * The Law of Fundamental Rights for Non-Lawyers * Everything You Need to Know to Argue About Cryptography * Digital Activism * Inside the World of Law Enforcement * Intellectual Property for the Information Age FOR MORE INFORMATION ABOUT CFP'95: Web: http://www-techlaw.stanford.edu/CFP95.html Gopher: gopher://www-techlaw.stanford.edu/CFP95 FTP: ftp://www-techlaw.stanford.edu/CFP95 Email: Info.CFP95(a)forsythe.stanford.edu Fax: (415) 548-0840 Call: (415) 548-9673 REGISTRATION Please register for the conference by returning the conference registration form along with the appropriate payment by any method listed below. The registration fee includes conference materials, three luncheons (Wednesday, Thursday, and Friday), two banquets (Wednesday and Thursday) and evening receptions (Tuesday, Wednesday, and Thursday). Registration Fees are: If mailed by: February 24 March 14 after 14 March Conference Fees $335 $395 $445 Tutorial Fees: $155 $185 $220 Registration is limited to 550 participants, so register early and save! By Mail: By Fax: (with Check or Credit Card) (with Credit Card only) CFP'95 Registration Send Registration Form P.O. Box 6657 (415) 548-0840 San Mateo, CA 94403 Available 24 hours By Phone: By Email (at your own risk*): (with Credit Card only) (with Credit Card only) (415) 548-0840 Register.CFP95(a)forsythe.stanford.edu 9 am to 5 pm Pacific Time * Information for sending a PGP-encrypted registration available at http://www-techlaw.stanford.edu/CFP95.html and ftp://www-techlaw.stanford.edu/CFP95. CFP'95 Scholarships: The Fifth Conference on Computers, Freedom and Privacy will provide a limited number of full registration scholarships for students and other interested individuals. These scholarships will cover the full costs of registration, including three luncheons, two banquets, and all conference materials. Scholarship recipients will be responsible for their own lodging and travel expenses. Persons wishing to apply for one of these fully-paid registrations should contact CFP'95 Student Paper and Scholarship Chair, Gary Marx at: Gary.Marx(a)colorado.edu or call (303) 492-1697. Hotel Accommodations: The Fifth Conference on Computers, Freedom and Privacy will be held at the San Francisco Airport Marriott Hotel in Burlingame, CA. This facility is spacious and comfortable, and is easily accessible from the airport and surrounding cities. Because of the intensive nature of the conference, we encourage our attendees to secure their lodging at the conference facility. Special conference rates of $99/night, single or multiple occupancy, are available. ************************************************************************* * Our room block is limited and these conference rates are guaranteed * * only until February 17,1995, so we urge you to make your reservations * * as early as possible. * ************************************************************************* After February 17 but before March 15, the special conference rate will be $110/night, single or multiple occupancy. When calling for reservations, please be sure to identify the conference to obtain the conference rate. Hotel Reservations: (415) 692-9100 or (800) 228-9290 or fax (415) 692-8016. Official Airlines: Special convention airfare discounts have been arranged on American and United Airlines. Bungey Travel, (800) 286-4391 or (415) 325-5686 or fax (415) 321- 5309, will be happy to assist you in any manner. Please identify yourself as attending the Computers, Freedom, and Privacy Conference and you will automatically receive a 5% discount off nonrefundable discounted US tickets or 10% off of all unrestricted US coach fares.

1 0

Re: Cooperation
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook(a)bga.com> > I agree that it is to our advantage to minimize the cooperation between > remailers, for the following reasons: > [...] > But there is a major difference between active cooperation and agreeing to > a standard. Active cooperation is just that--something which cannot be > automated, or which involves automated judgement decisions. I claim that > my ideas are merely standards. A standard which might even be extendable > into the dominions of a hostile government. I see your point. I tend to have something of a knee-jerk reaction against proposals which put more responsibility into the hands of the remailer operators, but as you say the mere promulgation of a standard does not in itself require cooperation. We have de-facto standards right now, which is what makes chaining possible. And from the technical point of view, the idea of remailers encrypting between themselves seems to do no harm and could possibly make the attacker's job potentially more difficult by reducing the amount of information he has available. One problem is that one remailer may not know about all of the others. So to the extent that your proposal requires a registry of remailers, a centralized service which keeps track of all remailers, I still have a problem. This is where my vision departs from those who see the "remailer net" as an entity, and for whom the notion that remailers would treat messages to each other specially is a natural assumption. If you would suggest that at each stage the message included not only the address of the next remailer, along with the "payload" which was already encrypted (by the sender) for that remailer, but in addition a key for that remailer and a request to encrypt under that key, then I would feel much better about it. This way there is no need for the remailer to know anything about whom it is sending to. Likewise if we wanted to specify in the standard that messages could be signed, that also would not imply collusion. However to specify that signatures must be checked would have some implications about acquiring the necessary public keys through some means, and I don't think that should be done. I do like the idea of standards. In fact I wonder if the current "mark 1" remailer command set shouldn't be documented as an Internet RFC. It has been in use for a couple of years now, evolving somewhat over that time, and some twenty or thirty remailers have operated for some part of that time following that spec. It would also give a certain amount of (undeserved, perhaps) respectability to remailer operators if there were an actual numbered RFC which they were following. And it does seem to me that this kind of thing is exactly what the RFC's are for. Certainly there are a great many "minor" RFC's which are less followed than our remailer standards. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLzZTfBnMLJtOy9MBAQFsRwIA4A5EzFZwJdEmSvcfMmnu+RCAEGYK56dg y2LBawLdYn5FNcnvH6YkfCMHIcWURm1b6emEsw32FVH2m6ScAAH/iQ== =F2+s -----END PGP SIGNATURE-----

5 5

Re: "encrypt tcp connections" hacks
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >It's certain that IP security will greatly increase the overall >security of the Internet. I'm not advocating its removal but rather >the acknowledgement that higher (and lower) level abstractions will >require their own cryptography. This resolves to a layered quality-of-service issue. Encryption and authentication at the network layer provides an excellent base for improving security, and in and of itself solves a lot of problems like packet payload sniffing, session stealing, etc. But as you so aptly point out, trust boundaries do not coincide with network boundaries. Applications that "ride" on top of TCP and UDP may have their own, very different, threat models. And sniffing the physical layer provides most of what you need for traffic analysis unless some sort of sophisticated packet laundering is used. You pointed this out to me at the last cpunks meeting--each layer in the network model needs to be able to ask for and use security facilities in the lower layer, as well as advertise its security features to the next layer up. Of course, it is perfectly reasonable for me to expect to write an email, encrypt it with PGP and send it via an encrypted SMTP protocol to my mail gateway. On its way, it will ride on top of an encrypted TCP session to port 25, with the physical T1 link between my site and the internet encrypted as well. This is an example of security features present at most of the layers between 1 and 7 of the OSI model. These should remain independent. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov WWW: http://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzad6E1Diok8GKihAQExdAP+LZvM2rbJWf6WwIs2oHPjfWRCyXAQTnYm gpMld86xiJeM5AKudlH2YW+b12lv+9wdH71Fo38FNOdLDX7xDkXQzmkz2creV7sQ GCfrJOAObLro8vwpZ5LVwin0qvmZzH4PO7to2Th3iYGbrXh4zoOdr5GNLU8j+wTd HcV9N6nELxg= =iNH8 -----END PGP SIGNATURE-----

1 0

RE: DNA ink
by Brian D Williams 17 Dec '03

17 Dec '03

>>Lucky Green says: >> At 10:30 PM 2/5/95, Dan Harmon wrote: >>I just saw an item on CNN about a company in LA called Art Guard. >>It sells an ink that is created using your dna as a protection >>against forged signatures. >> >> Why not just sign in blood? >The same occured to me. >Perry Yes, this would work even better! If the ink just contained your DNA, someone could use PCR to duplicate it! If you actually signed in blood, they would have to match the type and if a white blood cell was there they would have to "forge" the mitochondria since they have different DNA! This is not to mention other blood factors. There is prime material here for Klaus! on the the difficulties of running "blood remailers" "anonymous bloodletting," etc..... Brian D Williams Cypherpatriot "Prime material here" heh heh!

1 0

preliminary cypherpunks announcement
by Katy Kislitzin 17 Dec '03

17 Dec '03

hi! we're going to try again to broadcast this saturday's sf bay area cypherpunks meeting. Scheduled time is Feb 11, 1pm - 6pm. Crypto-anarchy will be the order of the day, as usual; will post a real announcement with speakers and topics shortly. Please let me know asap if there are conflicts... --kt Katy Kislitzin Silicon Graphics I/S Network Software ktk(a)corp.sgi.com

1 0