- cypherpunks-legacy - lists.cpunks.org

Re: Frothing remailers - an immodest proposal
by Hal 17 Dec '03

17 Dec '03

One point re remailer reliability: Even though in my discussions with Nathan I did not really agree with his suggestion to have remailers check signatures on incoming messages, actually Chaum did propose something similar in his 1981 paper. He would have each remailer sign the batch of messages it outputs each cycle. (Chaum's remailers used a straight batching approach.) The idea, as I recall, was to allow a remailer to prove that it had not engaged in a denial-of-service attack by purposely dropping some message into the bit bucket. If some customer put his message in here and it didn't ever come out over there, I guess the remailer could prove that it didn't lose the message by showing its signed batch. I'm not clear on the details though. Anyway, here is an area where message signing and reliability have some intersection. Hal

1 0

No Subject
by jltocher＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

From Edupage: THE NEW ETHOS OF THE NET A professor at St. Cloud University in Minnesota calls for overhauling business school curricula to stress ethical concerns in the electronic age the same way they stress finance or economic theory. The end result? "Information systems will be protected because most people will no longer be willing to purposefully contaminate a program or network; they will protect others' confidentiality, privacy, and copyright as they protect their own; they will refuse to plagiarize, fabricate, and perpetrate other types of fraud; and they will not tolerate such activities in others." The alternative is bleak: "...We will degenerate into secretive, encrypted, overly protective information hoarders, unwilling to share and disseminate knowledge -- except for profit." (Information Week 2/6/95 p.64) But, how do you really feel... John 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

to hfinney
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

mr finney , do you know if that perl prog of yours to add stuff to .pgp files can be ported to messy dos ? many thanx

1 0

Compromising the first remailer
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Nathan Zook wrote: > >notion of not assigning trust is simply nonsense. When you send a piece > >of mail to a remailer, encrypted or not, you are assigning complete > >trust in that remailer to keep you anonymous and not to forward your > >mail to the NSA immediately. > > NOT TRUE. With proper use of encryption, you are trusting your first > remailer only to not reveal that you sent a message, and not to correlate > that message to the one it sends out. With rational use of garbage running > two deep, you can even suffer this loss without significant harm. Actually any remailer, with NSA-modified operating software, can correlate the message it receives to the one it sends out, by keeping track of the message past any decryption until it's posted out. With rational use of garbage and chaining, all you do is stop the NSA from knowing your final destination from the first remailer, but they _would_ know the identity of the second remailer (assuming the first is compromised) and could try to attack the second, ad nauseum. Of course this was always known to be the problem, to which chaining and traffic analysis evasion are partial solutions. ----------------------------------------------------------------------------- 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: 1995-02-02 President Names Members to Intelligence Commissi
by Brett Turcotte 17 Dec '03

17 Dec '03

<much snippage of press release naming commission members> > > Attachment: > Biographic Information > > > > > > THE COMMISSION ON THE ROLES AND CAPABILITIES > OF THE UNITED STATES INTELLIGENCE COMMUNITY > <more snippage of bio information> Anyone else notice all of the inside the beltway plus NYC area types on this list....anyone want to bet on how much "newly required" intelligence capabilities will come out of this commission... Brett Turcotte turcotte(a)io.com

1 0

Mugshot Identification Database announcement
by Technoshaman Tom 17 Dec '03

17 Dec '03

Heard elsewhere... National Institute of Standards and Technology announces the release of NIST Special Database 18 Mugshot Identification Database (MID) NIST Special Database 18 is being distributed for use in development and testing of automated mugshot identification systems. The database consists of three CD-ROMs, containing a total of 3248 images of variable size, compressed with lossless compression. Each CD-ROM requires approximately 530 megabytes of storage compressed and 1.2 gigabytes uncompressed (2.2 : 1 average compression ratio). There are images of 1573 individuals (cases), 1495 male and 78 female. The database contains both front and side (profile) views when available. Separating front views and profiles, there are 131 cases with two or more front views and 1418 with only one front view. Profiles have 89 cases with two or more profiles and 1268 with only one profile. Cases with both fronts and profiles have 89 cases with two or more of both fronts and profiles, 27 with two or more fronts and one profile, and 1217 with only one front and one profile. Decompression software, which was written in C on a SUN workstation [1], is included with the database. NIST Special Database 18 has the following features: + 3248 segmented 8-bit gray scale mugshot images (varying sizes) of 1573 individuals + 1333 cases with both front and profile views (see statistics above) + 131 cases with two or more front views and 89 cases with two or more profiles + images scanned at 19.7 pixels per mm + image format documentation and example software is included Suitable for automated mugshot identification research, the database can be used for: + algorithm development + system training and testing The system requirements are a CD-ROM drive with software to read ISO-9660 format and the ability to compile the C source code written on a SUN workstation [1]. Cost of the database: $750.00. For ordering information contact: Standard Reference Data National Institute of Standards and Technology Building 221, Room A323 Gaithersburg, MD 20899 Voice: (301) 975-2208 FAX: (301) 926-0416 email: srdata(a)enh.nist.gov All other questions contact: Craig Watson craig(a)magi.ncsl.nist.gov (301)975-4402 [1] The SUN workstation is identified in order to adequately specify or describe the subject matter of this announcement. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the equipment is necessarily the best available for the purpose.

1 0

Re: Compromising the first remailer
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 6:11 PM 02/03/95, rishab(a)dxm.ernet.in wrote: >Actually any remailer, with NSA-modified operating software, can correlate the >message it receives to the one it sends out, by keeping track of the message >past any decryption until it's posted out. With rational use of garbage and >chaining, all you do is stop the NSA from knowing your final destination from >the first remailer, but they _would_ know the identity of the second remailer >(assuming the first is compromised) and could try to attack the second, ad >nauseum. Of course this was always known to be the problem, to which chaining >and traffic analysis evasion are partial solutions. Yes, but as long as _one_ remailer in your chain is not compromised by the NSA, and if that one remailer has high enough traffic going through it and does the proper things with reordering and latency and such (a big "if", currently), you're still safe. That turns out to be the whole purpose of chaining, since it has been shown that it doesn't neccesarily make traffic analysis any harder. The purpose is to hope that at least one link on your chain is both honest and properly working. Yeah, if all the links on your chain are NSA-sponsored, your in trouble. Nothing that can be done about that.

1 0

Re: There is another NetCash
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 10:09 AM 2/4/95, Hal wrote: >Some payment system is probably better than none, but I hate to see >the name "cash" expropriated by these non-cash systems. Indeed. That was the point of the URL to Mr. Solinsky's excellent introduction to the subject. It is easy to see that the original NetCash isn't a digital cash system, with its clearing of a single-use serial number transmitted unencrypted in the clear, and with its "bank" settling the transaction through the telco 900-number system. Not having looked yet, I bet the "other" NetCash is probably not Chaumian-equivalent digital cash either, or we'd have heard more about it. It would be a pretty major accomplishment, especially if it doesn't violate Chaum's patents. As Eric has said here recently, we have to remember the difference between transaction clearing (which First Virtual, for example, does well, at least as a prima facie system) and transaction settlement (which FV does on the back of the Visa/MC network), which is what a true cash-settlement system would do in one stroke. Someday, and not now, I would like to take up the cudgel and jumpstart the old offline/online cash debate. I like offline cash because it doesn't require a bank intervention at every transaction, double-spending cash and "inside-job" private key theft notwithstanding... Ah, well. Someday. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

MX'ing and jpunix.com
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- JPUNIX.COM (soon to be alias.net) offers a MX service for individuals that want to run an anonymous remailer but don't want the domain they are operating from to be immediately apparent. By making application to perry(a)jpunix.com, a remailer operator will be granted a DNS MX record pointing to the domain address of the requestor's choice and will appear to reside in the jpunix.com (alias.net) domain. Additional masking can be provided by having the MX record point to myriad.pc.cc.cmu.edu. What good does this do? I have an agreement with myriad.pc.cc.cmu.edu (Matt Ghio) where myriad will take the MX-pointed record and additionally alias it through the smail daemon on myriad. This function adds the unique benefit where determining the actual location of the remailer in question will be foiled when using nslookup. Since an additional alias is performed the result of an nslookup will always point to myriad. The actual location of the remailer remains hidden inside the alias on myriad. Lastly, Matt has the EXPN function of his sendmail daemon disabled so the identity of the remailer can't be determined by alias expansion. Future modifications to this scheme include adding an addition step whereby the MX-alias process will cause a version of Raph Levien's premail to post-process the message to add one or more random remailer paths the the overall path that the message travels. This step in still in the planning stages and has not been implemented yet. If you have and questions, or want to set up an MX record, send email to: perry(a)jpunix.com or ghio(a)myriad.pc.cc.cmu.edu John Perry < perry(a)jpunix.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzFN6lOTpEThrthvAQHfAAQAkzoGHz7iaJKHMzB5GEQr8OvEwhDY0F9s lCZUJhTw3KV2hVWDoUtZNPwiSf4vcsDhGx0CDQrDUon2vXC0mOHj4zBbDhhuUD5l /NCPOmtWKFSnWiny2JbD0esNIuxIaWfa/tVTkDoDq/zPtsG0awmHTpGMSeIkkxvy II1mDwnZ9n0= =2jQD -----END PGP SIGNATURE-----

2 1

IMPORTANT: BUG IN 68K IDEA ASSEMBLER DISTRIBUTED IN SECURE EDIT
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- IMPORTANT NOTE: If you are going to use the IDEA 68k assembler distributed with Secure Edit b0.5, please take note of the following bug: You have to change @Mulzero3: neg.w d7 <--- addq.w #1,d5 sub.w -2(a1),d5 bra.s @Muldone3 to: @Mulzero3: neg.w d5 <--- addq.w #1,d5 sub.w -2(a1),d5 bra.s @Muldone3 I have not yet received any reports of data being fouled up by this, and before tonight personally had encrypted and decrypted megabytes without error, but note that I HAVE FOUND EXAMPLES OF IT FOULING UP A BLOCK OF DATA. IT IS DANGEROUS TO USE THIS CODE IN ITS PRESENT FORM. Please make note of this if you are going to use this 68k code. Currently, I do not believe this code is being used anywhere except Secure Edit b0.5, although it was certainly about to be used. I will immediately upload a corrected version of Secure Edit and source. Sorry about the screw up. Tom -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzMbp1uwJA7oL8O9AQGk0wP/YF8VQ2jDtW63Wb7fteImBvYCfMi7NnTf tXMBV6U5iIKf+iBoED34gnwJyLAdEplpMa6P1yJUIMjNXly1/I+SzQoMFGVXuuKV m0h+idXI1mXTVG+gnmdpGMw9/6/u72DcaYCZRHveL8tuMesO5UdgQEDjvy+zX7+c 0cAvyXQaArg= =ubXB -----END PGP SIGNATURE-----

1 0