December 2003 - cypherpunks-legacy

Distributed "Family" of processors
by PMARKS＠VAX1.UMKC.EDU 17 Dec '03

17 Dec '03

I recognized the basic schema in the following from the history of the French Resistance movement. The idea is for critical information to be held in separate "cells" each of which knows only enough to inteact with the others, but not enough to compromise the entire net. ************************************************************************** Consider three sets of code in three computers that constitutes a "Family"(the whole program). "Grandpa" talks to "Pa". "Pa" then talks "Son". "Son" then talks to "Grandpa". Each "Family" member closely monitors its cup clock & if its expected message is not received on time - it suicides! Capture "Pa" & in seconds, "Grandpa" & "Son" take their own lives! That is to say, they scramble certain essential parts of themselves including cryptographic sections. ************************************************************************** In any covert activity, many conditions will lead to a mission abort. This is largely due to the paranoid nature of the activity and the low level of trust in others neccessitated by said activity. If even one aspect seems "wrong" the meeting, transmission, transfer, trade, whatever, is called off. No offense intended, and ususally none taken. When you are trying to be covert, everyone fears compromise. A computer system so paranoid that it swallows a poison-pill whenever it suspects unauthorized tampering (read: investigation) would be fairly secure, but unreliable. ***Many*** conditions would trigger the "trip-wire" mech- anisms so the system would have to have a high order of built-in redundency. What it always boils down to is, "who do you **really** trust?". Or, boy was my face red when I found out I vouched for my best friend's public key only to find out that he worked for the NSA. (Think it doesn't happen? HUMINT will tell you much more than Signal Analysis ever will.)

2 1

Remailers
by David Merriman 17 Dec '03

17 Dec '03

I 'know' that a decent remailer will time-delay forwarding messages so as to throw sand in the gears of traffic analysis. I wonder if it wouldn't help more if the remailer(s) were set up so that people could send 'dummy' messages to them. That is, say I wanted to ensure that traffic analysis on myself were made as difficult as possible. I could Email something to a remailer with an embedded 'flag' or code (ex: blackhole, disposal, trash, etc) telling it to forward the message to the Bitbucket. Alternatively, I could include some other code or flag (ex: rubber, bounce, ricochet, etc) telling it to take the included (dummy) data, scramble it some, and return it some random time later. Alternatively, the remailer could take a so-tagged message, generate some random data of similar size, and send it (along with my address) to another remailer that it knew about, which would generate *different* random data, and sent that back to me. Wouldn't something like this further complicate traffic analysis, or would it just constipate the net? Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Politics: fr. Latin 'poly' meaning 'many'; 'ticks' small blood-sucking parasites.

1 0

Re: Remailers
by Hal 17 Dec '03

17 Dec '03

From: David Merriman <merriman(a)metronet.com> > That is, say I wanted to ensure that traffic analysis on myself were made > as difficult as possible. I could Email something to a remailer with an > embedded 'flag' or code (ex: blackhole, disposal, trash, etc) telling it > to forward the message to the Bitbucket. Try chaining the message through multiple remailers, then to a bitbucket address. One such address is "nobody(a)soda.berkeley.edu". Presumably there are many of this type. > Alternatively, I could include > some other code or flag (ex: rubber, bounce, ricochet, etc) telling it to > take the included (dummy) data, scramble it some, and return it some > random time later. Send yourself an encrypted message, chaining through a bunch of remailers. See the cypherpunks ftp archive on soda.berkeley.edu for scripts which will let you do these things. Hal

2 1

current remailer list?
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

Would someone please forward me, or tell me know where I can find, a current list of remailers? I am no longer on the general cypherpunks list-- please e-mail me directly. thanks in advance, -john. -------------------------------------------------------------------------- John Blair: <jdblair(a)nextsrv.cas.muohio.edu> voice: (513) 529-4877 http://phoenix.aps.muohio.edu/users/jdblair/home.html KILL YOUR PGP public key available upon request. TELEVISION

1 0

Re: Byzantine Agreement Problem
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

The "Byzantine Agreement Problem" is _not_ solved in theory. The last time I surveyed the literature, it was still widely conjectured to be theoretically intractable. It has direct implications on networks and networked systems; however, often some of the constraints of the original problem can, with effort, be violated---which makes practical systems more feasible. These violations usually take the form of a second, more reliable, band of communication. Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: current remailer list?
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

Before my mailbox is filled with answers, thanks to Karl Lui Barrus for answering my request for a remailer list. -john. -------------------------------------------------------------------------- John Blair: <jdblair(a)nextsrv.cas.muohio.edu> voice: (513) 529-4877 http://phoenix.aps.muohio.edu/users/jdblair/home.html KILL YOUR PGP public key available upon request. TELEVISION

1 0

Clipper LEAF Holes?
by Mike Ingle 17 Dec '03

17 Dec '03

As I understand the Clipper/Capstone LEAF, it works like this: Take 80-bit session key. Encrypt with device-unique key. Add 32-bit serial number and 16-bit checksum. Encrypt resulting 128-bit packet with family key. One of the EES chips, the type designed for cellular and other phones, operates in "1-bit CFB mode". This would seem to indicate that it is a straight-thru device - that the data input and output rates are the same. So the LEAF is only sent once; it is not repeated throughout the output. The user is forced to send a valid LEAF because the receiving chip will not set up without receiving a LEAF. But how does the receiving chip check to see if the LEAF is valid? The obvious way is to decrypt it with the family key, and then verify the checksum. But EES chips for different countries will have different family keys. So if an American EES chip sends a LEAF to a foreign one, how does the foreign one verify the LEAF? Even if the receiver can decrypt the first level of the LEAF and examine the checksum, it doesn't have your device-unique key, so it cannot check to see if the session key in the LEAF is the same session key that you sent to it. So it would seem that any valid LEAF would work, even if it is not the one for the current session key. Am I missing something in the Clipper design which prevents this? --- Mike

1 0

The un-BBS
by Mike Ingle 17 Dec '03

17 Dec '03

There are occasional waves of actions against BBSes. The most recent onFrom owner-cypherpunks Sun Apr 24 05:14:11 1994 Return-Path: <owner-cypherpunks> Received: by toad.com id AA22474; Sun, 24 Apr 94 05:14:11 PDT Received: from cap.gwu.edu by toad.com id AA22467; Sun, 24 Apr 94 05:14:06 PDT Received: by cap.gwu.edu (4.1/SMI-4.1) id AA27650; Sun, 24 Apr 94 08:14:43 EDT Date: Sun, 24 Apr 94 08:14:43 EDT Message-Id: <9404241214.AA27650(a)cap.gwu.edu> From: sniles(a)cap.gwu.edu (Sabastian Niles) To: cypherpunks(a)toad.com Subject: FTP sites Reply-To: sniles(a)cap.gwu.edu Sender: owner-cypherpunks(a)toad.com Precedence: bulk Does anyone here know any good FTP sites for text files relating to programming/privacy issue/computer underground/or the like? If so, please e-mail me at sniles(a)cap.gwu.edu. Any sites that carry zipped files of the same subject matter would be welcome as well. Thanks.

1 0

Privacy with clipper
by Mikolaj Habryn 17 Dec '03

17 Dec '03

I seem to remember someone once writing that with the proposed clipper laws, you are allowed to encrypt messages before piping them through the clip chip, but the output must be left unaltered. The problem to this is that then whoever does the audits knows who's being sneaky. (Or something like that - i don't remember precisely.) Seems to me, if one is talking about videophone type devices, they are transmitting quite a great deal of info, and stegging in a message is quite feasible, is it not? You don't even have to do much of a hardware modification. Do something like having an HF carrier tone in the background, that anyone listening to it can't detect without the knowing what they're listenong for. Or insert a microburst transmission - it'll look like static. This is not to say, that the clip chip isn't worth fighting against, just that, as always, someone's going to come with a way around it. It's human nature, really. * * Mikolaj J. Habryn dichro(a)tartarus.uwa.edu.au * "Life begins at '040." PGP Public key available by finger * "Spaghetti code means job security!"

1 0

Clipper in Sunday Times
by Duncan Frissell 17 Dec '03

17 Dec '03

Page 5 of the Business section of the Sunday New York Times has a Clipper article by Peter H. Lewis. All the usual suspects. DCF "They are planning to smuggle automatic weapons a... move the plastic explosives in boxes disguised as in... keep secret from the authorities the identity of the p..." -- Either 1) The cleartext of the decrypted message in the "box" showing how Clipper works in the above article or 2) Governor Clinton personally directing weapons shipments to the Contras from the hidden CIA airfield near Mena Arkansas in 1986. --- WinQwk 2.0b#1165

1 0