- cypherpunks-legacy - lists.cpunks.org

info on local/regional groups & sublists
by Stanton McCandlish 17 Dec '03

17 Dec '03

For my OUTPOSTS list/FAQ, if you have any (public) inforation about local cypherpunks groups and sublists, like the Austin lists, or the UK branch, please let me know via personal email. Need to put out a new version of the FAQ soon, and am missing much info. All I have so far is: Main general: hughes(a)soda.berkeley.edu Main subscribe requests: cypherpunks-request(a)toad.com Main FTP: soda.berkeley.edu, pub/cypherpunks Hardware general: jdblair(a)nextsrv.cas.muohio.edu Hardware requests: cp-hardware-request(a)nextsrv.cas.muohio.edu Wonks general: cypherwonks-owner(a)lassie.eunet.fi Wonks requests: majordomo(a)lists.eunet.fi (message body of: subscribe cypherwonks [1st & last name] [address]) Austin general: Jim McCoy <mccoy(a)bongo.cc.utexas.edu> Doug Barnes <barnes(a)io.com> Austin req. austin-cypherpunks-request(a)bongo.cc.utexas.edu austin-cypherpunks-announce-request(a)bongo.cc.utexas.edu Austin FTP: ftp.cc.utexas.edu, pub/cypherpunks Any info on other CP groups, corrections to what little I have, pointers to other CP file sites, gopher/WWW/Wais servers, etc. all appreciated. Even some BBS number, snailmail addresses for any local groups that are getting less virtually, more physically organized, etc. That, and relevant other lists (anything that might be consider "online activist" or civil libertarian in nature) and resources. Again, please send via email to mech(a)eff.org rather than on the list. Muchas gracias in advance! -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

White House crypto briefings: Clipper, FIPS, escrow agents, export
by Stanton McCandlish 17 Dec '03

17 Dec '03

Briefings on Federal Encryption Policy/Telecommunications Security Today (Feb 4), the Administration will hold 2 briefings about cryptography and the Clipper chip. The briefings will "report on a review of federal policies and procedures for encryption and telecommunications security-related products and technologies." The first briefing, at 11am EST (i.e., in less that half an hour of this posting), will update Congressional committee staff, and the second will address concerns of industry reps, public interest groups, privacy advocates and other non-government parties. EFF will attend this second meeting, at 1pm EST. EFF will share what it learns about the results of either briefing as soon as possible. An early "heads up" from the the Administration indicates that the main subjects for the briefings will be: Administration will announce Clipper/Skipjack Federal Information Processing Standard (FIPS) Justice Dept. key escrow procedures to be announced Announcement of Treasury and NIST as Escrow Agents Decisions on encrytion products that fit under current export standards announced. Other topics also likely to be addressed (unconfirmed): State Dept. will, surprisingly, streamline procedures for export of Clipper Administration not going forward with DSS licensing agreement with PKP/RSADSI. -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: New remailer up.
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

>Before I start throwing out ideas that I'm sure aren't new to readers here, >I have a simple question that perhaps I should post to comp.unix.questions >or comp.lang.perl, but.... Can I, and how would I, get a perl script to >kick in and send out mail every few minutes when I am NOT logged in. Is this >possible on Netcom? Rather than try to run in some asynchronous mode as you suggest, why not do the following when each message arrives: place message in your queue, designating random hold time foreach message in the queue that's been held long enough send random number (1<=n<=3) dummy messages send the queued message send random number (1<=n<=5) dummy messages The whole thing remains data-driven while you're not logged in and can be manually flushed if you are logged in. So long as there is a steady stream of traffic, messages won't get stalled for long times. You could even send some 'activation' messages at controlled intervals from some comfortable site (where you can use cron), routed via another remailer. Just some ideas off the top of my head.

1 0

REMAILERS: Netcoms Policy and hazards to remailers
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

An issue arose today with Netcoms DASD migration... My Account was moved from /ux/accountname to /uxx/accountname, which caused my .forward file to begin bouncing mail. Netcoms sysadms promptly moved my .forward to .forard.bak to eliminate the bounces and notified me via the now working mail. During my conversation with the admin I asked specifically what Netcoms policy vis-a-vis ECPA, search warrants, and warrantless requests from Law enforcement of any kind for both e-mail in transit and stored files.. The answer was as it should be. A "proper" search arrant would be required prior to cooperation with LE. Netcom as a policy ill NOT provide ANY materials other than account name without a search warrant, unless an account on netcom is used to crack another site and netcom is liable( in which case they will file a complaint and give cooperation to investigating officers.) a warrant is required for release. The subject of remailer and crypto out of a netcom account didnt elicit any comment from the sysadmin...) Tomorrow I will call and ask specifically on that area... anon

1 0

Re: Running regularly
by Matthew Bernardini 17 Dec '03

17 Dec '03

> > Before I start throwing out ideas that I'm sure aren't new to readers here, > > I have a simple question that perhaps I should post to comp.unix.questions > > or comp.lang.perl, but.... Can I, and how would I, get a perl script to > > kick in and send out mail every few minutes when I am NOT logged in. Is this > > possible on Netcom? > > Most public Unix systems will not let you do this, in my experience. > The two Unix commands which usually give you the ability to run programs > at regular intervals are "at" and "crontab". You can read the man pages > and try running these to see if they are enabled for you. > > I had an idea for how to get around this, so that people could run batching > remailers which sent out mail, say, every 30 minutes or whatever. (Unlike > Xenon, I am of a generation which is accustomed to waiting more than a few > seconds for mail to travel across the country!) The idea was simply for > someone who DID have an account which would let them use at or cron, to > run a program which would simply send a "ding" message (not to be confused > with a "ping" message :) at regular intervals to a list of subscribers. > This message could have a special header field so that the remailer programs > could easily recognize it and take whatever action they wanted, like running > Karl Barrus' script to scan a directory for pending outgoing remailer mail > and send it out. (Karl has had batching running for months, as well as > postage-stamp-based remailers (albeit with non-anonymous stamps). He is > way ahead of most of this discussion.) > > Hal > > Perhaps this is too rudimentary ..... Why not make two shell scripts, one that sleeps for so long (say 20 minutes) using the unix sleep command, and then calls the remailer scripts in an infinite while loop. This would work if you set it up as a background process,and you don't need to be root for it to work. Only downsides are that when the machine crashes you have to log back in and restart script, your sleep command will always be in the top window if your sys-admin is watching, and you have to be careful not to spawn to many processes and bring the system down. Matt

4 3

Re: Prodigy snooping
by Mike Ingle 17 Dec '03

17 Dec '03

>I heard from a friend that Prodigy was scanning user's hard drives. >Basically, when you logged on Prodigy made a complete directory of your >hard drive and uploaded it. Prodigy was using this to find out what >applications you used so they could direct the appropriate advertising >towards you. Apparently, they're suffering several lawsuits now because >of it. This tale has been around for a while. Prodigy makes a huge file, over 1 MB, on your hard drive and stores information there to speed up the data transfer. People started finding bits of their files in there. They claimed that Prodigy was snooping into their systems. Prodigy denied it and claimed that their software just didn't bother to clear the disk space when it allocated it, so whatever was there, stayed there until the space was used. They distributed a utility which would zero out that information. Whether they were really snooping or not, who knows? If they were, they were pretty stupid to leave clear text in the file. >My friend heard this on the trailing end of a radio talk show. If it was >really happening, it sounds horrible. Could Secure Drive be set up to >stop this kind of attack? Secure Drive would stop it if you weren't logged into the encrypted drive when you ran Prodigy. Of course, if you were logged in and they knew about Secure Drive, they could get your encryption key as well as your data... --- Mike

1 0

request for information
by dave_taffs＠rainbow.mentorg.com 17 Dec '03

17 Dec '03

I saw the following on imp-interest, and thought somebody here might be interested in responding (perhaps?)... PS: She has David Chaum's internet address by now, I'm certain... to: imp-interest(a)thumper.bellcore.com from: owner-imp-interest(a)thumper.bellcore.com date: Fri, 4 Feb 1994 10:29:56 -0500 (EST) subj: Digicash story/Internet Letter sender: jayne levin <helen(a)access.digex.net> sent: 02/04/1994 8:33 am (PDT) --------- **| I would like to explore the issue of digital cash in my next issue of The Internet Letter. I am trying to contact David Chaum but don't have his e-mail address, so I'd appreciate any help in making contact with him. I'd also like to get a grip on some of the issues involved in developing digital cash as well as the status of work in this area. Who else should I talk to? Jayne Jayne Levin Net Week Inc. Editor 220 National Press Building The Internet Letter Washington, D.C. 20045 USA +1 202 638 6020 Fax: +1 202 638 6019

1 0

Running regularly
by Hal 17 Dec '03

17 Dec '03

> Before I start throwing out ideas that I'm sure aren't new to readers here, > I have a simple question that perhaps I should post to comp.unix.questions > or comp.lang.perl, but.... Can I, and how would I, get a perl script to > kick in and send out mail every few minutes when I am NOT logged in. Is this > possible on Netcom? Most public Unix systems will not let you do this, in my experience. The two Unix commands which usually give you the ability to run programs at regular intervals are "at" and "crontab". You can read the man pages and try running these to see if they are enabled for you. I had an idea for how to get around this, so that people could run batching remailers which sent out mail, say, every 30 minutes or whatever. (Unlike Xenon, I am of a generation which is accustomed to waiting more than a few seconds for mail to travel across the country!) The idea was simply for someone who DID have an account which would let them use at or cron, to run a program which would simply send a "ding" message (not to be confused with a "ping" message :) at regular intervals to a list of subscribers. This message could have a special header field so that the remailer programs could easily recognize it and take whatever action they wanted, like running Karl Barrus' script to scan a directory for pending outgoing remailer mail and send it out. (Karl has had batching running for months, as well as postage-stamp-based remailers (albeit with non-anonymous stamps). He is way ahead of most of this discussion.) Hal

2 1

Re: Running regularly
by Matthew Bernardini 17 Dec '03

17 Dec '03

> Matthew Bernardini <matthew(a)gandalf.rutgers.edu> wrote: > > > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > > using the unix sleep command, and then calls the remailer scripts in an > > infinite while loop. This would work if you set it up as a background > > process,and you don't need to be root for it to work. Only downsides are > > that when the machine crashes you have to log back in and restart script, > > your sleep command will always be in the top window if your sys-admin > > is watching, and you have to be careful not to spawn to many processes and > > bring the system down. > > I tried this on the system here, but it killed off the process when I > logged off. > > As for starting too many processes, just don't start them... leave it > as one single process that just repeats itself indefinently with sleeps > in between. > Did the processes get killed BECAUSE you logged off ? Or did they get killed because you left a single process runnning in the background for an extended period of time and an automated script killed the job. Why not ask the sysadmin how to setup a long computational job for a couple of days ? I don't think any sysadmin would have a problem with that. Then you could find out if the jobs are killed automatically somehow. If it turns out that it was just the process that was automatically killed on a time interval, then you could easily write a script that would spawn a new process and then kill the parent. Matt

2 1

Re: CERT advisory
by smb＠research.att.com 17 Dec '03

17 Dec '03

>The big issue, in my mind, is how the ftpd is going to get the key >to unlock the *system's* private key... Do you compile it into the >code? Should ftpd ask for it when it comes up? Since active interception is not nearly so easy as passive listening, it would be appropriate to use a Diffie-Hellman key exchange in this situation. This protocol has no persistent private keys, so the issue of keeping a private key around securely is not an issue. But you still have to type a password to a command that itself could have been compromised. (Not that D-H wouldn't be a tremendous help, of course.) All of the hand-held authenticators I'm familiar with require that the host -- or a dedicated, trusted, security server -- keep a secret key per user. That's not a great idea. Bellcore's S/Key doesn't, but I don't know of any hardware devices that implement it. Another possibility would be hand-held digital signature boxes that could sign a random challenge from the host.

1 0