December 2003 - cypherpunks-legacy

Child Porno
by Ben 17 Dec '03

17 Dec '03

Just heard on the radio "How child pornographers are using the 'Net to turn your home computer into their playground and why you can't do anything because of lax and permissive legislation." All this over some very discordany chords to make it seeem more ominous. Gotta love the evening news here in CT. >From the same people that had a feature of 'MArtial arts weapons as weapons of mass destruction and how easy they are to get.' I wonder if the producer is a closet facist or a ratings freak. Ben.

1 0

Selection key crypto protocol trial balloon
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Before replying to Tim's comments on Mike Ingle's new directions for anonymity which, I think, are based on a misunderstanding of what Mike was essentially positing, here's my (slightly lengthy) take on the Selection Key Crypto protocol. Please read it before criticising, as I've already done that... Mp is the plaintext message. Alice encrypts it with Bob's public key: Mc = E.kpub (M) [1] She sends Mc to Hermes, the Hoarder of Messages. Hermes also receives Alice's identity string (Ia) which will probably be anonymous, but let's assume it's not. Now's the tricky bit. Hermes adds Mc to its message store, S: S' = G (S, Mc) [2] The key here is G, the Digest function, which has to spread M over S (with a variation of the Fourier function, perhaps), and not just append it, so that the _only_ way it can be extracted is with Bob's selection key, which Bob transmits to Hermes along with an involuntary identity string (Ib) to get: Mx = H.ksel (S') [3] where H.ksel is the Regurgitate function applied with Bob's selection key, and Mx is _not_ the original encrypted message, Mc, nor the plaintext Mp. Finally Bob decrypts Ms with his _private_ key (or possibly a variation, which we'll call v(kpri)), to get the plaintext: Mp = D.v(kpri) (Ms) [4] So the possible crypto operations are: Mp = D.kpri (E.kpub(Mp)) Mp = D.v(kpri) (Mx) where v(x) may be = x Mx = H.ksel (S') And the Digest function, S' = G (S, E.kpub(Mp)) Note that only the private key kpri, and its variation v(kpri) are private. The other two are public. Now for the obvious criticisms: 1. after [1] Hermes can store Alice's identity (Ia) in a dark grey dossier, and match it to Bob's identity (Ib) and the extracted message (Mx). Nope. The premise of this scheme is that Mx doesn't look like Mc at all, and that G (in [2]) dissolves the original message into a sludge, from which Mx somehow emerges, NOT that it chops Mc into bits with Ia on a little nametag 2. after [1] Hermes can store Ia along with the message and feed [Mc, Ia] to [2] in the hope that it will reappear in [3] as [Mx, Ia']. Well, the digest function has prevent this, possibly by making the regurgitated thing so different from the input that matching Ia to Ia' will be impossible. Of course, Bob probably won't grok [Mx, Ia'] in [4] 3. Hermes gets Bob's identity string (Ib) in [3]. Et alors? As that is incidental, not required to extract the message (unlike in a remailer, where that identity string - e-mail address, return block, whatever is _precisely_ what is required for a message to reach), it's irrelevant. The _real_ identity is the selection key, which does not correlate to any cyberspatial location. See further on traffic analysis. 4. ksel, Bob's selection key, is obviously not private, at least not to Hermes, and may as well be public. So anyone can extract the message intended for Bob (which reinforces my previous point that Ib is irrelevant). But what they extract is Mx, which is not the plaintext. To get the plaintext you need not the selection key but Bob's private key, which only Bob has. 5. The Digest function [2-3] has to be robust, i.e. it shouldn't puke if it's got lots of messages, and should be able to extract the right one in any state. Well, yes, that's tough. Traffic analysis The difference between the SKC model and remailers Alice --> (Raven, the remailer net) --> Bob .... multiplied ad infinitum Alice --> (Hermes) --> Bob --> Carol, David, the whole world as the selection key is public The remailer net is essentially one-to-one, making traffic analysis easier and limiting Bob's deniability - if the last remailer says it's gone to Bob, it was _for_ Bob. The broadcast model essentially increases deniability - they all got it, any of them could have seen it if they had the key, and you'll only know that I had the private key with thumb-screws. But they all _get_ it, so bandwidth is huge. The SKC model is a compromise. It increases deniability - anyone could have got it, they all have the selection key, they could only have seen it with the private key etc. It cuts bandwidth. But it's not a data haven, at least not as earlier discussed. The data haven in its latest guise has the same deniability as SKC, and the same prerequisites that aid recipient protection (anon anon ftp etc). But it doesn't protect the sender. If the haven is in collusion with remailers that Alice used to post, it can link her to the message and possibly to Bob. With SKC, even with the collusion of remailers the link gets lost in digestion. Also, Bob (or anyone) can frequently extract stuff with the selection key, perhaps garbage if Hermes is misbehaving or without messages for Bob. Of course when (and how) Hermes is to expire messages is part of the problem of the various functions involved. Comments? ----------------------------------------------------------------------------- For Electric Dreams subscriptions and back issues, send a mail to rishab(a)arbornet.org with 'get help' as the message Subject. Rishab Aiyer Ghosh rishab(a)dxm.ernet.in rishab(a)arbornet.org Vox +91 11 6853410 Voxmail 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

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

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

Re: dna ink
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

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? -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

3 2

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

New directions in anonymity (needed)
by Mike Ingle 17 Dec '03

17 Dec '03

There has been a lot of talk about anonymity and the best ways of providing it recently. Anonymity now is about where cryptography was before Diffie and Hellman's paper, or untraceable transactions before Chaum. To use it, you have to trust someone, or at least a group of people. All of our anonymous systems boil down to only two techniques: indirection and broadcast. Indirection is sending a message through one or more intermediate nodes to conceal its point of origin. Broadcast is sending a message to multiple recipients to conceal the intended recipient. Indirection is somewhat secure for anonymous-to-known messaging. Properly done, all intermediate nodes must be compromised to reveal the anonymous sender. It is entirely broken for allowing replies to an anonymous person. To allow a reply, a traceable path must exist back to the anonymous person. Having obtained whatever piece of data is used to send a reply, the attacker can trace this back one node at a time. Kludge all you want, but there is no good solution to this. You can make the path disappear when it is used, but if the attacker gets it first, there is nothing you can do. Broadcast is exactly as secure as it is nonscalable. If you broadcast to 100 people, an attacker's uncertainty is one in 100. The security grows linearly with the overall bandwidth. For cryptographic-level security, it would need to grow exponentially with bandwidth. Anonymity needs something fundamentally new, something comparable to public key for cryptography or blind signatures for digital cash. Suppose a server has a large file. A message comes in and is combined into this file. Another message comes in with a key to retrieve data. The server processes the retrieval key against this large file and comes up with an output, which it returns to the person doing the retrieving. This output contains the input message, transformed in such a way that even the server cannot match it to the input that produced it. This is what we need. It would require three keys: an encryption key, a selection key, and a decryption key. The sender uses the recipient's encryption key to encrypt the message, then sends it to the server. The server mixes the message into its file, but cannot identify the encrypted file as destined for a particular recipient. The recipient's selecting key extracts the data, but the data extracted does not resemble the data the sender sent. The decryption key, kept private by the recipient, is necessary to return the data to its original form. The server must be unable to link the data from the sender to the data sent to the recipient, and this is the hard part. A method like this would permit anonymity without trust, much as public key allows secrecy without trust and digicash allows transaction privacy without trust. Is there any way to do it? There are functions like the Fourier transform that can distribute data over a large file, but the inverse function gives you back the same data. We need the not-so-inverse function to give back a different piece of data, but one that can be converted, by a private key, into the original, which the server never sees. Mike P.S. Have any of the "beta testers" actually tested RSAREF for Perl? RSA gave me permission to call the random number and DES routines, so I am ready to add that in and release the code.

4 4