- cypherpunks-legacy - lists.cpunks.org

Re: Can someone verify this conjecture for me?
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: nelson(a)crynwr.com (Russell Nelson) > > I'd like to make sure I understand how a digital mix works. I've read > Chaum's paper on it, but hey, there's a reason why I don't have a Phd > in spite of having all the coursework done. > > It seems like it solves two separate problems: 1) foiling traffic > analysis, and 2) foiling a cheater remailer. The problems are > separate, really, because if you really, really trust the remailer (as > many people do Julf), then 2) isn't a problem. All you need to do is > solve 1. Or, you can solve 1) by using a single remailer. A > necessary but not sufficient step to foil traffic analysis is to strip > headers. My take on the paper is that he first presents the "mix", or remailer, as a method of foiling traffic analysis. Then he extends this to the "cascade", or chain of remailers, which does not improve traffic analysis resistence but as you say provides some immunity against a bad operator. > If you trust any one remailer, then you needn't bother using any other > ones (assuming that remailer has enough traffic, delay, mixing, etc to > foil traffic analysis). There's no real difference between using a > set (N>1) of trusted remailers and using only one, because you can > consider the set of remailers to be a single remailer from the point > of view of traffic analysis. There are other differences which may be relevant in practice. One is bandwidth. With a Chaumian cascade of N remailers you get N times the bandwidth used, as well as increased latency through the remailer network. One thing that is not often appreciated in Chaum's paper is that at least in his first description of the cascade, the assumption is that all users use the same sequence of remailers in the same order. We OTOH usually assume a different model, where the different possible paths are chosen with some distribution and randomness. I posted an analysis of some of the impacts of this difference a few months ago. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLw4ZXhnMLJtOy9MBAQGjtwIA7tlEMnKPqUAVqAMSmK6EE6eaOlzhqeLL hsHXhNJajyZQjF6osybGSYJ00UBhRkbAxUOtjY4MNf6oMrb9fKRxGg== =A3oZ -----END PGP SIGNATURE-----

1 0

Re: Peter D. Lewis
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim sez: > I think Kelly is a person of high integrity. It's hard to demand much > more than this. I simply can't think much of a magazine that has cover stories deriving entirely from kiddie-kracker squabbles. Kelly may have plenty of integrity but that's not the word that the magazine "Wired" usually brings to mind. It's not the profit motive or the ads that get me: running a business, I know you can't be picky about who you take money from. It's the lack of meaningful content that annoys me. As with Lewis, frequenly when they're discussing something I know something about their stories are fraught with inaccuracies and rumours. My personal favorite is when they list reporters among the "experts" on their technology-watch light bites. Their entire approach is to cast Like "Seventeen," "Wired" should prepend "don't you wish you were" to its title. - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLw4tbioZzwIn1bdtAQEM7gF9EZE2qciEPOqQTYjwiqDF9vakwzSS3DSh ZJy1S0gTP7kNSTDnm/8UuoVOxehFhJ+X =g0sd -----END PGP SIGNATURE-----

2 1

Cooperation
by Nathan Zook 17 Dec '03

17 Dec '03

Hal: I agree that it is to our advantage to minimize the cooperation between remailers, for the following reasons: 1) The existance of a cabal dominating such a function admits the posibility of the abuse of power, for whatever reason. 2) The requirement of cooperation between remailers limits the size of the remailer net to the number of operators that can effectively cooperate with each other. (Yes, we can extend via overlapping groups, but this introduces chokepoints--another weakness.) 3) The requirement of cooperation between remailers raises the cost (in time and legal vulnerabilities) to enter the remailer net. 4) Failing all of these, there is a real chance (happening even now) that users will trust the operators too much. 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. Nathan

3 2

To Bundle Or Not To Bundle?
by jltocher＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

From Edupage: TO BUNDLE OR NOT TO BUNDLE? THAT IS THE MICROSOFT QUESTION One of the fears Microsoft rivals have is that Microsoft will build directly into the Windows operating system various applications software packages (such as encryption for financial processing over the Internet), because customers would be reluctant to pay for products that do more-or-less the same thing as an installed product that they get "for free." Although it's unlikely that the government would consider breaking Microsoft up into separate companies, it is conceivable that it could force Microsoft to limit what it includes with its operating systems. (The Economist 1/28-2/3/95 p.61) John L. Tocher THE CITY-a bounded infinity. A labyrinth where JLTocher(a)earthlink.net you are never lost. Your private map where every PGP: CE 72 1A 11 07 47 35 block bears exactly the same number. Even if you 35 9A C1 DE EA 64 21 BC 94 lose your way, you cannot go wrong. --Kobo Abe

1 0

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: 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

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

Re: lwall
by MathWorks Autoresponder 17 Dec '03

17 Dec '03

Your Usenet test article was received on Mon Feb 6 23:50:01 EST 1995 here at The MathWorks, Inc. in Natick, MA. Natick, MA is about 20 miles west of Boston, MA. You are receiving this message because you posted a test message to one of the *.test newsgroups. The MathWorks' news admin can be reached via e-mail at usenet(a)mathworks.com. Please note that we do not offer news access to sites outside of our organization. If you want to suppress this message in the future, include the word "ignore" in the Subject: header of any subsequent articles posted to *.test. You could also post your test articles with a Distribution: header of "local" to prevent them from leaving your local machine, or you could also ask your local newsadmin to create a local *.test group that will not propagate outside of your organization. All headers plus at most 10 lines of user text from your original article are reproduced below for your perusal: Path: news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!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

1 0