December 2003 - cypherpunks-legacy

remailers
by Raul Deluth Miller 17 Dec '03

17 Dec '03

I'm wondering if I understand this remailer debate. Here's my summary (based not so much on reading of cypherpunk traffic, but on my understanding of the basic principles): (*) define an encrypting mailer protocol (basically, just PGP or some such). When a mailer receives an encrypted message, it unpacks (0) a message which may have been doubly encoded (once by originator, once by prior remailer to disguise padding) -- if so, must decrypt twice. (1) the message to be forwarded, annotated with control info (e.g. padding, delay, key to reencrypt under) (2) payment information in whatever format is advertised for that remailer. As I understand it the problem with digital cash is defining physical link for the "cash", without compromising the identity of whoever payed into the account. The proposal-to-date involves a guild of remailers. As I see it, this would be primarily of value for shuffling cash around -- call it a build of bankers instead. Once you've established your "cash"-net, presumably with related services such as drop-boxes and temporary accounts, you could use more flexible mechanisms for anonymous mail, which feed off the cash net where necessary. I've not read Chaum(sp?)'s work on encrypted cash, so perhaps I've ignored some terribly obvious issues. [No PGP signature -- at the moment, I don't have a host sufficiently secure to be worth bothering with.] -- Raul D. Miller N=:((*/pq)&|)@ NB. public e, y, n=:*/pq <rockwell(a)nova.umd.edu> P=:*N/@:# NB. */-.,e e.&factors t=:*/<:pq 1=t|e*d NB. (,-:<:)pq is four large primes, e medium x-:d P,:y=:e P,:x NB. (d P,:y)-:D P*:N^:(i.#D)y [. D=:|.@#.d

1 0

Re: The Value of Anonymity
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Hear, hear! mkj's article on anonymity is worth reading. >From my perspective, the most important thing cryptography offers us is not just the ability to have private conversations without eavesdroppers; it's the ability to change the balance of power from the centralized control and accumulation of information that computers bring back to a level where _you_ can control what happens to your personal data. Do you _like_ starting transactions by giving some big company your Social Security Number which lets them, and everyone else, know everything you've ever done, where you live, how you vote, what you buy? We can move to a society where you can give the other party as much information as they need to do business with you, without having to give them everything else, or connect this transaction to all your others. Sometimes that means giving people more detail than you give them now, usually less. Cryptography becomes the technical glue to control how much you tell somebody on each transaction, anywhere from total anonymity to deep personal information, to let you have a driver's license that says "yes this person is a safe driver" without it becoming the key to your bank account of you lose your wallet, to have voter's registration that doesn't permit fraud but doesn't require universal identification. Some good technical references are the set of papers that David Chaum published about blind signatures and anonymous credentials. Bill

1 0

Re: From me to me to you...The Actual Article
by Erik Selberg 17 Dec '03

17 Dec '03

Carol Anne Braddock writes: > This is the article, and what I did with it. It is complete in it's > entireity, from the bang paths, to the crosspostings. Please study them > Now, the article, > Date: Sat, 7 Jan 1995 01:26:26 -0600 > From: Carol Anne Braddock <carolann(a)vortex.mm.com> > To: carolann(a)vortex.mm.com > Newsgroups: soc.support.transgendered, alt.transgendered, > mn.general, alt.sex.femdom, alt.artcom, alt.sex.bondage, alt.sex, > comp.infosystems.www.users, alt.dreams.lucid, alt.dreams > Subject: (fwd) Re: Phil Zimmermann So, I don't read any of those groups, and I could be dead wrong on all of this. But I'll yap away anyway. Off the cuff, I'd say your article could be inappropriate. Granted it's a good cause, and you're not advertising for yourself but for a charity. However, charitable spam is still spam (and I'm not calling your article spam... spam lite, maybe). I understand your point about feeling a sense of community with the above groups; however, I think that massive "Please help..." postings can be just as annoying as the MAKE.MONEY.FAST postings. Erik Selberg "I get by with a little help selberg(a)cs.washington.edu from my friends." http://www.cs.washington.edu/homes/selberg

1 0

Re: Latency, bandwidth, and anonymity
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

My initial reaction to "Anonymous video conferencing" was "That's when you wear black ski masks and use voice scramblers and call from video payphones", i.e. not very useful. ("Subcomandata Marcos here...") On the other hand, Wei Dai's followup message about > In the longer term, anonymous communication is in danger of being used > only by fringe groups if it falls too much behind the non-anonymous kind > in terms of latency and bandwidth (and cost, I guess). Maybe ONLY drug > dealers, nuclear terrorists, etc., will use anonymous remailers when full > sensory virtual interaction is the must popular way for most people to > communicate and remailers are still the only choice for the > anonymity-conscious. puts a different spin on it. It's a real problem, if not now, then maybe in 5-10 years. I realize that those of us in the Phone Company who have predicted universal Picturephone in the past have been over-optimistic :-), but the video compression people and the faster-chip people keep bringing us closer to having good-quality low-bandwidth video, and ISDN and fast modems are bringing available loop-end bandwidth up to the point that reasonably-priced circuits can carry it. (Long-haul raw bits have been cheap enough for a while; it's the distribution and switching technology that have a lot of the cost, and providing cheap high-bandwidth circuits makes it hard to make money on voice calls.) The approaches to anonymous video conferencing will depend a bit on whether the technology takes off on the nets or the phone system, if those two are still different by then. It's easier to obscure the origins of a call on the nets, where users own large parts, than it is on the phone system, where the Phone Companies own and operate most of it; the latter environment would require Phone Remailers, such as PBXs you call into on T1 lines and get shuffled out on other circuits - it's hard to get adequate mixing except in rather large environments.... Recircuiting on the nets will be left as an excercise to the reader. I suspect the harder parts of the job may be doing the faces and voices right - anonymous voice conference bridges are ok if the participants mostly don't know each other, but they're less useful if people know each other and cops with computerized voiceprint equipment may be eavesdropping (not common now, though computers and models of the human voice are improving; I suppose voice disguisers may improve from the kid's-toy quality to something better if there's a market, or if computers with full-duplex soundcards become more common.) Faces are harder, and they're not really a crypto problem - how do you fake them well? It's not too hard to do a "quayletool" quality solution that generates moving lips in front of a static picture, even timed with an audio feed, but that won't play too well in the business world, and having the camera pointing at your calendar or home page is only semi-useful. If video-calling evolves on the nets, there'll be a lot more need for speed-matching services, and it may be that computer-enhanced video receiving for high-bandwidth users will fund the technology development for face-simulation? If so, maybe you can use it to start with fake stills instead of real ones? Bill

3 2

Re: Data Haven problems
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

dfloyd asks for ideas about preventing spamming in data havens, for the code that he's working on. It's a hard job. A related problem is how to prevent your data haven from becoming the porno-ftp site of the week, and either being swamped with traffic or raided by the Post Office Reactionary Neighborhood Police. One way to stop spamming is to charge sufficient money for the service that using it always pays for itself - spamming is then reduced to a source of profit, e.g. no problem. If people want to hire you to store spam, it's their money they're wasting. But that requires an anonymous digital cash infrastructure, which we don't really have yet. And it's a lot less interesting academically (:-) than finding solutions which can also work in a cooperative system, or at least a system that doesn't charge per transaction. Probably the most important step you can take is to build in operator-selectable filtering, because the problems keep changing. Operators probably need to be able to block storage and retrieval by specific users and sites (It's easier to prevent access by president(a)whitehouse.gov than it is to detect forged requests, and you probably want to keep both real and fake Cantor&Siegel users off, plus the bozo of the month and the broken-remailer of the day.) Some operators may find it useful to limit the amount of data that can be stored or retrieved by a specific user or site, though this is less useful with anonymous and pseudonymous remailers around, since "a specific user" becomes vaguer. Filtering by filename and type can also be useful - if you don't allow files named *.gif and *.jpg, users may be less likely to spam you with pornography. Namespace control in general is an issue - do users get to choose filenames, or list directories, or do they have to know the names of files to retrieve. Another issue is whether files can only be retrieved by the sender - probably a local policy issue. Some sites may only accept encrypted files, which reduces the spam potential considerably, as well as reducing your exposure to the porn police, though it's difficult to do anything about files that are encrypted with a public key whose private key has been posted to the net, or fake crypto headers in an otherwise unencrypted file, unless you put in lots more code to check the insides of files and watch the net for such postings, which is unrealistic. There's also the problem that PGP and especially RIPEM files are non-stealthy, and users may not want to leave even keyids in their files. Bill

8 10

Re: Can someone verify this conjecture for me?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> From: nelson(a)crynwr.com (Russell Nelson) > > 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. There are a couple of advantages of chaining multiple remailers. One is that traffic analysis is an art, rather than a science, and to really foil it, you've got to know how good it is, which is hard. Long-term patterns may show up even though the traffic mixes are pretty good in the short run, and if you can spread out the remailer use and increase the traffic load, plus constantly sending encrypted traffic between remailers, it does make the job harder. If the Bad Guys can isolate their target to a few remailer users, they can often find the real one by rubber-hose or a small number of wiretaps at the user locations instead of the remailers; that's impractical if there are thousands of potential users in multiple countries across the remailer-chain. Another is that if one good trustable remailer can foil traffic analysis, then multiple remailers increases the chance that at least one of them is good. Sure, Julf's a good guy, but what if the KGB has kidnapped his grandmother, or the CIA has planted wiretaps inside his computer - will you know if it's compromised? There's also the reliability issue - what if the Finnish Phone Company decides Julf is using too much of their resources and cuts him off, or the Mafia steals one of your police-informants' remailers, or the California Public Utilities Commission declares email to be a common carrier and insists on auditing all transactions? Multiple remailer in a strongest-link chain reduce the risks. Bill

1 0

Re: Vinge's True Email name ?
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <Pine.BSI.3.91.950109001111.9299A-100000(a)garnet.msen.com>, Lou Poppler <lwp(a)garnet.msen.com> wrote: >I knew that old compuserve account was good for something. >They list Vinge, Vernor San Diego CA 72267.2656(a)compuserve.com Sigh. Please don't use this, people. I'm sure VV has no desire to pay for oodles of mail telling him just how much people like him. Treat it like a home phone number (of course, some people abuse home phone numbers of famous folks...). - - -- 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 - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxCrChNhgovrPB7dAQF7VgQAqsDQM0h7b0VDmBISGd3o0YqYg4q2HYmQ m0g7VtnX3yEU1vi9N96HPilMwe2JGs/6Frlvf9IKMmzGAIJxEQzGdMLbow54Il1/ akV9siQAH7BvKwaEWkzO8dDi6nl83ZtawVXIQNacIb5v9oEIQwK/vw4aYWitmDAv B0eJJUVT1XI= =u+fn - -----END PGP SIGNATURE----- - --- [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 iQBFAwUBLxDlzSoZzwIn1bdtAQEXTwGAqVqaYnu+0yy8/d0HSZseTDuxP7BBWqGb PuzL4Xpu2HE7DDrIaALalplmGIYrHnun =zr9V -----END PGP SIGNATURE-----

2 1

Re: Vinge's True Email name ?
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- NOTE: This mutation of this thread has no crypto content, but some (awfully specific) privacy relevance. Todd Masco writes: > Lou Poppler <lwp(a)garnet.msen.com> wrote: > >I knew that old compuserve account was good for something. > >They list Vinge, Vernor San Diego CA [email address omitted] > Sigh. Please don't use this, people. I'm sure VV has no desire to > pay for oodles of mail telling him just how much people like him. Treat > it like a home phone number (of course, some people abuse home phone > numbers of famous folks...). I began composing a reply precisely to this effect, but was stopped by the words "They list...". If the address appears in some standard Compu$erve email directory, then this was hardly a major transgression. Allow me to suggest a compromise. If some enterprising VV fan would volunteer to collect fan mail from c'punks, then forward it all, everyone involved might be fairly satisfied. Disclaimer: I'm not familiar with the details of CI$'s fee schedule; if one pays by sheer volume and not number of messages, then obviously this approach won't alleviate the burden. Maybe then someone could volunteer actually to ask VV whether/how he'd like to hear from fans.... - - -L. Futplex McCarthy - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLxDr62f7YYibNzjpAQGxAwP+LloeLQS/BJcZciApmMWEvmOhSaCQJX8u uuwzprP2ZYTmbsb08lfTHnofS1TXKmoZ3BrYdiqjugaCTKFweg8BSZ2vw5i6KplV x2ArBnejYPKjtqs3C12mf8WJrgjnKdMZ9LxLgjlE1ymELG1bhH0loIyq3YX3x46G 69hvZyz/qQ8= =h05K - -----END PGP SIGNATURE----- - --- [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 iQBFAwUBLxDtAyoZzwIn1bdtAQHLNAF+LEFF+UniR9jrXSZxd6Ia9L5aJIXjFFt3 J9aUAIUQKXf0o5ytM2nHYUvj7v0cWhn6 =e+gV -----END PGP SIGNATURE-----

2 1

More signal than YOU can handle.
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- For the moment, all of the archives that Eric just dropped me are on ftp://ftp.hks.net/cypherpunks/All I'll be making some primitive engines to access individual articles by various means but I thought I'd put 'em up in case anybody else with more disk space than brains would like to snarf 'em (following the Shulgin model). (By the way, Glimpse looks like it'll be ideal, since everything is already in its own file, the "since June" archive currently being our /usr/spool/news/... dir.) Look for more info in this space (that sucking sound is my copious free time). - - -- Todd. - -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAwUBLxD1GBNhgovrPB7dAQEOQAQAuTRIVTQOzIbjqrUAFsPu3xHTJAH+3YnX ickYtw627leo3vs7wD2rxGfHNx6As7JbzSI1JwD26zsb2CMqMGgvQHNQ5eD7rW/N 3ICSWACwESWlnL/rAFvVh69mZDM/IUv5C+eSTVHKdlh3KWYbetRvCgkRNQvGVl58 S06pthGBpJ8= =f4fe - -----END PGP SIGNATURE----- - --- [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 iQBFAwUBLxD1nyoZzwIn1bdtAQEv7wGAhSVywzGivjeo9fZwVrYDRaJx596TPVeJ pjutyvubg3yyKmqFD+Ele62LhiPvhxtX =pooh -----END PGP SIGNATURE-----

2 1

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)chaos.bsu.edu 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{"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"; $remailer{"mix"} = "<mixmaster(a)nately.ucsd.edu> cpunk hash latent cut ek"; $remailer{"q"} = "<q(a)c2.org> cpunk hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. Last ping: Mon 9 Jan 95 6:00:01 PST remailer email address history latency uptime ----------------------------------------------------------------------- nately remailer(a)nately.ucsd.edu ++++++++++ 1:28:30 99.99% rahul homer(a)rahul.net **#**##****# 4:31 99.99% mix mixmaster(a)nately.ucsd.edu ++-+-++-++ 48:36 99.99% penet anon(a)anon.penet.fi *+****+***** 28:32 99.99% vox remail(a)vox.xs4all.nl ----------- 14:34:13 99.99% usura usura(a)replay.com -- -+--+*** 22:31 99.44% bsu-cs nowhere(a)bsu-cs.bsu.edu +##**##***+# 23:14 99.26% ideath remailer(a)ideath.goldenbear.com * --- ----- 2:08:58 99.12% q q(a)c2.org --+--*++-- 2:33:18 98.62% soda remailer(a)csua.berkeley.edu -..-.- ... 8:10:14 98.47% alumni hal(a)alumni.caltech.edu ++ *-**+**** 7:37 97.74% portal hfinney(a)shell.portal.com ** *-#*#*#** 5:32 97.74% c2 remail(a)c2.org *--*+* *+ 1:13:45 95.50% desert remail(a)desert.xs4all.nl _.----.--- 19:54:01 94.80% extropia remail(a)extropia.wimsey.com ++__ +++++ 13:02:14 84.83% xs4all remailer(a)xs4all.nl *-- -+*** 16:29 76.54% rebma remailer(a)rebma.mn.org -*___-__- 31:31:05 70.47% flame tomaz(a)flame.sinet.org -*-*+ 29:22 37.83% 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. Comments and suggestions welcome! Raph Levien

1 0