December 2003 - cypherpunks-legacy

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

Re: to hfinney
by Hal 17 Dec '03

17 Dec '03

From: anonymous-remailer(a)shell.portal.com > 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 Perl does exist for ms-dos, and I think those scripts would probably work OK there. They don't do anything exotic, just some byte reads and writes. Maybe the random-number generation would need to be looked at; as I said, that is the one weak part. But probably they would work OK. Hal

1 0

Re: commercial authecation
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > Keith Henson asked how to find the digital-time-stamp folks, > Surety Technologies Inc., started by Stuart Haber and Scott Stornetta > as a spinoff of Bellcore. > > They're now actively in business - there was an article in one of the > trade rags that you can get their signature kit for PCs for > something like $50 with tokens for 50 notarizations. > Details on their web page. This technology is very clever and bound to be extremely important. But does anyone else think that the price is a little high? I mean the marginal cost can't be more than a few seconds of CPU time for each time stamp... This price tag will temporarily put the time stamp technology out of ubiquitous use, where every piece of e-mail, homework paper, Usenet post, etc., is automaticly time stamped in a cryptographically secure way so that authorship can be asserted and proved. I think the need for proof of authorship is going to become increasingly important in an increasingly online world, where copying is so effortless, and reputations are based on digital identities. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzMXKDl0sXKgdnV5AQFA+gP/XcrjAncBMVqocpXYfAaBR7RJ2PDR4ZF/ TEgCPcPM7we4eoR5w++7V+jsBhtNRSng5OUCeKQWSCU8BDnkUXuQNpQ8+fNKciMS RQWn1PBx4carczVOJoNyR1U8Rxu9tIH0Drh/NIZJ4324azpMOd8ysVFkJ4QODCPu 07Bf7pZ36c0= =tAcu -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai(a)eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ?

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 to hfinney
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

hal sez: : Perl does exist for ms-dos, and I think those scripts would probably work : OK there. They don't do anything exotic, just some byte reads and : writes. Maybe the random-number generation would need to be looked at; : as I said, that is the one weak part. But probably they would work OK. kool . could you please repost the scripts , i seem to have misplaced them. also , where can i get perl for dos , any idea ? tia .

3 2

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

Remailer Unreliability
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> Well, *I* think it is a good idea. But how does remailer1 know that >>remailer2 is both a remailer and down? > >By attempting a connection to the SMTP port and using the alternate if >it fails? This depends on a significant change in remailer features - existing remailers don't do message delivery, they pass remailed messages off to the local MTA (e.g, sendmail, Smail, whatever) and let it take care of delivery. Expecting remailers to handle queueing and delivery adds lots of code and complexity. (It also may piss off sysadmins who aren't remailer operators. Bogus or not, some institutions frown on attempting mail delivery manually or with non-standard programs.) Also, it's difficult to say when delivery has failed. Not every failure (where failure = not delivered in a reasonable time) results in a bounce message; if the sending remailer can't determine success or failure immediately, it will have to keep a database of the last few (hundred, probably) primary/alternate address pairs, and then extract the failed message from the bounce message, then reprocess with the alternate address. Yuck. I think the easiest way to do this would be for remailers to have a list of "unavailable remailers", and to process the primary/alternate choice immediately upon receipt/resending - but if we have a good way to provide the remailers with availability information, we've probably found a good way to provide it to users, too. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzKgyH3YhjZY3fMNAQHlkwP7Bj5D5PbC1H+x3XXqP3gdUTTL6eLMjt2d 6cmj/kr0nv88XwXkIttj7r4wSDRXSe8K4mpU4utNQ1l+RlArDzZLkiY/qleuRhGX yRplXo6eoNwSv24oBCIVwdu7r+gnlhVs4sU3tzkWD+deOQxVXffdPL0opZ1Cn8v6 qRmKmuOYFB8= =i/8j -----END PGP SIGNATURE-----

1 0

Re: VoicePGP cracked in 10 minutes?...
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> > I heard a rumor hear in Ctl. Tx. that the VoicePGP project was cracked in the > > last couple of days in approx. 10 minutes. Anyone have any info on this other > > than one of those wild rumors that occur? > > Considering that VoicePGP hasn't even been released, this is > fascinating news. Perhaps the same team could work next on cracking > things that haven't even been invented yet. Cracking VoicePGP is easy, since it's still a bones version without the encryption installed yet - anybody who can figure out where to get the software should be able to do it. Might take more than 10 minutes to do that :-) However, the rumor mostly sounded like a pro-active version of the "NSA cracked PGP" version of the FBI Modem Tax on Religious Broadcasting put out by Madeline Murray O'Shergold.

1 0

Re: Is the remailer crisis over?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> Well folks as of 11:30 on 1-30-94 there are 14 remailers with uptimes > greater than 99%. What's the consensus...Is the remailer crisis over? The "remailers are broken" crisis may be over, but until there are a lot of remailers in service, and 14 isn't a lot, with a lot of traffic on them, remailers won't be a very effective security tool. If the Bad Guys wanted to watch all 14 remailers, it'd probably not be hard to figure out which messages came from which senders, just because there aren't enough for real tracking. If the Bad Guys decided to confiscate 14 remailers, they could do it. If your machine got busted or sued for sending an anonymous message somebody didn't like, and you contended that you're a remailer and there was no way to prove it originated on your machine, "they" could respond that you're not one of the 14 well-known remailers and if you were "they" would have been watching you because they watch every machine that talks to the well-known remailers, and you're not one of them. As the folks in the nuclear-war planning business say, fewer than 100 of anything isn't reliable. Bill

1 0