- cypherpunks-legacy - lists.cpunks.org

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

<none specified>
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wonder if 'Net-cash' is any good? Try sending e-mail to netbank-info(a)agents.com with the words netbank-intro on the first line of body. It says: The NetBank ...is based on "payment coupons" that may be traded via electronic mail ... NetCash is easily obtained by using the NetBank's "Check Cashing by FAX" service. Customers may purchase NetCash by writing a personal check and faxing it to the NetCash Distribution Center. Travelers on the Infobahn may carry NetCash and cash checks while online. and lots more. Does not look too anymous, however, and there is no mention of PGP in the documents I got. But do check it out. When you get the info, they give you 5 cents worth of NetCash, BTW. They also have other stuff: For information on related topics, please send e-mail to "netbank-info(a)agents.com" with the following keyword(s) in the message: Keyword Topic netbank-faq Answers to frequently asked questions buying-netcash How to buy NetCash from the NetBank netbank-merchant Opening a NetBank Merchant account shareware-info Using the NetBank to collect shareware fees boardwatch-story Reprint of NetCash story from Boardwatch Magazine story-update Enhancements since the Boardwatch story was published - --- [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 iQBFAwUBLzNURyoZzwIn1bdtAQFwJwF+KeI9ErF2N04Y1+XwX4B6teBDlIudSuip uNhn0k80uoru/vIWb//WMiMCBFHT+Bww =39YD -----END PGP SIGNATURE-----

1 0

signature validation on secure edit messages
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

Jeez. I really don't know why the heck this always happens to me, my digsigs not validating. You can finger me at tjbryce(a)amherst.edu to retrieve a message with a valid signature. I always write the message in eudora, copy it, sign it in MacPGP as TEXT with attached signature, then go back and paste it over the old message. Then I go back to MacPGP and check the signature on the clipboard to be sure - no problems. But after getting mailed, it doesn't work. Damn. Tom

1 0

There is another NetCash
by Hal 17 Dec '03

17 Dec '03

From: rah(a)shipwright.com (Robert Hettinga) > At 5:19 AM 2/4/95, Anonymous wrote: > >I wonder if 'Net-cash' is any good? > > Probably the best discussion of the available transaction > processing/settlement mechanisms is by Jason Solinsky. It's called "An > Introduction to Electronic Commerce", and though he probably hasn't updated > it since he wrote it a few months ago, he discusses NetCash there... People interested in NetCash should be aware of a potentially confusing name re-use. NetCash is also the name of a payment system designed by people associated with the Information Sciences Institute (affiliated, I think, with USC). A reference is: <URL: ftp://PROSPERO.ISI.EDU/pub/netcheque/information/netcash-cccs93.ps.Z > Despite the names, neither one is cash in the cryptographic sense: neither uses blinding. If you didn't want the bank to be able to create a database of every transaction you make, everything you spend and with whom, you would need to have some anonymous connection with the bank and exchange your netcash through that connection. This would be cumbersome IMO. Some payment system is probably better than none, but I hate to see the name "cash" expropriated by these non-cash systems. Hal

1 0

Re: Why encrypt intra-remailernet.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

> Date: Sun, 29 Jan 1995 17:56:34 -0800 > From: Hal <hfinney(a)shell.portal.com> > > Of course it was Chaum himself in his 1981 paper (which I think is > available from the CP FTP site) who described the duplicate-message > attack. I don't see that inter-remailing encryption helps much, > because the attacker can still notice that whenever they inject > message A, _something_ goes to Bob. The real solution, as Chaum > pointed out, is that the remailer must reject duplicate messages, > even when separated by days. Doing this without keeping a database > of all messages ever sent is left as an exercise. Perhaps the postage could integrally contain the request-remailing- to field. Supose the postage were <e-money, to-address> encrypted to the remailer. Then replayers would want to copy the to-address into a new piece of postage. But, we assume, they can't figgure out what it is because they don't have the key for the remailer. If the remailer issued it's own non-blinded stamps, the remailer would have to keep a list of canceled stamps. (For as long as that series of stamps remains valid.) If the remailer used Chaumiam e-cash no logs would need to be kept at all. > Another aspect worth mentioning is that message splitting can make > the kinds of statistical correlations that Wei Dai was looking at > more of a danger. [...] Ideally you'd want to dribble them out at > some standard rate, a rate at which you always send a message > whether you have something to send or not. But this may introduce > unacceptable latency. If everybody ran a second level remailer, and if they always forwarded something (of very nearly the same size) when they recieved an encrypted message, then without compromising the users machine it would be imposible to say when a message was delivered. Some of the messages forwarded would need to be junk. Is there a polite way to send mail to a remailer, and ask it to junk the mail? Some of the messages forwarded would have to be 'part n of m' messages. Noyb

1 0