December 2003 - cypherpunks-legacy

Re: Cooperation
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 3:43 PM 02/06/95, Perry E. Metzger wrote: >I'd say that it would work far better if things were changed to MIME >formats. You would send a message by recursively encapsulating your >message to be remailed inside a MIME message. Simple and clean... Well... perhaps for a future remailer standard. I think the purpose of an RFC at this point is to clearly outline how it is that present remailers work, and standardize the working somewhat, and provide a document for people writing new remailers to look at to make sure their remailers work like everyone elses (or are a superset of the "Standard Type 1 Remailer" functions, a superset which certainly could include MIME or anything else). The point is to accurately describe how most remailers work now, rather then propose a major change in the way most remailers work. The latter has a place, but the former seems more pressing, as well as easier to do, and perhaps a first step to the latter. Changing "Request-Remailing-To:" to "Anon-Send-To:" is trivial, in that it would be an incredibly minor code change, and in that some remailers already implement "Anon-Send-To:". But changing everything to MIME would not be so trivial, and if we published a "standard" that said to do it with MIME, we'd end up with a standard that in fact no one follows, that doesn't accurately describe the way things are. The remailers are definitely evolving, and it's been mentioned that it might be a good idea to have a Type 1 Remailer standards document, and a Type 2 Remailer standards document, etc. But it seems of primary importance to first publish a standard of how the remailers _are_ (Type 1 remailer), instead of how we might wish they could be. (Type 1 remailer with MIME, Type 2 remailer, whatever). As for the idea of using MIME headers in itself, I'm a bit concerned that it might make it overly complicated to put together a to-be-remailed message by hand. I'm not entirely familiar with MIME and recursive encapsulation of MIME, so my concern might be ungrounded. But I think it might be a Good Thing that it's easy to remail a message by hand by adding a simple "::\nAnon-Send-To:" at the top, and it would be a mistake to make it more complicated or dificult to do this by hand, unless it's really neccesary for some reason.

1 0

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

a simple explanation of DC-Net
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The DC-Net is not very easy to understand. I'll try to explain the most important parts of the concept as simply as I can. Let's say there are a number of participants in a DC-Net. Each participant shares a different one-time pad with each of several other participants. At most one participant can send one bit through the DC-Net per "round". How does this work? For each round i, a participant takes the i-th bit of all the one-time pads that he has and XORs them together. If he doesn't want to send a bit, he just broadcasts the resulting bit to every other participant. If he DOES want to send a bit, then he broadcasts the XOR of that resulting bit and the bit he wants to send. When everyone has done this, each participant takes all of the bits that has been broadcasted, and XORs them together. This last action produces the output of the DC-Net for the i-th round. Suppose for the first round nobody wants to send a bit. Since each one- time pad is known by 2 participants, the first bit of each pad has been XORed into the final output twice. Since anything XORed by anything twice equals itself, these two XORs cancel each other out. And since nothing else has been XORed into the output, the output must equal 0. If one participant wanted to send a bit, however, then something else HAS been XORed into the output. Since all the bits from the one-time pads cancel out, the output equals the bit he wanted to send. Wei Dai P.S. I realize someone has probably written something like this already, but I hope this explanation helps someone who is still puzzled. If nothing else, it serves as a sanity check on my own understanding. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzbKfTl0sXKgdnV5AQGTpwQAtGe5zl91MgA/ayzBGo/DLXh7NyTDSw00 h/qZZxh2U9HoNFLHMMiHV64PYE8poJlCH8kLDY+XZlv1phoiBtMnc2AehN5XVJmr YCQ77rH9vp6yk6SZ5F7HV/UNIIQj6TkW806OZP7LlgUrXWPZdCSYGPh7n60J4TkD RaspzTgFcUk= =ml6y -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

3 2

Remailer RFC
by Michael Handler 17 Dec '03

17 Dec '03

[ I shouldn't be posting -- I'm legally not supposed to be on the net. But hell... ] I've been compiling and editing a remailer standards document, following the format of the Internet RFCs [mainly because I think it's elegant]. I'd be glad to make it a `formal' RFC, registered with the IETF... But I have no idea how it's done. If anyone out there wants to tell me how... Michael -- Michael Handler <grendel(a)netaxs.com> Civil Liberty Through Complex Mathematics Philadelphia, PA "Toi qui fais au proscrit ce regard calme et haut" -- Baudelaire * Skotoseme PGP Key ID FC031321 Print: 9B DB 9A B0 1B 0D 56 DA 61 6A 57 AD B2 4C 7B AF

1 0

(dis)advantages of DC-Net vs remailers
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- tcmay(a)netcom.com wrote: > Chaumian digital mixes--what you Americans call "remailers"--mainly > solves the sender anonymity problem. Message pools, or broadcast to a > group or site that includes the receiver, mainly deals with receiver > anonymity. The combination of the two deals with both. > > Both are solved elegantly with the Dining Cryptographer's Protocol, > about which much is written on this list every few months. Messages > are "sent" in an Ouija-board fashion and received by the person who > can successfully decrypt a public message sent over the system. I tend to favor remailers + broadcasting + anonymous-return-addresss over the DC-Net protocol. Let me list some of their relative advantages and disadvantages. Please add to these if you can think of more... Advantages of DC-Net over remailers - more flexible trust relationships - you can add your buddies to the set of people who have to be compromised to trace you - lower latency - don't have to wait for remailers to collect enough mail for batches - untracibility need not depend on assumptions about the enemy's computational power Disadvantages of DC-Net - complexity - explaining the core concepts of a remailer takes only a couple of lines, as opposed to a couple of screens for a DC-Net Implementation of a DC-Net seems to be an order of magnitude harder as well. - more vulnerable to denial of service attacks - MUCH higher bandwidth costs I think over the long run the last factor will be most important. In a DC-Net, for each bit one participant wants to send to another, EVERY OTHER participant must broadcast a bit to ALL participants. I can imagine a remailer-net with one million users, but I don't see any possibility that a DC-Net can be scaled to that size. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzboXjl0sXKgdnV5AQEqqAP+JU2sgiESnFZm+CCgNNboXnL3uKg0GP4Z y6NV+U56yGvPKzsi9suUiOpbuzwsYVaMnWIuqRCOaxic75SFsDi0NvjE1K4JgyXz aoyVs1i+xlFKnfmZr1+7EAheUq7wlfSWdp0cnAhbNWSrC3cSuDiNGYciJQLW8GGv 3YUvmW+Xoj0= =Aa+t -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

2 1

RE: Re: lwall
by rparratt＠london.micrognosis.com 17 Dec '03

17 Dec '03

Someone at Berkeley's been a reet tit, haven't they.. -- Richard > ------------------------------- your post follows ---------------------------- > Path: netnet2.netnet.net!news.sprintlink.net!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail > Subject: lwall > Message-ID: <PINE4545-dhfsdkjc(a)ack.berkeley.edu> > NNTP-Posting-Host: ack.berkeley.edu > Organization: cypherpunks > Lines: 2 > From: cypherpunks(a)toad.com > Distribution: world > Newsgroups: alt.test > Date: 6 Feb 1995 19:34:19 GMT > > test > test >

1 0

Re: dna ink
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 6:39 PM 02/06/95, root wrote: >The blood is water soluble and many of the componants breakdown over time. By >injecting DNA (which has lifetimes measured in millions of years) in some kind >of matrix (ie epoxy or cyanoacetates) it becomes possible to create a modern >'seal' similar to the wax seals of yesteryear. In the case of the old seals it >was not the wax which provided the protection but rather the symobigy that was >embedded in it (ie DNA). > >And you thought that T Rex forward from the dinosaur mailing list about DNA >from dinosaur bones was unrelated to crypto......bwahahahahaha Something I've been is: Why can't one of your enemies just get a piece of your hair or fingernails or something, and make their own DNA ink our of your DNA? They could probably even send it to this DNA ink company, and they'd make your enemy ink out of your own DNA without even noticing. Doesn't seem very secure to me. [Yeah, it's not crypto related, but I've been wondering about this since the topic was first brought up, and am somewhat surprised that of the few messages there were making fun of the DNA ink, none mentioned this fact. Is that because it's too obvious to mention, or is there something I'm not thinking about which makes DNA ink useful after all?]

5 5

Source code for Applied Cryptography
by lce＠wwa.com 17 Dec '03

17 Dec '03

I think it's been mentioned that the source code for Bruce Schneier's "Applied Cryptography" was available via ftp. Would someone be so kind as to post some locations where it can be obtained? Thanks for the help.

1 0