December 2003 - cypherpunks-legacy

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

interagency_workgroup.notice (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: Running regularly
by mbriceno＠netcom.com 17 Dec '03

17 Dec '03

Xenon askend: >> 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? Hal answered: >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. Netcom has a "policy against detached processes because of the load they put on the system and therfore 'crontab' and 'at' disabled for all users.(Netcom support)" To make your life even harder they kill all your processes upon hangup. Here is (half) the workaround: They forgot to disable "sleep" and they also didn't disable "nohup." You can simply write a script that sleeps for 30 min, executes your program and goes back to sleep. Call it with "nohup script &" and you're in business. The next problem that must be addressed is the auto-logout upon >14min of inactivity on the modem level that Netcom imposes on you. There is a simple 2 line command that you can add to your .login file to disable the auto-logout. I saw it once posted in one of the Netcom newsgroups, but I lost it. Perhaps you might post the question there. I would not advise to ask Netcom support for it... Some of the messages responding to the above post talked about "supending the account for intentionally disabling, blah, blah" 8-) Good luck, -- Marc Briceno <mbriceno(a)netcom.com> PGP public key by finger

1 0

reno_key_escrow.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

gore_crypto.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

harris.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

clipper_q-and-a.txt (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

wh_press_secy.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: STEG: a real-life use for steganography
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Eric talks about a hypothetical system S which he discussed with real acquaintance X of country C (with repressive government G), for stegging information I in through exogenously-produced CDs of indigenous music M. One problem is that S is proposed for use by lots of people in C. That means the whole system won't be a secret for long. Soon G will know not only which records and which equipment to ban, but also the passphrases for the records--so why encrypt or even camoflage it? Maybe making copies of existing popular records would help. Classics that lots of people already have. Are there already records produced for C but manufactured outside of C? Do they import music popular outside C? > -- A facility to gather the data being put on the disks. This by > itself is no trivial task, since it involves the collection of many > disparate sources. Maybe the newsgroup you mention is just the thing for the second-to- last step in the chain. It can combine efforts of people who don't have to know each other. > -- An encryption system for the arranged data. Such a system can't > treat the data as one long stream, because of the segmented nature of > the data. There's also the problem of recovering from errors on the CD. > The ability to mount the CD as a file system would be good > leverage for other programmers. > -- A decryption system to get the data off the CD. Can most CR ROM drives read the raw music format? Many? If not, can the bit stream to the ADC in a CD player be intercepted? Maybe the best hardware from a physical camoflage standpoint would be those little CDROM drives that double as "walkmen". > A system to make rememberable sentences out of an > arbitrary 128 bits (and the inverse) would be useful to facilitate > word of mouth. Isn't it good enough to always start with sentences invented by people and encode into bits? > encoding and error correction systems used in CD's. I do know that > they are not simple, being much more than bit-correcting linear codes. I think when they're not giving you exactly what you put in, they're doing desparate things like repeating the last few milliseconds. So about all you can do is put CRCs and IDs on blocks (maybe small blocks?) and be able to deal with lost and misplaced blocks. It might be useful to have signatures on block boundaries so you could recognize them out of continuous streams. Maybe you would just take two blocks worth of data and slide your buffer along one byte at a time till you got a good CRC...but by then you would have received a lot more data. Better have a long buffer. > -- A standard for the encoding of file system data onto these low > bits. This should be a separate document, even though the design of > this will be influenced by the bit encoding standard. Some adaptation > of existing file system standards may be appropriate. Here, too, you need to deal with lost blocks. Having one copy of the root of the index might not be great. Also, assuming you're using modified CD players instead of CDROM drives, you might want to take advantage of the music track structure. -fnerd quote me - - skip sweet sweetbacks badass skipjack song, jack. 3x, fast. -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0