December 2003 - cypherpunks-legacy

Re: Broadcasts - Bandwidth Problem ?
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Jonathan Rochkind writes: > Many people seemed to think that a newsgroup for this sort of a thing was a > waste of bandwith. I don't really agree, and think that the bandwith is > neccesary for a distributed method of making the remailer net more robust > to remailers popping into and out of existence. In case the bandwidth on {alt.anonymous, alt.anonymous.messages} started to bother news admins, we could actively encourage them to put the groups on very short expiration periods, i.e. articles might expire after only a day. Assuming people are using automated sniffers to collect their anonymous mail, this shouldn't present any obstacle to the use of the groups as message pools. Keeping the ciphertext around in public for a shorter time sounds like a Good Thing (tm), anyway. I agree that bandwidth seems essential to foiling traffic analysis. - - -L. Futplex McCarthy; PGP key by finger or server "We've got computers, we're tapping phone lines; I know that that ain't allowed" --Talking Heads - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLuwe/Wf7YYibNzjpAQFK4AP/YFtRJMd0emeRJgZf4QaL4qPvMFKNn3Uv MYFhJ8GR2M4x1q/ZAwhJsP3NuIeRk5UAWc1Ti1OYKjDkNvoQ52DK3uOW6aCqxYp0 3REpK53F0PkuVL9EnfGImrUWAyeUr2oZOzp1O67hD0eCYhM4IdcdDudA/97Xh0R+ zRIhgC6/Gfo= =n6qM - -----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 iQBFAwUBLuwgPSoZzwIn1bdtAQFFgAF+LXvBnjZEZxsMx9MU+fGX9ynuAnrqKs6S EFbgsBG8aFvul2skOsgIBrVW5luJm4c7 =iPbm -----END PGP SIGNATURE-----

3 3

Exact quotation from Freeh on banning unapproved crypto ?
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Can anyone point me to a source of verbatim quotations of Louis Freeh's now- legendary comments about the possibilities of banning unapproved cryptography ? All I have been able to find thus far are vague paraphrases. Thanks. - - -L. Futplex McCarthy - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLuwh+2f7YYibNzjpAQHp+wP9F2tGTtTYg+QRlDQVkrgfQh6YSbKRXNW1 OJX22BcuhAFsMX1LUTZQ5unYiwXi8pu9jdyeCV5nGU/PSKO3noSEunBFlSPCm0nm yW5UEiWGWjRuDUJNEEB81W9KVdB8JPvTgsBANv4skQpT8pNPumQz54uPvEaFJ8O3 bt+zxTB6dc8= =ATOv - -----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 iQBFAwUBLuwjSCoZzwIn1bdtAQFs5wF/c6t636S1GnUKygE2/UBJGwyoSnubAYJ6 5+Ck9KIrIavZ7n/7qLWhYX+7jp8Xkq54 =MM0m -----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{"jpunix"} = "<remailer(a)jpunix.com> cpunk pgp hash latent cut post ek"; $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)xs4all.nl> 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"; $remailer{"mix"} = "<mixmaster(a)nately.ucsd.edu> cpunk hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. Last ping: Mon 12 Dec 94 6:00:01 PST remailer email address history latency uptime ----------------------------------------------------------------------- xs4all remailer(a)xs4all.nl ***+*-+***** 9:24 99.99% usura usura(a)xs4all.nl ***-*-++**** 10:38 99.99% alumni hal(a)alumni.caltech.edu +*+**+**+*** 7:33 99.99% penet anon(a)anon.penet.fi ++**+******* 29:39 99.99% c2 remail(a)c2.org +++-_--+++-+ 58:05 99.99% flame tomaz(a)flame.sinet.org +*++******+- 14:55 99.98% nately remailer(a)nately.ucsd.edu ++++++++++++ 32:43 99.98% portal hfinney(a)shell.portal.com ************ 4:17 99.97% jpunix remailer(a)jpunix.com +*++***** +- 14:42 99.96% myriad remailer(a)myriad.pc.cc.cmu.edu **+********* 5:32 99.94% vox remail(a)vox.xs4all.nl ---------..- 14:16:12 99.99% rahul homer(a)rahul.net *********** 5:06 99.88% bsu-cs nowhere(a)bsu-cs.bsu.edu *+-***-**++ 22:31 99.82% mix mixmaster(a)nately.ucsd.edu -+-+-++**+++ 32:50 99.80% ideath remailer(a)ideath.goldenbear.com ******-*++ 29:24 99.82% desert remail(a)desert.xs4all.nl -------.--- 10:57:50 99.99% extropia remail(a)extropia.wimsey.com --+++---.-+ 5:00:06 99.68% rebma remailer(a)rebma.mn.org *-..-.-*--- 10:34:53 99.71% soda remailer(a)csua.berkeley.edu .-......_. 11:45:06 96.63% 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

Re: Articles on RC5 and GOST in January 95 Dr Dobbs Journal
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

> > Ian Farquhar writes: > > Around the mid 1980's a rather interesting device appeared. It was > > essentially an automated scanner for high-density barcodes. > > A recent mini-article in "WiReD" mentions a barcode-like encoding > mechanism being promoted by (I think) Xerox. It's apparently denser > than barcode and it survives copying well. The Xerox technology is essentially a series of tiny slashes and backslashes. The slashes stand for a 1 and the backslashes a 0 - or vice-versa. This gives you a binary data stream that you can work with. From what I understand, without looking at them closely, the area with these slashes looks like a gray screen. When I first read about this technology a couple of months ago, it was given as a way that sufficiently smart color copiers could restore original color to a black and white copy. Of course there are all kinds of other applications.... ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX http://spirit.aud.alcatel.com:8081/~droelke/

1 0

Re: Clarification of my remarks about Netscape
by Kipp E.B. Hickman 17 Dec '03

17 Dec '03

In article <9412111620.AA41983(a)eldamar.walker.org>, you write: > Several people have asked me to clarify my recent comments about Netscape. > I am more than happy to oblige. > > First of all, let me begin by saying that I am a biased observer, and that > all of this is my personal opinion. My annoyance with Netscape is also closer > to the surface this week than it normally is, due to a variety of factors > (including having just returned from the San Jose IETF meeting). My initial > comment, and the ones that follow in this message, are thus more frank than is > my usual style on, say, public Usenet newsgroups. > > That being said, here are some of the data that has gone into my impressions > of Netscape so far. > > (1) Netscape plays very fast and loose with HTML. Rather than participating > in the existing standardization efforts, they have indiscriminately added > "extensions" to it that are not supported by any other client software, > and which in some cases go directly against HTML's markup-oriented > structure. This only adds more confusion to an already muddy area, > delays the prospects for a standard HTML specification, and divides the > WWW into "WWW Classic" and "Netscape-compatible". Personally, as a > strong proponent of universal interoperability, I find this reprehensible. > There is no need to bypass existing efforts just to add cosmetic value to > your own software. This has nothing to do with security... > (2) The Netscape Secure Sockets proposal has an extremely poor security model. > It is not an end-to-end security model, but rather relies on transport > level security, which is in my view dangerously inadequate for reasons > which should be obvious to most of the folks on this list. Clearly I'm an idiot. Explain it to me. And while you are at it, why don't you email me your comments on the spec? I put my email address in there for that very reason. Jeesh. > It is also > tied directly to the RSA certification hierarchy. Now, for those of us > who have X.509 certificates rooted in the RSA Commercial Certification > authority, that's fine, but it also means that any other WWW client that > wishes to interoperate with Netscape's "secure servers" must license > TIPEM from RSA Data Security, and consequently pay RSA's rather high > royalties, unless the software is free (in which case RSAREF can be used). > This serves as a direct barrier to competition from other commercial > vendors. This is not all bad--I happen to like RSADSI's products and > technology--but promoting a transport-level security system instead of > an end-to-end one is to my mind simply irresponsible. This is an outright lie. We don't use TIPEM. You could build a conformant SSL implementation using RSAREF and the freeware IDEA cipher code. As for a barrier to competition. So what else is new? We all have barriers to overcome before we can compete. Should we get rid of TCP/IP as a barrier to using the web? > There has been no peer review of Netscape's security model--it was simply > implemented by fiat, without regard for the IETF standards process. I > find that this leaves a very bad taste in my mouth. I also heard similar > sentiments from a wide variety of other attendees at the IETF, including > members of the IP Security working group, people who attended the Secure > HTTP BOF, and others. This leads me to believe that it's not just a > matter of me leaping to wild conclusions. You are somewhat right here. In fact, this was done because we are a company interested in surviving long enough to withstand the eventual attack by microsoft. Instead of waiting several years before anything was agreed upon and ending up with a kitchen sink protocol as all others these days do, we took a simpler approach. And instead of hiding in a closet with it, we brought it out to light. As a result we received critical review from some decent members of the crypto community, including: Martin Abadi Mike Burrows Alan Schiffman Matt Robshaw Burt Kaliski to name a few. As for the IETF standards process, we are pushing the document into the RFC process. > (3) Netscape is viewed as a "loose cannon" by most of the other commercial > players in the WWW arena, mainly because they have introduced a fair > amount of FUD into the HTML standardization effort, while simultaneously > promoting themselves as being standards-based. Members of Apple's > "Cyberdog" project and Microsoft's web projects, who *are* trying to > contribute to the standards process, had particularly excoriating things > to say in this regard. This is a matter of opinion. However, I believe that our opinions don't matter in the long run because of the 800 pound gorilla Microsoft. They will push something out, it will be proprietary, and they will name the tune and ask us to play along. Now we can either just sit back in our current comfy cozy standards based processes and languish for a few years, and then SIGH and say "Gee wasn't that fun, too bad microsoft shoved yet another piece of excrement down our throats" or we can be "loose cannons", get something out there, try it out and see what happens. The market will decide one way or the other. > Now, as I said, I am biased and my comments about Netscape are strictly my > person opinions. I will be perfectly willing to revise these opinions as I > receive more data. For example, if Netscape takes a more active part in > the standards process, works with RSA to secure wider availability of the > underlying technology required by their proposals, and generally demonstrates > a willingness to play nicely with other children, that would be great, and > I'll just as strongly defend them as I am panning them now. > > However, in my view, they have not shown a good initial track record. > Only time will tell. > > > Amanda Walker > InterCon Systems Corporation > > --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp(a)mcom.com http://www.mcom.com/people/kipp/index.html -- --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp(a)mcom.com http://www.mcom.com/people/kipp/index.html

8 23

Re: Real-time surveillance of the police
by doumakes＠netcom.com 17 Dec '03

17 Dec '03

The technology of monitoring location is interesting, of course, but why on earth would the police, who will not consent to civilian review, ever go along with something orders of magnitude more extreme? ObCrypto/Privacy: I suspect there would be an immense amount of radio traffic involved in keeping track of a substantial group of people, say, over 1000. I don't doubt the ability of the device(s) to transmit the information, but the ability of the receivers to digest it all in real time. -- ______________________________________________________________________ Don Doumakes Finger doumakes(a)netcom.com for PGP public key Foxpro databases built to your specifications. Email me for details.

1 0

BEAT COPS
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Michael Crawford wrote: ... individual cops can rack up millions of dollars in legal settlement costs and still remain on the force. I heard ... that a small handfull of cops in San Francisco had cost the City tens of millions, with individual cops repeatedly causing lawsuits, without getting fired. True, but that's without embarrassing videotapes. The clueless populace doesn't stay clueless for long when they seen the police "blooper" tapes. Police unions won't have much clout compared to an enraged public. ... at least one cop wouldn't go for it - the cop we caught jacking off to a magazine of ill repute... Gives whole new meanings to "night stick," "the long arm of the law," "stop and frisk," "pat down," "pounding a beat" and going to the "policeman's ball." (Anyone else want to jump in on this one?) S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Misunderstanding of Remail Headers
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 2:13 AM 12/12/94, L. McCarthy wrote: >Hal writes: >> There was also a misperception that my remailer was an official effort >> endorsed by Portal (again, despite the disclaimers). Note that it was >> they who were contacted, not me (yet). This might suggest that it will >> not be possible to cleanly separate the remailer operators and service >> providers when problems like this arise. Both may end up being hassled >> (time will tell whether I am). > >This is all too familiar to me. Although I still haven't heard the official >line on the shutdown of Underdog following the Scythe spam, at least some >people locally (including, crucially, my advisor) received the impression that >I had forged (and authored !) the offending news articles in spite of the >disclaimer headers. Maybe the remailers should put bogus "From:" lines in, to avoid this? Make it "From: nobody", or "From: Anonymous", or even something odd like "From: AnonUser!hfinney(a)shell.portal.com". Put in some other lines telling the actual address of the remailer, as well as a complaints-to: address. Maybe "Sender: hfinney(a)shell.portal.com", or "Remailer:hfinney@shell.portal.com". The "From:" line seems to be confusing people. The author of the article quoted from the Globe & Mail appearantly didn't even understand the disclaimer. The article was worded in such a way to make it seem the disclaimer was saying that Bob Rae didn't really write the message, as opposed to saying that Hal Finney didn't really write the message! Something needs to be done so that even the most internet clueless will understand that the message _isn't_ from Finney or McCarthy or Joe Random RemailerOp, which appearantly isn't clear to many people currently.

2 1

extra dashes in PGP-related blocks?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

When people have been posting their public keys, or encrypted address blocks, to various lists I'm on, all of the "-----BEGIN whatever..." lines seem to have a "- " preppended to them. So, for instance, they look like: - -----BEGIN PGP MESSAGE----- Version: 2.6.2 [stuff] - -----END PGP MESSAGE----- I'm guessing if I really sent a block like that to a remailer, the remailer would hork because of the prepended "- "s. I know that sometimes people's public keys they've posted to a list look like that, and when I try to add them to PGP, it horks, and I've got to go into a text editor and remove the "- ", and then add it to my keyring. Does anyone know what it is that's putting in these "- "s, why it's putting them in, and how to stop it?

4 8

Re: extra dashes in PGP-related blocks?
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> I'm guessing if I really sent a block like that to a remailer, the > remailer would hork because of the prepended "- "s. I know that > sometimes people's public keys they've posted to a list look like > that, and when I try to add them to PGP, it horks, and I've got to > go into a text editor and remove the "- ", and then add it to my > keyring. PGP does this... Not only does it complicate nested PGP signed messages, but if you pgp-sign an entire MIME message (i.e. by sending it to the autosigning service) instead of placing the signed doc inside the MIME boundries, it can cause mail readers to not recognize the MIME boundries and display the letter as normal ASCII-Mail. andrew

1 0