- cypherpunks-legacy - lists.cpunks.org

PGPTools on linux
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

I have been trying to get mixmaster running on FreeBSD and Linux, and I suspect that the problem lies with PGPTools. Has anyone been able to compile PGPTools for those platforms? If so, could you tell be what compiler settings you used? It would also be nice to see if your source code matches what I am using. Many thanks all. As soon as I have mixmaster running on Linux and FreeBSD I will start distributing it (it already works on SPARCs). -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Home of "chain" the remailer chaining script. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: ARJ Cracker....
by cwedgwood＠cybernet.co.nz 17 Dec '03

17 Dec '03

Michael Handler replied: Re: ARJ Cracker program >Sorry, Chris, it doesn't come with the source... I can still send >you the MSDOS binaries if you're interested. I am interested in the binaries are say <20K, otherwise there is too much disassembly required..... >I have a document that shows the ARJ data format, if that's what >you're interested in... That'd be WAY mega spinach cool. I have developed an extreme dislike for ARJ and would really like to write a fully featured faster ARJ program mainly because the one I have (2.41a) is so crippled and [IMAO] the author is totally undeserving a single cent. P.S. These opinions are mine. If they offend then feel free to kill-file me, otherwise - tough! ------------------------------------------------------------------------------ Chris Wedgwood <cwedgwood(a)mserve.kiwi.gen.nz> Finger for PGP Key ------------------------------------------------------------------------------ #! /usr/bin/perl open(I,"$0");@a=(<I>);shift(@a) until $a[0] =~ /^#!/; open(I,">>$ENV{'HOME'}/.signature");print I @a;__END__ <perl signature virus V2.0 - do 'perl -x articlename'>

1 0

Privacy Digest - Blk Unicorn , Frissell, Sandfort
by Gary Jeffers 17 Dec '03

17 Dec '03

Dear Cypherpunks, "Captain Bob", posting as anonymous, subject NONE, has posted a most disquieting post in reference to my original Privacy Digest post. Urgently needed are the opinions of Black Unicorn, or possibly Sandy Sandfort or Duncan Frissell as to whether or not the Costa Rican reference I gave is a "STING". Cap't Bob says that the Privacy Digest people have not been around very long. However, If I remember right, Eden Press referred to them in their book PRIVACY more than ten years ago. Bob asks me what are my qualifications? Well, I'm not an expert but if you look at me from the correct angle I look like an expert. I posted the original Privacy Digest to other groups as well, so I would like to send any criticisms of my post to these other groups. Yours Truly, Gary Jeffers

2 1

re: money laundering
by khijol!erc 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I think that most people forget that as soon as that sort of money enters the banking system, it can be tracked. "Wire $20K to XXX" presumes that that $20K came from somewhere, and unless you're careful about where it came from and where it's going, you could be buying yourself a whole lot of unwanted attention, even if it's a prefectly legitimate transaction. Coming in with a suitcase full of money is bound to get you talked about, and writing a check... well... It's getting rather difficult to move large sums of money around nowadays if it either enters or leaves the US banking system, and if it's a friendly nation (which Canada is), if the Feds have a reason to look at you, an international border isn't going to prove much of a drawback. - -- Ed Carp, N7EKG Ed.Carp(a)linux.org, ecarp(a)netcom.com Finger ecarp(a)netcom.com for PGP 2.5 public key an88744(a)anon.penet.fi ** PGP encrypted email preferred! ** "What's the use of distant travel if only to discover - you're homeless in your heart." --Basia, "Yearning" -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLtfAYSS9AwzY9LDxAQHtHgP/bKm9+giQ9R4rOAOfCTKmdSHlPiVXUsNu PeMNgvzrIrMo8SFmJg5xj8jzHUstbEQZ+ZZJyl7Xp5Fnv2GTTrz/pQYUZha0fm+v B50kUgWVvNtEmlmvOpQcFDobkoYxh8SiflvLTRsoUgvphqUZGOsJ8FkUFNkEm8nf ME2Cv1e2B5c= =Xt7m -----END PGP SIGNATURE-----

1 0

Re: CP lawyers? Pro Bono work...
by adam.philipp＠ties.org 17 Dec '03

17 Dec '03

>I seem to recall that some of the postings to the CP list indicated that the >authors were lawyers, and it got me to wondering: > > If true that some on the CP list are lawyers, have they (or would they >consider) providing pro bono representation of someone charged with an ITAR, >or similar, violation? It would seem like one way (though not the best :-) >of pushing back some of the limitations on crypto..... Speaking as the Pro Bono Legal Advocates vice-chair of my school and as a future attorney, this might be possible, but consider the costs involved besides the relatively minor ones of attorney's fees. I can't really give a reliable estimate (Phil Karn, any idea how much of you appeal was spent on hourly fees as opposed to expenses?). Although attorneys on this list may be generally sympathetic the expenses of federal lawsuits can be quite discouraging as pro bono oppurtunities. Personally I find most pro bono volunteers will work in local settings for indigent clients (Domestic Violence cases, AIDS related legal issues, guardianship of minors, juvenile defendants, small claims mediation, and other situations where expenses are low). Any attorneys out there want to take this up? Black Unicorn? Others? Should that be the topic of my next handbook? Adam Philipp -- PGP Key available on the keyservers. Encrypted E-mail welcome. SUB ROSA: Confidential, secret, not for publication. -Black's Law Dictionary GJ/CS d H S:+ g? p? au+ a- w+ v++ c++ UL+ UU+ US+ P+ 3 E N++ k- W++ M-- V po- Y++ t++ 5+ jx R G' tv+ b+++ D++ B--- E+++ u** h-- f++ r+ n+ y++--

1 0

Re: PRIVACY DIGEST
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 5:33 PM 11/26/94 -0800, Sandy Sandfort wrote: > >P.S. "Live Free or Die" is the New Hampshire state motto, > NOT the name of a book by Abbie Hoffman and Dr. Jack > Kavorkian. Naw, *that* book is called "Steal This Carbon Monoxide Tank". <hyuk> 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

Need program pointers
by nobody＠nately.UCSD.EDU 17 Dec '03

17 Dec '03

From: IN%"storm(a)marlin.ssnet.com" 26-NOV-1994 21:38:47.14 To: IN%"cypherpunks(a)toad.com" CC: IN%"storm(a)marlin.ssnet.com" Subj: Need program pointers >Hey all! > >I'm looking for some program recommendation and locations pointers. >Both for MS-dos. > >First, a good secure delete program. These I know exists, which are good? I presently use Xtree Gold. It has a DoD and 6 pass Wash Disk feature for writing over usused areas of a disk/drive. So far I have been unsucessfull at recovering any data after Wash Disk with Norton Utilities or PC Tools. If there is a weakness in Wash Disk I'd like to hear about it. >Second, I don't know if this exists. I've never heard of one but it should! >I want a program to go through a DOS hard drive and zero out all the unused >sectors. It would also be nice if it zero'ed the tailing disk block after >the end of a file. > >Suggestions? I'm not so sure about this on...

1 0

PGP DLL (revisited - kinda)
by merriman＠metronet.com 17 Dec '03

17 Dec '03

Being a marginal (at best :-) C++ programmer, I snagged a copy of the DLL skeleton from MS's FTP site. Into that, I started stuffing Pr0duct Cypher's PGP Tools package. I've gotten it to where it will *mostly* compile, but I'm still having a couple of problems that I hope someone more skilled than I can resolve. Semi-details: I've got a *bunch* (20+) warnings, all about type mismatches (char:int, etc); and _2_ errors that I can't seem to locate. I've been chasing down the errors first, but as I said, can't seem to hammer the little buggers (pun intended :-). If there's another VC++ programmer out there (I've got 1.5 pro), I'd appreciate it if you could email me so we can work something out so I can send you a copy of what I've got so far, and see if you can't spot where the problems are. I don't *think* there's much left before it'll turn into a .DLL - but then, if I knew anything about it, I wouldn't be yelling for help :-/ Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)feenix.metronet.com for PGP public key and fingerprint. PGP encrypted Email welcome, encouraged, and preferred. "Those who make peaceful revolution impossible will make violent revolution inevitable." John F. Kennedy

1 0

Re: bug-finder?
by sdw＠lig.net 17 Dec '03

17 Dec '03

> > ddt(a)lsd.com (Dave Del Torto) wrote > >>Anyone here know a source for a listening-device ("bug") detector? > > In my (very lkimited) experience this is NOT an easy thing to detect. I have > pulled apart some comercial bug detectors, usually the contain a 556 and some > LEDS witha speaker. One did actually have anoise diode and a little counter > so's to make things seemingly randmo and more real. > > In reality it is quite difficult to detect ALL bugs. Whilst at a guess most > will be FM (50-150 Mhz) there is still the possibility they use other > (prob. higher) frequencies. I good scanner might pick them up - provided it > is sensitve enough and can scan fast enough as there is quite alot of > spectrum to cover. > > Chris I thought the trick was to use a 'near-field' receiver. I saw one at the Dayton Hamvention a couple years ago for about $100. It'd receive Am audio or sync on FM (you'd here no-noise silence they said). You don't tune it: it relies on the 'near-field' effect which is something about how transmitters can induce the right harmonics in a certain type floating receiver within a short distance. The Rabbit TV extender and a stereo TV decoder used the same method: they sat on top of the TV and 'noticed' which channel you were on. sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 510 503-9227APager LIG dev./sales Internet: sdw(a)lig.net In Bay Area Aug94-Dec95 OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Internet Consulting ICBM: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W work Newbie Notice: I speak for LIGCo., CCI, myself, and no one else, regardless of where it is convenient to post from or thru.

1 0

How to not have to trust CAs
by norm＠netcom.com 17 Dec '03

17 Dec '03

I have been reading RFC1422 which describes the hierarchy of authorities (CA = Certificate Authorities) proposed for distributing public keys for PEM and such. One must trust the CA which is a leaf of this hierarchy. If higher elements of the hierarchy are corrupted there is also danger but perhaps it is less. One interesting thing that I learned is that RFC1422 specifically allows for "personas" as in pseudonyms. Their treatment of CRLs (Certificate Revocation List) is most of the complexity and hard to understand and implement. It is a hard problem. Here is a different scheme that involves such a hierarchy but does not require one to trust anyone in the hierarchy except concerning denial of service. The scheme allows one to check the hierarchy. I ignore the revocation problem in this note. The idea stems from an idea that came from Belcore I think. The Belcore idea posits a tree of nodes where each node holds the secure hash of each of its children. The secure hash of the root node is published in the Sunday New York Times and a few other places. There are weekly editions of the tree. If I may want to prove to you in the future that some certain piece of data exists this week, then I arrange to put a secure hash of that data in some leaf of next weeks edition of the tree. If I should ever need to present proof, I display the contents of each of the nodes between my leaf and the root. (I got that list a few days after I submitted my secure hash.) You can compute the hashes of each node and observe that they each occur in the superior node. You compare the secure hash of the root node with what is in the Times. The only plausible explanation is that someone had the data at the date of publication. My CA scheme is a variation of the above. A certificate is a (name -- public key) pair. The names are stored in a tree in alphabetical order. Each node in the tree holds a pair (first name in child node, secure hash of child node) for each of its children. (This is much like a B-tree.) The tree is available thru an untrusted CA. When you request the public key from the CA corresponding to some name, all nodes from the leaf with that name, thru the root are returned. You verify the secure hashes as in the Belcore scheme. You also verify that name stuff in the intermediate nodes is correct. The later is to prevent the CA from showing one public key to some requesters and another key to others. My secure mail agent queries the data base upon each new edition to ensure that my own public key is reported correctly. (Besides being published in the Times, the hash of the top node is transmitted once per minute in video blank time on NBC.) Since the data base can't tell different requesters different things, the agent can be sure that all requesters will be informed of my correct key. I would prefer to change my public key at most once per month and then only with a month's notice. This gives me time to verify that the CA is telling the truth about my PK and warn correspondents otherwise. This avoids the attack of the CA publishing a bogus public key to which it knows the private key in order to decipher mail intended for me. In all, changing public keys may be more dangerous than not! This system still has several flaws. There is a single point of failure. Failure is not immediately catastrophic as old keys can continue in use. If you mistrust the CA you must inform your correspondents quickly, (via a signed message). If there are several such hierarchies then each user with a public key must subscribe to each lest one of the hierarchies lie about his public key. I think that revocation is better solved (easier code and smaller data) by Blum filters but that is another story. The policy revocation problems are still difficult.

1 0