- cypherpunks-legacy - lists.cpunks.org

Just testing the post
by uunet!in2.uu.net!news.sprintlink.net!news.utech.net!＠warwick.com 17 Dec '03

17 Dec '03

Post Test -- John G. Jones Director, Computer Services UTDS, Inc. <http://www.utech.net> <mailto:john@utech.net> 1593 E. Chestnut Lompoc, CA 93436 (805) 735-4447

1 0

Re: (Fwd) Gov't run anon servers
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 1:08 PM 3/5/96 -0800, Jim McCoy wrote: >The point is not to make a system which is absolutely, positively, no >doubt about it, secure against any attacker. If cypherpunks could do >this they would be working for defense contractors and others who make >certified systems. The objective is to make a system which is difficult >to attack, one which costs the attacker time/money. ... It seems to me that one of the best ways to better protect the remailer system would be to regulary change the remailer keys. By destroying the old secret keys, you protect the remailer and its operator against rubber hose attacks aimed at decrypting recorded traffic. As a suggestion: Assume you change the keys every week. You post this week's key to a public keyserver, replacing last week's key. To allow continuous operation you remember both this week's and last week's secret keys and process messages encrypted under either. To validate these keys, you use a long-term key to sign them. Note that for the really paranoid, this long-term key can be kept at a separate site, and only used after e.g. voice verification of the new key's fingerprint. Regards - Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: Remailer Security
by David E. Smith 17 Dec '03

17 Dec '03

At 11:06 PM 3/4/96 -0500, jrochkin@cs wrote: >At 11:06 PM 03/04/96, lmccarth(a)cs.umass.edu wrote: >Um, there's no reason why your remailer's account needs to be logged into >interactively, is there? Seems like remailer ops should disable login to >remailer accounts, putting '*' into the password field in /etc/passwd, or >however unix lets you disable login (I know it does). If I want a remailer's key, I would probably try to go after root. Not only will it get me that key, but there's no telling what else might turn up in the meantime. If you can get access to any account on the system, odds are good you can give yourself root access anyway. It's almost a "freebie." >Obviously, the general security risk of someone gaining unauthorized access >to the remailer executable or data files is still there, and important to >keep in mind. But this would seem to be a fairly logical security measure. You could always do a custom-compile of PGP that never checks for a passphrase; it's compiled into the executable. That's only a trivial measure at best (heck, hex editors have been around since roughly the dawn of UNIX) but it's a place to start. I don't think it's possible to have too much security. dave ----- David E. Smith, c/o Southeast Missouri State University 1000 Towers Circle South MS 1210 Cape Girardeau MO 63701 dsmith(a)midwest.net, dave(a)nym.alias.net, PGP 0x961D2B09 (573)339-3814 http://www.midwest.net/scribers/dsmith/ "Reality is only for those lacking in true imagination."

1 0

Square pegs in round holes
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

>Bob must find out whether Alice has declared (commited) her interest >in him, if and only if he has declared (commited) his interest in her. >Before he does so, he can at most know that a girl is interested in him. >Another description: Bob and Alice can have a date if they both commit >to each other. If only one commits, nobody will ever find out about it. >- T is the trusted third party. Well if we *must* use D-H that is a way, but why do that ? Instead of using a binary assymetric key, why not a triple ? (Just because I do not know of any does not mean that one does not exist). Consider a function such that Alice has a key such that given a message M, when encrypted by Alice may be manipulated by T such that Bob can decrypt it. Similarly, Bob has a key that when manipulated by T' can be read by Alice. Assymetric but not binary. The advantage here is that while "T" is trusted by both, he/she/it/other is not able to read either message, rather acts as a catalyst. Such a mechanism could be as indicated or could be circular e.q. a cipher such that A can generate a message readable by T who can generate a message redable by B who can generate one readable by A. True you could do this with three pairs of keys distributed alternatively so that a single person can only write left and read right. As to why you would want such a curiosity, consider a corporation with 80,000 mailboxes. It would be desirable for each person to be able to send E-Mail to any other person but not desirable for each person to have to hold all 80,000 keys. Given a triple (tertiary ?) function each individual would only need their receive key and a "post office" transmit key. On sending a message, it would be encrypted with a session key and the session key encrypted with the post office key. The post office would have all 80,000 receive functions but through the assymetic keying would only be able to convert the session key to something each intended recipient could decode but not be able to decode the message itself. This would meet both criteria (not key escrow but that is under "management") D-H is wonderful but has difficulties with scalability. If such a function existed (has anyone looked ?) it would solve the problem. "The exercise is left to the student" Warmly, Padgett

1 0

Re: FW: Communications Decency Act (hee-hee)
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

tcmay wrote: >Welcome to the Fourth Reich. Read _The_Ominous_Parallels_ by Leonard Peikoff JFA **** OLD KEY: USE ONLY FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

FW: Communications Decency Act (hee-hee)
by blanc 17 Dec '03

17 Dec '03

Had to share this funny bit with y'all...... .. Blanc ---------- From: William Pickard[SMTP:bpickard@pickard-murphy.com] Sent: Sunday, March 03, 1996 6:07 PM To: Mark Anderson Subject: Communications Decency Act Scott Adams, the author of Dilbert, contributes this to the debate: Communications Decency Act -------------------------- The government of the United States has passed a law which makes it a crime to transmit indecent materials over the Internet. As a citizen of this great country I plan to fully comply with that law. >From now on, whenever I get the urge to use an offensive word in e-mail I will substitute the name of an offensive politician. I urge you to do the same. The beauty of this approach is that they can't easily ban these new naughty words without changing their own names. I know I could get in trouble for suggesting such a thing, but I don't give a flying Clinton what they think. And if they don't like it they can come over here and kiss my Gingrich. William Pickard bpickard(a)pickard-murphy.com Pickard & Murphy, Inc. Telephone (206) 323-5979 3213 East Alder Street FAX (206) 860-4877 Seattle, Washington 98122-6314

1 0

TER_ror
by jya＠pipeline.com 17 Dec '03

17 Dec '03

EcoMist, March 2, 1996: "What is terrorism? The use of terror is more widespread and effective than is generally recognised." A special essay that weighs military action, guerrilla warfare and terrorism. TER_ror ----- This issue also presents "in the mind of the terrorist," "a new plan for Ulster" and "Israel, Palestine and Hamas."

1 0

key security for anon remailers
by Bill Stewart 17 Dec '03

17 Dec '03

We've been discussing the security problems with leaving your PGP key around on anonymous remailers. Mixmaster and the ghio2 remailers have the key compiled in, but at least for ghio2 the string is sitting there unencrypted and unmasked in the binary, where somebody who can access the binary can run "strings" to steal it, without even the bother of decompiling :-) The primary alternative is to start up the remailer with the PGP passphrase in its environment, but doing that has its problems - the ghio2 remailer is made to run as a batch process called for each message, rather than a permanent listener, and if you did something like put the key into the sendmail daemon's environment, it'd probably be even easier to steal (e.g. anybody on the machine could do it by setting up their own mail-processor.) A minor hack that I do with my remailer is to keep two versions of the source - a vanilla one for distribution, and one with all my customized information that I actually compile and run. So how can you keep a persistent process that isn't part of the mail empire? One approach is to have a remailer daemon using sockets or named pipes that does the decryption and feeds mail to a remailer process (which _it_ calls) for delivery or has its own builtin remailing - you'd input the key to the daemon when you start it up, and wouldn't need to leave it in a file or environment, just in the executing process itself. Probably an hour's hack using PGP3.0, or you can grind up the current I/O routines for PGP 2.6.2 and ignore the fact that you void your RSAREF license that way. You'd have to get rid of some of the code that overwrites the passphrase and other sensitive data, though. Another approach is to have a separate box that's not on the network that the remailer runs on (obviously this is easier on a machine you've got at home or work rather than at an ISP...) You can take that old 8086 or 386, run a daemon to accept files on the serial port and return them to the mail system on the serial port. Uucp is probably secure enough. (Does PGP run on Minix, or on any of the old Xenix or Venix operating systems? It's probably easier to build workable communications daemons on one of them than on DOS, though there are DOS uucp and kermits that you could hack up. For a 386, Linux is the obvious choice.) Since the entire remailer would be running on the box, and you don't permit logins from the serial port, it's probably pretty secure, even against someone with root on the network-connected machine, assuming all your traffic is encrypted.

1 0

St. Louis Cypherpunks
by eggplant＠inlink.com 17 Dec '03

17 Dec '03

I'm lookig for people who live in the St. Louis area who are interested in computers in general and the internet specificly. If you could drop me a line, I would be most appreciative. Thnx in advance.... -- "... In Germany they first came for the Communists and I didn't speak up because I wasn't a Communist. Then they came for the Jews, and I didn't speak up because I wasn't a Jew. Then they came for the trade unionists, and I didn't speak up because I wasn't a trade unionist. Then they came for up because I wasn't a trade unionist. Then they came for Catholics, and I didn't speak up because I was a Protestant. Then they came for me-and by that time no one was left to speak up..." Pastor Martin Niemoller ++++++++++++ ************************************** * Matthew Murphy ------------ eggplant(a)inlink.com * ---------- * http://www.inlink.com/~eggplant * The Web page is under construciton at this time though.. * Please don't mind the mess.... * ************************************** ++++++++++++ finger eggplant(a)inlink.com for my PGP key.

1 0

Re: SEAL cipher info requested (something actually list related!)
by Mutant Rob 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Christopher Allen wrote: > What I am seeking is more than what is in the book: > > * are there are any links on the web to SEAL? I tried skimming the web and found little relevant info. [..] > * has anyone currently licensed it? I have heard through the grapevine that Richard Mark's version of UUENCODE implements SEAL. > * should we be (the community) be looking at SEAL > for standards (say as an alternative to RC4?)? RC4 is not patented, and AFAIK RSA is not actively seeking royalties etc. for using it. SEAL is patented/patent pending. - --- [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 iQBFAwUBMT2TwioZzwIn1bdtAQEWnwF/arOP9WA0xMEFNtrPMUt4eTlUPzxRmTnf qbfvyvd9Kd2H9BG4dNF1lgzVFLfj6GnI =nzCA -----END PGP SIGNATURE-----

1 0