From tribble at xanadu.com  Tue Dec  1 00:40:47 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Tue, 1 Dec 92 00:40:47 PST
Subject: thoughts on digital cash
In-Reply-To: <9212010219.AA19516@newsu.shearson.com>
Message-ID: <9212010700.AA24193@xanadu.xanadu.com>


For important claims like that, the value added is that other people
putting in voluntary effort to produce things spend it in places that
better satisfy your desires.  It certainly is an indirect reward,
however.

dean





From karn at qualcomm.com  Tue Dec  1 02:24:57 1992
From: karn at qualcomm.com (Phil Karn)
Date: Tue, 1 Dec 92 02:24:57 PST
Subject: Secure Key exchange
Message-ID: <9212011022.AA25238@servo>


<phr at napa.Telebit.COM> allegedly asks:
>> If you meet someone claiming to be John Gilmore,
>> how will you know he's not an impostor?

Get a copy of last Saturday's New York Times. John's picture appears
on page 7. Of course, it's always possible for the NSA to print up a
"special edition" of that paper just for you... :-)

Phil





From karn at qualcomm.com  Tue Dec  1 02:28:08 1992
From: karn at qualcomm.com (Phil Karn)
Date: Tue, 1 Dec 92 02:28:08 PST
Subject: Secure key exchange
Message-ID: <9212011027.AA25256@servo>


>Just to point out, though, this is not foolproof. A good impressionist
>can fool people, especially if they are extremely skilled.

Perhaps. But if it's someone you know well, the imposter may have a
hard time passing that particular Turing Test. For example, Jeff
Schiller called me the other night, nominally to compare our RSA
public keys before signing, but we ended up chewing the fat for nearly
an hour.  It would be hard for an imposter to duplicate that feat
without arousing my suspicion.

Another (somewhat more likely) possibility is that the NSA or FBI
might be holding a gun to the guy's head when you call him up to
verify the key you got with his name on it. Perhaps we need "duress"
hash codes. :-)

Phil





From mlf3 at Lehigh.EDU  Tue Dec  1 07:03:51 1992
From: mlf3 at Lehigh.EDU (Matt Fante)
Date: Tue, 1 Dec 92 07:03:51 PST
Subject: Nonlinear CODEC of the digital domain
Message-ID: <199212011455.AA69037@ns3.CC.Lehigh.EDU>


Here is a new crypto idea - I would appreciate some feedback!

Matt.

My senior project is the extension of a grad student's *published*
thesis entitled "Nonlinear CODEC in the digital domain".

I use essentially a digitial filter to encode/decode the digital domain.
I believe that it has applications to data security and I welcome
people's input to this claim.


The encoder.  My prototype encodes 4-bits but I have software that
works for n bits.  If you would like to have the software let me know.
I'm not an ASCII artist but here goes my best block diagram of the
IIR digital filter encoder:


           x[n] ---------> + --------------------------> u[n]
                           ^                    |
                           |                    |
                           |                    |
                           |                    |
                           |              --------------
                           |              |   z^(-1)   |
                           |              --------------
                           |                    |
                           |                    |
                           |                    |
                           + <------------------|
                           ^                    |
                           |              ---------------
                           |              |   z^(-1)    |
                           |              ---------------
                           |                    |
                           |                    |
                           |              ---------------
                           |              | Left Circ   |
                           |              ---------------
                           |                    |
                           |                    |
                           ----------------------

x[n] is the input data word, u[n] is the encoded output word,
z^(-1) (z transform) is a delay element and Left_Circ is the left
circulate function, i.e. Left_Circ(10)=5 (10 has binary representation
1010 and upon left circulation we get 0101 which has decimal representation
5).  Another example is Left_Circ(3)=6.

Clearly this filter is IIR with function:

 u[n] = x[n] + u[n-1] + Left_Circ( u[n-2] )

the decode is FIR and is found by solving for x[n]

 x[n] = u[n] - u[n-1] - Left_Circ( u[n-2] )

I won't bother you with another ASCII block diagram.

I have run all kinds of signals (in software) through the filter
pair.  I get, what seems to me, a moderately secure coding of the
digital domain with exact signal reconstruction from its coded form.

Both Wavelet and Fourier techniques have failed to find anything
"interesting" in the encoded domain.


Please play around with this and send me feedback ( mlf3 at Lehigh.EDU )

Matt.
________________________________________________________________
                         Matt Fante
________________________________________________________________





From barrus at tree.egr.uh.edu  Tue Dec  1 09:03:17 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Tue, 1 Dec 92 09:03:17 PST
Subject: remailer scripts
Message-ID: <9212011702.AA01281@tree.egr.uh.edu>



In a previous message, Hal Finney describes in general terms how the
anonymous remailer works.

I have a "spare" account I could use to set up such scripts - it's an
HP9000 model 730 running HP-UX (if that matters).

So if someone will send me the scripts, I will try to install them and
test them myself.  And if I get it working, there will be a new anonymous
remailer for our use...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From barrus at tree.egr.uh.edu  Tue Dec  1 09:18:49 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Tue, 1 Dec 92 09:18:49 PST
Subject: Nike says: Just Do It
Message-ID: <9212011718.AA01351@tree.egr.uh.edu>



I agree with Mark's letter: we've philosophized enough - let's
implement a digital bank.

The only thing I have to go on is a recently posted summary of a
digital cash scenario - apologizes to the poster, I don't have the
article handy and I can't remember who nicely summarized the protocol.
If that summary isn't good enough, I'll go look for more of Chaum's
stuff.

I'm willing to help pull such a feat off - even if to start I (and
anybody else who wants to help!) take Email and respond by hand.  

The only high precision math routines I have are the rsa programs that
are available @ghost.unimi.dsi.it (see Dave Vincenzetti's (sp?) recent
message on sci.crypt) OR what I used during my crypto class for
working through various protocols: Mathematica.  Automating the
procedure can come later, and I'm willing to work with anybody in
doing that as well.  If initially the transactions are handled by hand
and Mathematica, don't expect a rapid turnaround! :-) The nice thing
about Mathematica is that I can run it remotely and don't need to be
in front of the NeXT to do it - especially since the command line
version is good enough for out purposes: high precision integer math,
etc.

I remember the protocol involved a hash (MD5 is suggested) of an input
to produce a number.  Suggestions?  Would turning the MD5 output into
a hex number be good enough?

Anyway, I'm going to work through the protocol a few times by hand and
post again with more info in a bit...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From fnerd at smds.com  Tue Dec  1 10:17:33 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Tue, 1 Dec 92 10:17:33 PST
Subject: How far is to far?
Message-ID: <9212011758.AB05964@smds.com>


Mark (mark at coombs.anu.edu.au) sed

> Maybe it's not in the spirit of this mailing group but 

Seems on topic to me.

> what of the question
> of purposeful abuse of the anon mailers/newsposters? Say for instance some
> person posts either a sh*tload of garbage to every known group, flooding
> the USENET...

Tim May and Fen Labalme have given good replies.

I hate the sloppy setup of the internet/usenet/netnews/mailing-lists
in general.  The way things are gives anarchy a bad name, and I think 
they could use a good hosing off--if only that would mean they would
get cleaned.  Unfortunately the way people react to abuses is often 
just to add extra patches.

Take "kill files," which Tim mentions.  The thing I hate about that term
(even more than that they're lists of people to "kill,") is that they're
after-the-fact.  Here's this mail that keeps pouring into my mailbox, and
every day my robot has to find and burn the 90% that even a robot can be
taught to recognize as junk.  Prompt, temporary STUPID relief of symptoms.

(I mean, while I'm at it, I hate the broadcast-and-filter model of netnews,
CD ROMs, and cable TV.  I want things available for me to go fetch.)

That kind of filtering has a place, but I like more positive-reputation,
positive-interest models.  Like subscription mail groups.  Also, I
understand that Fido users have to pay their own transport charges.  I
don't know if that applies to the "echo" groups, but it should...Mr. 
Jennings?...because that's another natural kind of filtering against
network hosing.  You can flood my mailbox if you pay me enough.

>> or a more personal attack whereby they send out anonymously 
>> information that was so fundamentally personal to someone they could
>> possibly react very badly....
>> 
>> What if someone posted some top secret information and the various three
>> letter acronyms all went out for someone's blood.

I guess these won't happen much, just judging from how much they happen now
even though they're not that hard to do.  But sure, they'll happen.

It would be nice if people learned information-hygene lessons like
skepticism and protecting privacy, and accepting-life lessons like accepting
what does get revealed about oneself and others...(whistful grin).

More like, people will learn if we teach; things will change if we change
them.  Scary issues are good educational material when used right, 
especially when you can say, "This is stupid and it can be *fixed* and
we can use your help."

-fnerd
quote me...within *reason* of course
fnerd at smds.com (FutureNerd Steve Witham)






From fnerd at smds.com  Tue Dec  1 10:17:44 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Tue, 1 Dec 92 10:17:44 PST
Subject: Lazy man's PGP key collection
Message-ID: <9212011758.AA05964@smds.com>


I collect PGP keys with a PGP keys mailbox.
Instead of trashing a message when I'm through reading it, if it has
a PGP key, I transfer it to the PGP keys mailbox.  In Eudora that means
pulling down the Transfer menu to the "-> PGP keys" entry.

These are, of course, only play keys.  They could be from people who aren't
who they say they are, or they could have been tampered with on the way to
me.  Unless they've been signed by someone I trust and have a trustworthy
key for.  (Just a standard disclaimer anytime I mention public keys.)

-fnerd
only her cryptographer knows for sure
fnerd at smds.com (FutureNerd Steve Witham)






From phantom at u.washington.edu  Tue Dec  1 13:32:27 1992
From: phantom at u.washington.edu (The Phantom)
Date: Tue, 1 Dec 92 13:32:27 PST
Subject: PGP and Digi-money
Message-ID: <Pine.3.05.9212011301.B25355-b100000@stein.u.washington.edu>


	Well, it looks like it is going to happen. I, too, am interested
in seeing the experiment run. The way it was talked about earlier this
week, I pictured a system where people would snail-mail an amount of money
to a central authority (bank) and would be turned into credits. Since this
was only a simulation (not to raise eyebrows) I was thinking that a cap
could be established (say, $25). Now it looks as if we'll have no acutal
cash backing for the first simulation. How will this be distributed?
Should everyone on the list be given a set amount of digital cash to start
the 'poker game', or will we choose a smaller, representative sample? 
	For the game, we'll have to set up an account as an internet
`bank', scripts to handle incoming cash requests, etc. Are these the least
of our worries? 

	I'm also willing to help in any way I can, although I too know
little C. I have a decent background in various other areas which may be
helpful. 

	On an entirely different subject: Has anyone worked up a PGP
version that may help me out? My 286 plugs along when working on keys. :)
I am specifically wondering if anyone has hacked in and created a PGP that
supports the '87 coprocessor.

thanks-


Matt Thomlinson
University of Washington, Seattle, Washington.
Internet: phantom at u.washington.edu      	    phone: (206) 528-5732
PGP 2.0 key availaible via email or finger phantom at hardy.u.washington.edu







From rchilder at us.oracle.com  Tue Dec  1 14:40:32 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Tue, 1 Dec 92 14:40:32 PST
Subject: PGP and Digi-money
Message-ID: <9212012239.AA25238@rchilder.us.oracle.com>



"Should everyone on the list be given a set amount of digital cash to start
 the 'poker game', or will we choose a smaller, representative sample? "

Maybe we should generate some digicash with a PostScript printer, just to
make it interesting.

I wonder how public key cryptology would effect efforts to counterfeit ?
It seems to me that this same technology could make cash much harder to
forge ... even allowing one to actually _print_ one's tender, authenticated
by the information buried in the serial number of the bill ... and it would
be the serial numbers that the bank would track, not the actual pieces of
paper.

-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.





From phantom at u.washington.edu  Tue Dec  1 15:00:53 1992
From: phantom at u.washington.edu (The Phantom)
Date: Tue, 1 Dec 92 15:00:53 PST
Subject: whoops! Too much 8086 assembly,
Message-ID: <Pine.3.05.9212011428.B9038-9100000@stein.u.washington.edu>


Too much assembly language and not enough FPU support. It was pointed out
that I should simply try recompiling with the coprocessor option. :l
Sure easier than writing it in assembly, eh?

ahem. 

thanks for you time -

Matt Thomlinson
University of Washington, Seattle, Washington.
Internet: phantom at u.washington.edu      	    phone: (206) 528-5732
PGP 2.0 key availaible via email or finger phantom at hardy.u.washington.edu






From barrus at tree.egr.uh.edu  Tue Dec  1 19:20:22 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Tue, 1 Dec 92 19:20:22 PST
Subject: anonymous remailer
Message-ID: <9212020319.AA03423@tree.egr.uh.edu>



Fellow cypherpunks:

There is a new anonymous remailer for our use.  Its address is
elee7h5 at rosebud.ee.uh.edu, its name is "remailer03", and here is the
public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm
uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v
gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR
tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg==
=9mBX
-----END PGP PUBLIC KEY BLOCK-----


Also, here is a script I have to use the remailers.  It is the
ultimate in brute force :-)  Perhaps if more people implemented
remailers, a general script can be written to bounce mail off them
all, or a subset of them all, in the style of Bill's scripts which were
recently posted.  It didn't take long at all to set up: I spent most
the time installing perl in my account, and tracing down an annoying
bug that was my fault - I forgot to make the *.pl files executable.  

-----------8<--------->8----------
if [ $# != 3 ]
then
	echo "Usage: anon.mail message destination remailer"
	exit 1
fi

anon1=remailing
mail1=hal at alumni.caltech.edu
anon2=remailer
mail2=remailer at rebma.mn.org
anon3=remailer03
mail3=elee7h5 at rosebud.ee.uh.edu

message=$1
dest=$2

if [ $3 = remailing -o $3 = hal -o $3 = alumni -o $3 = 1 ]
then
  remail=$anon1
  mailaddr=$mail1
fi

if [ $3 = remailer -o $3 = rebma -o $3 = 2 ]
then
  remail=$anon2
  mailaddr=$mail2
fi

if [ $3 = remailer03 -o $3 = elee7h5 -o $3 = rosebud -o $3 = 3 ]
then
  remail=$anon3
  mailaddr=$mail3
fi

t1=.anon1
t2=.anon2

echo "::" > $t1
echo "Request-Remailing-To: $dest" >> $t1
echo "" >> $t1
pgp -ea $t1 $remail

echo "::" > $t2
echo "Encrypted: PGP" >> $t2
echo "" >> $t2
cat $t1.asc >> $t2
cat $message >> $t2

rm -rf $t1 $t1.asc
mail $mailaddr < $t2
-----------8<--------->8----------





From wmo at rebma.rebma.mn.org  Tue Dec  1 20:27:29 1992
From: wmo at rebma.rebma.mn.org (Bill O'Hanlon)
Date: Tue, 1 Dec 92 20:27:29 PST
Subject: anonymous remailer
In-Reply-To: <9212020319.AA03423@tree.egr.uh.edu>
Message-ID: <m0mwlGE-0006U1C@rebma.rebma.mn.org>


>
>
>Fellow cypherpunks:
>

(Karl's remailer announcement, key, and script elided.  Thanks, Karl -- the
more the merrier!  And the more, the safer, I would think.)

I've got a couple really trivial comments.  Karl, your script called "mail"
to deliver the file.  Looks like it works on your machine, but on mine,
"mail" called /bin/mail, which seemed to put an "Apparently-To: xxx" header
in the message, and messed things up.  If any of you have a problem with
Karl's script, you might check that.  I used elm to send the file, but I
would think /bin/mailx or /bin/Mail (depending on what Unix you're using)
would work as well.

Also, I'm hoping one of you who is proficient in perl will rewrite the
darn thing.  It needs generalizing, and perl's just the language for
the job...  As a Bourne shell script, it looks ugly, especially with all
those temporary files all over the place.

-Bill
-- 
Bill O'Hanlon						 wmo at rebma.mn.org




From hugh at domingo.teracons.com  Wed Dec  2 04:49:15 1992
From: hugh at domingo.teracons.com (Hugh Daniel)
Date: Wed, 2 Dec 92 04:49:15 PST
Subject: Help with the contents of the Cypherpunks Mail Archive
Message-ID: <9212021248.AA08444@domingo.teracons.com>


  As I said I would at the last 'in person' meeting I am starting up a
mail archive of usefull things for old and new Cypherpunks.  At first
we will have a few files that can requested over email, ftp and more
complex files sturctures might come later.

  The most important files that needs to get built are the FAQ
(Frequently Asked Questions), the Glossary and the bibliographys.
These need to be done keeping in mind who we want to reach, the
programmer new to crypto systems and useage.
  This is a group effort, if you have a good definition of a word send
it to me, I will likely use it!  If you think you can do a great job
of describeing one of the questions from the FAQ in a page or so,
whip it out and send it to me!  I will compile/edit what ever comes my
way into the right place in the archive files.

  Once we have a good FAQ then when new folks join the list we can
send them the FAQ to read and get them up to speed that much faster.
This will mean that we will have just repetition on the main list and
therefore a better signal to noise ratio!

  So, go over the list at the end of this email message and see if
there is anything you want to tackle, and if there is write some of
that English code!

		||ugh Daniel
		Keeper of the archive for now...

Propsed contents of the Cypherpunks mail archive.

Glossory

Bibliography

Beginers Anotated Bibliography by Subject

FAQ --- A beginers guide to Cypherpunking
	What is the cypherpunks list all about?
	Why do I need crypto?
	What is privacy?
	What are public keys?
	What is the differences between DES & RSA?
	Why can't I just use rot13?
	Why is generateing random numbers hard?
	Why do crypto in software insted of hardware?
	Why is this crypto stuff still legal?
	What journals are there on this subject?
	What are the good beginer books on crypto systems?
	What is the NSA and why does everyone seem to hate them?
	What is crypto anarchy?
	Is all I need to crypt my email?
	What are remailers and DC-Nets?
	What can I do?


Sources
	Remailer sources
	Random number generators & testers





From barrus at tree.egr.uh.edu  Wed Dec  2 06:34:45 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Wed, 2 Dec 92 06:34:45 PST
Subject: summary of remailers
Message-ID: <9212021434.AA04655@tree.egr.uh.edu>



Here is a summary of the currently available anonymous remailers:

hal at alumni.caltech.edu

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi
T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg==
=K00H
-----END PGP PUBLIC KEY BLOCK-----


remailer at rebma.mn.org

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ==
=/qHx
-----END PGP PUBLIC KEY BLOCK-----


elee7h5 at rosebud.ee.uh.edu

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm
uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v
gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR
tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg==
=9mBX
-----END PGP PUBLIC KEY BLOCK-----


/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From nobody at rosebud.ee.uh.edu  Wed Dec  2 09:12:11 1992
From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu)
Date: Wed, 2 Dec 92 09:12:11 PST
Subject: .
Message-ID: <9212021712.AA14781@toad.com>


Subject: Digital Cash

One point of digital cash is to allow electronic payments, so printing
it on paper would not be useful as other than a novelty.  People would
have to scan the bit patterns back in, which would be inconvenient.

How big will a piece of digital cash be?

An electronic "dollar bill" in the simple scheme of Chaum's consists
of two parts:  (x, f(x)^(1/e).  X is a random number, f(x) is a one-way
function like MD5, and e is the exponent which could be taken to represent
the denomination of the bill.  MD5 takes 64 bytes as an input "chunk"
so that would be a natural size for x.  f(x)^(1/e) is f(x) "signed" by
the bank using exponent e, so that would be about the size of the bank's
modulus n, say 1024 bits or 128 bytes.  Probably there would be some
control information as well.  So the total size of an electronic banknote
would be 128 + 64 + a few, or about 200 bytes, maybe a little more.
To print this you'd have to Ascii-encode it, which generally expands
things by 1/3, so you'd get about 270 to 300 characters per bill/coin.
This would be around four or five lines of text, comparable to a PGP
key (and looking about as interesting - totally jumbled letters and
numbers).

"Forgery" is in one sense hard and in one sense easy.  It's hard because
to create new dollar bills because you have to forge a signature using
the bank's public key (n, e).  This is equivalent to breaking at least
some uses of RSA.

But it's easy to reproduce existing electronic dollars, and you don't even
need a Xerox machine.  Just "copy dollar1 dollar2" on your PC, and repeat
the process.  Presto, plenty of dollars, all exactly the same.  Send one
to the butcher, one to the baker, and you've still got plenty more
where those came from.

Keeping this kind of re-use from occurring is one of the things that
makes electronic cash tricky.  Chaum's simple scheme has the receiver
of cash calling the bank or sending the cash there right away.  The
bank has a list of "serial numbers" for all the cash that's ever been
deposited, which it compares against to see if this is a re-use.  The
first person to deposit a dollar with a given serial number gets credit
for it; the others are told that it's worthless.

Another area that people seem a little unclear about is the difference
between electronic cash and electronic checking accounts.  A checking
account could be managed by simple RSA-signed messages (e.g. created with
PGP) saying, please transfer $X.00 to account number XYZ.  If you wanted
to buy something from someone, you'd find out what his account number
is with the bank, write up a little note like this, sign it using your
public key with PGP, and email it to the person that you wanted to buy
from.  He'd send it on to the bank and his account would get credited.
Again, you'd want to put a serial number on your check so that the guy
couldn't send it again tomorrow and get another $X.00.

Or, you could just send it directly to the bank and request the bank to
notify the seller that the funds had been transferred.  This would seem
to avoid the re-use problem.

The difference between this system and electronic cash is that the bank
knows exactly what is going on.  It sees all transactions, so it knows
which accounts are making payments to which other accounts.  This is
true of ordinary paper checking accounts as well, of course.

Electronic cash is designed so that not even the bank can tell who is
paying whom.  I withdraw some cash, say, $100.00, and I pay you $35.00
by mailing you the electronic bills.  You deposit them.  The bank has
no way of determining which particular withdrawal produced those bills
which you are depositing.  This is, more or less, how real cash works.

Hal
74076.1041 at compuserve.com







From tcmay at netcom.com  Wed Dec  2 12:32:11 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 2 Dec 92 12:32:11 PST
Subject: FAQ in sci.crypt
Message-ID: <9212022031.AA14301@netcom2.netcom.com>


Cypherpunks of Cypherspace,

I just found a new FAQ and bibliography in sci.crypt. It's by Larry
Loen and is intended as a stopgap FAQ, as sci.crypt hasn't had a good
FAQ in a while. It doesn't cover the digital cash, anonymous
remailers, crypto anarchy, etc. kinds of stuff, but it answers FAQs
about one-time pads, ciphers, RSA, etc.

Since this is a mailing list, I will not forward it. (It's 26 or so
screenfuls of VT-100 screens, which is fairly long.)

Also, I still have the "Crypto Glossary" available for forwarding to
any newcomers to this list.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From tribble at xanadu.com  Wed Dec  2 13:16:58 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Wed, 2 Dec 92 13:16:58 PST
Subject: Help with the contents of the Cypherpunks Mail Archive
In-Reply-To: <9212021248.AA08444@domingo.teracons.com>
Message-ID: <9212021905.AA04514@xanadu.xanadu.com>


Other topics for the FAQ:

crypto for authentication
pseudonyms
economics of privacy/security
what's in a reputation
digital cash
verifying keys

dean





From crunch at netcom.com  Wed Dec  2 13:22:39 1992
From: crunch at netcom.com (John Draper)
Date: Wed, 2 Dec 92 13:22:39 PST
Subject: Suggest splitting things up
Message-ID: <9212022122.AA16492@netcom2.netcom.com>


To Cypherpunks:

Greetings,  Back on-line again,  after wading through about 225 messages
that has accumulated in the last 4 days.   The volume of messages
is really getting high,  and perhaps we might want to try and break
them up into the following proposed lists.

  a) PGP Development - a mailing list has already been set up,  but
     is reserved exclusivly for those doing the actual coding work.
     
  b) Digital money - A lot of traffic seems to contain this subject,
     which is all very interesting,  but doesn't apply to me because
     money is something I never seem to have anyway.
     
  c) Key management and collaboration - for discussion on various key
     exchange methodology.
     
Anyway,  this is just a thought.    And might help to cut down traffic.
One also might consider setting up a newsgroup.

JD





From centaur at netcom.com  Wed Dec  2 14:53:33 1992
From: centaur at netcom.com (Paul Blair)
Date: Wed, 2 Dec 92 14:53:33 PST
Subject: Information wanted
Message-ID: <9212022252.AA07012@netcom.netcom.com>




	Hello there!  I'm interested in getting information on the
cypherpunk movement.  Could y'all perhaps e-mail me back with your
manifesto and suchlike things?  Much obliged!

     Paul
-- 





From jwn2 at qualcomm.com  Wed Dec  2 16:01:19 1992
From: jwn2 at qualcomm.com (John W Noerenberg)
Date: Wed, 2 Dec 92 16:01:19 PST
Subject: Suggest splitting things up
Message-ID: <9212030000.AA02120@harvey>


At  1:22 PM 12/2/92 -0800, John Draper wrote:

>To Cypherpunks:
>
>Greetings,  Back on-line again,  after wading through about 225 messages
>that has accumulated in the last 4 days.   The volume of messages
>is really getting high,  and perhaps we might want to try and break
>them up into the following proposed lists.

Sounds like a fine idea.

john noerenberg
jwn2 at qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================






From mitra at pandora.sf.ca.us  Wed Dec  2 16:27:35 1992
From: mitra at pandora.sf.ca.us (Mitra)
Date: Wed, 2 Dec 92 16:27:35 PST
Subject: Suggest splitting things up
In-Reply-To: <9212022122.AA16492@netcom2.netcom.com>
Message-ID: <BynqKt.IDI@pandora.sf.ca.us>



I've had this list gatewayed into a newsgroup locally since it started, 
as long as people are reasonably disciplined (what us, disciplined) about
keeping the same subject line, then the volume of this list is quite managable.
OTOH - there is no way I could have handled this volume in my regular mailbox.

- Mitra

-- 
Mitra                                                  mitra at pandora.sf.ca.us
Technical Director, Pandora Systems                    (415)488-0944





From nobody at rosebud.ee.uh.edu  Wed Dec  2 16:43:39 1992
From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu)
Date: Wed, 2 Dec 92 16:43:39 PST
Subject: No Subject
Message-ID: <9212030043.AA01011@toad.com>


This is a test post of a triple-remailed message, all encrypted.
Sent at Wed Dec  2 16:17:47 GMT 1992

(Signed)
Guess Who?








From barrus at tree.egr.uh.edu  Wed Dec  2 18:17:58 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Wed, 2 Dec 92 18:17:58 PST
Subject: digital banking, file formats, etc.
Message-ID: <9212030217.AA07111@tree.egr.uh.edu>



This is a run through of Hal Finney's summary of the bank protocol.
Here is what I envision the digital bank working like, with rough  
sketches of file formats, conspicuously similar to the remailer's  
:-):

1) Alice chooses x, r
   Alice computes B = r^3 * f(x) mod n
   Alice sends the following message to the bank via an anonymous  
remailer

    ::
    withdraw
    <account name>
    <B = r^3 * f(x) mod n>
    Reply-To: <an anonymous remailer>
    <remailing request to Alice encrypted with appropriate remailer  
public key>

In the final version, this message will be encrypted as well

2) Bank computes D = B^(1/3)
   checks <account name> for balance, withdraws if ok
   Bank sends to appropriate remailer

    ::
    Encrypted: PGP

    <remailing request included in Alice's mail>

    <D>

3) Alice computes C = f(x)^(1/3) by dividing D by r.
   Alice gives Bob (x, C) - via anonymous mail, presumably :-)

4) Bob wants to verify (x, C)
   Bob mails to Bank via anonymous remailer

    ::
    verify
    <x>
    <C>
    Reply-To: <an anonymous remailer>
    <remailing request to Bob encrypted with appropriate remailer  
public key>

    In the final version, this message will be encrypted as well

5) Bank checks x to see if its been used
   Bank sends back to remailer

    ::
    Encrypted: PGP

    <remailing request included in Bob's mail>

    <usage status: used or unused>

6) Bob accepts the "cash"
   Bob sends to bank via anonymous remailer

    ::
    deposit
    <account name>
    <x>
    <C>
    Reply-To: <an anonymous remailer>
    <remailing request for Bob encrypted with appropriate remailer  
public key>

7) Bank checks x, C, account name; if everything OK, deposit
   Bank replies via anonymous remailer

    ::
    Encrypted: PGP

    <remailing request included in Bob's mail>

    <message indicating deposit accepted or rejected>

Alice and Bob may send message to and receive messages from the bank  
via anonymous remailers.  Or more than one...
During the testing/development phase, account names and balances can  
be made public (available via finger command or something like that)  
for verification.
Account names can be hashes of some user chosen string (Email address  
plus random text, etc.)

Customers must be able to 
  choose: two random numbers x, r
  compute: f(x)
           r^3 * f(x) mod n
           f(x)^(1/3) or C^3
  solve: D = C r mod n for C

Bank must be able to
  solve: D^3 mod n for D

So, PGP has routines which can generate random number, calculate  
hashes, and be modified slightly to perform the necessary math.  The  
Bank will be supported by a host of scripts and the math performing  
PGP routines.

Sometime later I will post a run through of the digital bank protocol  
(all numbers and done with Mathematica) as an example for those who  
are interested in an example of the protocol.

Any input or comments or help will be welcome.  Or, if someone else  
is further along than me, I volunteer!  Unfortunately, since the end  
of the semester draws near, I will be unable to work on this very  
much for the next few weeks.  Besides, I've got to go pick up the  
O'Reilly and Associates Perl book to 
move this project along...


---
/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From honey at citi.umich.edu  Wed Dec  2 19:29:35 1992
From: honey at citi.umich.edu (peter honeyman)
Date: Wed, 2 Dec 92 19:29:35 PST
Subject: uh oh, o-o
Message-ID: <9212030329.AA03885@toad.com>


the following remarks were transcribed from today's live satellite
broadcast from sun on object oriented technologies, hosted by john
gage.  in his introductory remarks, he said:

    I found something else that a number of you probably have read already,
    it's in a way relevant to this, about searching through large archives.

    This is John Gilmore, Sun employee number five.

    [Holding up to the camera last Saturday's NYT article.]

    This is John in his normal confrontational stance with the National
    Security Agency.

    John wanted two textbooks on cryptanalysis that were classified, then
    declassified briefly, then reclassified.

    Using good search techniques, using what Bob Kahn would call "knowledge
    robots" or "knowbots", objects searching for your bibliographic material
    on the net, John found them in a public library and that made the NSA
    very upset.

    For about three days there was a fight, this was in Saturday's New York
    Times, there was a fight until Tuesday of this week, yesterday, they
    declassified these books.

    So using object technology in some rough sense to pore through enormous
    amounts of information is a topic that may sound futuristic but it's
    very, very real, we think, and we'll talk about that.

enjoy.

	peter





From barrus at tree.egr.uh.edu  Wed Dec  2 19:49:53 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Wed, 2 Dec 92 19:49:53 PST
Subject: bank protocol run through
Message-ID: <9212030349.AA07296@tree.egr.uh.edu>



I find it useful to work through a protocol by hand a few times to  
really see what's going on.  Here is an example of the digital bank  
protocol.  It is meant for people who are curious to see if it works,  
as educational material for new subscribers, or general interest.

I'm choosing relatively small numbers to use: in a real  
implementation, they would be much much larger.

OK, let's start!

----------------------------------------
On the bank's side, it chooses the primes
p = 2038074743 and
q = 2038074947
and so the public key n = pq = 4153749073821763621
also phin = Euler totient function of n 

          = (p-1)(q-1) = 4153749069745613932
The bank decides to make people use the exponent 5 (it's just easier  
to tell if GCD[5, phin] is 1)

1) Alice chooses a random x, r.  She hashes x to yield fx
x = 3141526535
r = 5772156649
fx = 2718281828

Here, I just picked the value of the hash function from the  
mathematical air, so to speak.

Alice computes B = r^5 fx mod n
 = (5772156649^5 2718281828) mod 4153749073821763621
 = 592088213321408342 


-> B = PowerMod[r^5 fx, 1, n] in Mathematica

Alice sends B to the bank.

2) The bank takes fifth root of B.  Or, it raises B to the power that  
is the inverse of 5 mod n.
To find the inverse of 5 mod n, compute
inv1 = 5^(-1) mod phin = 5^(-1) mod 4153749069745613932
 = 1661499627898245573

The bank can do this since it knows the factorization of n.

-> inv1 = PowerMod[5, -1, phin] in Mathematica

So, to take the fifth root:
D = B^inv1 mod n 

 = (592088213321408342 ^ 1661499627898245573) mod 4153749073821763621
 = 1189395596986402260

-> D = PowerMod[B, inv, n] in Mathematica

Just as a check: D^5 mod n = 

 = (1189395596986402260 ^ 5) mod 4153749073821763621
= 592088213321408342 = B     So we're OK.
-> Mod[D^5, n] in Mathematica

Bank sends Alice D.

3) Alice extracts C by dividing D by r.  Or, she solves the following  
equation for C:
D = C r mod n, or
1189395596986402260 = C 5772156649 mod 4153749073821763621

This can be solved by multiplying D by the inverse of r mod n, and  
taking the result mod n.  You don't need to know the factors of n.   
As a technical note, there will be only one solution since GCD[D,n] =  
1, which is usually true since n only has two factors p and q.  The  
bank is in trouble if GCD[D, n] != 1 since that means n can be  
factored by the information in D.

inv2 = r^(-1) mod n
 = 5772156649 ^ (-1) mod 4153749073821763621
 = 3900656075651054436

-> inv2 = PowerMod[r, -1, n] in Mathematica

So, C = (D inv2) mod n
 = (1189395596986402260 3900656075651054436) mod 4153749073821763621
 = 3844350519262422248

-> C = Mod[D inv2, n] in Mathematica

Just as a check: C r mod n = 

 = (3844350519262422248 5772156649) mod 4153749073821763621
 = 1189395596986402260 = D     So we're OK.
-> Mod[C r, n] in Mathematica

So now Alice has
x = 3141526535 and
C = 3844350519262422248

4) Alice pays Bob by giving him (x, C)

5) Bob verifies that C = fx ^ (1/5) mod n.  Or, he verifies that fx =  
C^5 mod n
C^5 mod n = 

 = 3844350519262422248 ^ 5 mod 4153749073821763621
 = 2718281828

which does indeed equal f(3141526535) = 2718281828 where f is our  
hashing function.  So Alice isn't cheating by sending a bogus (x, C)

But Bob must also send (x, C) to the bank to verify Alice isn't  
trying to spend the money more than once!
----------------------------------------

So there it is, with numbers and Mathematica statements for those who  
have access to Mathematica.  Hopefully, the numbers are large enough  
to convince people it didn't work out by chance.

Now, the code to perform the math must be written, as well as the  
scripts to support the bank.  Has anyone used the RSAREF routines, or  
should we stick to what's supplied with PGP?  I haven't thought that  
far ahead.  Like I said earlier, I'll pick up work on this in a few  
weeks.

---
/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From shipley at tfs.COM  Wed Dec  2 20:33:22 1992
From: shipley at tfs.COM (Peter Shipley)
Date: Wed, 2 Dec 92 20:33:22 PST
Subject: Suggest splitting things up
In-Reply-To: <9212030000.AA02120@harvey>
Message-ID: <9212030432.AA01759@edev0.TFS>



>At  1:22 PM 12/2/92 -0800, John Draper wrote:
>
>>To Cypherpunks:
>>
>>Greetings,  Back on-line again,  after wading through about 225 messages
>>that has accumulated in the last 4 days.   The volume of messages
>>is really getting high,  and perhaps we might want to try and break
>>them up into the following proposed lists.
>
>Sounds like a fine idea.
>

I aggree.





From shipley at tfs.COM  Wed Dec  2 20:36:57 1992
From: shipley at tfs.COM (Peter Shipley)
Date: Wed, 2 Dec 92 20:36:57 PST
Subject: Suggest splitting things up
In-Reply-To: <9212030000.AA02120@harvey>
Message-ID: <9212030436.AA01770@edev0.TFS>




I suggest to groups be split as suggested  but I will like to add
that it be donw 

cypherpunks-pgp:	pgp development
cypherpunks-digi-cash:	digital cash

cypherpunks:	cypherpunks-digi-cash cypherpunks-pgp (all of the above)


		-Pete

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx
gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1
YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+
=OR9u
-----END PGP PUBLIC KEY BLOCK-----







From rchilder at us.oracle.com  Wed Dec  2 21:14:29 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Wed, 2 Dec 92 21:14:29 PST
Subject: Suggest splitting things up
Message-ID: <9212030513.AA04842@rchilder.us.oracle.com>



>>Greetings,  Back on-line again,  after wading through about 225 messages
>>that has accumulated in the last 4 days.   The volume of messages
>>is really getting high,  and perhaps we might want to try and break
>>them up into the following proposed lists.

>Sounds like a fine idea.

"I aggree."

So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated
into one giant digest of messages, sans headers ) would also make the
traffic manageable, while preserving the ability for the various groups
to benefit from one another's divergent, but relevant, insights into the
overall process and its possible applications.

Even if you split the list into multiple 'sub-topical' lists, you'll be
'swamped' with N times the maintenance ( and I suspect maintenance is
already a bit of a hassle, with bounce messages and the like 'deluging'
the hapless administrative staff with a 'rain' of problems ), as well
as 'flooded' with N times as many subscribe and unsubscribe requests ...
and will probably still contemplate a digest format eventually.   (-:

An interactive direct mail option should be preserved, in fact, it would
remain the primary entity ... all that's needed is to add some sort of
alias that evaluates to a queue to the list, then write a script to read
the queue ( with some queue management to avoid race conditions ), strip
out all but trivial header information and '> ' those left behind, and
generate email to those individuals whom have transferred themselves from
the primary alias to the secondary digestifier-and-remailer.

There's a thing called majordomo at greatcircle.com that does this, I think.
I don't know if it's public domain, but it does a lot of this, firewalls
and firewalls-digest are both served by it, and I think it also provides
archival services and such. ( There are others, also. )

My $0.02.


-- richard






From tcmay at netcom.com  Wed Dec  2 21:28:56 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 2 Dec 92 21:28:56 PST
Subject: Suggest splitting things up
In-Reply-To: <9212030436.AA01770@edev0.TFS>
Message-ID: <9212030528.AA25608@netcom.netcom.com>


Peter Shipley is one of several people suggesting this list be split
into parts. His specific idea is:

> I suggest to groups be split as suggested  but I will like to add
> that it be donw 
> 
> cypherpunks-pgp:	pgp development
> cypherpunks-digi-cash:	digital cash
> 
> cypherpunks:	cypherpunks-digi-cash cypherpunks-pgp (all of the above)

Splitting the list into "pgp development" and "digital cash" would
take care of the topics being discussed in the _last few days_, but
would do little for the various other "threads du jour" that have
occupied us: one-time pads, dongles, legal issues, key registration,
special purpose chips, etc.

Are we to form a new list each time something fails to fit into one
of the groups suggested?

I think there's a simpler split, should one be needed:

* cypherpunks-technical...writing software, details of dongles, math,
PERL, details of algorithms, PGP development, etc.

*cypherpunks-political...laws, debate, public policy, ethics of
encryption, spread of digital cash, etc.

*cypherpunks-announce....just the announcements of meetings, upcoming
events, important developments, etc.

Now splitting the list means more duplicate messages for those who
subscribe to both (when messages are cross-posted, as some will be),
more "missed" messages when one of the groups is not subscribed to
(resulting in "Can you send me the article....?" thrashing), and some
amount of additional work by the list administrator (Eric Hughes).

Given that a list bifurcation will only buy a savings of 2x in volume
for most people (and many will automatically take both lists), and
given that we all know factors of 2 don't count (:-}), I recommend
against splitting the list.

Besides, you never know what useful stuff will get posted in the group
you don't get. Anybody who chooses to stay ignorant of what the other
group is doing probably won't be able to contribute much to the group
he subscribes to.

--Tim



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU  Wed Dec  2 21:50:52 1992
From: UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU (Fan Li TAI)
Date: Wed, 2 Dec 92 21:50:52 PST
Subject: enjoy enjoy
Message-ID: <9212030550.AA06424@toad.com>


Hiya,
        Below's something I found...  I know you all have been swamped with
mail... but this one is in the spirit of things, I think...  Found it in
Life...

____begin____
From: sherman at .cs.umbc.edu (Dr. Alan Sherman)
Subject: Superpolylogarithmic Subexponential Functions
Newsgroups: rec.music.dementia

Announcing: Technical Report TRCS-91-17, University of Maryland
Baltimore County.  A preliminary version of this paper appeared in two
parts in {\it SIGACT News}, {\bf 22}:1 (winter 1991), Whole Number~78,
65--73, and {\bf 22}:2 (spring 1991), Whole Number~79, 51--56.


        On Superpolylogarithmic Subexponential Functions

                        Alan T. Sherman
                Computer  Science Department
                University of Maryland Baltimore County
                Baltimore, Maryland 21228
                        and
                Institute for Advanced Computer Studies
                University of Maryland College Park
                College Park, Maryland 20742

                June 21, 1990 (revised April 1, 1991)


                        Abstract

A superpolylogarithmic subexponential function is any function that
asymptotically grows faster than any polynomial of any logarithm but
slower than any exponential.  We present a recently discovered
nineteenth-century manuscript about these functions, which in part
because of their applications in cryptology, have received
considerable attention in contemporary computer science research.
Attributed to the little-known yet highly-suspect
composer/mathematician Maria Poopings, the manuscript can be sung to
the tune of ``Supercalifragilisticexpialidocious'' from the musical
Mary Poppins.  In addition, we prove three ridiculous facts about
superpolylogarithmic subexponential functions.  Using novel extensions
to the popular DTIME notation from complexity theory, we also define
the complexity class SuperPolyLog/SubExp, which consists of all
languages that can be accepted within deterministic
superpolylogarithmic subexponential time.  We show that this class is
notationally intractable in the sense that it cannot be conveniently
described using existing terminology.  Surprisingly, there is some
scientific value in our notational novelties; moreover, students may
find this paper helpful in learning about growth rates, asymptotic
notations, cryptology, and reversible computation.

Keywords. Algorithms, asymptotic notation, complexity theory,
cryptography, cryptology, DTIME, mathematical humor, Maria Poopings,
Mary Poppins, musical computer science, reversible computation,
Supercalifragilisticexpialidocious, superpolylogarithmic
subexponential functions, SuperPolyLog/SubExp.

                --- lyrics ---

            Superpolylogarithmic Subexponential Functions
    (Sung to the tune of ``Supercalifragilisticexpialidocious.'')

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Superpolylogarithmic subexponential functions!
Faster than a polylog but slower than exponential.
Even though they're hard to say, they're truly quintessential.
Superpolylogarithmic subexponential functions!

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

For Alice to send a message through to Bob when Eve's eavesdropping,
do use a trapdoor one-way function---not a one-key mapping.
First take a message x, let's say, and raise it to the e;
then mod it out by p times q but keep these secretly.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

The process takes but poly-time and appears to be secure:
why even just a single bit is one over polylog pure.
Though Alice thinks that Eve must spend time at least exponential,
by using Lenstra's elliptic curves, Eve splits n subexponentially.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

we remove the heat with water but there's a better strategy.
Since thermodynamics does not apply when info is not doomed,
the laws of physics don't require that power be consumed.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Now Bennett said in `73, to run a program P,
you simulate the program P, but do so reversibly.
The problem with this method is that space is exponential,
so trade off time to save on space---this really is essential! Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Did you know if you invert one, you get a
funtionential subexporithmic logapolyrepus?
But that's quite a singularity!  So,

If you are in an oral exam and cannot find the way,
just summon up these words and then you've got a lot to say.
But better use them carefully or you could fail the test.
A professor once asked me,
``What do you call functions that grow faster than any
polylogarithm but slower than exponential?'' There're,

Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!

                --- end of lyrics ---

Note: See paper for detailed performance notes and mathematical
proofs by anagramming.







From ebrandt at jarthur.Claremont.EDU  Wed Dec  2 21:57:33 1992
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Wed, 2 Dec 92 21:57:33 PST
Subject: Suggest splitting things up
In-Reply-To: <9212030436.AA01770@edev0.TFS>
Message-ID: <9212030557.AA06522@toad.com>


> From: Peter Shipley <shipley at tfs.COM>

> I suggest to groups be split as suggested  but I will like to add
> that it be donw 

[ a different way ]

Before we consider splitting the list, we should ask whether there are
a significant number of people who would take less than all of the
sublists.  I really don't know.  If the purpose is just to provide a
way to know what "kind" of message you're about to read, we could use
a "tag" the way sci.v-w does, if we find this necessary.  I personally
don't object to this kind of list volume.

> 		-Pete

   Eli   ebrandt at jarthur.claremont.edu





From crunch at netcom.com  Wed Dec  2 22:38:55 1992
From: crunch at netcom.com (John Draper)
Date: Wed, 2 Dec 92 22:38:55 PST
Subject: Suggest splitting things up
Message-ID: <9212030638.AA03477@netcom2.netcom.com>


I recommend that we adopt Yim May's idea for how the mailing lists
are split up.   BTW,  if that ever happens,   I only want to me
on the cypherpunks-technical,  and cypherpunks-announce mailing
lists.

Cheers
JD





From nobody at rebma.rebma.mn.org  Wed Dec  2 22:44:26 1992
From: nobody at rebma.rebma.mn.org (nobody at rebma.rebma.mn.org)
Date: Wed, 2 Dec 92 22:44:26 PST
Subject: No Subject
Message-ID: <m0mx9a9-0005l0C@rebma.rebma.mn.org>


Here's a new look for electronic cash.  Instead of having a bank where
people have accounts, have the "banker" be a money changer.  He
changes Federal Reserve Notes into crypto dollars.  Anybody can send
him dollars, and include an email address and public key, and he will
email them that same amount of electronic cash.  Anybody can email him
electronic cash, and include a snail-mail address, and he will send
them that same amount of U.S. dollars.

You don't have a permanent relationship with him, you just use the
service when you need to change between electronic and paper dollars.

With the Chaum cash that was discussed here a while ago, where you
need to "deposit" it right away when you get it, here's what you could
do instead.  Send it to the money changer, and ask for fresh crypto
cash back.  It's like you combined a "deposit" with an exactly equal
"withdrawal".  What you get back is good cash that you can hold or
spend as needed.  There are no account numbers involved, no demand
deposits, no bank account at all.

Eric Hughes mentioned demand deposits as defining a bank, so maybe
this would be a way around that.

--
Mr. Money
--






From ncselxsi!drzaphod at ncselxsi.netcom.com  Thu Dec  3 07:38:03 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod)
Date: Thu, 3 Dec 92 07:38:03 PST
Subject: digital banking, file formats, etc.
Message-ID: <19286.drzaphod@ncselxsi>


In Message Wed, 2 Dec 92 20:17:19 -0600,
  Karl L. Barrus <tree.egr.uh.edu!barrus at netcomsv.netcom.com> writes:

>1) Alice chooses x, r
>   Alice computes B = r^3 * f(x) mod n
>   Alice sends the following message to the bank via an anonymous
>remailer
>
>    ::
>    withdraw
>    <account name>
>    <B = r^3 * f(x) mod n>
>    Reply-To: <an anonymous remailer>
>    <remailing request to Alice encrypted with appropriate remailer
>public key>
>

     What happens if the bank mails $$$ to Alice.  Somebody intprive Alice of HER money.  I havn't read much about digital money
protocols so correct me if I'm wrong. TTFN!
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized





From nraizman at winchester.pp.psc.edu  Thu Dec  3 08:34:29 1992
From: nraizman at winchester.pp.psc.edu (nraizman at winchester.pp.psc.edu)
Date: Thu, 3 Dec 92 08:34:29 PST
Subject: Info Wanted
Message-ID: <9212031629.AA08600@winchester.pp.psc.edu>


Wiggidi-wiggidi-whassup?
I'm new here, and , while I can follow the digital money threads, and
otehr such things, I am lost when it comes to this PGP and Public Key
stuff. Could someone please explain it to me? 
Thanx a lot!
nraizman at winchester.pp.psc.edu





From barrus at tree.egr.uh.edu  Thu Dec  3 11:21:49 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Thu, 3 Dec 92 11:21:49 PST
Subject: digital banking, file formats, etc.
In-Reply-To: <19286.drzaphod@ncselxsi>
Message-ID: <9212031921.AA09706@tree.egr.uh.edu>



Dr. Zaphod writes:
>What happens if the bank mails $$$ to Alice.  Somebody intprive
>Alice of HER money.  I haven't read much about digital money protocols
>so correct me if I'm wrong. TTFN!

Well,

I intend for the communications themselves to encrypted as well.  This
would call for the remailing request to also somehow include Alice's
public key, and Bob's communications to include his public key, etc.
This will prevent intercepted mail from tampering and keep the
anonimity.  .  Possibly the bank will have two public keys: one for
money, and one for mail.

However, in the initial phase to keep things simple, the messages
won't be encrypted - only the remailing info will.  This will
implement the anonymous part, and allow transactions, but will provide
no protection against intercepting mail, etc.  Heck, the initial
system will only allow withdrawals and deposits of a constant
denomination, so I'll worry about spoofing later :-)

I'm operating under the premise of getting something out that is
usable but not full blown.  So extra denominations, fully encrypted
messages, etc. will be added later.

Also, I received a mail from rjc at gnu.ai.mit.edu (Rob Crowley?) - whose
mail I seem to have misplaced - voicing concern over proving deposits in
the event that the bank can't be trusted.  Any of the digital currency
protocol articles discuss this issue?  I guess I need to visit the
library again and do some more research, after finals.

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From andrew_derry at sfu.ca  Thu Dec  3 12:07:53 1992
From: andrew_derry at sfu.ca (andrew_derry at sfu.ca)
Date: Thu, 3 Dec 92 12:07:53 PST
Subject: digest (not splitting)
Message-ID: <9212032007.AA24537@whistler.sfu.ca>


Richard Childers <rchilder at us.oracle.com> says:
>So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated
>into one giant digest of messages, sans headers ) would also make the
>traffic manageable, while preserving the ability for the various groups
>to benefit from one another's divergent, but relevant, insights into the
>overall process and its possible applications.

I'm for the digest format.  Should make it much more managable.

---
Andrew Derry                      |
ACS at HCC - Simon Fraser University |
Internet: derry at sfu.ca            |






From edgar at spectrx.Saigon.COM  Thu Dec  3 15:26:58 1992
From: edgar at spectrx.Saigon.COM (Edgar W. Swank)
Date: Thu, 3 Dec 92 15:26:58 PST
Subject: Secure key exchange
Message-ID: <ecF7uB10w165w@spectrx.saigon.com>


Anserwing some comments about my suggestions for key verification.
 
Phil Karn pointed out that the next version of PGP will display an
MD-5 hash of any public key for phone comparison purposes.  That's
great, but that version of PGP isn't here quite yet. I suspect, in
any case, that the added security isn't all that great since I suspect
it's very hard to find another valid key-pair where the public key
matches the last 24 bits plus some fragment of another 20 bits or so
from the middle of the key.
 
Phone, as opposed to mailed paper verifications has the following
problems:
 
Phil says you have to recognize the voice, which implies you've met
him in close quarters, which implies you could have exchanged keys
physically anyway.  If the only place you've heard the voice is
over the phone, that's not a very good criterion.
 
Phone verification is good, IMHO, *only* if the person being verified
is *called at a listed number*. You can't verify a person who calls you,
(unless you know the voice).  You can't verify a person you call at
an unlisted number which you got over the net!!
 
Economics: Net participants are scattered over the country and even the
world. Paper verification costs about $2-$3 allowing for my fee, copying
costs and two-way international postage. Adding notarization adds about
$5.00.  Phone verification is economical locally (maybe cheaper than
mail), but more expensive when long-distance rates apply, especially
international rates.
 
Meeting at parties or face-to-face is most expensive of all, unless
the meeting happens fortuitously. Overseas plane fare to exchange keys
is beyond the means of most of us.
 
Phil says:
 
    I would much rather trust a simple verification procedure based on
    redundancy and close personal relationships than a single,
    complex, impersonal process involving people I don't know.  This
    is not to impugn your integrity, of course -- I'm simply speaking
    on principle.
 
No offense taken!  I, on the other hand, would rather have in my hand
a signed statement of identity with photocopied ID that I can keep
and file away.  I also don't want to go broke making international
phone calls.
 
As it happens, I, so far, have not been able to sign a single key!!
 
I called Phil Zimmerman at a listed number, I read him my key and
he signed it, but he was called away from the phone before he could
verify his key to me. So I can't sign his!
 
I've met a few people at parties I've given my paper key (fragments)
to. So far none of them have signed my key, but none of them had
paper key fragments to trade, so I can't sign theirs.
 
George Gleason commented about supplying home addresses.  Your
comments are well taken. Phil Zimmerman also commented to me in E-mail
that some people don't want the serial numbers on their photo ID
copied.  Everyone please feel free not to supply a home address and
to obscure any home address or serial number on the photocopied
photo ID. I'll still sign your key, although I'll note what you did
in my signed key directory, which I'll send to customers & publish
here.  If you don't want *me* to know your home address, you can
use a P.O. box for me to return my (or other customers') ID
certificate(s) to you. On the other hand, as the service provider,
MY home address and phone are public info.
 
I also acknowledge George's criticism re the "I'm not a cop"
statement. I'm going to leave it in my statement, because it's
true, but in general you should be aware that any legal protection is
questionable at best.  The lack of protection has been verified by
a source on Extropians and by an attorney on the RIME network.
 
In the meantime, I guess we can discuss illegal subjects not with
"I've done ..." but with "I've heard that ..." or "I used to know
somebody who ...". Also anonymous remailers will be a big help.

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From fnerd at smds.com  Thu Dec  3 15:36:23 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Thu, 3 Dec 92 15:36:23 PST
Subject: understandable cypher software
Message-ID: <9212032155.AB19933@smds.com>


Folks--

A paragraph of philosophy and then some technical PGP questions.

I should be able to verify with my own eyes how cypher technology works.  
Otherwise I'm trusting my security to somebody's black box.
I should be able to write my own and test that it interacts with someone 
else's the way it's supposed to.  I should be able to monitor the 
communications between my copy of a cypher product and some other, and 
verify that they're doing the things people say they are. 
Besides, I'd like to carry the crypto basics in my head "just in case."
To these ends, I'd like cypher software that is as easy to read and
understand and trust as possible.  I'd like to start with a distilled PGP.  

Does this list cover the heart chambers of PGP? (Not to devalue the rest):
        RSA
        IDEA
        The signature algorithm (MD5?)
                128 bits?
                Is that based on RSA?
        A cryptostrong pseudorandom # generator?
                Is this based on RSA?
        Something that takes keystroke delays (real, but not so good, 
                random numbers) and makes real good random numbers?
                Is this based on RSA?
        A data compression algorithm (some variation of LZW?)
        A binary<-->ascii translator

RSA seems to depend on doing modulo-multiply on big integers.  What are the 
relative speeds of the different modmults in PGP (modulo processor speed)...
        the simplest C version
        the fastest C version
        the fastest assembler version on the processor where it matters least
        the fastest assembler version on the processor where it matters most?

Given the time to do modmult, couldn't all the rest (including modexp) be
done in an interpreter that had big ints and modmult as a primitive?

What's the formula for RSA again?
        out = in * something ^ somethingelse mod yetanother??
        I know it can't be, because the key is only one number.

What is/are the basic primitive(s) for IDEA?

-fnerd
"Computer software must not only work, it must also appear to work."
                           --Carl Hewitt
fnerd at smds.com (FutureNerd Steve Witham)






From eichin at cygnus.com  Thu Dec  3 15:53:18 1992
From: eichin at cygnus.com (Mark W. Eichin)
Date: Thu, 3 Dec 92 15:53:18 PST
Subject: understandable cypher software
In-Reply-To: <9212032155.AB19933@smds.com>
Message-ID: <9212032352.AA02808@tweedledumber.cygnus.com>


>> RSA seems to depend on doing modulo-multiply on big integers.  What are the 
>> relative speeds of the different modmults in PGP (modulo processor speed)...
	Also consider reliability. As of 2.0, modmult on the SPARC
(using the MERRITT code) fails on some keys, while either the PEASANT
or UPTON routines function correctly but are slower. (I haven't had
time to test them in parallel and find where they diverge, but there
is a large keyring "out there" that breaks the MERRITT code in several
places...)
	(on the main thread, yes, understanding "the whole thing" is a
good idea, and perhaps modifying the code to make this easier is a
useful development goal...)
								_Mark_





From ncselxsi!drzaphod at ncselxsi.netcom.com  Thu Dec  3 16:08:48 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod)
Date: Thu, 3 Dec 92 16:08:48 PST
Subject: Suggest splitting things up
Message-ID: <47824.drzaphod@ncselxsi>


In Message Wed, 2 Dec 92 21:56:54 PST,
  Eli Brandt <jarthur.Claremont.EDU!ebrandt at netcomsv.netcom.com> writes:

> I personally don't object to this kind of list volume.

    Neither do I, just to cast my vote in the hat.  In fact, I don't even
think that we need to tag the messages for the type of content.  I'm
interested in anything that is posted in this list and read every message.
TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized





From cordones at IMAGE.CS.NYU.EDU  Thu Dec  3 16:29:18 1992
From: cordones at IMAGE.CS.NYU.EDU (Deus Ex Machina)
Date: Thu, 3 Dec 92 16:29:18 PST
Subject: Brand-spanking new key
Message-ID: <9212040026.AA29192@IMAGE.CS.NYU.EDU>


Hello everyone.
I just finished installing PGP2.0 in a rush...so..here goes my 
1024-bit Military grade (he..guess I am a little paranoid..) key.
Give it a try and perhaps I will experience some ESP...

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisdxzYAAAEEALaDepo7QeCT2MCu+02nGuAZIJtoRwbxlwulUT/SehKH7xFW
43UqHZKHwMjDT5S8TESpGLtanhKsgmGa+Pp1X/tEImS2CqEvnPQhy0mjQMqR1WZ7
NfKenvUesXkE6pTpg/8Fk1AwsqRiypUEHoiNeU4k14gceilSg2Z/lrxl5FyxAAUR
tCNFbCBab3JybyA8Y29yZG9uZXNAcm9ib2NvcC5ueXUuZWR1Pg==
=o+Oh
-----END PGP PUBLIC KEY BLOCK-----



so..have phun...

El Zorro





From hughes at soda.berkeley.edu  Thu Dec  3 18:31:36 1992
From: hughes at soda.berkeley.edu (Eric Hughes)
Date: Thu, 3 Dec 92 18:31:36 PST
Subject: FTP site
Message-ID: <9212040228.AA26580@soda.berkeley.edu>



We have an anonymous FTP site.  It's at soda.berkeley.edu.  The
directory is pub/cypherpunks.  Right now there's not much in it.  A
few miscellaneous documents are in the misc/ directory.  There's an
empty directory for listings of ftp sites in other places that hold
crypto software of various forms.

But most importantly the source code to the remailer as currently
running is in there.  I'd like to see even more remailers than three.
And if you can't put up a remailer (because, to take one of the few
good examples, you don't run Unix) I'd still like people to study the
code.

We'll eventually have weekly digests of mail traffic from the list,
but those aren't created yet.

Enjoy!

Eric





From hughes at soda.berkeley.edu  Thu Dec  3 18:35:51 1992
From: hughes at soda.berkeley.edu (Eric Hughes)
Date: Thu, 3 Dec 92 18:35:51 PST
Subject: Suggest splitting things up
Message-ID: <9212040235.AA27065@soda.berkeley.edu>



A word on the subject of altering the list from the list maintainer.

There's been lots of discussion about splitting up the list into
various pieces.  In a word, it's not going to happen.

Look, this is the cypherpunks list.  Cypherpunks write code.  A
corollary to this is that cypherpunks take responsibility for the
volume of mail they receive.  If you're getting too much mail, use a
filter.  Many of you may not know that the remailer software as
currently configured pressed into service just such a filter.

In the just-announced ftp site, there's the source code, in perl, to
just such a filter.  You can change it to do whatever you like.  In
particular, you can install it to filter all your cypherpunks mail to
a separate mailbox, file, or subdirectory.

You can also use MH, whose slocal the above perl filter was based on.
slocal can filter all of your cypherpunks mail to separate places.

You can also send all of your cypherpunks mail to a separate directory
and use a newsreader to read it.  I've never done this, but certain
list members have.  If one of them (say, Mitra, who recently mentioned
that he does this) would post a short summary of how it's done to the
list and offer to answer questions off-line, I'd appreciate it.

Eric





From ghsvax!hal at uunet.UU.NET  Thu Dec  3 18:36:43 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Thu, 3 Dec 92 18:36:43 PST
Subject: digital banking
Message-ID: <9212040022.AA15172@nano.noname>


I enjoyed seeing Karl's walk-through of Chaum's digital cash
algorithm.  The numbers looked right.  One point is that doing
different denominations isn't that much harder, you just need to have
more exponents.  As you generate your primes p and q, make sure that
p-1 and q-1 aren't divisible by any small primes (other than 2).  This
will ensure that phi = (p-1)(q-1) is not divisible by small primes, hence
that gcd(e, phi) will be 1 for those same small primes, in fact for
all the odd numbers.

Karl also quoted a comment from Ray Cromwell expressing concern over
proving deposits.  Ideally you'd get a signed receipt from the bank
for every deposit you make.  In the case of electronic deposits, there
exist protocols for "gradual secret exchange" that might be suitable
for this purpose.  What you'd like is to send the bank your deposit
"gradually", while the bank simultaneously gradually sends you a
digitally signed receipt.  I don't recall the details of these
protocols.  Gradual exchange would not be very convenient for email
because of the long turnaround times in mail systems, but if you had a
better connection it might be useful, especially for large deposits.

Another way to look at it is, what stops the local merchant from
taking your payment, putting it in his pocket, and then denying that
you've given him anything?  It would just be his word against yours.
One answer is, if he does that to multiple people, their multiple
stories would have more credibility than his denials.  Similarly, a
bank which made a habit of cheating its customers would find itself
publically exposed.  So it may be reasonable to trust the bank for
routine transactions.

Hal
74076.1041 at compuserve.com





From mitra at pandora.sf.ca.us  Thu Dec  3 19:36:42 1992
From: mitra at pandora.sf.ca.us (Mitra)
Date: Thu, 3 Dec 92 19:36:42 PST
Subject: Suggest splitting things up
In-Reply-To: <9212040235.AA27065@soda.berkeley.edu>
Message-ID: <Byptzn.6J9@pandora.sf.ca.us>


Sure Eric, 

I'm on SCO unix (i.e. non compatible with everyone else - I cant even 
get perl running yet), I've added the following lines to my .maildelivery

To	cypherpunks at toad.com	|	A	inews -0 -a list -n list.cypherpunks
Cc	cypherpunks at toad.com	|	A	inews -0 -a list -n list.cypherpunks
Apparently-To	cypherpunks at toad.com	|	A	inews -0 -a list -n list.cypherpunks

This catches the three most common address headers, unfortunately the
mailing list at cypherpunks doesnt behave like a well-behaved reflecter
should and put its own address in the header (most would add "Sender:
cypherpunks at toad.com")

All this does is pipe messages that match the headers into inews with the args
following. Those args are:

-0	An extension I added, which makes inews always return 0 (otherwise
	our braindead delivery agent "mmdf" cycles forever trying to deliver
	bad messages and creating a HUGE dead.article.	
-a list	Add an "Approved: list" line so that inews will post it to a moderated
	newsgroup
-n list.cypherpunks	Stick it in the newsgroup "list.cypherpunks"

list.cypherpunks is set up moderated, with the moderater being 
cypherpunks at toad.com

Happy gatewaying, if someone has a better way of doing this then let me 
know.

- Mitra


-- 
Mitra                                                  mitra at pandora.sf.ca.us
Technical Director, Pandora Systems                    (415)488-0944





From gg at well.sf.ca.us  Fri Dec  4 03:10:36 1992
From: gg at well.sf.ca.us (George A. Gleason)
Date: Fri, 4 Dec 92 03:10:36 PST
Subject: enjoy enjoy
Message-ID: <199212041109.AA24355@well.sf.ca.us>


Great one...!

When I was taking undergrad social science stats, I came up with a similar
one, just one verse though...

Pearson-product-moment-correlation coefficients!
If you still can't get it then you're mentally deficient
Is this really learning or selection by attrition?
Pearson-product-moment-correlation coefficients!

-gg





From miron at extropia.wimsey.com  Fri Dec  4 03:39:29 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Fri, 4 Dec 92 03:39:29 PST
Subject: Chosen cryptotext and RSA
Message-ID: <1992Dec4.102619.25216@extropia.wimsey.bc.ca>


Can chosen crypto-text break RSA?  (I.e., having access to the
decryption machine - as a black box and finding the decryption
exponent.)
-- 
	Miron Cuperman <miron at extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron at cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |





From VANGUARD at gribb.hsr.no  Fri Dec  4 06:18:02 1992
From: VANGUARD at gribb.hsr.no (VANGUARD at gribb.hsr.no)
Date: Fri, 4 Dec 92 06:18:02 PST
Subject: Weakness of the PGP scheme ?
Message-ID: <MAILQUEUE-101.921204152203.416@gribb.hsr.no>


To my knowledge there is done very little cryptographical anlysis on
the PGP protocol, and just recently I saw I possible weak point in
the PGP scheme.

The underlying security of the PGP scheme is based on two different
systems, the RSA asymetric cipher and the IDEA cipher. For standard
encryption the plaintext is encrypted with a IDEA using a "random"
key, then the key is communicated using RSA. Then we have two direct
ways of analysing a message, we might have a run a plaintext attack
on the ciphertext trying out all possible IDEA keys which will tak
a lot of effort, or we might break the RSA key to get the IDEA key.

But I propose an easier attack; Using a Encrypted Ciphertext together
with the public key used for encryption, It would be possible to run
a trial encrypting all possible IDEA keys using the RSA public key
and compare it with the encrypted IDEA key, if a match is found then
you have the IDEA key for this one message. Using an RSA chip that is
capable of performing exponetsiations VERY fast I dont think that
this would be unfeasable.

The most important factor in this attack is the length of the IDEA
key. But another concern is the generation of the IDEA key, is it
possible knowing the value of the RANDSEED to know all the subsequent
IDEA keys?, or would knowing the last IDEA key drastically reduce the
time needed to search for a subsequent one? So far I haven't studied
PGP enough to answer all these questions.





From pmetzger at shearson.com  Fri Dec  4 09:43:36 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Fri, 4 Dec 92 09:43:36 PST
Subject: Weakness of the PGP scheme ?
In-Reply-To: <MAILQUEUE-101.921204152203.416@gribb.hsr.no>
Message-ID: <9212041720.AA05323@newsu.shearson.com>


>From: VANGUARD at gribb.hsr.no

>The underlying security of the PGP scheme is based on two different
>systems, the RSA asymetric cipher and the IDEA cipher. For standard
>encryption the plaintext is encrypted with a IDEA using a "random"
>key, then the key is communicated using RSA. Then we have two direct
>ways of analysing a message, we might have a run a plaintext attack
>on the ciphertext trying out all possible IDEA keys which will tak
>a lot of effort, or we might break the RSA key to get the IDEA key.

>But I propose an easier attack; Using a Encrypted Ciphertext together
>with the public key used for encryption, It would be possible to run
>a trial encrypting all possible IDEA keys using the RSA public key
>and compare it with the encrypted IDEA key, if a match is found then
>you have the IDEA key for this one message. Using an RSA chip that is
>capable of performing exponetsiations VERY fast I dont think that
>this would be unfeasable.

This is quite wrong. This only makes sense if RSA were inherently much
faster than IDEA. In fact, IDEA is orders of magnitude slower than
RSA; thats the whole reason that we use IDEA session keys encrypted
with RSA and not RSA itself to encrypt the message -- RSA is way too
slow. The result of this is that trying all possible IDEA keys
directly to break the cypher is far far faster than trying to encrypt
all possible IDEA keys with RSA. Now, since the security of IDEA
depends on it being secure from brute force attacks like trying all
possible IDEA keys and seeing which one produces a good message, the
result is that if IDEA is secure, PGP is certainly secure from the
attack you mention.

>The most important factor in this attack is the length of the IDEA
>key. But another concern is the generation of the IDEA key, is it
>possible knowing the value of the RANDSEED to know all the subsequent
>IDEA keys?, or would knowing the last IDEA key drastically reduce the
>time needed to search for a subsequent one?

If the random number generator is good, then it should not be possible
to predict the next session key. If it is bad, all bets are off. I
would agree that questions of the quality of the RNG have been
inadequitely explored.

Perry





From ghsvax!hal at uunet.UU.NET  Fri Dec  4 09:55:49 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 09:55:49 PST
Subject: PGP questions
Message-ID: <9212041752.AA17033@nano.noname>


It's probably good to discuss how PGP works here, for educational
purposes, but I would expect people to get the source code if they
really are interested.  I can give some pointers here to answers to
some of the questions people have asked.

Steve Witham asks several questions.  I think the crypto glossary
which Tim posted a couple of weeks ago tells how RSA works, so I won't
reiterate that here.  Steve, if you didn't get it, maybe Tim could
send it to you.

PGP's signature algorithm creates an MD5 message digest of the
message, then signs that digest by raising it to the secret exponent
"d", mod "n".  MD5 is a public-domain message digest algorithm created
by RSA Data Security, Inc, which breaks messages into blocks of 64
bytes as input and produces a 16-byte (128-bit) digest.  PGP then pads
this 16-byte number to be about the size of n, and does the
exponentiation.

PGP does not do its decryption/signature exponentiation by actually
raising the number to the power of d mod n, but by doing a
mathematically equivalent operation involving two exponentiations, one
mod p and one mod q.  Since p and q are half the length of n, and
exponentiation takes roughly the third power of the number of bits in
the modulus, this reduces the amount of time by a factor of 4.

The random number generator has several different modes, and I can
only suggest looking at random.c.

The data-compression algorithm is not really relevant but is based on
zip.  The binary-ascii translator is also not important but is a
variant on the PEM standard.

Steve asks a lot of questions about the speed of different versions.
Maybe asking on alt.security.pgp would produce some representative
values.  I'm not sure whether anyone has a database with all these
numbers.

I understand that PGP 2.1 may have a faster version of the Upton
modmult.  Preliminary timings suggest that it's still slightly slower
than the Merritt modmult on the Sparc, but if Merritt really is
unreliable (I haven't heard about this) then switching to Upton will
not involve much of a penalty.  PGP is very fast on Sparcs anyway and
I don't think making it 10% slower would matter.

Profiling indicates that yes, during the RSA encryption phase, most of
the time is spent in modmult.  An interpreter could be built to do a
modular exponentiation using a C implementation of modmult and it
would be about as fast.  However, that still leaves the generation of
the random session key, padding it with random numbers so that it is
suitable for RSA operations, converting the RSA-encrypted session key
into a format suitable for writing to a file, doing the IDEA
encryption, wrapping this all up with control information so that it
can be decrypted, looking up key information from a key ring file or
some other data file (possibly decrypting it on the fly), converting
to ASCII, etc.  All these are part of an encryption/decryption cycle
and can't really be skipped.

Hal
74076.1041 at compuserve.com





From barrus at tree.egr.uh.edu  Fri Dec  4 10:02:46 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Fri, 4 Dec 92 10:02:46 PST
Subject: No Subject
Message-ID: <9212041802.AA13345@tree.egr.uh.edu>


FutureNerd Steve Witham writes:

>I should be able to verify with my own eyes how cypher technology works.  
>Otherwise I'm trusting my security to somebody's black box.

This is important, which is why its nice to have source code.
However, be prepared to invest a little :-) time in the study of PGP's
code; I recently printed it out and must have sucked a toner cartridge
nearly dry as it took more than 500 pages!  Check out 'wc -l *.[ch]'
which results in 22720 lines for me.

>        The signature algorithm (MD5?)
>                128 bits?
>                Is that based on RSA?

Get the md5.doc from rsa.com - available via anonymous ftp.  It
explains the algorithm (which is largely bitwise operations on blocks
of the input stream) and even includes source code.

>        A cryptostrong pseudorandom # generator?
>                Is this based on RSA?

Somebody posted a cryptographically strong prng to sci.crypt recently,
but I haven't had a chance to look it over.  I have my own rng - a ten
sided die, which I haven't had occasion to use, yet.  

>        A binary<-->ascii translator

Phil Karn's DES package includes source code for uuencode, which
performs this translation.  I'm sure it is somewhere in the PGP code
as well.  There is also RFC 1113.

>What's the formula for RSA again?
>        out = in * something ^ somethingelse mod yetanother??
>        I know it can't be, because the key is only one number.

Close!  That looks like the formula for solving ax mod n = d for x
given a, n, d.

RSA: pick two primes p and q.  Then n=pq.  As Hal Finney said, the two
primes should be "good" in the sense that p-1 and q-1 have no small
prime factors.  Obviously, you can't avoid having 2 divide p-1 and
q-1, but that should be about it.  Also, p and q should differ in
length by a few digits otherwise an enemy may begin to try factoring n
by starting near sqrt(n).

Pick a decryption exponent d.  d and phi(n) should be relatively
prime, where phi(x) = Euler totient function = # of numbers less than
x which are relatively prime to x = x-1 for x prime.  For n, phi(n) =
(p-1)(q-1).  Calculate the inverse of d mod phi(n) and call it e, your
encryption exponent (e = d^(-1) mod phi(n)).  Publish n and e as your
public info, and keep d secret as your decryption key.

Somebody encrypts a message by calculating M^e mod n.  You decrypt the
ciphertext by calculating C^d mod n.

For example: p=7, q=11 => n=77 and phi(n)=60.
I pick d=13, gcd(13,60) = 1 so it is acceptable.
Then e = 13^(-1) mod 60 = 37.  Check: 13 37 mod 60 = 1.
A message M=20 is encrypted as 20^37 mod 77 = 48.
I decrypted the ciphertext 48 like this: 48^13 mod 77 = 20, and I got
back the original message.

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From ghsvax!hal at uunet.UU.NET  Fri Dec  4 10:03:39 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 10:03:39 PST
Subject: Weakness of the PGP scheme ?
Message-ID: <9212041755.AA17036@nano.noname>


Vanguard at gribb.hsr.no asks about trying all the IDEA keys.  If you
will look in idea.h you will see that the IDEA key is 16 bytes long,
which is 128 bits.  This is long enough to make trying them all
impossible.  Trying to predict one IDEA key by knowing the previous
one also looks hard, as PGP basically cycles IDEA on random input and
takes the output as the keys.  If you could predict this output it
would be similar to breaking IDEA.

On the other hand, PGP normally keeps its random information in a
small file called randseed.bin.  It uses the contents of this file
plus the current time of day in seconds as the input to generate the
IDEA key.  If you stole this file from someone (it's not
cryptographically protected, unlike the secret key ring), and you know
within several hours or a day when he sent each message, you could
probably calculate all possible IDEA keys in a feasible amount of time
(by trying all plausible values for the time of day in seconds).  This
would also let you calculate the new contents of the randseed.bin
file.  As long as you didn't miss any messages he sent, you could keep
doing this and break all of his outgoing messages.

You can prevent this by removing your randseed.bin file and
substituting an empty file (or one that is less than 16 bytes long) in
its place.  This will cause PGP to prompt you for random keyboard
input each time you send a message, which would make it impossible for
the attack above to work.  It would mean less convenience, though.

The relevant routines are make_random_ideakey() and
strong_pseudorandom() in crypto.c, as well as the code in random.c.

Hal
74076.1041 at compuserv.ecom





From tcmay at netcom.com  Fri Dec  4 13:23:43 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Fri, 4 Dec 92 13:23:43 PST
Subject: Sources of Crypto Information
In-Reply-To: <9212040228.AA26580@soda.berkeley.edu>
Message-ID: <9212042123.AA12247@netcom.netcom.com>


Cypherspace Residents,

Several people have asked about what PGP is, how RSA works, what
digital cash is all about, etc. I'll recap where and how these
questions can be answered.

1. Long term, there will be a FAQ, to be coordinated by Hugh Daniel,
who recently posted about this.

2. I posted or mentioned the following items to this list very recently:

- Crypto Glossary (which explains, albeit briefly, RSA, digital cash,
DC-Nets, PGP, etc.). This has been also been submitted for the
anonymous ftp site (at soda.berkeley.edu in pub/cypherpunks).

- Larry Loen's crypto FAQ he posted to sci.crypt recently. This was
also submitted for the  ftp site.

3. The documentation for PGP has a good discussion of the issues, how
the IDEA cipher works, etc. Read this, please, before asking the
entire list how RSA works.

4. "Cypherpunks read crypto books" is my variant of Eric's
"Cypherpunks write code." (No point in trying to write code if you
don't have any idea what you're doing.) I've described many excellent
books and articles. Almost any recent book will give you an excellent
list of other books.

5. Hal Finney and Karl Barrus have both written excellent summaries
of how digital cash works. Work through their examples! (A personal
note: I'm blissfully PERL-illiterate, but I use Mathematica on my Mac,
so Karl's examples in Mathematica overjoyed me!)

6. Several weeks ago I posted some articles on the dining
cryptographers protocol, as Hal also did. I can send these to anyone
who wasn't on the list then. (Ditto for the Crypto Glossary.)

7. Sci.crypt is worth reading, especially if you have a good
newsreader like "tin" which allows interesting threads to be quickly
identified. 

Hope this helps.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From norm at netcom.com  Fri Dec  4 15:51:08 1992
From: norm at netcom.com (Norman Hardy)
Date: Fri, 4 Dec 92 15:51:08 PST
Subject: digital banking
Message-ID: <9212042350.AA21011@netcom2.netcom.com>


As I understand Chaum's Digi-Cash scheme the bank customer is 
protected both against bank fraud and merchant fraud but not 
against collusion between the two. The customer need not be 
unknown to the bank in order that her purchases with bank notes be 
unknown to the bank. This is where blind bank signatures come in. 
Neither need the merchant be unknown to the bank. Remailers are 
unnecessary to hide connection between the merchant and his 
customers. The bank knows both but has no way to associate them.
 
This being the case, the bank customer is protected against a 
false denial of deposit. When one deposits Digi-Cash in a bank he 
presumably waits for an indication from the bank that the cash was 
still valid (not previously deposited). The customer retains this 
indication as a receipt which is signed by a private bank key. A 
bank's positive reputation is useful but not necessary at this 
point.
 
Another concern is the false denial of payment by the merchant. If 
the merchant's customer is willing to reveal to a judge that she 
paid the merchant, and she retained the note with which she paid, 
and the bank retains a record of the merchant's deposits then she 
can argue that it was she that caused the bank to mint the note 
since only the person for whom the note was minted and the 
merchant who had cashed it (and the bank) should know its bits. 
This would require that the bank respond to the judicial query 
"has bank customer M deposited note x?".





From hh at soda.berkeley.edu  Fri Dec  4 17:04:59 1992
From: hh at soda.berkeley.edu (Eric Hollander)
Date: Fri, 4 Dec 92 17:04:59 PST
Subject: usenix
Message-ID: <9212050104.AA18056@soda.berkeley.edu>



A list for discussion of the crypto-bus to usenix has been formed.  To join,
send mail to usenix-crypto-bus-driver at soda.berkeley.edu.

e





From nobody at cs.Buffalo.EDU  Fri Dec  4 17:32:06 1992
From: nobody at cs.Buffalo.EDU (nobody at cs.Buffalo.EDU)
Date: Fri, 4 Dec 92 17:32:06 PST
Subject: Another remailer
Message-ID: <9212042350.AA10597@armstrong.cs.Buffalo.EDU>


I have set up another reamiler... the address is babani at cs.buffalo.edu
Be warned: There is no PGP ability as of yet.

Let me emphisize that:  THERE IS NO PGP ABILITY ON THIS REMAILER. 

I have not gotten the pgp program up and running as of yet.  But... if
you want to bounce mail through the remailer... it shouldn't be to
much of a problem.  Just use one of the other remailer keys and
encrypt your message with that.  Just add the usual lines to your
message.  For example:

----Begin fake message to a remailer----
::
Request-Remailing-To: remailer at rebma.mn.org

--------BEGIN PGPv2.0 MESSAGE------ (endcoded with rebma's key)
blah blah
--------END PGPv2.0 MESSAGE-------

----End fake message to a remailer------


Report any problems to me or to any of the other remailing sites.

-- 
+==== Internet: babani at cs.buffalo.edu ===+======== Amateur-Radio: N2LYC ======+
!      Bitnet: V078LNGT at ubvms.BITNET     |        UUCP: rutgers!ub!babani     !
! Alternate: an173 at cleveland.freenet.edu | Plsure dpnds on the othrs prmison. !
+When you finally discover all of lifes answers, they'll change the questions.+






From fnerd at smds.com  Fri Dec  4 17:46:33 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Fri, 4 Dec 92 17:46:33 PST
Subject: getting .hqx files with ftpmail
Message-ID: <9212050131.AB05869@smds.com>


A note for fools like me trying to get Mac .hqx files through "ftpmail"...

USE ASCII MODE!  Otherwise it defaults to adding an extra layer of "btoa"
encoding on the file (or you can switch it to uuencode, but why uuencode
an .hqx file--it's already plain text).  "btoa" files start like this:
        xbtoa begin
        wef9a87eg8a9wery8s7arg87gae8g7waeo87rwe8r(garbage)...
as opposed to uuencoded files like:
        begin fred.txt
        aewhgp9ergu90ser890syuer98gse98r(garbage)...
or .hqx files (this is from memory):
        (This file has to be decoded with BinHex 2.0)
        k9wegesz9p8rgy89serg9oser98ser98(garbage)...

I don't know where to find "btoa," and ftpmail's help message just says
to ask my local wizard.  He never heard of it.

--- Example request to ftpmail ---
        connect mac.archive.umich.edu
        cd mac/util/encryption
        ascii
        get macpgp2.0.sit.hqx

-fnerd
fnerd at smds.com (FutureNerd Steve Witham)






From nobody at soda.berkeley.edu  Sat Dec  5 14:50:36 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Sat, 5 Dec 92 14:50:36 PST
Subject: test
Message-ID: <9212052203.AA19366@soda.berkeley.edu>




This is a test of my new anon-remailer based on Hal's code.  It does not
yet feature pgp (pgp is having a hard time compiling on soda, but that
will change soon...)

To use it, just use the Anon-To: field in the header and mail
to hh at soda.berkeley.edu

There will soon be an even fancier remailer at soda (and not running out
of my account).  Details as they become available.

sincerely,
nobody






From edgar at spectrx.Saigon.COM  Sat Dec  5 14:51:16 1992
From: edgar at spectrx.Saigon.COM (Edgar W. Swank)
Date: Sat, 5 Dec 92 14:51:16 PST
Subject: First digital money?
Message-ID: <5Ps0uB3w165w@spectrx.saigon.com>


Following cross-posted from Extropians:
 
To: gnu.ai.mit.edu!Extropians
Date: 02 Dec 92 11:31:59 EST
From: Duncan Frissell <szebra!CompuServe.COM!76630.3577>
Subject: If I only had $100K
 
 
Bankers Trust has started a Global Settlement Fund to allow securities traders
to make free funds transfers 24 hours a day.  The Chicago Mercantile Exchange
now accepts GSF shares in addition to cash and T-bills for settlement purposes.
 
GSF shares will pay interest and there are no transactions charges for
transfers.  For now, the account minimum is $100,000 and participating
institutions must have a link to Bankers Trust's New York operations center.
The company plans to open similar funds denominated in Yen and Pounds Sterling.
It also plans a BBS system which will allow traders to arrange forex exchanges
with the holders of other currency shares 24 hours a day.
 
Bankers Trust has targeted the Fed Wire that does 60 million transactions worth
$200 billion a year but is slow and expensive.
 
Now once such a system reaches the *retail* level we'll really have something.
 
Duncan Frissell
 
*******************************************************************************
* DUNCAN FRISSELL                        Attorney at Law, Writer, and Privacy *
* CIS 76630,3577                         Consultant since the Nixon           *
* Internet 76630.3577 at compuserve.com       Administration                     *
* Easylink 62853962                                                           *
* Attmail !dfrissell                                                          *
* TLX:  402231 FRISSELL NYK                                                   *
*                                                                             *
*          * Clinton Inaugural Sale - Any Question Answered for $9.99 *       *
*                                                                             *
*******************************************************************************

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From jthomas at access.digex.com  Sat Dec  5 14:51:18 1992
From: jthomas at access.digex.com (Joe Thomas)
Date: Sat, 5 Dec 92 14:51:18 PST
Subject: Hardware RNGs
Message-ID: <Pine.3.05.9212051331.A28464-b100000@access.digex.com>


I just joined the list (rather loudly, I'm afraid), but I've already seen
several writers complain about the quality of RNGs and PRNGs for the 
purposes of cryptography.  PGP stores up keystroke-derived random bits
in a file, which has been pointed out as a possible security hole.  But
requiring random keystrokes every time one wishes to send a message seems
an inconvenient tradeoff, to say the least.

Someone posted a plan for a Zener diode-based hard RNG on sci.crypt a few
weeks ago.  I'm not much of a solderer normally, but this seems like a 
good idea if anyone out there has tried it out and tested the output for
nonrandomness.  (Of course, ideally we'll have alpha-decay-based RNGs
--guaranteed random by the laws of physics-- but I'll settle for thermal
noise on the cheap for the moment).

Anyone tried these yet?  More to the point, does anyone have some code
patches for PGP to use a hard RNG preferentially over other random
bitstreams?  (Yeah, it would be pretty easy, but there's no sense in
duplicating effort if we could get something standardized, pretty and
portable agreed on.)

Joe

P.S. Sorry about the wasted bandwidth last week.  My fingers were moving
faster than my brain, but I should have recognized this address as a
probable mailing list.  Thanks to all who politely directed me to the
-request address.







From ghsvax!hal at uunet.UU.NET  Sat Dec  5 17:25:29 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Sat, 5 Dec 92 17:25:29 PST
Subject: Anonymous address problems
Message-ID: <9212060122.AA19491@nano.noname>


We've had some discussion of anonymous addressing, which allows
someone to post an address at which mail can be sent to them without
people being able to find out exactly who they are.

I showed how the current remailers could, somewhat clumsily, allow
anonymous addresses.  The problem is, with a single-remailer anonymous
address that remailer sees whom each anonymous address corresponds to,
so you have to trust it.  Now that other encrypting remailers are up
it's possible to have anonymous addresses which go through more than
one remailer before going to the final destination.  This, I thought,
would provide a more secure address since a whole group of remailers
would have to be "broken" in order for someone to find out where a
given anonymous address leads.

However, with the current implementation, there is a security
weakness.  Whomever owns the last remailer in the chain for your
anonymous address can find out who you are.  They do this simply by
sending an anonymous message with known contents, like "test number
1598293".  They then watch all messages going through their remailer,
looking for one whose contents match what they sent.  If they are the
last remailer in the chain, when they see this message go through
them, they can look at whom it is being sent to, and so they then know
your true name.  So, a multi-remailer anonymous address is really no
more secure than a single-remailer one.

Chaum, in his "mix" paper, avoided this problem by having the
anonymous addresses include a random number which each remailer sees
as it decrypts the incoming message.  (There is always such a number,
it turns out, for the RSA encryption to be secure.)  He had the mix,
as it passes the message through, encrypt the contents with a
single-key algorithm (like DES) using this random number as the key.
This way the message is transformed at each step and so if it later
comes back through the same mix, it won't be recognizeable as the one
it sent earlier.  So the attack above fails.

For this to work, the user has to save the random numbers that were
used to construct his anonymous address, and decrypt the message using
DES with these as keys before going on to read it or public-key decrypt
it as usual.  This would be quite a bit less convenient.

Chaum goes on to say that these return addresses can only be used
once.  I was a little puzzled by the exact attack that he is trying to
defend against in applying this rule.  Chaum doesn't always make the
attacks clear, leaving that as an exercise for the reader.  I believe
the problem is that, say, the last remailer in the chain could send 100
messages to a given anonymous address (all would have different
contents).  Then, after working its way through the remailer chain, it
would see 100 messages going to the same final destination.  It could
guess that those 100 were the 100 it sent, especially if it repeats this
test every few days with different numbers.

Chaum's rule of allowing each anonymous address to be used only once
makes them much less useful.

These complications just go to show that real security doesn't come
easy or cheap.  There is still work to be done before we achieve the
goal of crypto anonymity.

Hal
74076.1041 at compuserve.com






From nobody at soda.berkeley.edu  Sat Dec  5 19:21:20 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Sat, 5 Dec 92 19:21:20 PST
Subject: remailers
Message-ID: <9212060320.AA03303@soda.berkeley.edu>



Remailers are proliferating!  Several more will be coming on line soon!

Two thoughts:

Remailers should keep a directory of other remailers, along with their
keys.  They should, at random intervals, send messages to other remailers,
selected at random.  They should have a field like

Purpose:  traffic-analysis

If a remailer on this "ring" sees this field, it will have, say, a 90%
chance of remailing to another remailer in the ring, again, encrypted and
with the traffic-analsysis field.

This will cause a certain amount of random traffic between remailers.  A
traffic-analysis message could bounce around many times before finally
ending up in the great /dev/null.

We need two other things:  overseas remailers (for those of us who live
under US law).  Domestic (US) remailers could have their archives searched
with a searchwarant.  However, if your mail has gone accross the oceans a
few times, it would be pretty much impossible to get the neccessary warrants
and cooperation in all the countries its been through.

I'll set up a European remailer if someone else will.

The other thing we need to do is make a list of remailers and their keys and
put it up for ftp on soda.berkeley.edu in ~ftp/pub/cypherpunks.  In fact,
there could be an automatic service, whereby remailers automatically send
mail to a remailer at soda, listed their keys and protocols, and the soda
remailer automatically updates a remailer directory.

e






From habs at acf3.NYU.EDU  Sat Dec  5 19:27:02 1992
From: habs at acf3.NYU.EDU (Harry A. B. Shapiro)
Date: Sat, 5 Dec 92 19:27:02 PST
Subject: subscribe me
Message-ID: <9212060326.AA04183@acf3.NYU.EDU>


subscribe me

-- 
habs at acf3.NYU.EDU
habs at gnu.ai.mit.edu
habs at well.sf.ca.us
habs at panix.com




From nobody at soda.berkeley.edu  Sun Dec  6 10:30:31 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Sun, 6 Dec 92 10:30:31 PST
Subject: this is a test
Message-ID: <9212061829.AA03378@soda.berkeley.edu>



igonore this message...

e





From nobody at soda.berkeley.edu  Sun Dec  6 12:44:52 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Sun, 6 Dec 92 12:44:52 PST
Subject: No Subject
Message-ID: <9212062044.AA06744@soda.berkeley.edu>


Cypherpunks!

Like several people (I guess), I am working on an implementation of
digital cash.  Because of the possible legal repurcussions, I'd prefer
to remain anonymous at this time.  Thanks to the efforts of the people
on this list, this is now possible.

My implementation is pretty far along.  It uses PGP modules for the
arithmetic, so the speed is good.  It works on Unix and I should be
able to get it working on MSDOS in a day or two.  Sorry, I don't have
the ability to work on a Mac version.

Here are some of the features.  The basic cash algorithm is the Chaum
system which was posted here.  Multiple denominations are supported,
using different exponents for each denomination.  The program is
presented in the context of a package to be used for an email based
game like Monopoly where the program would be used to allow cash
transfers.  One player is the "banker", and he uses a different
execution module than the other players.  The banker program keeps a
database of used note numbers which is used to detect money reuse.
The database is maintained using a freeware version of the "dbm"
package, so it should be fast even for large note number databases.

The mapping between exponents and values is as follows:

    exponent	    value
	17		1
	19		2
	23		5
	29		10
	31		20
	37		50
	41		100
	43		200
	47		500
	53		1000
	59		2000
	61		5000
	67		10000

and so on, up to a value of 2e9.  The exponents are ascending primes
starting with 17.  This was chosen because you want them to be
smallish for fast note checking, but it was too slow to find primes p
and q for the bank key such that (p-1)(q-1) was not divisible by any
small primes.  The program chooses random p and then tests p-1 to make
sure it passes the divisibility test, and rejects it if not.  Too many
were being rejected when I started with an exponent of 3.  Starting
with 17 rejects about 1/2 the exponents, compared to something like
80% when I started with 3.  The "value" fields are presumed to be
cents, but could be whatever you like.

The code I've written does not do anything other than the basic
electronic cash algorithms.  It does not do bank account maintenance.
It doesn't do PGP encryption.  It doesn't send mail.  (It does have
some functions to scan and check the files created by the program.)

Cash generation is a 3 step process.  First, the user creates what I
call a "withdrawal request" packet.  This is a set of triplets of the
form (e, s, refx), where e is the exponent from the table above, s is
a 16-byte "unique identifier" used solely to link these withdrawal
requests with the returned messages from the bank, and refx is r^e * f(x).
f(x) is MD5 of x, padded to the size of the bank's modulus n using the
PGP routine which pads MD5 signatures.  This padding helps make sure the
arithmetic is more "mixing".  x is the random input to MD5, which I've
chosen as 64 bytes since that is the block size MD5 works on.  (The
output of MD5 is 16 bytes.)  r is the blinding factor.  This is now
128 bits long; longer r's take too long to calculate r^-1 in the third
step, below.  (It takes longer for PGP to calculate r^-1 than to do an
RSA decryption, for r = n = 1024 bits!)

Second, the bank program converts the withdrawal request packet into
what I call a "withdrawal" packet, by just RSA-decrypting the third
entry using the inverse exponent "d" for the value exponent "e".
(These "d" values are calculated at keygen time and stored with the
bank's key information in a private file.)  I call the return triplet
(e, s, rfxd), where e is the value exponent again, s is the same
unique identifier, and rfxd is r * f(x)^d.

(As I said above, the code I've written does not try to maintain
account balances or do any other banking functions.  It just does the
cash algorithms.  There is a routine to scan a withdrawal request and
return the total value being requested for withdrawal.  The idea was
that this could be used as input to a banking program to decide
whether to allow the withdrawal.)

Third, the "player" (e.g. user) program transforms the withdrawal
packet into a "money" packet, by un-blinding it.  To do this, it has
to recover the x and r which correspond with each triplet.  This is
done by the use of a dbm database of "pending withdrawal requests"
which is written during step 1, above.  The database entries are keyed
by (e, s) and return the corresponding (x, r) which were generated
during step 1.  Using x and r, the user transforms (e, s, rfxd) into
(e, x, fxd), the digital cash.  e is the value exponent, x is the
random 64-byte number, and fxd is f(x)^d, the signed version of the
MD5'd and padded x.

There are also player functions to scan and check a money file
(comparing a calculated f(x) to fxd^e), merge money files, and extract
some items from a money file into another money file (this last is
what is to be used for payment).  There are banker functions to check
incoming money and compare against the used-note database, and to add
incoming money to that database.  (The database consists of the
16-byte f(x) values for each note.)

I am pretty happy with the basic routines, but the user interface
needs work.  There are three kinds of files floating around
(withdrawal requests, withdrawals, and money files) and I'm worried
that this will be confusing to the user.  If he accidentally deletes
one at the wrong time he could lose money permanently.  Or if he
accidentally reuses one he could be accused of fraud.  I'm not sure
what the best model is for the user.

The specific issues of creating withdrawal messages and extracting
"bills" from a money file are areas where the user interface should be
made nice.  We want to make it easy for the user to specify exactly
what denominations he wants to work with.  One possibility is to
simply have him input the amount (e.g. $10.55) and the program
calculates that that's a 1000, a 50, and a 5, but this isn't really
flexible enough.  A nice system would be to give him a list of options
and let him fill out a form on-screen, but that's hard to do portably.

Another idea I've had is that there should be a special money file
called the user's "wallet" which is the default place where incoming
money from the bank should go.  This might help organize things.  He
still needs to be able to create other money files for paying other
people, and remembering to delete them after he sends them.

Any suggestions or thoughts on these interface issues, or comments
about how this program could or should be integrated into a larger
system, would be appreciated.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
-----END PGP PUBLIC KEY BLOCK-----







From nobody at ocf.Berkeley.EDU  Mon Dec  7 00:30:49 1992
From: nobody at ocf.Berkeley.EDU (nobody at ocf.Berkeley.EDU)
Date: Mon, 7 Dec 92 00:30:49 PST
Subject: yet another remailer
Message-ID: <199212070730.AA07386@plague.berkeley.edu>



I've set up another remailer, this one on my ocf account.  It's also based
on Hal's (very easy to use and useful) script and does not yet have
encryption because pgp201 is not the most portable thing around.

To use, just do the standard thing:

send mail to hh at ocf.berkeley.edu with the line:

Anon-To:

or

Request-Remailing-To:

and it will do the rest.  Have fun!

e





From fnerd at smds.com  Mon Dec  7 08:26:16 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Mon, 7 Dec 92 08:26:16 PST
Subject: CHATTER Re: Broadcast/Filter vs. "Fetching"
Message-ID: <9212071546.AB14663@smds.com>


(I put "CHATTER" in the subject line as a clue that this is general talk
off the subject of directly implementing crypto stuff.)

Yanek Martinson    <yanek at novavax.nova.edu> sent an interesting message
to me--I think he meant to post it--in response to my gripe:

>> (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews,
>> CD ROMs, and cable TV.  I want things available for me to go fetch.)
>
>But if you have the disk space and bandwidth to spare, it really does
>make sense to receive everything and then decide what you want.

Perhaps our company could make room for a couple days worth of the complete
netnews.  But,
  o  That's hardly all the information there is.
  o  I could never read it all, and I don't trust computer filters much.
  o  I don't want to be a slave to the newsfeed/use-it-or-lose-it deal;
     I want to follow threads into the past, at my leisure.  I want to let
     some discussions cook and then come back to them.

>In your "fetch" scenario, what if I don't like (strongly) what Joe wrote.
>So I can nuke Joe (or his archive) and no-one can "Fetch" the article.

This is what I found interesting.  You would really like the network (some
network) to support distributed redundant archives, preferably with cross-
checking.  It would be even nicer if information could be stored, with
storage cost charged to the owner and/or readers, and yet not have it 
knowable where the information was.  Somehow a backwards mix setup.  Put 
on your crypto thinking caps, kids.

>On the other hand with the current set-up, it has already propagated 
>to hundreds of thousands of sites and it's impossible to stop.

Yes.  But, say, tens of untraceable sites would be okay.  The flip side of
100K x redundancy is the little emily postnews handslap--"ARE YOU SURE?"--
and the rigamarole over creating new groups, and whether all the machines
between you and the center of the universe get all the groups, etc.
Plus the fact that most sites delete the stuff after a week or two, and
all the effects on people's writing that has.

>Also, if you want to filter stuff, then you should pay for the CPU
>that does the filtering for you.

My brain filters my mail!  Boy do I pay for it!

>Why would you expect someone else
>to run your filter on their machine just so you would know if you
>wanted to fetch their article.

??  I don't want machine filtering at all.  Mostly I want references I can
follow up easily.  That's what fetching means.

>Maybe I did not understand what you meant by "fetching".  

Hope it's clearer.

>Could you describe your idea in more detail?
>I absolutely agree that most of what comes in over my
>newsfeed is junk, I just don't see a good way of 
>fixing this problem while retaining the robustness
>and widespread communications capability.
>
>> -fnerd
>> quote me...within *reason* of course
>
>(I guess 4 lines (including the sig) is well within reason)

-fnerd
quote me
fnerd at smds.com (FutureNerd Steve Witham)






From wendtj at jplpost.Jpl.Nasa.Gov  Mon Dec  7 09:56:00 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Mon, 7 Dec 92 09:56:00 PST
Subject: No Subject
Message-ID: <9211077237.AA72375@jplpost.jpl.nasa.gov>


          ruthere





From warlord at MIT.EDU  Mon Dec  7 19:49:44 1992
From: warlord at MIT.EDU (Derek Atkins)
Date: Mon, 7 Dec 92 19:49:44 PST
Subject: Just in case you haven't heard (PGP 2.1 released)
Message-ID: <9212080347.AA10257@deathtongue.MIT.EDU>


-----BEGIN PGP SIGNED MESSAGE-----

PGP 2.1 Available
- -----------------

Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. 
This new version of the world's most popular and politically
controversial public key encryption program has numerous bug fixes
over version 2.0, and several new features.  

For example, you can now display the MD5 hash of a public key, to
facilitate verifying it over the telephone with the owner of that
public key.  Also, it is now possible to send via email an
unencrypted signed message without putting the whole message in
Radix-64 format, to make it possible to read without PGP.  This is
analogous to the PEM MIC-CLEAR signed message functionality.

PGP 2.1 incorporates many patches from the user community to port it
to more platforms.  And it runs faster.  Also, a lot of annoying bugs
and ergonomic oversights have been fixed.  PGP 2.0 fans will find
many rough edges have been smoothed out.

The filenames are pgp21.zip for the MSDOS executable release, and
pgp21src.zip for the source code release.  You must have PKUNZIP
version 1.1 or later to unzip them, or they won't unzip.  The primary
initial FTP sites that have it are:

Finland:    nic.funet.fi  (128.214.6.100)
            Directory: /pub/unix/security/crypt/

Italy:      ghost.dsi.unimi.it  (149.132.2.1)
            Directory: /pub/security/

As previously, this prohibited and politically popular program will
probably propagate through the same channels as PGP 2.0.  Of course,
if you live in the USA, you really shouldn't be using it.

If you have any questions about where else to get it, contact Hugh
Miller, at hmiller at lucpul.it.luc.edu.  Hugh can send you the latest
evolving list of FTP sites, BBS phone numbers, and other sources.

Philip Zimmermann
Phil's Pretty Good Software


-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+
ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0
JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ
vs/OHzY5LiU=
=nV70
-----END PGP SIGNATURE-----





From ghsvax!hal at uunet.UU.NET  Mon Dec  7 19:51:29 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Mon, 7 Dec 92 19:51:29 PST
Subject: Anonymous address problems, etc.
Message-ID: <9212080059.AA20745@nano.noname>


Chris Hibbert sent me a solution for the problem I mentioned about the
last remailer in an anonymous address chain being able to discover the
true name for the address.  He suggested making your own remailer be
the last one in the chain.  If you added a little padding, so the
second-to-last remailer couldn't tell (from the small size of the
encrypted address) that yours was last, this sounds pretty good.  And
it's another reason to run a remailer, even if you had to do it
manually.

On the digital cash issue - I think we should get some kind of
implementation of digicash (oops, "electronic money") out for people
on the list to play with.  Then, we should think of some kind of
experimental email-based game to play which would use the special
characteristics of anonymous cash.  Maybe we could use the remailers,
too.  Players would send cash back and forth to each other as part of
the game.  Even if the tools are sort of rough at first, this could
show where the most work is needed.

Can anyone think of a good kind of game that we could play?  As Eric
Hughes pointed out, the cash doesn't have to be "cash", it could
represent "gold" or "carrots" or any other material which exists in
limited quantity.

I think it was on the extropians list that Eli Brandt pointed out the
need for a shorter term than "digital cash" for this cryptographic
money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
analogy to "email".  Here's another one: "crydets", based on
"credits".  Or maybe we should call them "Chaums".  That way he'd be
less likely to sue us for infringing on his patent. ;-)  I notice he
managed to cleverly name DC-nets after his initials so maybe he'd like
this.

Hal
74076.1041 at compuserve.com

P.S. I hear PGP 2.1 is coming out today.





From hh at soda.berkeley.edu  Mon Dec  7 19:51:58 1992
From: hh at soda.berkeley.edu (Eric Hollander)
Date: Mon, 7 Dec 92 19:51:58 PST
Subject: ocf remailer
Message-ID: <9212080024.AA22987@soda.berkeley.edu>



For various reasons, my remailer on the ocf is going down indefinitely.  It
was fun while it lasted, I laughed, I cried, but now it's over.

e





From nobody at alumni.cco.caltech.edu  Mon Dec  7 19:52:58 1992
From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu)
Date: Mon, 7 Dec 92 19:52:58 PST
Subject: pgp2.1 released
Message-ID: <9212072305.AA21821@alumni.cco.caltech.edu>


PGP 2.1 is released.  It's on soda.berkeley.edu, for your convenience,
in directory pub/cypherpunks.

The 2.1 release has the ability to sign a message as leave the message
in plaintext.  This should be used by all the pseudonyms in the group
to prove continuity of authorship.





From hibbert at xanadu.com  Mon Dec  7 19:55:23 1992
From: hibbert at xanadu.com (Chris Hibbert)
Date: Mon, 7 Dec 92 19:55:23 PST
Subject: Anonymous address problems
In-Reply-To: <9212060122.AA19491@nano.noname>
Message-ID: <9212071859.AA11109@entropy.xanadu.com>



There's a cheap fix for the particular problem you mentioned, Hal. 
(Of course, that's usually the case, and it's usually too weak a fix
to help generally, but I think this one gives us back the ability to
use anonymity here.)  

The cheap fix is to make sure that the last remailer in the chain
(the one closest to you) is your own!  That way you can ensure no
one else checks its translation.  No one else can be sure which is
the second-to-last hop, so they can't tell who owns the last
remailer. 

Chris





From nobody at pmantis.berkeley.edu  Mon Dec  7 19:56:34 1992
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Mon, 7 Dec 92 19:56:34 PST
Subject: another remailer!
Message-ID: <9212080357.AA10697@pmantis.berkeley.edu>


I set up another remailer.  All in all it took me about 30 min to compile
perl and set up Hal's script.  It's too easy!

Just do the standard thing:  mail to hh at pmantis.berkeley.edu with the line
in the header Anon-To: or Request-Remailing-To:

Have fun!

e





From nobody at cicada.berkeley.edu  Mon Dec  7 21:45:33 1992
From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu)
Date: Mon, 7 Dec 92 21:45:33 PST
Subject: another remailer (again?)
Message-ID: <9212080541.AA11090@cicada.berkeley.edu>


Yes, it's the second remailer I've set up today.  Gee, at this rate, I'll
have the entire CPU power of the United States dedicated to remailing
within four months.

Just do the usual thing:

mail hh at cicada.berkeley.edu with the header line Anon-To: or
Request-Remailing-To: and the remailer does the rest.  cicada and pmantis
have been able to compile pgp201 and so they will soon have encrypted
remailer capability.  They will also soon be running pgp21 (as soon as I get
a chance to compile that).  They are very fast machines, so I will probably
give them military grade keys.  They are also very secure machines.

It's too bad about not being able to use the ocf, but those machines are
slow anyway and probably wouldn't be able to run pgp ever.  My soda remailer
should be running pgp fairly soon.  And I have 1-3 remailing sites almost
ready to go, probably coming on sometime next week.  And hughes is working
on another remailer at soda, a really fancy one.

Have fun everyone!

e






From ebrandt at jarthur.Claremont.EDU  Mon Dec  7 22:12:22 1992
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Mon, 7 Dec 92 22:12:22 PST
Subject: Anonymous address problems, etc.
In-Reply-To: <9212080059.AA20745@nano.noname>
Message-ID: <9212080612.AA05211@toad.com>


> money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
> analogy to "email".  Here's another one: "crydets", based on
> "credits".  Or maybe we should call them "Chaums".

I passed over "emoney" et al, because I thought they just sounded
lousy.  Too brute-force... "crydets" I like, though.  BTW, it was
"cryp", like "scrip".  Any further suggestions before the RFD?  :-)

Does anyone have a current contact for Chaum, or maybe know the
fellow, in order to ask him how, well, PKP he's going to be about
the whole thing?

> Hal

	 PGP 2 key by finger or e-mail
   Eli   ebrandt at jarthur.claremont.edu





From nobody at soda.berkeley.edu  Mon Dec  7 22:25:37 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Mon, 7 Dec 92 22:25:37 PST
Subject: remailers, the prime user of bandwidth in the US (well, not yet)
Message-ID: <9212080624.AA17822@soda.berkeley.edu>



Could all remailer operators please mail me (hh at soda.berkeley.edu) the
following information so that I can set up a remailer directory?  There are
so many remailers right now that this needs to be done:

1) address to mail to. for instance, hh at soda.berkeley.edu

2) how it works. what lines to put in the header, how to give it a pgp
block, etc.

3) pgp key (if used)

4) how to contact the owner. this may be anonymous. you can easily set up
your mail delivery file to have a Purpose: field and check it for
"contact-owner" which would then forward the mail to the owner.

4) owner's name and email address (optional).

I will compile all of this information and put it up for ftp on soda.

e





From gg at well.sf.ca.us  Tue Dec  8 02:48:26 1992
From: gg at well.sf.ca.us (George A. Gleason)
Date: Tue, 8 Dec 92 02:48:26 PST
Subject: Anonymous address problems, etc.
Message-ID: <199212081046.AA21621@well.sf.ca.us>



How about e-marks...?  Sort of the next big thing after D-marks (Deutche
Marks, you know, German currency).  I don's like "crydets" because it seems
like it's not straightforward pronounciation, especially when dealing with
other languages; too easy to confuse with "credits," and "cry-debts"
("boo-hoo-hoo, another collection notice!")... we need a word which is
less ambiguous than that.  "Cryp" like "scrip" is also like "Crip," which is
a very very unpleasant connotation and might leave a bad taste in the mouth
of Latinos in the US.  

E-Marks.  Clear and straightforward, easy to pronounce and not too many
syllables or weird spelling tweax.  

-gg.





From gnu  Tue Dec  8 05:31:54 1992
From: gnu (John Gilmore)
Date: Tue, 8 Dec 92 05:31:54 PST
Subject: Captain Midnight returns?
In-Reply-To: <9212032155.AB19933@smds.com>
Message-ID: <9212081331.AA15358@toad.com>


> ...put it on your crypto feature ring.  Has a sort of futuristic ring to it.

Hmm, perhaps we should eventually build real Captain Midnight Decoder
Rings, which would fit around your finger.  When the face of the ring
was inserted into a DIN-plug serial port, it would power up, and talk a
serial protocol to do the crypto operations needed to sign and decrypt
messages, a la Phil Karn's design.  There are smart-card microcontrollers
with most or all of the right features -- we'd just have to figure out how
to pot one into a ring with a truncated DIN-plug.

	John





From fnerd at smds.com  Tue Dec  8 09:53:58 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Tue, 8 Dec 92 09:53:58 PST
Subject: peasant_multiply question
Message-ID: <9212081715.AA26885@smds.com>


Folks--

I got out my copy of the original RSA paper, and I'm comparing it to the
PGP 2.0 code.  I have a question about the peasant_modmult routine (the
simplest modmult in PGP).  Here's pseudocode of what I think it's doing:

    /* Inputs: modulus, multiplier, multiplicand */
    /* Output: prod */

    prod = 0;
    set sniffer to most significant bit of multiplier;
    nbits = number of significant bits in multiplier;

    while( nbits-- )
        {
        shift prod left 1;
        prod = prod - modulus;
        if( the bit of the multiplier being sniffed = 1 )
            {
            prod = prod + multiplicand;
            prod = prod - modulus;
            }
        move the sniffer to the next bit of the multiplier;
        }

My question is (assuming I'm understanding the code right), how can it
work subtracting modulus unconditionally all the time?  Won't it make
prod negative sometimes, and then keep multiplying the negative number
by two until it overflows?   Isn't that a problem??

-fnerd
quote me
fnerd at smds.com (FutureNerd Steve Witham)






From fnerd at smds.com  Tue Dec  8 11:38:37 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Tue, 8 Dec 92 11:38:37 PST
Subject: PGP questions
Message-ID: <9212081910.AB28737@smds.com>


>It's probably good to discuss how PGP works here, for educational
>purposes, but I would expect people to get the source code if they
>really are interested.  I can give some pointers here to answers to
>some of the questions people have asked.

Thanks for the answers, Hal.  I have been digging into the original
RSA paper and the PGP 2.0 sources.  By the way, sorry if my response
time is long; I've been traveling for work lately.

I suggested leaving the minimum set of compute-intensive routines
in C and implementing the higher-level stuff in some higher-level language 
("HLL"), possibly interpreted.  Hal pointed out some of the crunching 
jobs other than modmult.  Using an HLL has cons as well as pros to it.

The main advantage (for my purpose here) is that C code has a lot of noise 
that gets in the way of understanding.  This could also be improved by some 
coding style changes--for instance, using some object-oriented stuff (data 
structures that handle more of their own details) and, ahem, fewer #ifdefs...
Another advantage of an HLL is ease of trying out different, er, schemes.

If I used an HLL, I think it would be one that had very C-like syntax.

The main drawback of an HLL is that it's another program that you
have to trust.  Sometimes inner parts of interpreters and compilers are 
hard to write so that they are correct *and seem* correct when you look 
at them.  A couple of things they can do are automatic space allocation, 
garbage collection and "burning" data that's no longer in use ("garbage 
burning?").

-fnerd
quote me
fnerd at smds.com (FutureNerd Steve Witham)






From MCGRATHJ%GRNET at lan.lincoln.cri.nz  Tue Dec  8 13:47:01 1992
From: MCGRATHJ%GRNET at lan.lincoln.cri.nz (McGrath, James)
Date: Tue, 8 Dec 92 13:47:01 PST
Subject: No Subject
Message-ID: <9212082145.AA14652@crop.lincoln.cri.nz>


Karl said: 

> Also, p and q should differ in length by a few digits otherwise
> an enemy may begin to try factoring n by starting near sqrt(n).

When PGP generates keys doesn't it always pick d and e to have
the same number of bits, ie 446 for the strongest type?

Is this the same thing? 

I suppose that if you are allowed leading 0s it isn't a problem
at all, but if the first couple of bits were ones in each key, (a
16:1 chance) wouldn't that significantly reduce the power
required to factor the PK using this approach?

Just a thought,

Jim





From ghsvax!hal at uunet.UU.NET  Tue Dec  8 14:53:49 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Tue, 8 Dec 92 14:53:49 PST
Subject: PGP key generation
Message-ID: <9212082250.AA22082@nano.noname>


Steve Witham asks about PGP's "peasant_modmult" routine, how it can
subtract the modulus on each addition.  It doesn't, but the code is a
little misleading (taken from mpilib.c, PGP 2.1):

    while (bits--)
    {	mp_shift_left(prod);
	msub(prod,pmodulus);	/* turns mult into modmult */
	if (sniff_bit(multiplier,bitmask))
	{   mp_add(prod,multiplicand);
	    msub(prod,pmodulus);	/* turns mult into modmult */
	}
	bump_bitsniffer(multiplier,bitmask);
    }

What is confusing is that "msub" looks like "mp_sub".  Actually, msub
is a macro defined in mpilib.h:

#define msub(r,m) if (mp_compare(r,m) >= 0) mp_sub(r,m)
	/* Prevents r from getting bigger than modulus m */

So, msub actually only subtracts if it's necessary, as would be
expected.


Jim McGrath asks:

> When PGP generates keys doesn't it always pick d and e to have
> the same number of bits, ie 446 for the strongest type?

d and e are the decryption and encryption exponents.  e is chosen to
be small, typically the number 17 or slightly larger.  d is then about
the size of n, your key modulus.

p and q, the two primes which are multiplied to get n, are about the
same size, usually.  PGP does have some code to make sure they aren't
too close to the same size (taken from rsagen.c, PGP 2.1):

        /*	See if p and q are far enough apart.  Is q-p big enough? */
        mp_move(u,q);	/* use u as scratchpad */
        mp_sub(u,p);	/* compute q-p */
        if (mp_tstminus(u))	/* p is bigger */
        {    mp_neg(u);
            too_close_together = (countbits(u) < (countbits(p)-7));
        }
        else		/* q is bigger */
            too_close_together = (countbits(u) < (countbits(q)-7));

        /* Keep trying q's until we get one far enough from p... */
    } while (too_close_together);

What this does is make sure that |p-q| is > 1/128 of the larger of p
or q.  This is designed to make sure that p and q are both very far
from the square root of n.  I.e. if n were 1024 bits, p and q could
both be about 512 bits, but they would be at least about 2^505 from
the square root of n, foiling the square root attacks.

Hal
74076.1041 at compuserve.com





From a.hunter at dunaad.co.uk  Tue Dec  8 14:56:40 1992
From: a.hunter at dunaad.co.uk (Alan Hunter)
Date: Tue, 8 Dec 92 14:56:40 PST
Subject: Re Anonymous address problems etc
Message-ID: <2b25279b.dunaad@dunaad.co.uk>





On Mon, 7 Dec 92 16:59:12 PST, (Hal Finney) ghsvax!hal at uunet.uu.net wrote:
>
> On the digital cash issue - I think we should get some kind of
> implementation of digicash (oops, "electronic money") out for people
> on the list to play with.  Then, we should think of some kind of
> experimental email-based game to play which would use the special
> characteristics of anonymous cash.  Maybe we could use the remailers,
> too.  Players would send cash back and forth to each other as part of
> the game.  Even if the tools are sort of rough at first, this could
> show where the most work is needed.
> 
> Can anyone think of a good kind of game that we could play? 

How about making cypherpunks a subscription mailing list, and paying
contributors?

Alan





From a.hunter at dunaad.co.uk  Wed Dec  9 12:58:03 1992
From: a.hunter at dunaad.co.uk (Alan Hunter)
Date: Wed, 9 Dec 92 12:58:03 PST
Subject: Experiments in Digital cash
Message-ID: <2b264d98.dunaad@dunaad.co.uk>




On Wed, 9 Dec 92 02:25:49 -0800, "John Draper" <crunch at netcom.com> wrote:
> Cm'on Alan,  give us unemployed folks a break.   Life's a bitch already
> for us unemployed folks.    To have to pay to get Cypherpunks mail
> would not go very good.

Just in case...

I meant as an experiment in the use of digital cash and banks.  I'm
sure that DigiBank Inc would give us all an overdraft facility for
starters.

Alan





From gnu  Thu Dec 10 03:03:08 1992
From: gnu (John Gilmore)
Date: Thu, 10 Dec 92 03:03:08 PST
Subject: No more PGP keys without signatures, please!
In-Reply-To: <9212080624.AA17822@soda.berkeley.edu>
Message-ID: <9212101103.AA02644@toad.com>


People continue to post PGP keys that are not vouched for by anyone.
E.g. none of the keys for remailers has any signatures.  This makes it
impossible to trust those remailers, since anyone could have generated
such a key and sent it through a remailer saying it was from someone
else.

If you put up a remailer service, sign its key with your personal key,
at least.  Preferably get a few other people to sign it (by showing them
that they key is really the one used in the remailer, in person).

If you generate a key for yourself, don't just post it -- take it to
a friend, and cross-sign each others' keys.  If you do that a few times,
then you can post it, and the receipients are likely to know one of those
friends, possibly trusting them to certify your key.

	John





From emv at msen.com  Thu Dec 10 05:01:55 1992
From: emv at msen.com (Edward Vielmetti)
Date: Thu, 10 Dec 92 05:01:55 PST
Subject: 'token exchange' market in Arizona
Message-ID: <m0mznTp-0000A8C@garnet.msen.com>


For you all.  Interesting because it would appear to be a real live
marketplace, with real live money, tho no crypto per se in there.

--Ed

------- Forwarded Message

From: rkeca04 at uts.manchester-computing-centre.ac.uk (Thomas Krichel)
Subject: Arizona token exchange
To: cti-econ at mailbase.ac.uk
Date: Thu, 10 Dec 92 11:55:03 GMT

  Greetings,

  this is an  item from corryfee. Apologies to those who have
  already seen it. I thought it was sufficiently interesting
  to pass it on. 

  BTW, the some of the results of the Santa Fe experiment, to which
  the text refers, will be published in a forthcomming book by 
  John Rust and Dan Friedman "Double Auction Markets: Theory, Institutions,
  Evidence". Publisher is Addison-Wesley (Santa Fe Institute series
  On Studies in the Science of Complexity).

  Cheers,

  ______                               
    /   /                              Department of Economics
   /   /_  ________  __.  _            University of Keele
  /   / /_(_) / / <_(_/|_/_)           ST5 5BG                         
    _   ,                  _           Great Britain          
   ' ) /           /      //           Tel.: 44 - 782 - 714847  
    /-<  __  o _. /_  _  //            Fax:  44 - 782 - 717577
  ./   )/ (_<_(__/ /_</_</_            E-mail: Krichel at uts.mcc.ac.uk

> 
>  
>  
>  
>                             ANNOUNCING THE OPENING OF THE
>  
>                             ARIZONA TOKEN EXCHANGE (AZTE)
>  
>                                   January 1, 1993
>  
> Earn cash profits by competing against computerized program traders
>  
> THE CHALLENGE
>  
> Is "artificial intelligence" superior to human intelligence? In
> some domains such as chess, computer programs now outperform all
> but the very best human players.  However in other domains such as
> speech, handwriting, and other kinds of pattern recognition,
> computers lag far behind human beings.  On Wall Street computer
> "program traders" are becoming increasingly common, yet there is
> substantial controversy over their performance -- they have even
> been blamed as a factor in the October 1987 stock market crash.
> The purpose of this study, co-sponsored by the University of
> Arizona's Economic Science Laboratory and the Santa Fe Institute,
> is to compare the performance of human and program traders to see
> whether humans can learn to exploit the limitations  and
> idiosyncracies of computers in repeated interactions.
>  
> THE ARIZONA TOKEN EXCHANGE
>  
> To compare the performance of human and program traders we have
> created a computerized market, the Arizona Token Exchange (AZTE),
> in which a fictional commodity, "tokens", are traded.  The market
> is a simplified version of commodity exchanges such as the Chicago
> Board of Trade where buyers and sellers are able to call out bids
> and asks to buy or sell units of the commodity.  In each trading
> session on AZTE traders are assigned the role of buyer or seller
> and are given an allocation of tokens.  A seller's objective is to
> sell their tokens for as much as possible above the token cost and
> a buyer's objective is to buy tokens as cheaply as possible below
> their redemption value.
>  
> By ranking the token costs and redemption values, well-defined
> supply and demand curves can be constructed.  The intersection of
> these curves defines the so-called competitive equilibrium (CE)
> price and quantity, at which neoclassical economic theory predicts
> all trading will occur.   The complication is that in the AZTE,
> each trader's token costs and redemption values are private
> information and differ from trader to trader.  Thus traders in the
> AZTE face a complex sequential decision problem: how much should
> they bid or ask for their own tokens, how soon should they place a
> bid or ask, and under what circumstances should they accept an
> outstanding bid or ask of some other trader? An additional
> complication is that each trading session runs for a fixed amount
> of time.  This creates a difficult trade-off, for if traders spend
> too much time looking for a good deal, they may find themselves
> locked out of the market without trading anything.
>  
> HOW IS TRADER PERFORMANCE EVALUATED?
>  
> In the AZTE there is a well-defined performance measure: trading
> efficiency, EFF.  This is the ratio of profits a trader actually
> earns divided by the profits it would have made if all trades took
> place at the competitive equilibrium level.  Thus, if a trader's
> EFF is greater than 100% they are earning more than their "fair"
> share of the profits.  The use of EFF is more desirable
> performance measure than simply using trading profits, since
> profits depend on the token allocations which are allocated at
> random from a known distribution.
>  
> After each trading session, participants will earn cash profits
> equal to the following linear function of their efficiency:
>  
>      $ payments =  a + b(EFF-100)
>  
> The term a represents a fixed fee paid for participating in the
> trading session and the term b(EFF-100) represents a bonus
> (penalty) for trading above (or below) 100% efficiency.  Thus, it
> is possible to lose money in any particular trading session.
> Dollar earnings are cumulated over successive trading sessions and
> subjects are eligible to "cash out" at any time after participating
> in a minimum number of trading sessions (provided cumulative
> earnings are positive).
>  
> THE OPPONENTS: COMPUTER PROGRAM TRADERS
>  
> Unlike real commodities markets where most traders are humans, in
> the AZTE all of your opponents will be computer programs.  The
> opponent programs will be selected from a field of over 30
> different trading strategies including winners of the Santa Fe
> Institute's Double Auction Tournament held in March, 1990.  The
> program traders range in sophistication from simple rules of thumb
> (such as Gode-Sunder "Zero-Intelligence" strategy) to sophisticated
> optimizing/learning algorithms (such as neural nets and genetic
> algorithms) developed from the recent literature on artificial
> intelligence.  The identities of your opponents will (usually) be
> revealed to you at the start of each trading session.  You will
> also be informed about other market characteristics such as the
> number of buyers and sellers, the number of tokens, and the joint
> distribution from which token values are drawn.
>  
> SETTING UP AN ACCOUNT
>  
> To trade on the AZTE you will need a Unix or PC-compatible computer
> linked to the Internet computer network.  We provide the trading
> interface software that allows you to log on and trade at any time
> you like and for as long as you like (subject to general
> restrictions).  To qualify for an AZTE trading account you need to
> file an application providing information on your address, phone,
> and email address, and a release form stating whether or not you
> want to remain anonymous in published analyses of the outcome of
> this experiment.  Upon receipt of the application we will set up a
> trading account and access password.  Your dollar earnings will
> cumulate in your account until you decide to cash out, at which
> time we will close your account and mail you a check for the total
> amount of your earnings.
>  
> The software and ASCII traders' manual (including the application
> form) is available via anonymous ftp on "fido.econ.arizona.edu", in
> the azte sub-directory.  The manual (azte.man) explains how the
> software works and what is required to use it.  We suggest you ftp
> this first and read through it, then get the appropriate trading
> interface for your system.  The DOS interface requires VGA graphics
> resolution and the use of Clarkson packet drivers for the network
> interface card.  The Clarkson drivers are also available via ftp on
> "fido.econ.arizona.edu".
>  
> If you don't have access to anonymous ftp, we will mail you a
> diskette containing the software and trader's manual.  To cover the
> costs of a diskette and surface mail, send $5.00 to:
>  
>        Shawn LaMaster
>        Manager, Economic Science Systems Development
>        Economic Science Laboratory
>        McClelland Hall, Room #116
>        University of Arizona
>        Tucson, Arizona  85719
>        (602) 621-6218
>  
>        Internet: lamaster at ziggy.econ.arizona.edu
>  
> We will assist in ftp and setting up the Clarkson packet drivers,
> just give us a call.
>  
>  
> The AZTE software was co-developed by:
>  
> Sean Coates        Economic Science Laboratory, University of Arizona
> Shawn LaMaster     Economic Science Laboratory, University of Arizona
> Richard G. Palmer  Duke University
> John Rust          University of Wisconsin
> Vernon L. Smith    Economic Science Laboratory, University of
> Arizona
> 




------- End of Forwarded Message






From hughes  Thu Dec 10 08:01:27 1992
From: hughes (Eric Hughes)
Date: Thu, 10 Dec 92 08:01:27 PST
Subject: No Subject
Message-ID: <9212101601.AA08764@toad.com>


Fourth Meeting

When: Saturday, Dec 12, 1992, 12:00 noon
Where: Cygnus Support offices

Schedule: 
	Noon	Schmooze, key exchange
	1:00	Business
	5:00	Adjourn

Agenda:

1. Media coverage.  Do we want to deal with the	press?  If so, how?

2. Reputation Systems.  Dean Tribble presenting.

3. Authenticated Diffie-Hellman (STS). Arthur Abraham presenting.

4. Reports


Notes:

1. Please be prompt.  We will begin the business section at 1:00
sharp.

2. Bring a portable computer and your key rings for PGP key exchange
and signing.





From andrew_derry at sfu.ca  Thu Dec 10 09:31:17 1992
From: andrew_derry at sfu.ca (andrew_derry at sfu.ca)
Date: Thu, 10 Dec 92 09:31:17 PST
Subject: Key swap in Vancouver, BC, Canada, anyone?
Message-ID: <9212101730.AA00143@whistler.sfu.ca>


Is anybody in, or comming to, Vancouver, BC that I could swap public keys
with?

Thanks.
---
Andrew Derry                      |
ACS at HCC - Simon Fraser University |
Internet: derry at sfu.ca            |






From Marc.Ringuette at GS80.SP.CS.CMU.EDU  Thu Dec 10 11:03:58 1992
From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU)
Date: Thu, 10 Dec 92 11:03:58 PST
Subject: 'token exchange' market in Arizona
Message-ID: <9212101903.AA12887@toad.com>


I participated in SFI's "Double Auction Tournament" a couple of years
ago, placing second.  Computer programs participated in a stock market
game, with individual buyers and sellers competing with each other to
make profit from fictional tokens.  The emphasis of the contest was on
computer trading strategies, not on monetary systems or computer
security.  

This new "token exchange" sounds like a continuation of the original
contest in which there will be an opportunity to compete and refine
strategies over a longer term.  It will probably be run from a central
server with minimal concern over security; these are economists
interested in stock market systems, not computer security people.

In the original contest, there was a prize pool of $10,000 divided
among the 30 contestants, with no contestant winning more than about
$500.  It seems likely that they'll have a similar bankroll for this
one, as an inducement for people to compete.


-- Marc Ringuette (mnr at cs.cmu.edu)





From hughes  Thu Dec 10 11:14:03 1992
From: hughes (Eric Hughes)
Date: Thu, 10 Dec 92 11:14:03 PST
Subject: Directions to Cygnus support offices
Message-ID: <9212101913.AA13306@toad.com>



	Cygnus Support
	1937 Landings Drive
	Mt. View, CA  94043
	+1 415 903 1400   switchboard
	+1 415 903 1418   John Gilmore

Take US 101 toward Mt. View.  From San Francisco, it's about a
40-minute drive.  Get off at the Rengstorff Ave/Amphitheatre Parkway
exit.  If you were heading south on 101, you curve around to the
right, cross over the freeway, and get to a stoplight.  If you were
heading north on 101, you just come right off the exit to the
stoplight.  The light is the intersection of Amphitheatre and
Charleston Rd.  Take a right on Charleston; there's a right-turn-only
lane.

Follow Charleston for a short distance.  You'll pass the
Metaphor/Kaleida buildings on the right.  At a clump of palm trees and
a "Landmark Deli" sign, take a right into Landings Drive.  At the end
of the road, turn left into the complex with the big concrete
"Landmark" sign.  Follow the road past the deli til you are in front
of the clock tower that rises out of one of the buildings, facing you.
Enter through the doors immediately under the clock tower.  They'll be
open between noon and 1PM at least.  (See below if you're late.)

Once inside, take the stairs up, immediately to your right.  At the top
of the stairs, turn right past the treetops, and we'll be in 1937 on 
your left.  The door is marked "Cygnus".

If you are late and the door under the clock tower is locked, you can
walk to the deli (which will be around the building on your left, as
you face the door).  Go through the gate in the fence to the right of
the deli, and into the back lawns between the complex and the farm
behind it.  Walk forward and right around the buildings until you see
a satellite dish in the lawn.  Go up the stairs next to the dish,
which are the back stairs into the Cygnus office space.  We'll prop
the door (or you can bang on it if we forget).

Or, you can find the guard who's wandering around the complex, who
knows there's a meeting happening and will let you in.  They can be
beeped at 965 5250, though you'll have trouble finding a phone.

Don't forget to eat first, or bring food at noon!  I recommend hitting
the burrito place on Rengstorff (La Costen~a) at about 11:45.  To get
there, when you get off 101, take Rengstorff (toward the hills) rather
than Amphitheatre (toward the bay).  Follow it about ten blocks until
the major intersection at Middlefield Road.  La Costen~a is the store
on your left at the corner.  You can turn left into the narrow lane
behind the store, which leads to a parking lot, and enter by the front
door, which faces the intersection.  To get to the meeting from there,
just retrace your route on Rengstorff, go straight over the freeway,
and turn right at the stoplight onto Charleston; see above.

See you there!

	John Gilmore








From fnerd at smds.com  Thu Dec 10 12:24:49 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:24:49 PST
Subject: Tapes of Cypherpunks meeting?
Message-ID: <9212101813.AA19425@smds.com>


>Fourth Meeting
>
>When: Saturday, Dec 12, 1992, 12:00 noon
>Where: Cygnus Support offices

Would it be possible to pay someone to video (or at least audio)
tape this meeting (& others)--or at least the scheduled speakers?  
I can imagine privacy concerns...  Maybe someone could
get ready to do it and then ask the attendees whether it's okay,
or under what arrangement.  There will definitely be people there
with somewhat informed opinions on whether to trust me.

This brings up a fun concept: encrypted digital video and audio.
Would it be hard to do IDEA encryption at the standard CD rate?
There are schemes to compress video to that rate--how available
are they?  How much investment in equipment and crunch time do 
you need?  How easy is it to interrupt the bit streams in and out
of a DAT recorder?  How cheap is the decoder?

At present I would prefer VHS.

from out of nowhere
-fnerd
fnerd at smds.com (FutureNerd Steve Witham)






From fnerd at smds.com  Thu Dec 10 12:26:02 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:26:02 PST
Subject: CHATTER Broadcast/Filter vs. "Fetching"
Message-ID: <9212101749.AA19315@smds.com>


Yanek Martinson basically says that the information that comes over the 
netnews right now is small enough that you could archive a couple weeks' 
worth on a gigabyte disk and put the rest on four DAT tapes per year.

True, but that's only the current rate of this particular channel.
Plus, most of the time I'd have to go back to tape.  But the real problem
here is that I haven't explained what I want instead.

I want all the archives of all the information in all media that have ever
been published and stored electronically (including on video and audio tape)
available at a second's notice.  That's the volume and access-time part of
it.  The other part is, how do I find what I want?  Yanek responds to me:

>>...I don't trust computer filters much.
>
>So how would you expect to know to "fetch" it?

Because I read one thing, and it says "in response to your article number
so-and-so," or, "Hey, folks, there's a great book on this over here."
In other words, following mentions in other things I see--things written
mostly by humans, at least at this point, but also published indexes
(manual or automatic) and guides.

That plus maybe a couple of low-bandwidth subscription setups like
magazines, and maybe one or two discussion groups like this one that I
would give full time attention to.

>> ...support distributed redundant archives,
>
>That's the current setup.
>
>> preferably with cross-checking. 
>
>What exactly do you mean by this?

That when I requested something, automatically a couple of storage sites
would be asked for its MD5 checksum, and my machine would check them against
each other and the actual data I got.
>
>> It would be even nicer if information could be stored, with
>> storage cost charged to the owner and/or readers,
>
>I don't think this would work too well.  Just because I answer someone's
>question on a newsgroup, I would not want to receive a bill for the
>storage.

The DAT system you describe has all the potential readers pay for the storage.
If they want to, then fine, but if not, and you don't want to either, that's 
fine, let your answer evaporate.  Someone always *is* paying.

>> and the rigamarole over creating new groups, and whether all the machines
>> between you and the center of the universe get all the groups, etc.
>
>Then get Len Rose's satellite dish (I did) and you can be pretty sure 
>you get all the newsgroups.

What's that cost, including electronics, modem, etc?  
Also, you didn't answer about the difficulty of creating groups.

-fnerd
store me now and quote me later
fnerd at smds.com (FutureNerd Steve Witham)






From fnerd at smds.com  Thu Dec 10 12:26:15 1992
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:26:15 PST
Subject: crypto credits
Message-ID: <9212101749.AB19315@smds.com>


>need for a shorter term than "digital cash" for this cryptographic
>money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
>analogy to "email".  Here's another one: "crydets", based on
>"credits".  Or maybe we should call them "Chaums"....

How about "crypto credits" or "quatloos?"

(And you're right about David Chaum, Dining Cryptographers and Digi Cash.)

-fnerd
quote me
fnerd at smds.com (FutureNerd Steve Witham)






From tcmay at netcom.com  Thu Dec 10 12:59:53 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 10 Dec 92 12:59:53 PST
Subject: Tapes of Cypherpunks meeting?
In-Reply-To: <9212101813.AA19425@smds.com>
Message-ID: <9212102058.AA18076@netcom.netcom.com>



Steve Witham writes:

> Would it be possible to pay someone to video (or at least audio)
> tape this meeting (& others)--or at least the scheduled speakers?  
> I can imagine privacy concerns...  Maybe someone could
> get ready to do it and then ask the attendees whether it's okay,
> or under what arrangement.  There will definitely be people there
> with somewhat informed opinions on whether to trust me.

I doubt this will ever happen. Videotaping is a hassle, is even more
of a hassle when it comes to distributing the tapes, and is very
disruptive. People start mugging for the camera, or avoid speaking at
all. All in all, a bad idea.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From rb at hprrb.rose.hp.com  Thu Dec 10 14:36:21 1992
From: rb at hprrb.rose.hp.com (Robert Brooks)
Date: Thu, 10 Dec 92 14:36:21 PST
Subject: A/V compression
Message-ID: <9212102233.AA15517@hprrb.rose.hp.com>


> 
> This brings up a fun concept: encrypted digital video and audio.
> Would it be hard to do IDEA encryption at the standard CD rate?
> There are schemes to compress video to that rate--how available
> are they?  How much investment in equipment and crunch time do 
> you need?  How easy is it to interrupt the bit streams in and out
> of a DAT recorder?  How cheap is the decoder?
> 

I picked this up off the net a while ago.  Sounds like the CL451 might
be programmable to do encryption/decryption, too.

Background:  MPEG is a compression standard for compressing VHS-quality
video and stereo audio into a 1.5Mbit/s stream.

If anyone's interested in funding/collaborating on a project involving
this, let's talk.


---
>From eletanjm at nuscc.nus.sg Fri Jul 10 21:06:25 1992
>Relay-Version: version Notes 2.8.4  1990/05/09; site hprpcd.rose.hp.com
>From: eletanjm at nuscc.nus.sg (TAN JIN MENG)
>Date: Sat, 11 Jul 1992 04:06:25 GMT
>Date-Received: Sun, 12 Jul 1992 01:35:12 GMT
>Subject: NEW MPEG I CHIP
>Message-ID: <1992Jul11.040625.17239 at nuscc.nus.sg>
>Organization: National University of Singapore
>Path: hprpcd!hprdash!hpergfg2!hpda!hpcc05!hplextra!hpscdc!sdd.hp.com!nigel.msen.com!yale.edu!jvnc.net!nuscc!eletanjm
>Newsgroups: comp.multimedia
>Lines: 23
>
>Has anyone seen a demo or read about the new MPEG chipset from C-Cube
>systems?
>
>I heard it's great!
>
>Some facts I know (or think I know)
>
>*       CL450 - is a decoder only
>*       CL451 - due out later this year is full encoder/decoder codec
>*       core is a RISC based processor with 36bit bus splittable into
>        4 data streams. 4 separate acc/mul units (ie SIMD).
>*       Can stream a full resolution video at ISA bus rates.
>*       Microcode and C compiler development kit.
>*       CL451 currently runs at 66MHz using fairly old .8 micron
>        technology ==> we can expect to see even higher speed devices.
>*       CL451 is pipelinable - ie can put multiple CL451 in tandem to
>        perform any amount of processor intensive activities. (eg real
>        time edge/motion detection, special effects etc).
>*       CL451 is a single chip solution. Just add VRAM.
>
>*       Largest demand so far - for Karaoke!! C-Cube has Jap. backers.
>
>jin meng
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~       Robert Brooks                           ~
~       Hewlett Packard Company                 ~
~       rb at hprpcd.rose.hp.com                   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~       Robert Brooks                           ~
~       Hewlett Packard Company                 ~
~       rb at hprpcd.rose.hp.com                   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





From whitaker at eternity.demon.co.uk  Thu Dec 10 15:12:06 1992
From: whitaker at eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 10 Dec 92 15:12:06 PST
Subject: MEETING: Cypherpunks UK (Sunday)
Message-ID: <6042@eternity.demon.co.uk>


Announcing - on incredibly short notice! - the first meeting of
Cypherpunks UK...

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
this Sunday, 13 December 1992, from 1200 onwards (at least until 1800),
at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

Otherwise, we might come close to a (n(n-1))/2 situation... ;-)

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of PGP public keys in the U.K.
  o   The local development of anonymous remailers and a proposed
        automatic public key repository
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and set up the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding
recently to include all versions of PGP, and "fellow traveller" files).

There will be other people here whom I think you will find
interesting...  be seeing you!

Semper vigilans,

Russell Earl Whitaker                   whitaker at eternity.demon.co.uk
Communications Editor                       71750.2413 at compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================





From mark at coombs.anu.edu.au  Thu Dec 10 17:24:57 1992
From: mark at coombs.anu.edu.au (Mark)
Date: Thu, 10 Dec 92 17:24:57 PST
Subject: Questions about US/Canadian Laws about public encryption
In-Reply-To: <BysM6J.76z@minerva1.bull.it>
Message-ID: <mark.724036564@coombs>


David Banisar <Banisar at washofc.cpsr.org> quotes:

>> (1) Is feeding public data or telephone networks with crypted data
>>     illegal or those who posted articles on the subject were just
>>     wishing it were made illegal ???

One might ask that they prove it is encrypted and not merely garbage your
pumping down the line to defeat traffic analysis attacks. I dont think it's
illegal so send garbage down a line assuming your paying for it and noone
is being defrauded by your use of the medium.

If you have good enough cryptography they cant prove it's encrypted. If they
managed to decode it to something that looks like text but isnt the original
cleartext then they are just grabbing at straws and not 'decrypting'.

If you choose to put the "standard" bytes in front and behind every block to
make it *look* like it's encrypted with a well known algorithm thats your
business.

To me proving it's encrypted amounts to decrypting it which is what your
trying to protect against. If they can prove the algorithm is weak then you
can just pay the fine and choose another method.

Mark
mark at coombs.anu.edu.au





From mark at coombs.anu.edu.au  Thu Dec 10 17:31:26 1992
From: mark at coombs.anu.edu.au (Mark)
Date: Thu, 10 Dec 92 17:31:26 PST
Subject: Questions about US/Canadian Laws about public encryption
In-Reply-To: <BysM6J.76z@minerva1.bull.it>
Message-ID: <mark.724037151@coombs>


On a discussion of devices one can attach to a phone line to encrypt
your comms:

rcain at netcom.com (Robert Cain) writes:

>There may be U.S. national security
>laws broad enough to stop a potential seller of such a device and I
>have been told that under such laws (of which I know little by definition)
>a stop order can be issued by a court which you must obey but can't even
>open because it carries a top secret seal and furthermore you cannot even
>discuss it without looking at Leavenworth.  So it is entirely possible that
>hidden laws exist to prevent sale of such devices, have been used and we
>would not know it under the umbrella of U.S. national security. 

So much for "ignorance of the law is no excuse". They want it both ways?
Secret laws and you obeying them? Sounds like the rules my roomies make up
as we play any board game. (aka cheating :)

Mark
mark at coombs.anu.edu.au





From nobody at rosebud.ee.uh.edu  Thu Dec 10 21:24:21 1992
From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu)
Date: Thu, 10 Dec 92 21:24:21 PST
Subject: No Subject
Message-ID: <9212110524.AA22910@toad.com>


-----BEGIN PGP SIGNED MESSAGE-----

Update on the digital cash project

I am having some problems with the port to MSDOS, mostly due to
implicitly assuming 32-bit integers in a few places.  Probably I won't
get it working until next weekend.

To recap, the program provides Chaum-style digital cash via two
executables, one for the "players" and one for the "banker".  The
banker creates a public key which has a single modulus n and multiple
exponents, the prime numbers starting with 17.  He sends n to the
players and all is ready.

Players withdraw money by running their programs and specifying the
denominations they want to withdraw.  For example, you could withdraw
a 1, two 5's, a 10 and a 20.  This would create a file with 5 entries
to be sent to the bank.  PGP should be used to encrypt and
ascii-encode this file (for privacy) and it should be mailed to the
banker.

The banker receives this file and runs his program to RSA-sign the
values in each of the withdrawal-request entries.  This is the
"blinded cash" that Chaum describes.  Again, PGP should be used for
mailing this back to the user.

The player then has to "unblind" the file to make it "real" digital
cash.  This also changes it so that the bank won't recognize it when
it is deposited.  He uses his version of the program to do this,
producing an actual digital money file with the five "digital bills"
in it.

To pay another user, he runs another function to extract the desired
bills from this file.  Suppose he wants to extract a 1 and a 5.  This
leaves a 5, a 10 and a 20 in the original file, and creates a new
digital cash file with a 1 and a 5.  He would then use PGP again to
encrypt this for safety and mail it to the person he wants to pay.

That person can run a "check" function on the incoming digital money
to make sure it has a proper bank signature on it and is not a
forgery.  He would then mail it directly to the bank so that it could
get credited to his account.

The banker runs his program which checks the signatures on the
incoming money, looks in a database file to make sure these bills
haven't been used before, and adds these bills to the database.  (The
database stores 16 bytes per bill.)  He should then record the deposit
and perhaps send a confirmation to the depositor (my program doesn't
get involved with that).

I hope this gives a clearer picture of how the electronic money
program works.  It is a simple implementation but I think many systems
would work similarly.

I appreciated the suggestion to use cash as part of the list
management itself.  Rather than paying people who post, I wonder if it
would be better to make people pay to post.  Many people have
complained about the volume.  :)  Unfortunately, I suspect that this
would involve too much overhead for the mailing list maintainer.

Maybe the thing to do is to just get the software out there and let
people decide what they want to do with it (if anything).  I'm
probably going to take a couple more weeks to clean up the user
interface and get these bugs out, then I'll try sending it someone to
be put on the cypherpunks ftp archive.

It's nice to be able to finally sign these messages!

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC
aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw
7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX
M/McOuwuIjs=
=/HGX
-----END PGP SIGNATURE-----





From nobody at cicada.berkeley.edu  Thu Dec 10 23:20:55 1992
From: nobody at cicada.berkeley.edu (nobody at cicada.berkeley.edu)
Date: Thu, 10 Dec 92 23:20:55 PST
Subject: remailers
Message-ID: <9212110717.AA07396@cicada.berkeley.edu>


This is another call for info from remailer operators.  I only heard from a
few of you.  Please send me info about how to use your remailer, including
the public key.  I will be setting up a special mailing list for remailer
operators so we can discuss the technical issues of remailing, so if you
mail me, you get on the list (if you want to).

Remember, the more remailers there are and the more they are used, the safer
it is for each individual remailer operator.  And people won't use them
unless they know how.  And they won't know how unless there's a directory of
them.

e
hh at soda.berkeley.edu





From gg at well.sf.ca.us  Fri Dec 11 02:22:14 1992
From: gg at well.sf.ca.us (George A. Gleason)
Date: Fri, 11 Dec 92 02:22:14 PST
Subject: Questions about US/Canadian Laws about public encryption
Message-ID: <199212111020.AA28057@well.sf.ca.us>


Any attempt at "secret law" in the US would be pretty straightforward to
defeat on the basis that it denies due process and a whole lot else besides.
 Secret court orders!  Retch!  Next person to get one should run not walk to
the offices of the nearest big newspaper or radio/TV station and do a live
on-air interview.  Then the govt has to take on the press as well, and by
that time it's kinda too late.  





From tribble at xanadu.com  Fri Dec 11 10:10:54 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Fri, 11 Dec 92 10:10:54 PST
Subject: Questions about US/Canadian Laws about public encryption
In-Reply-To: <199212111020.AA28057@well.sf.ca.us>
Message-ID: <9212111720.AA24204@xanadu.xanadu.com>


	 Any attempt at "secret law" in the US would be pretty straightforward to
	 defeat on the basis that it denies due process and a whole lot else besides.
		Secret court orders!  Retch!  Next person to get one should run not walk to
	 the offices of the nearest big newspaper or radio/TV station and do a live
	 on-air interview.  Then the govt has to take on the press as well, and by
	 that time it's kinda too late.  

This worls in theory, but practice can be much more confusing.  For
instance, the warrant used to invade Steve Jackson Games was sealed,
so they couldn't see what was being looked for.  If you face a Grand
Jury, then you can't take the 5th (thus drug crimes are being pursued
by Grand Juries).  Etc.  I'm not prophesying gloom and doom (at least
not here :-), merely pointing out that what makes sense, what seems
ethical, what the theory of the law says, and what the practice of
the law says are all different, and it's quite easy to be wrong.

dean





From nobody at pmantis.berkeley.edu  Fri Dec 11 14:58:27 1992
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Fri, 11 Dec 92 14:58:27 PST
Subject: Chaum's "The Dining Cryptographers Problem" (VERY LONG)
Message-ID: <9212112258.AA09353@pmantis.berkeley.edu>


The following article is brought to you by the Information Liberation
Front (ILF), a group dedicated to the timely distribution of important
information. 

The ILF encourages you to use this article for educational purposes
only and to seek out the original article. Minor spelling errors and
slight alterations of formulas may have gotten past the OCR process.

We apologize for the length, but feel this is one of the key articles
in this area. 


J. Cryptology (1988) 1:65-75

The Dining Cryptographers Problem:

Unconditional Sender and Recipient Untraceability

David Chaum
Centre for Mathematics and Computer Science, Kruislan 413, 1098 SJ 
Amsterdam, The Netherlands

Abstract.  Keeping confidential who sends which messages, in a 
world where any physical transmission can be traced to its 
origin, seems impossible. The solution presented here is 
unconditionally or cryptographically secure, depending on whether 
it is based on one-time-use keys or on public keys, respectively. 
It can be adapted to address efficiently a wide variety of 
practical considerations.

Key words.  Untraceability, Unconditional Security, Pseudonymity.

Introduction

Three cryptographers are sitting down to dinner at their favorite 
three-star restaurant. Their waiter informs them that arrangements 
have been made with the maitre d'hotel for the bill to be paid 
anonymously. One of the cryptographers might be paying for the dinner, 
or it might have been NSA (U.S. National Security Agency). The three 
cryptographers respect each other's right to make an anonymous 
payment, but they wonder if NSA is paying. They resolve their 
uncertainty fairly by carrying out the following protocol:

Each cryptographer flips an unbiased coin behind his menu, between 
him and the cryptographer on his right, so that only the two of them can 
see the outcome. Each cryptographer then states aloud whether the two 
coins he can see--the one he flipped and the one his left-hand neighbor 
flipped--fell on the same side or on different sides. If one of the 
cryptographers is the payer, he states the opposite of what he sees. An 
odd number of differences uttered at the table indicates that a 
cryptographer is paying; an even number indicates that NSA is paying 
(assuming that the dinner was paid for only once). Yet if a 
cryptographer is paying, neither of the other two learns anything from 
the utterances about which cryptographer it is.

To see why the protocol is unconditionally secure if carried out 
faithfully, consider the dilemma of a cryptographer who is not the 
payer and wishes to find out which cryptographer is. (If NSA pays, there 
is no anonymity problem.) There are two cases. In case (1) the two 
coins he sees are the same, one of the other cryptographers said 
"different," and the other one said "same." If the hidden outcome was 
the same as the two outcomes he sees, the cryptographer who said 
"different" is the payer; if the outcome was different, the one who said 
"same" is the payer. But since the hidden coin is fair, both possibilities 
are equally likely. In case (2) the coins he sees are different; if both 
other cryptographers said "different," then the payer is closest to the 
coin that is the same as the hidden coin; if both said "same," then the 
payer is closest to the coin that differs from the hidden coin. Thus, in 
each subcase, a nonpaying cryptographer learns nothing about which of 
the other two is paying.

The cryptographers become intrigued with the ability to make 
messages public untraceably. They devise a way to do this at the table 
for a statement of arbitrary length: the basic protocol is repeated over 
and over; when one cryptographer wishes to make a message public, he 
merely begins inverting his statements in those rounds corresponding 
to 1 's in a binary coded version of his message. If he notices that his 
message would collide with some other message, he may for example 
wait a number of rounds chosen at random from a suitable distribution 
before trying to transmit again.

1. Generalizing the Approach

During dinner, the cryptographers also consider how any number of 
participants greater than one can carry out a version of the protocol. 
(With two participants, only nonparticipant listeners are unable to 
distinguish between the two potential senders.) Each participant has a 
secret key bit in common with, say, every other participant. Each 
participant outputs the sum, modulo two, of all the key bits he shares, 
and if he wishes to transmit, he inverts his output. If no participant 
transmits, the modulo two sum of the outputs must be zero, since every 
key bit enters exactly twice; if one participant transmits, the sum 
must be one. (In fact, any even number of transmitting participants 
yields zero, and any odd number yields one.) For j rounds, each 
participant could have a j-bit key in common with every other 
participant, and the ith bit of each such key would be used only in the 
ith round. Detected collision of messages leads to attempted 
retransmission as described above; undetected collision results only 
from an odd number of synchronized identical message segments. 
(Generalization to fields other than GF(2) is possible, but seems to 
offer little practical advantage.)

Other generalizations are also considered during dinner. The 
underlying assumptions are first made explicit, including modeling 
key-sharing arrangements as graphs. Next, the model is illustrated 
with some simple examples. The potential for cooperations of 
participants to violate the security of others is then looked at. Finally, 
a proof of security based on systems of linear equations is given.

1.1. Model

Each participant is assumed to have two kinds of secret: (a) the keys 
shared with other participants for each round; and (b) the inversion 
used in each round (i.e., a 1 if the participant inverts in that round and a 
0 if not). Some or all of a participant's secrets may be given to other 
participants in various forms of collusion, discussion of which is 
postponed until Section 1.3. (For simplicity in exposition, the 
possibility of secrets being stolen is ignored throughout.)

The remaining information about the system may be described as: (a)
who shares keys with whom; and (b) what each participant outputs
during each round (the modulo two sum of that participant's keys and
inversion). This information need not be secret to ensure
untraceability. If it is publicly known and agreed, it allows various
extensions discussed in Sections 2.5 and 2.6. The sum of all the
outputs will, of course, usually become known to all participants.

In the terminology of graphs, each participant corresponds to a 
vertex and each key corresponds to an edge. An edge is incident on the 
vertices corresponding to the pair of participants that shares the 
corresponding key. From here on, the graph and dinner-table 
terminologies will be used interchangeably. Also, without loss of 
generality, it will be assumed that the graph is connected (i.e., that a 
path exists between every pair of vertices), since each connected 
component (i.e., each maximal connected subgraph) could be considered 
a separate untraceable-sender system.

An anonymity set seen by a set of keys is the set of vertices in a 
connected component of the graph formed from the original graph by 
removing the edges concerned. Thus a set of keys sees one anonymity 
set for each connected partition induced by removing the keys. The main 
theorem of Section 1.4 is essentially that those having only the public 
information and a set of keys seeing some anonymity set can learn 
nothing about the members of that anonymity set except the overall 
parity of their inversions. Thus, for example, any two participants 
connected by at least one chain of keys unknown to an observer are both 
in the same anonymity set seen by the observer's keys, and the observer 
gains nothing that would help distinguish between their messages.

1.2. Some Examples

A few simple consequences of the above model may be illustrative. The 
anonymity set seen by the empty set (i.e., by a nonparticipant observer) 
is the set of all vertices, since the graph is assumed connected and 
remains so after zero edges are removed. Also, the anonymity sets seen 
by the full set of edges are all singleton sets, since each vertex's 
inversion is just the sum of its output and the corresponding key bits.

If all other participants cooperate fully against one, of course no 
protocol can keep that singleton's messages untraceable, since 
untraceability exists only among a set of possible actors, and if the set 
has only one member, its messages are traceable. For similar reasons, 
if a participant believes that some subset of other participants will 
fully cooperate against him, there is no need for him to have keys in 
common with them.

A biconnected graph (i.e., a graph with at least two vertex-disjoint 
paths between every pair of vertices) has no cut-vertices (i.e., a single 
vertex whose removal partitions the graph into disjoint subgraphs). In 
such a graph, the set of edges incident on a vertex v sees (apart from v) 
one anonymity set containing all other vertices, since there is a path 
not containing v between every pair of vertices, and thus they form a 
connected subgraph excluding v; each participant acting alone learns 
nothing about the contribution of other participants.

1.3. Collusion of Participants

Some participants may cooperate by pooling their keys in efforts to 
trace the messages of others; such cooperation will be called collusion. 
For simplicity, the possibilities for multiple collusions or for pooling 
of information other than full edges will be ignored. Colluders who lie 
to each other are only touched on briefly, in Section 2.6.

Consider collusion in a complete graph. A vertex is only seen as a 
singleton anonymity set by the collection of all edges incident on it; all 
other participants must supply the key they share with a participant in 
order to determine that participant's inversions. But since a collusion 
of all but one participant can always trace that participant merely by 
pooling its members' inversions as already mentioned, it gains nothing 
more by pooling its keys. The nonsingleton anonymity set seen by all 
edges incident on a colluding set of vertices in a complete graph is the 
set of all other vertices; again, a collusion yields nothing more from 
pooling all its keys than from pooling all its inversions.

Now consider noncomplete graphs. A full collusion is a subset of 
participants pooling all of their keys. The pooled keys see each colluder 
as a singleton anonymity set; the colluders completely sacrifice the 
untraceability of their own messages. If a full collusion includes a cut-
set of vertices (i.e., one whose removal partitions the graph), the 
collusion becomes nontrivial because it can learn something about the 
origin of messages originating outside the collusion; the noncolluding 
vertices are partitioned into disjoint subgraphs, which are the 
anonymity sets seen by the pooled keys.

Members of a partial collusion pool some but not all of their keys. 
Unlike the members of a full collusion, each member of a partial 
collusion in general has a different set of keys. For it to be nontrivial, 
a partial collusion's pooled keys must include the bridges or separating 
edges of a segregation or splitting of the graph (i.e., those edges whose 
removal would partition the graph). Settings are easily constructed in 
which the pooled keys see anonymity sets that partition the graph and 
yet leave each colluder in a nonsingleton partition seen by any other 
participant. Thus, colluders can join a collusion without having to make 
themselves completely traceable to the collusion's other members.

1.4. Proof of Security

Consider, without loss of generality, a single round in which say some 
full collusion knows some set of keys. Remove the edges known to the 
collusion from the key-sharing graph and consider any particular 
connected component C of the remaining graph. The vertices of C thus 
form an anonymity set seen by the pooled keys.

Informally, what remains to be shown is that the only thing the 
collusion learns about the members of C is the parity sum of their 
inversions. This is intuitively apparent, since the inversions of the 
members of C are each in effect hidden from the collusion by one or 
more unknown key bits, and only the parity of the sum of these key bits 
is known (to be zero). Thus the inversions are hidden by a one-time pad, 
and only their parity is revealed, because only the parity of the pad is 
known.

The setting is formalized as follows: the connected component C is 
comprised of rn vertices and n edges. The incidence matrix M of C is 
defined as usual, with the vertices labeling the rows and the edges 
labeling the columns. Let K, I, and A be stochastic variables defined on 
GF(2)^n, GF(2)^m, and GF(2)^m, respectively, such that
K is uniformly distributed over GF(2)^n, K and I are mutually 
independent, and A = (MK) cross I. In terms of the protocol, K comprises 
the keys corresponding to the edges, I consists of the inversions 
corresponding to the vertices, and A is formed by the outputs of the 
vertices. Notice that the parity of A (i.e., the modulo two sum of its 
components) is always equal to the parity of I, since the columns of M 
each have zero parity. The desired result is essentially that A reveals 
no more information about I than the parity of 1. More formally:

Theorem.  Let a be in GF(2)^n. For each i in GF(2)^n, which is assumed by 
I with nonzero probability and which has the same parity as a, the 
conditional probability that A = a given that I = i is 2^(1 - m). Hence, 
the conditional probability that I = i given that A = a is the a priori 
probability that I = i.

Proof.  Let i be an element of GF(2)^n have the same parity as a. 
Consider the system of linear equations (MK) cross i = a, in k an 
element of GF(2)^n. Since the columns of M each have even parity, as 
mentioned above, its rows are linearly dependent over GF(2)^m. But as a 
consequence of the connectedness of the graph, every proper subset of 
rows of M is linearly independent. Thus, the rank of M is m - 1, and so 
each vector with zero parity can be written as a linear combination of 
the columns of M. This implies that the system is solvable because i 
cross a has even parity. Since the set of n column vectors of M has rank 
m - 1, the system has exactly 2^(n - m + 1) solutions.

Together with the fact that K and I are mutually independent and 
that K is uniformly distributed, the theorem follows easily.                           

2. Some Practical Considerations

After dinner, while discussing how they can continue to make 
untraceable statements from this respective homes, the cryptographers 
take up a variety of other topics. In particular, they consider different 
ways to establish the needed keys; debate adapting the approach to 
various kinds of communication networks; examine the traditional 
problems of secrecy and authentication in the context of a system that 
can provide essentially optimal untraceability; address denial of 
service caused by malicious and devious participants; and propose 
means to discourage socially undesirable messages from being sent.

2.1. Establishing Keys

One way to provide the keys needed for longer messages is for one 
member of each pair to toss many coins in advance. Two identical 
copies of the resulting bits are made, say each on a separate optical 
disk. Supplying one such disk (which today can hold on the order of 
10^10 bits) to a partner provides enough key bits to allow people to 
type messages at full speed for years. If participants are not 
transmitting all the time, the keys can be made to last even longer by 
using a substantially slower rate when no message is being sent; the 
full rate would be invoked automatically only when a 1 bit indicated 
the beginning of a message. (This can also reduce the bandwidth 
requirements discussed in Section 2.2.)

Another possibility is for a pair to establish a short key and use a 
cryptographic pseudorandom-sequence generator to expand it as needed. 
Of course this system might be broken if the generator were broken. 
Cryptanalysis may be made more difficult, however, by lack of access 
to the output of individual generators. Even when the cryptographers do 
not exchange keys at dinner, they can safely do so later using a public-
key distribution system (first proposed by [4] and [3]).

2.2 Underlying Communication Techniques

A variety of underlying communication networks can be used, and their 
topology need not be related to that of the key-sharing graph.

Communication systems based on simple cycles, called rings, are 
common in local area networks. In a typical ring, each node receives 
each bit and passes it round-robin to the next node. This technology is 
readily adapted to the present protocols. Consider a single-bit message 
like the "I paid" message originally sent at the dinner table. Each 
participant exclusive-or's the bit he receives with his own output 
before forwarding it to the next participant. When the bit has traveled 
full circle, it is the exclusive-or sum of all the participants' outputs, 
which is the desired result of the protocol. To provide these messages 
to all participants, each bit is sent around a second time by the 
participant at the end of the loop.

Such an adapted ring requires, on average, a fourfold increase in 
bandwidth over the obvious traceable protocols in which messages 
travel only halfway around on average before being taken off the ring by 
their recipients. Rings differ from the dinner table in that several bit-
transmission delays may be required before all the outputs of a 
particular round are known to all participants; collisions are detected 
only after such delays.

Efficient use of many other practical communication techniques 
requires participants to group output bits into blocks. For example, in 
high-capacity broadcast systems, such as those based on coaxial cable, 
surface radio, or satellites, more efficient use of channel capacity is 
obtained by grouping a participant's contribution into a block about the 
size of a single message (see, e.g., [5]). Use of such communication 
techniques could require an increase in bandwidth on the order of the 
number of participants.

In a network with one message per block, the well-known contention 
protocols can be used: time is divided evenly into frames; a participant 
transmits a block during one frame; if the block was garbled by 
collision (presumably with another transmitted block), the participant 
waits a number of frames chosen at random from some distribution 
before attempting to retransmit; the participants' waiting intervals 
may be adjusted on the basis of the collision rate and possibly of other 
heuristics [5].

In a network with many messages per block, a first block may be 
used by various anonymous senders to request a "slot reservation" in a 
second block. A simple scheme would be for each anonymous sender to 
invert one randomly selected bit in the first block for each slot they 
wish to reserve in the second block. After the result of the first block 
becomes known, the participant who caused the ith 1 bit in the first 
block sends in the ith slot of the second block.

2.3. Example Key-Sharing Graphs

In large systems it may be desirable to use fewer than the m(m - 1)/2 
keys required by a complete graph. If the graph is merely a cycle, then 
individuals acting alone learn nothing, but any two colluders can 
partition the graph, perhaps fully compromising a participant 
immediately between them. Such a topology might nevertheless be 
adequate in an application in which nearby participants are not likely 
to collude against one another.

A different topology assumes the existence of a subset of 
participants who each participant believes are sufficiently unlikely to 
collude, such as participants with conflicting interests. This subset 
constitutes a fully connected subgraph, and the other participants each 
share a key with every member of it. Every participant is then 
untraceable among all the others, unless all members of the completely 
connected subset cooperate. (Such a situation is mentioned again in 
Section 3.)

If many people wish to participate in an untraceable communication 
system, hierarchical arrangements may offer further economy of keys. 
Consider an example in which a representative from each local fully 
connected subgraph is also a member of the fully connected central 
subgraph. The nonrepresentative members of a local subgraph provide 
the sum of their outputs to their representative. Representatives would 
then add their own contributions before providing the sum to the 
central subgraph. Only a local subgraph's representative, or a collusion 
of representatives from all other local subgraphs, can recognize 
messages as coming from the local subgraph. A collusion comprising 
the representative and all but one nonrepresentative member of a local 
subgraph is needed for messages to be recognized as coming from the 
remaining member.

2.4. Secrecy and Authentication

What about the usual cryptologic problems of secrecy and 
authentication?

A cryptographer can ensure the secrecy of an anonymous message by 
encrypting the message with the intended recipient's public key. (The 
message should include a hundred or so random bits to foil attempts to 
confirm a guess at its content [1].) The sender can even keep the 
identity of the intended recipient secret by leaving it to each recipient 
to try to decrypt every message. Alternatively, a prearranged prefix 
could be attached to each message so that the recipient need only 
decrypt messages with recognized prefixes. To keep even the 
multiplicity of a prefix's use from being revealed, a different prefix 
might be used each time. New prefixes could be agreed in advance, 
generated cryptographically as needed, or supplied in earlier messages.

Authentication is also quite useful in systems without identification.
Even though the messages are untraceable, they might still bear
digital signatures corresponding to public-key "digital pseudonyms"
[1]; only the untraceable owner of such a pseudonym would be able to
sign subsequent messages with it. Secure payment protocols have
elsewhere been proposed in which the payer and/or the payee might be
untraceable [2]. Other protocols have been proposed that allow
individuals known only by pseudonyms to transfer securely information
about themselves between organizations [2]. All these systems require
solutions to the sender untraceability problem, such as the solution
presented here, if they are to protect the unlinkability of pseudonyms
used to conduct transactions from home.

2.5. Disruption

Another question is how to stop participants who, accidentally or even 
intentionally, disrupt the system by preventing others from sending 
messages. In a sense, this problem has no solution, since any 
participant can send messages continuously, thereby clogging the 
channel. But nondisupters can ultimately stop disruption in a system 
meeting the following requirements: (1) the key-sharing graph is 
publicly agreed on; (2) each participant's outputs are publicly agreed on 
in such a way that participants cannot change their output for a round 
on the basis of other participants' outputs for that round; and (3) some 
rounds contain inversions that would not compromise the 
untraceability of any nondisrupter.

The first requirement has already been mentioned in Section 1.1, 
where it was said that this information need not be secret; now it is 
required that this information actually be made known to all 
participants and that the participants agree on it.

The second requirement is in part that disrupters be unable (at least 
with some significant probability) to change their output after hearing 
other participants' outputs. Some actual channels would automatically 
ensure this, such as broadcast systems in which all broadcasts are 
made simultaneously on different frequencies. The remainder of the 
second requirement, that the outputs be publicly agreed on, might also 
be met by broadcasting. Having only channels that do not provide it 
automatically, an effective way to meet the full second requirement 
would be for participants to "commit" to their outputs before making 
them. One way to do this is for participants to make public and agree on 
some (possibly compressing and hierarchical, see Section 2.6) one-way 
function of their outputs, before the outputs are made public.

The third requirement is that at least some rounds can be contested 
(i.e., that all inversions can be made public) without compromising the 
untraceability of non-disrupting senders. The feasibility of this will be 
demonstrated here by a simple example protocol based on the slot 
reservation technique already described in Section 2.2.

Suppose that each participant is always to make a single reservation 
in each reserving block, whether or not he actually intends to send a 
message. (Notice that, because of the "birthday paradox," the number of 
bits per reserving block must be quadratic in the number of 
participants.) A disrupted reserving block would then with very high 
probability have Hamming weight unequal to the number of participants. 
All bits of such a disrupted reserving block could be contested without 
loss of untraceability for nondisrupters.

The reserved blocks can also be made to have such safely contestable
bits if participants send trap messages. To lay a trap, a participant
first chooses the index of a bit in some reserving block, a random
message, and a secret key. Then the trapper makes public an
encryption, using the secret key, of both the bit index and the random
message. Later, the trapper reserves by inverting in the round
corresponding to the bit index, and sends the random message in the
resulting reserved slot. If a disrupter is unlucky enough to have
damaged a trap message, then release of the secret key by the trapper
would cause at least one bit of the reserved slot to be contested.

With the three requirements satisfied, it remains to be shown how 
if enough disrupted rounds are contested, the disrupters will be 
excluded from the network.

Consider first the case of a single participant's mail computer 
disrupting the network. If it tells the truth about contested key bits it 
shares (or lies about an even number of bits), the disrupter implicates 
itself, because its contribution to the sum is unequal to the sum of 
these bits (apart from any allowed inversion). If, on the other hand, the 
single disrupter lies about some odd number of shared bits, the values 
it claims will differ from those claimed for the same shared bits by 
the other participants sharing them. The disrupter thereby casts 
suspicion on all participants, including itself, that share the disputed 
bits. (It may be difficult for a disrupter to cast substantial suspicion 
on a large set of participants, since all the disputed bits will be in 
common with the disrupter.) Notice, however, that participants who 
have been falsely accused will know that they have been--and by 
whom--and should at least refuse to share bits with the disrupter in 
the future.

Even with colluding multiple disrupters, at least one inversion must 
be revealed as illegitimate or at least one key bit disputed, since the 
parity of the outputs does not correspond to the number of legitimate 
inversions. The result of such a contested round will be the removal of 
at least one edge or at least one vertex from the agreed graph. Thus, if 
every disruptive action has a nonzero probability of being contested, 
only a bounded amount of disruption is possible before the disrupters 
share no keys with anyone in the network, or before they are revealed, 
and are in either case excluded from the network.

The extension presented next can demonstrate the true value of 
disputed bits, and hence allows direct incrimination of disrupters.

2.6. Tracing by Consent

Antisocial use of a network can be deterred if the cooperation of most 
participants makes it possible, albeit expensive, to trace any message. 
If, for example, a threatening message is sent, a court might order all 
participants to reveal their shared key bits for a round of the message. 
The sender of the offending message might try to spread the blame, 
however, by lying about some odd number of shared bits. Digital 
signatures can be used to stop such blame-spreading altogether. In 
principle, each party sharing a key could insist on a signature, made by 
the other party sharing, for the value. of each shared bit.

Such signatures would allow for contested rounds to be fully resolved,
for accused senders to exonerate themselves, and even for colluders to
convince each other that they are pooling true keys.  Unfortunately,
cooperating participants able to trace a message to its sender could
convince others of the message's origin by revealing the sender's own
signatures. A variation can prevent a participant's signatures from
being used against him in this way: instead of each member of a pair
of participants signing the same shared key bit, each signs a separate
bit, such that the sum of the signed bits is the actual shared key
bit. Signatures on such "split" key bits would still be useful in
resolving contested rounds, since if one contester of a bit shows a
signature made by the second contester, then the second would have to
reveal the corresponding signature made by the first or be thought to
be a disrupter.

In many applications it may be impractical to obtain a separate 
signature on every key bit or split key bit. The overhead involved could 
be greatly reduced, however, by digitally signing cryptographic 
compressions of large numbers of key bits. This might of course require 
that a whole block of key bits be exposed in showing a signature, but 
such blocks could be padded with cryptographically generated 
pseudorandom (or truly random) bits, to allow the exposure of fewer 
bits per signature. The number of bits and amount of time required to 
verify a signature for a single bit can be reduced further by using a 
rooted tree in which each node is the one-way compression function of 
all its direct descendants; only a digital signature of each participant's 
root need be agreed on before use of the keys comprising the leaves.

3. Relation to Previous Work

There is another multiparty-secure sender-untraceability protocol in 
the literature [1]. To facilitate comparison, it will be called a mix-net 
here, while the protocol of the present work is called a dc-net. The 
mix-net approach relies on the security of a true public-key system 
(and possibly also of a conventional cryptosystem), and is thus at best 
computationally secure; the dc-net approach can use unconditional 
secrecy channels to provide an unconditionally secure untraceable-
sender system, or can use public-key distribution to provide a 
computationally secure system (as described in Section 2.1).

Under some trust assumptions and channel limitations, however, 
mix-nets can operate where dc-nets cannot. Suppose that a subset of 
participants is trusted by every other participant not to collude and 
that the bandwidth of at least some participants' channels to the 
trusted subset is incapable of handling the total message traffic. Then 
mix-nets may operate quite satisfactorily, but dc-nets will be unable 
to protect fully each participant's untraceability. Mix-nets can also 
provide recipient untraceability in this communication environment, 
even though there is insufficient bandwidth for use of the broadcast 
approach (mentioned in Section 2.4).

If optimal protection against collusion is to be provided and the 
crypto-security of mix-nets is acceptable, a choice between mix-nets 
and dc-nets may depend on the nature of the traffic. With a mail-like 
system that requires only periodic deliveries, and where the average 
number of messages per interval is relatively large, mix-nets may be 
suitable. When messages must be delivered continually and there is no 
time for batching large numbers of them, dc-nets appear preferable.

4. Conclusion

This solution to the dining cryptographers problem demonstrates that
unconditional secrecy channels can be used to construct an
unconditional sender-untraceability channel. It also shows that a
public-key distribution system can be used to construct a
computationally secure sender-untraceability channel. The approach
appears able to satisfy a wide range of practical concerns.

Acknowledgments

I am pleased to thank Jurjen Bos, Gilles Brassard, Jan-Hendrik Evertse, 
and the untraceable referees for all their help in revising this article. 
It is also a pleasure to thank, as in the original version that was 
distributed at Crypto 84, Whitfield Diffie, Ron Rivest, and Gus Simmons 
for some stimulating dinner-table conversations.

References

[1]	Chaum, D., Untraceable Electronic Mail, Return Addresses, and 
Digital Pseudonyms, Communications of the  ACM, vol. 24, no. 2, 
February 1981, pp. 84-88.
[2]	Chaum, D., Security Without Identification: Transaction Systems 
to Make Big Brother Obsolete, Communications of the ACM, vol. 28, 
no. 10, October 1985, pp. 1030-1044.
[3]	Diffie, W., and Hellman, M.E., New Directions in Cryptography, IEEE 
Transactions on Information Theory, vol. 22, no. 6, November 1976, 
pp. 644-654.
[4]	Merkle, R.C., Secure Communication over Insecure Channels, 
Communications of the ACM, vol. 21, no. 4, 1978, pp. 294-299.
[5]	Tanenbaum, A.S., Computer Networks, Prentice Hall, Englewood 
Cliffs, New Jersey, 1981.


[End of Transmission]



-- 










From ebrandt at jarthur.Claremont.EDU  Fri Dec 11 15:39:32 1992
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Fri, 11 Dec 92 15:39:32 PST
Subject: YA remailer
Message-ID: <9212112339.AA11270@toad.com>


I have a Hal-standard remailer running at this address,
ebrandt at jarthur.claremont.edu -- haven't compiled PGP
on this silly Sequent box yet, so no ARA's.

	 PGP 2 key by finger or e-mail    (and finger works now)
   Eli   ebrandt at jarthur.claremont.edu





From wmo at rebma.rebma.mn.org  Fri Dec 11 18:27:14 1992
From: wmo at rebma.rebma.mn.org (Bill O'Hanlon)
Date: Fri, 11 Dec 92 18:27:14 PST
Subject: keys for me and remailer@rebma.mn.org
Message-ID: <m0n0MGM-0006XZC@rebma.rebma.mn.org>


I don't know how much use this is, since no one has signed my key, but here
it is, plus the key for the remailer here at rebma, signed by me.

If anyone is going to be in the Minneapolis area, lemme know.

Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAirR6jkAAAEEAOMZFXG8bGGSpctmszxLug8IoLi55pUy+gR81K6ZBfLOmrTh
XCeuSBZ+yi6IZXuabOTsKo9r6wHVAvumZlfMvcp9Jbasp6Lc756aacsatHYsiQR4
7feUmp/coOyZ4ZfAXCmapc3dozYB9vWoWMhQy8QmWhotR8zTLRlm7A4meZALAAUR
tCBXYXJyaW9yIDx3bW9AcmVibWEubW4ub3JnPiBrZXkgMg==
=3/XA
-----END PGP PUBLIC KEY BLOCK-----
And here's the remailers:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3
jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF
0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv
BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO
=nBQt
-----END PGP PUBLIC KEY BLOCK-----
-- 
Bill O'Hanlon						 wmo at rebma.mn.org




From tcmay at netcom.com  Sat Dec 12 09:50:58 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Sat, 12 Dec 92 09:50:58 PST
Subject: (fwd) EFFector Online 4.00
Message-ID: <9212121749.AA20077@netcom2.netcom.com>


Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

Cypherpunks,

Here's the latest EFFector Online, which happens to have stuff about two of
us, John Gilmore and me, and which mentions Tom Jennings! No
mention of our little group, yet, but I expect we can't hide for long.

--Tim May

From: rita at eff.org (Rita Marie Rouvalis)
Subject: EFFector Online 4.00
Followup-To: comp.org.eff.talk
Originator: rita at eff.org
Keywords: crypto, nsa, pioneer wards
Organization: Electronic Frontier Foundation
Date: Fri, 11 Dec 1992 20:00:04 GMT


########## ########## ########## |
########## ########## ########## |         GILMORE VS. THE NSA
####       ####       ####       |
########   ########   ########   |
########   ########   ########   |   THE CRYPTO ANARCHIST MANIFESTO
####       ####       ####       |
########## ####       ####       |  2nd PIONEER AWARDS DEADLINE LOOMS
########## ####       ####       |
=====================================================================
EFFector Online           December 11, 1992               Issue  4.00
           A Publication of the Electronic Frontier Foundation
                            ISSN 1062-9424
=====================================================================


                      ACCESSING THE NSA
 JOHN GILMORE FILES SUIT WITH THE NATIONAL SECURITY AGENCY


At the beginning of July 1992, John Gilmore filed a FOIA request
with NSA asking for access to parts of cryptologic treatises
written by NSA personnel:  Military Cryptanalysis, Parts III
and IV, by William Friedman (WF-3/4); and Military
Cryptanalytics, Parts III-VI, by William Friedman and
Lambros Callimahos (LC3-6).

Parts I and II of each of these treatises had already been
declassified and published.  At the time of the request, it
was not definitely known whether the parts requested by
Gilmore had been re-classified.    

Under the FOIA, agencies are required to communicate
responses to requesters within statutorily prescribed time
periods.  Failure to comply with the time limits for response
constitutes a denial of the request, giving the requester the
right to appeal.

When NSA violated the first applicable time period,
Gilmore filed an administrative appeal with the NSA's FOIA
appeals authority.  There is also a time limit for response
to such appeals.  After this time limit passed without a
response from the NSA's appeals authority, Gilmore filed
a complaint in federal court in the Northern District of
California on Sept. 4, 1992, as permitted by the FOIA.

Gilmore's complaint alleged three claims:  First, that the
NSA improperly withheld these documents from him, and
had no legal basis for withholding; second, that the NSA's
failure to comply with the FOIA time limits constituted a
form of improper withholding; and third, that the NSA in
general engages in an illegal pattern or practice of routinely
violating the FOIA time limits, which should be declared
illegal and enjoined.

In the period between the initial FOIA request to NSA, and
the filing of the complaint in federal court, Gilmore obtained
copies of two of the withheld documents:  Military
Cryptanalysis Parts III and IV, by Friedman.  These copies
were discovered in libraries accessible to the general
public and were provided by these libraries without any
kind of restriction.  Gilmore intended to get expert opinion
on the national security risk posed by disclosure of these
documents.  He also reasoned that their very availability
in such libraries demonstrated that there could be no legal
basis for withholding them from a FOIA requester.

At the time the documents were obtained, Gilmore had not
received any indication from NSA that the documents were
classified.  It was therefore possible that the documents
were not, in fact, classified.  In addition, FOIA requests for
documents generally trigger agency declassification review.
Thus, even if the documents were in fact classified at the
time of the request, it was possible that NSA would decide
that they should no longer be classified, and release them
to Gilmore.

After the complaint was filed, Gilmore not only served the
complaint upon NSA, he also served a number of discovery
requests upon NSA, seeking to discover information about
both the history of these documents and about NSA's FOIA
processing procedures.

In early October, after NSA had received the complaint and
the discovery requests, NSA finally sent its responses to
the FOIA request.  NSA informed Gilmore that the documents
were not going to be released to him.  NSA said that it had
located WF-3/4 and LC-3, but that LC-4/5/6 had never been
completed because of the death of Lambros Callimahos.

First, NSA asserted that the three documents which did
exist were classified.  WF-3/4 were classified CONFIDENTIAL,
the lowest level of classification under Executive Order
12,356 governing classified information.  LC-3 was
classified SECRET, the middle level of classification.

Under the FOIA, an agency may withhold documents if they
are properly classified for reasons of national security.

Second, NSA asserted that the documents could also be
withheld under a different exemption in the FOIA.  Under the
(b)(3) exemption, documents may be withheld if there exists
a statute which authorizes an agency to withhold them.  NSA
pointed to several statutes which arguably covered this
material.  One of these statutes, 18 U.S.C. Section 798,
makes it a federal crime knowingly to disclose classified 
cryptologic or communications intelligence information to
unauthorized persons.

At this point, it became clear to Gilmore that there was a
problem.  He now knew for a fact that the documents he had
were classified (WF-3/4) and that it would be a crime for
him to disseminate them.  He could no longer continue with
his plan of showing them to other persons for fear of
criminal prosecution.  He also feared that should NSA ever
discover that he possessed them, he would be subjected to
search and seizure and the copies confiscated.  (Note that
although the First Amendment Privacy Protection Act
generally protects the press against search and seizure
for materials intended for publication where the crime
involves mere possession or dissemination of information,
it does not apply to any materials covered by the espionage
statutes, of which 18 U.S.C. Section 798 is one.)

NSA did not, however, know that he had them.  Gilmore
decided that the best course of action was to submit copies
of WF-3/4 to the federal district court under seal.  By so
doing, he would ensure that at least these copies would be
kept out of the NSA's hands, since it was unlikely that a federal
judge would relinquish possession of documents material to
pending litigation.  Thus, on November 12, Gilmore made an
ex parte application to file these documents under seal with
Judge Thelton Henderson, the federal judge hearing his case.
Gilmore also concurrently filed a motion for leave to amend
his original complaint in order to address the constitutional
and other issues arising from his possession of the documents
and the criminality of disseminating documents found in
libraries open to the general public.

It is important to realize that the criminal statute at issue
here does not recognize improper classification as a defense.
Under existing law, the government need only show that the
documents were classified by the government, and that they
are cryptologic- or communications-intelligence-related.  It
remains unclear precisely what the specific requirement
under the statute is, i.e., whether "knowingly" means actual
knowledge of classification, or merely some reason to know.

(That same day, NSA filed two motions of its own:
a motion for a protective order blocking Gilmore's discovery 
requests, and a motion for summary judgment asking the
court to dispose of the case on the ground that NSA was
entitled to judgment as a matter of law.  In support of its
summary judgment motion, NSA filed a sworn declaration
by Michael Smith, Chief of Policy, explaining why the
documents should be withheld, and why NSA's FOIA
processing procedures were not illegal.)

NSA was served with papers indicating that WF-3/4 had been
received by the district court.  This was the first time that
NSA knew that Gilmore possessed the documents.  They
reacted strongly.  John Martin, the Justice Department lawyer
representing NSA, asked that Gilmore surrender his copies to
NSA, saying that NSA was very upset and might send its own
agents or FBI agents to get the copies from Gilmore.  He also
wanted to know where Gilmore got them.  Martin also suggested
that Gilmore might be criminally liable under the espionage
statutes relating to possession of national defense information.

NSA regained its composure the next day, realizing that it
did not know exactly what Gilmore had.  Although NSA had
been served with papers indicating what Gilmore had done,
Gilmore had not sent them copies of the documents.  Thus
they could not know for sure whether the documents he had
were the ones they considered classified.  Gilmore agreed to
send copies of his copies to NSA for their review, after
which NSA would decide what to do.

During this period, tension was high.  Gilmore considered
filing an ex parte motion for a temporary restraining order
against NSA and the U.S. Attorney General to prevent them
from both moving against him personally and against any
copies of the documents presently on library shelves.  This
motion was drafted but never filed.

On the day before Thanksgiving, NSA announced that WF-3/4
would be declassified, and effectively renounced any claim
that it could withhold them from the public.  NSA gave no
official reason for its action.

NSA is currently reviewing the third document, LC-3, to
see how much of it can be released now that WF-3/4 have
been declassified.  (NSA had asserted in its summary judgment
papers that LC-3 was based on WF-3/4.)  NSA's review is to
be completed by January 15, 1993, at which time it will
release an edited version of LC-3 to Gilmore.

It is anticipated that this edited version of LC-3 will be
analyzed by Gilmore and his experts, and that Gilmore and
NSA will engage in settlement negotiations to determine
whether NSA has satisfied Gilmore's request.  The
settlement discussions will also include Gilmore's claims
regarding NSA's FOIA processing procedures.

The parties have stipulated that if no settlement is reached
the litigation will proceed.  A status conference has been
set for February 9.  NSA will, if necessary, file an amended
motion for summary judgment by February 12.  Following
opposition and reply briefs, the hearing on all motions will
take place on March 22.

[John Gilmore is a member of the EFF Board of Directors. He can
reached as gnu at cygnus.com.  Gilmore's lawyer, Lee Tien, can
be reached as tien at toad.com.]


                  -==--==--==-<>-==--==--==-


                THE CRYPTO ANARCHIST MANIFESTO

                              by
                        Timothy C. May
                      (tcmay at netcom.com)


A specter is haunting the modern world, the specter of crypto 
anarchy. 

Computer technology is on the verge of providing the ability for 
individuals and groups to communicate and interact with each other 
in a totally anonymous manner. Two persons may exchange 
messages, conduct business, and negotiate electronic contracts 
without ever knowing the True Name, or legal identity, of the other. 
Interactions over networks will be untraceable, via extensive re-
routing of encrypted packets and tamper-proof boxes which 
implement cryptographic protocols with nearly perfect assurance 
against any tampering. Reputations will be of central importance, far 
more important in dealings than even the credit ratings of today. 
These developments will alter completely the nature of government 
regulation, the ability to tax and control economic interactions, the 
ability to keep information secret, and will even alter the nature of 
trust and reputation.

The technology for this revolution--and it surely will be both a social 
and economic revolution--has existed in theory for the past decade. 
The methods are based upon public-key encryption, zero-knowledge 
interactive proof systems, and various software protocols for 
interaction, authentication, and verification. The focus has until now 
been on academic conferences in Europe and the U.S., conferences 
monitored closely by the National Security Agency. But only recently 
have computer networks and  personal computers attained sufficient 
speed to make the ideas practically realizable. And the next ten 
years will bring enough additional speed to make the ideas 
economically feasible and essentially unstoppable. High-speed 
networks, ISDN, tamper-proof boxes, smart cards, satellites,  Ku-band 
transmitters, multi-MIPS personal computers, and encryption chips 
now under development will be some of the enabling technologies. 

The State will of course try to slow or halt the spread of this 
technology, citing national security concerns, use of the technology 
by drug dealers and tax evaders, and fears of societal disintegration. 
Many of these concerns will be valid; crypto anarchy will allow 
national secrets to be traded freely and will allow illicit and stolen 
materials to be traded. An anonymous computerized market will 
even make possible abhorrent markets for assassinations and 
extortion. Various criminal and foreign elements will be active users 
of CryptoNet. But this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of 
medieval guilds and the social power structure, so too will 
cryptologic methods fundamentally alter the nature of corporations 
and of government interference in economic transactions. Combined 
with emerging information markets, crypto anarchy will create a 
liquid market for any and all material which can be put into words 
and pictures. And just as a seemingly minor invention like barbed 
wire made possible the fencing-off of vast ranches and farms, thus 
altering forever the concepts of land and property rights in the 
frontier West, so too will the seemingly minor discovery out of an 
arcane branch of mathematics come to be the wire clippers which 
dismantle the barbed wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


                   -==--==--==-<>-==--==--==-


Date: Wed, 02 Dec 92 21:31:47 -0800
From: haynes at cats.UCSC.EDU (Jim Haynes)
Newsgroups: comp.dcom.telecom
Subject: Historical Note on Telecom Privacy

Apropos of all the talk on FBI wiretapping, cellular eavesdropping,
etc., I found this passage in "Old Wires and New Waves"; Alvin F.
Harlow; 1936.  He's writing about unscrupulous telegraph operators in
the early days.  They would use information in telegrams for personal
gain, or delay messages or news for personal gain, or sell news
reports to non-subscribers of the press association.

    "Pennsylvania passed a law in 1851, making telegrams secret,
    to prevent betrayal of private affairs by operators.  When,
    therefore, an operator was called into court in Philadelphia
    a little later, and ordered to produce certain telegrams which
    would prove an act of fraud, he refused to do so, saying that
    the state law forbade it.  The circuit court, shocked at this
    development, proceeded to override the law, saying:

       It must be apparent that, if we adopt this construction
       of the law, the telegraph may be used with the most
       absolute security for purposes destructive to the
       well-being of society - a state of things rendering
       its absolute usefulness at least questionable.  The
       correspondence of the traitor, the murderer, the robber
       and the swindler, by means of which their crimes and
       frauds could be the more readily accomplished and
       their detection and punishment avoided, would become
       things so sacred that they never could be accessible to
       the public justice, however deep might be the public interest
       involved in their production.
    
    The judge therefore ordered the operator to produce the telegrams."


                   -==--==--==-<>-==--==--==-


         THE SECOND ANNUAL INTERNATIONAL EFF PIONEER AWARDS:
                       CALL FOR NOMINATIONS
                     Deadline: December 31,1992

In every field of human endeavor,there are those dedicated to expanding
knowledge,freedom,efficiency and utility. Along the electronic frontier,
this is especially true. To recognize this,the Electronic Frontier
Foundation has established the Pioneer Awards for deserving individuals
and organizations.

The Pioneer Awards are international and nominations are open to all.

In March of 1992, the first EFF Pioneer Awards were given in Washington
D.C. The winners were: Douglas C. Engelbart of Fremont, California;
Robert Kahn of Reston, Virginia; Jim Warren of Woodside, California; Tom
Jennings of San Francisco, California; and Andrzej Smereczynski of
Warsaw, Poland.

The Second Annual Pioneer Awards will be given in San Francisco,
California at the 3rd Conference on Computers, Freedom, and Privacy
in March of 1993.

All valid nominations will be reviewed by a panel of impartial judges
chosen for their knowledge of computer-based communications and the
technical, legal, and social issues involved in networking.

There are no specific categories for the Pioneer Awards, but the
following guidelines apply:

   1) The nominees must have made a substantial contribution to the
      health, growth, accessibility, or freedom of computer-based
      communications.

   2) The contribution may be technical, social, economic or cultural.

   3) Nominations may be of individuals, systems, or organizations in
      the private or public sectors.

   4) Nominations are open to all, and you may nominate more than one
      recipient. You may nominate yourself or your organization.

   5) All nominations, to be valid, must contain your reasons, however
      brief, on why you are nominating the individual or organization,
      along with a means of contacting the nominee, and your own contact
      number. No anonymous nominations will be allowed.

   6) Every person or organization, with the single exception of EFF
      staff members, are eligible for Pioneer Awards.

   7) Persons or representatives of organizations receiving a Pioneer
      Award will be invited to attend the ceremony at the Foundation's
      expense.

You may nominate as many as you wish, but please use one form per
nomination. You may return the forms to us via email to

             pioneer at eff.org

You may mail them to us at:
             Pioneer Awards, EFF,
             155 Second Street
             Cambridge MA 02141.

You may FAX them to us at:
             +1 617 864 0866

Just tell us the name of the nominee, the phone number or email address
at which the nominee can be reached, and, most important, why you feel
the nominee deserves the award.  You may attach supporting
documentation.  Please include your own name, address, and phone number.

We're looking for the Pioneers of the Electronic Frontier that have made
and are making a difference. Thanks for helping us find them,

The Electronic Frontier Foundation

        -------EFF Pioneer Awards Nomination Form------

Please return to the Electronic Frontier Foundation
via email to:       pioneer at eff.org
via surface mail to EFF 155 Second Street, Cambridge, MA 02141 USA;
via FAX to +1 617 864 0866


Nominee:

Title:

Company/Organization:

Contact number or email address:

Reason for nomination:

Your name and contact information:

Extra documentation attached:

DEADLINE: ALL NOMINATIONS MUST BE RECEIVE BY THE ELECTRONIC FRONTIER
FOUNDATION BY MIDNIGHT, EASTERN STANDARD TIME U.S., DECEMBER 31,1992.


                   -==--==--==-<>-==--==--==-


         MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION

If you support our goals and our work, you can show that support by
becoming a member now. Members receive our bi-weekly electronic
newsletter, EFFector Online, the @eff.org newsletter
and special releases and other notices on our activities.  But because
we believe that support should be freely given, you can receive these
things even if you do not elect to become a member.

Our memberships are $20.00 per year for students, $40.00 per year for
regular members.  You may, of course, donate more if you wish.

Our privacy policy: The Electronic Frontier Foundation will never, under
any circumstances, sell any part of its membership list.  We will, from
time to time, share this list with other non-profit organizations whose
work we determine to be in line with our goals. If you do not grant
explicit permission, we assume that you do not wish your membership
disclosed to any group for any reason.

---------------- EFF MEMBERSHIP FORM ---------------

Mail to: The Electronic Frontier Foundation, Inc.
    155 Second St. #40
    Cambridge, MA 02141

I wish to become a member of the EFF  I enclose:$__________
    $20.00 (student or low income membership)
    $40.00 (regular membership)
    $100.00(Corporate or company membership.
    This allows any organization to
    become a member of EFF. It allows
    such an organization, if it wishes
    to designate up to five individuals
    within the organization as members.)

    I enclose an additional donation of $

Name:

Organization:

Address:

City or Town:

State:     Zip:    Phone:(    )     (optional)

FAX:(    )    (optional)

Email address:

I enclose a check [  ]   .
Please charge my membership in the amount of $
to my Mastercard [  ]     Visa [  ]    American Express [ ]

Number:

Expiration date:

Signature:

Date:

I hereby grant permission to the EFF to share my name with
other non-profit groups from time to time as it deems
appropriate   [  ]  .
      Initials:

Your membership/donation is fully tax deductible.
=====================================================================
     EFFector Online is published by
     The Electronic Frontier Foundation
     155 Second Street, Cambridge MA 02141
     Phone: +1 617 864 0665 FAX: +1 617 864 0866
     Internet Address: eff at eff.org
 Reproduction of this publication in electronic media is encouraged.
 Signed articles do not necessarily represent the view of the EFF.
 To reproduce signed articles individually, please contact the authors
 for their express permission.
=====================================================================
     This newsletter is printed on 100% recycled electrons.

-- 
Rita Rouvalis                                Electronic Frontier Foundation
rita at eff.org                                                    eff at eff.org
CIS:70007,5621                                                (617)864-0665

--
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From nobody at rebma.rebma.mn.org  Sat Dec 12 14:04:53 1992
From: nobody at rebma.rebma.mn.org (nobody at rebma.rebma.mn.org)
Date: Sat, 12 Dec 92 14:04:53 PST
Subject: no subject (file transmission)
Message-ID: <m0n0efX-0006XfC@rebma.rebma.mn.org>


-----BEGIN PGP SIGNED MESSAGE-----

Update on the digital cash project

I am having some problems with the port to MSDOS, mostly due to
implicitly assuming 32-bit integers in a few places.  Probably I won't
get it working until next weekend.

To recap, the program provides Chaum-style digital cash via two
executables, one for the "players" and one for the "banker".  The
banker creates a public key which has a single modulus n and multiple
exponents, the prime numbers starting with 17.  He sends n to the
players and all is ready.

Players withdraw money by running their programs and specifying the
denominations they want to withdraw.  For example, you could withdraw
a 1, two 5's, a 10 and a 20.  This would create a file with 5 entries
to be sent to the bank.  PGP should be used to encrypt and
ascii-encode this file (for privacy) and it should be mailed to the
banker.

The banker receives this file and runs his program to RSA-sign the
values in each of the withdrawal-request entries.  This is the
"blinded cash" that Chaum describes.  Again, PGP should be used for
mailing this back to the user.

The player then has to "unblind" the file to make it "real" digital
cash.  This also changes it so that the bank won't recognize it when
it is deposited.  He uses his version of the program to do this,
producing an actual digital money file with the five "digital bills"
in it.

To pay another user, he runs another function to extract the desired
bills from this file.  Suppose he wants to extract a 1 and a 5.  This
leaves a 5, a 10 and a 20 in the original file, and creates a new
digital cash file with a 1 and a 5.  He would then use PGP again to
encrypt this for safety and mail it to the person he wants to pay.

That person can run a "check" function on the incoming digital money
to make sure it has a proper bank signature on it and is not a
forgery.  He would then mail it directly to the bank so that it could
get credited to his account.

The banker runs his program which checks the signatures on the
incoming money, looks in a database file to make sure these bills
haven't been used before, and adds these bills to the database.  (The
database stores 16 bytes per bill.)  He should then record the deposit
and perhaps send a confirmation to the depositor (my program doesn't
get involved with that).

I hope this gives a clearer picture of how the electronic money
program works.  It is a simple implementation but I think many systems
would work similarly.

I appreciated the suggestion to use cash as part of the list
management itself.  Rather than paying people who post, I wonder if it
would be better to make people pay to post.  Many people have
complained about the volume.  :)  Unfortunately, I suspect that this
would involve too much overhead for the mailing list maintainer.

Maybe the thing to do is to just get the software out there and let
people decide what they want to do with it (if anything).  I'm
probably going to take a couple more weeks to clean up the user
interface and get these bugs out, then I'll try sending it someone to
be put on the cypherpunks ftp archive.

It's nice to be able to finally sign these messages!

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC
aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw
7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX
M/McOuwuIjs=
=/HGX
-----END PGP SIGNATURE-----





From nobody at soda.berkeley.edu  Sat Dec 12 14:25:21 1992
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Sat, 12 Dec 92 14:25:21 PST
Subject: no subject (file transmission)
Message-ID: <9212122224.AA04784@soda.berkeley.edu>


Cypherpunks!

Like several people (I guess), I am working on an implementation of
digital cash.  Because of the possible legal repurcussions, I'd prefer
to remain anonymous at this time.  Thanks to the efforts of the people
on this list, this is now possible.

My implementation is pretty far along.  It uses PGP modules for the
arithmetic, so the speed is good.  It works on Unix and I should be
able to get it working on MSDOS in a day or two.  Sorry, I don't have
the ability to work on a Mac version.

Here are some of the features.  The basic cash algorithm is the Chaum
system which was posted here.  Multiple denominations are supported,
using different exponents for each denomination.  The program is
presented in the context of a package to be used for an email based
game like Monopoly where the program would be used to allow cash
transfers.  One player is the "banker", and he uses a different
execution module than the other players.  The banker program keeps a
database of used note numbers which is used to detect money reuse.
The database is maintained using a freeware version of the "dbm"
package, so it should be fast even for large note number databases.

The mapping between exponents and values is as follows:

    exponent	    value
	17		1
	19		2
	23		5
	29		10
	31		20
	37		50
	41		100
	43		200
	47		500
	53		1000
	59		2000
	61		5000
	67		10000

and so on, up to a value of 2e9.  The exponents are ascending primes
starting with 17.  This was chosen because you want them to be
smallish for fast note checking, but it was too slow to find primes p
and q for the bank key such that (p-1)(q-1) was not divisible by any
small primes.  The program chooses random p and then tests p-1 to make
sure it passes the divisibility test, and rejects it if not.  Too many
were being rejected when I started with an exponent of 3.  Starting
with 17 rejects about 1/2 the exponents, compared to something like
80% when I started with 3.  The "value" fields are presumed to be
cents, but could be whatever you like.

The code I've written does not do anything other than the basic
electronic cash algorithms.  It does not do bank account maintenance.
It doesn't do PGP encryption.  It doesn't send mail.  (It does have
some functions to scan and check the files created by the program.)

Cash generation is a 3 step process.  First, the user creates what I
call a "withdrawal request" packet.  This is a set of triplets of the
form (e, s, refx), where e is the exponent from the table above, s is
a 16-byte "unique identifier" used solely to link these withdrawal
requests with the returned messages from the bank, and refx is r^e * f(x).
f(x) is MD5 of x, padded to the size of the bank's modulus n using the
PGP routine which pads MD5 signatures.  This padding helps make sure the
arithmetic is more "mixing".  x is the random input to MD5, which I've
chosen as 64 bytes since that is the block size MD5 works on.  (The
output of MD5 is 16 bytes.)  r is the blinding factor.  This is now
128 bits long; longer r's take too long to calculate r^-1 in the third
step, below.  (It takes longer for PGP to calculate r^-1 than to do an
RSA decryption, for r = n = 1024 bits!)

Second, the bank program converts the withdrawal request packet into
what I call a "withdrawal" packet, by just RSA-decrypting the third
entry using the inverse exponent "d" for the value exponent "e".
(These "d" values are calculated at keygen time and stored with the
bank's key information in a private file.)  I call the return triplet
(e, s, rfxd), where e is the value exponent again, s is the same
unique identifier, and rfxd is r * f(x)^d.

(As I said above, the code I've written does not try to maintain
account balances or do any other banking functions.  It just does the
cash algorithms.  There is a routine to scan a withdrawal request and
return the total value being requested for withdrawal.  The idea was
that this could be used as input to a banking program to decide
whether to allow the withdrawal.)

Third, the "player" (e.g. user) program transforms the withdrawal
packet into a "money" packet, by un-blinding it.  To do this, it has
to recover the x and r which correspond with each triplet.  This is
done by the use of a dbm database of "pending withdrawal requests"
which is written during step 1, above.  The database entries are keyed
by (e, s) and return the corresponding (x, r) which were generated
during step 1.  Using x and r, the user transforms (e, s, rfxd) into
(e, x, fxd), the digital cash.  e is the value exponent, x is the
random 64-byte number, and fxd is f(x)^d, the signed version of the
MD5'd and padded x.

There are also player functions to scan and check a money file
(comparing a calculated f(x) to fxd^e), merge money files, and extract
some items from a money file into another money file (this last is
what is to be used for payment).  There are banker functions to check
incoming money and compare against the used-note database, and to add
incoming money to that database.  (The database consists of the
16-byte f(x) values for each note.)

I am pretty happy with the basic routines, but the user interface
needs work.  There are three kinds of files floating around
(withdrawal requests, withdrawals, and money files) and I'm worried
that this will be confusing to the user.  If he accidentally deletes
one at the wrong time he could lose money permanently.  Or if he
accidentally reuses one he could be accused of fraud.  I'm not sure
what the best model is for the user.

The specific issues of creating withdrawal messages and extracting
"bills" from a money file are areas where the user interface should be
made nice.  We want to make it easy for the user to specify exactly
what denominations he wants to work with.  One possibility is to
simply have him input the amount (e.g. $10.55) and the program
calculates that that's a 1000, a 50, and a 5, but this isn't really
flexible enough.  A nice system would be to give him a list of options
and let him fill out a form on-screen, but that's hard to do portably.

Another idea I've had is that there should be a special money file
called the user's "wallet" which is the default place where incoming
money from the bank should go.  This might help organize things.  He
still needs to be able to create other money files for paying other
people, and remembering to delete them after he sends them.

Any suggestions or thoughts on these interface issues, or comments
about how this program could or should be integrated into a larger
system, would be appreciated.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
-----END PGP PUBLIC KEY BLOCK-----






From wmo at rebma.rebma.mn.org  Sat Dec 12 15:44:58 1992
From: wmo at rebma.rebma.mn.org (Bill O'Hanlon)
Date: Sat, 12 Dec 92 15:44:58 PST
Subject: Remailer problem at rebma fixed
Message-ID: <m0n0g5G-0006bMC@rebma.rebma.mn.org>



My apologies to those who have used PGP with the remailer at rebma
over the past week.  I upgraded to pgp2.1, and I failed to notice
that the PGPPASS environment variable has given way to the -z password
option.  Users of Hal's remailer scripts take notice.

I ran the mail through that had failed, so there might be duplicates
of messages sent out, since some people might have resent the message
if they didn't see it go by (that is, if they sent it to something where
they'd see the result, such as the cypherpunks list.)

Sorry for the inconvenience.

-Bill

-- 
Bill O'Hanlon						 wmo at rebma.mn.org




From yanek at novavax.nova.edu  Sun Dec 13 11:35:50 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 11:35:50 PST
Subject: dc-nets implementation (protocol spec)
Message-ID: <9212131931.AA13443@novavax.nova.edu>


I am writing a dc-net implementation.   What follows is some design 
discussion, a protocol specification that defines the interaction,
message format, and file formats, followed by notes, and plans for
future enhancements.  A basic familiarity with the concept of dc-nets is
assumed, for people new to this, see Chaums's article on the topic,
posted here recently.

I am assuming interaction through e-mail because this is, right now,
the most accessible medium.  A more efficient approach would be to
use a true broadcast media, such as coax cable, or satellite.  But
coax only works for local areas, and not everyone has satellite uplink
capability.

In the future, I envision all or most local area networks running their
own small dc-nets that use ethernet broadcast, these being linked
hierarchically to medium-level dc-nets that use any internet type of
communication medium (udp datagrams, tcp connections, smtp, usenet news,
shared ftp space, etc) or other regional communication such as radio
(amateur packet radio, spread-spectrum, or even CB) , and these finally
being linked into global dc-nets that use satellite broadcast.  

This type of system would achieve the truly anonymous global communication
system, similar to what Vinge describes in True Names:

      He dumped the last twenty-four hours of the world bulletin
      board into his home memory space and began checking through
      it.  The bulletin board was ideal for untraceable reception
      of messages: anyone on Earth could leave a message [...] If 
      a user copied the entire board, and /then/ searched it, there
      was no outside record of exactly what information he was
      interested in.  There were also simple ways to make nearly 
      untraceable entries on the board.

DC-nets will remove the "nearly" from the last sentence.

The system I am writing is for research purposes only, I would like to 
have about 6 to 8 people running it, and then observe it in action. 
I am not aware of any existing, operational dc-net.  If you know of
one, please let me know.  I would not like to develop a new, incompatible
protocol if it is not fundamentally better than something existing.

The dc-net system is independent of how the keys are distributed/created.
This system assumes that there is already a key stream existing between
any two users, that it can use.

There are several methods by which keys can be distributed.  The most
secure would probably be to use a hardware RNG to generate a one-time
pad, which is then trasfered by some secure means (exchanged on floppies
in person, or put on a 4GB DAT tape (4mm, $20 or less) and sent by
some courier service, etc).  Another possibility is to use
Diffie-Hellman protocol to agree on a set of keys.  The simplest method,
and one I chose to use in this project, is to generate a random key
stream, encrypt it with the other person's public key, sign it with
yours, and send it through e-mail.  See the next message for details
on message formats used for this.  

Again, the core dc-net system described in this message is in no way
dependent on this form of key exchange.  Any other key distribution
method can be "dropped in" without changing anything.

The design document follows:


--------------------------------------------------------------------------
ALGORITHM (pseudocode):

This algorithm is executed independently by each participant.  The list
of participants, RBSIZE, and MSGSIZE must be agreed on beforehand.  There
must be an existing keystream, or a way to receive one.

Begin Round (increment round number)

Stage 1 (reservation):
    Take RBSIZE bits off everyone's pad, xor all together.
    For every message you need to send, reverse a random bit.
    Sign with your public key, and transmit to all.
    When received everyone's block, xor all together.
    If result is all zeros, round ends.  Go on to the next round.

Stage 2 (transmission):
    For every '1' bit in reservation block:

    Begin Message (increment message number)

        Take MSGSIZE bits off everyone's pad, xor all together.
        If the bit was reserved by you, xor with your message.
        Sign with your public key, transmit to all.
        When received everyone's block, xor all together, getting message.
        If message was yours, verify it, mark it as sent.
        If not, it is a message from someone else. Process as an incoming
	message.

    End Message (go to next set bit of reservation block if any)

End Round (go to next round, optionally delay to save bandwidth)



----------------------------------------------------------------------------
MESSAGE FORMAT:

(messages are sent as signed, armored, non-encrypted PGP messages)

 Subject: dc-net transmission

 DCNET <network>; ROUND <round>; PARTICIPANT <userid>; STAGE <stage> [MSG <n>]

 <binary data stream follows>

----------------------------------------------------------------------------
FILE FORMATS:

dcnet/<netname>/myname

    your own participant name for that network


dcnet/<netname>/participants       

    list of participants and addresses in the following format:

         <userid>:<address>


dcnet/<netname>/pad/<participant>

    one-time pad for the user, straight 8-bit binary data
        optionally pgp-encrypted with your public key, signed to prevent
        disclosure and tampering; these options not implemented yet


dcnet/<netname>/spool/<stage>/<participant>

        spool where you store responses received, until you receive
        all of them.  Your own responses are stored there too


dcnet/<netname>/outgoing/*

        messages you need to send, one message per file.  
        should be stored encrypted too. 


dcnet/<netname>/incoming

        program that will process any messages received from this 
        network.  In the simplest case this would be a shell script
        that puts the message to the user's mailbox.  But it could
        also drop it into another net's outgoing directory if it
        matches some criteria, or it could be posted to a newsgroup,
        or anything else you want to do.


dcnet/<netname>/log

        this file contains log of transmissions received times and sizes.
        it should only contain public information, so it can be posted
        for analysis of net efficiency, bandwidth used, etc.


------------------------------------------------------------------------
NOTES:

I must thank the ILF (Information Liberation Front) for their timely post
of Chaum's article.  I had started with the two-person example provided
in the cypherpunks glossary, and independently extended it to apply to
any number of participants, and had progressed up to the idea of
hierarchial dc-nets, and was struggling with the question of collision
detection, when the article was posted.  Chaum's reservation blocks are
an elegant and efficient solution.  His formal proof of security is
also reassuring.

RBSIZE is the number of bits in the reservation block.  This should be
much larger than number of participants, to minimize the chance of
two participants randomly reserving the same bit (in which case the
transmission has to be retried in the next round).  A convenient number
to use is 1024 bites (128bytes), if the number of users is small.

When operating in idle mode (no messages to be sent), RBSIZE bits are
sent to each participant each round. So the total bandwidth used is,
assuming 1kbit RBSIZE, 25 participants, and two rounds an hour, about
150 kilobytes per day sent and received by each participant, or about 14
bits per second.  This is quite insignificant, considering today's 
communication equipment.  

MSGSIZE is the size of a message.  This should be about the size of an
average message, not the largest one.  Making this too large will waste
bandwidth.  I will use message size of 5kilobytes.  This is quite
small, but enough for research purposes.  This will make the messages
several screenfuls long.  Longer messages can be split into parts, and
reassembled.  For example, this message would be split into two parts.

For each message that is sent, the number of bytes that every every
participant must send and receive is MSGSIZE times the number of 
participants (using the above assumptions, 125 kilobytes).

Using a true broadcast media would dramatically reduce these bandwidth
requirements, making large-scale systems with many participants
feasible.

This implementation uses a <netname> to distinguish between separate
dc-nets a user may be participating in.  A netname can be any string, 
subject to filename limitations.  Keeping them alphanumeric and under 14
chars should work on most machines.. They might also be case insensitive.

Netnames do not have to be globally unique, one person just can not be on
two nets of the same name.

Persons are referenced to by <participant>, which would normally be the
username but can be an arbitrary string subject to the same limitations.
Two perople with the same participand name can not be on one dc-net.

Are any of you amateur radio (HAM) operators?  I would be interested if
this system could be run over packet radio.  Are there any regulations
against encrypted traffic?  

----------------------------------------------------------------------
FUTURE ENHANCEMENTS:

In addition to mail-based interaction, usenet newsgroups, ethernet broadcasts,
shared ftp access, and tcp connections should be supported.  

A protocol for dynamically adding participants to the net, removing
oneself from the net, or changing the address should exist.

A way to deal with malfunctions, such as not receiving a message from
a participant.  Currently the net will wait forever, for that one message
to arrive.  A time-out should probably established, after which everyone
will re-send their contribution without including the missing person.
This is potentially dangerous, since it is equivalent to disclosing that
participant's key streams.  Since one-time pad is used, this will not
compromise earlier communication, but the person must be notified if they
ever come back on-line to not use that portion of key again.

Support for encrypted and signed storage of keystreams and outgoing
messages. 

A protocol for routing messages between hierarchical dc-nets.

Automatic splitting of messages longer than MSGSIZE.

A way to indicate the message size in the allocation block, so
communications would not be wasted on small messages, and large messages
would not have to be split into pieces.

-----------------------------------------------------------------------
PLEASE send any comments, criticism, or ideas to:

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From hpengwyn at cix.compulink.co.uk  Sun Dec 13 11:52:18 1992
From: hpengwyn at cix.compulink.co.uk (John Styles)
Date: Sun, 13 Dec 92 11:52:18 PST
Subject: Electronic P.O.Boxes
Message-ID: <memo.806675@cix.compulink.co.uk>



Do any of the remailer schemes proposed address the problem of the ability
to have replies sent to you without the replier knowing to whom they
are replying - this being akin to P.O.Boxes / Magazine box numbers and
equivalents.
A sample use might be.
I wish to send someone a message so I request a box from someone
e.g.
---
mail to someone at somewhere
AllocateBoxTo:hpengwyn at cix.compulink.co.uk
---
This would send a code to you identifying a unique box and allowing you to
identify yourself (presumably you would want the ability to send this reply
by remailer so you are not identifying yourself to the box holder). It would
also send a code to you for you to pass on to repliers to your message.

You would then post and/or send the message to the person/people you wished
to communicate with (this need not be from the same account) passing on the
second of these two codes and an address to send messages to (this would
presumably be the box holding company unless you wanted the replier not to kno-
w
who was running the box, as well as not knowing who it is for).

They would reply by sending this code and a message to the address given 
(possibly anonymously of course).
This message (probably encrypted) would be held for you - allowing you to
receive messages from accounts not even set up at the time you requested
the box.

You would then get the replies by sending a message
e.g.
---
mail to someone at somewhere
GetReplies
<text of FIRST code sent by box holder>
<address or some mechanism for replies to find you>
---

Maybe the scheme discussed previously can do all of this (except the ability
to have accounts set up after replies have been sent to you) if so please
explain how. [I have only recently joined the list]

Thanks,
John





From barrus at tree.egr.uh.edu  Sun Dec 13 14:56:08 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Sun, 13 Dec 92 14:56:08 PST
Subject: Electronic P.O.Boxes
In-Reply-To: <memo.806675@cix.compulink.co.uk>
Message-ID: <9212132255.AA13304@tree.egr.uh.edu>



John,
	Thanks for the comments.  Right now (as far as I know) the
only way to be able to receive "anonymous replies" is for you to
include in your message the appropriate header.  This is the method I
use: create the necessary remailing request to your real mail address,
and include that with the instructions on how to use it.  For example:

----here is a sample letter----
Hello,
	This is an anonymous letter and you don't know who I am.  To
reply, cut everything below the marks, add your text on the end, and
send the whole thing to this address: <a remailer's address>

-----cut here-----
::
Encrypted: PGP

<here is where you would put your encrypted remailing request to your
real mail address...>

<Enter your text here, below the "END PGP" block that will delimit the
remailing request.  Mail the portion between the cut marks to the
appropriate remailer.>
----cut here----
----end of the sample letter----

It works! 

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/





From yanek at novavax.nova.edu  Sun Dec 13 15:42:04 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 15:42:04 PST
Subject: one-time-pad distribution for dc-nets
Message-ID: <9212132337.AA20132@novavax.nova.edu>


As mentioned in my previous message, dc-nets need a one-time pad keystream.
Of the many methods of accomplishing this, for my experimental dc-net I
chose not the most secure method, but the simplest to implement.
Recognizing that dc-net users will want to use various key-distribution
mechanisms (true one-time pad, with the keys trasnfered over a secure
out-of-band channel, diffey-hellmann, etc) I designed the dc-net to be as
independent of the key distribution method as possible.  The dc-net just
reads the keystream from a file, and calls a program when it is about to
run out of keys, and needs more.  

This message describes the method of key distribution I will use.  I assume
that all participants know each others' public keys, and have verified such
by independent means, or they are signed by mutually trusted certifiers.
PGP encryption is used to send randomly generated one-time pad.  Two
participants send keys to each other whenever the remaining key stream 
reaches below an agreed-upon threshold, then the keys are combined in a
pre-determined way (no matter which one sent his message first, the result
will be the same).  Keys are transferred in large chunks, larger than the
normal message size, so that these trasfers would not have to be too
frequent.  

-----------------------------------------------------------------------
MESSAGE FORMAT:

(messages are sent as signed, armored encrypted PGP messages)

  Subject: dc-net transmission

  DCNET <network>; PARTICIPANT <userid>; KEYCHUNK <n>

  <binary data follows>


-----------------------------------------------------------------------
ALGORITHM:

When remaining keystream for <userid> on dcnet <network> falls below
MINTHRESHOLD, increment keychunk number (n), generate CHUNKSIZE random
bits, encrypt and sign them, and send them to the other person.

Wait for the other participant's message.  Decrypt it, and verify the
signature. 

Compare the two key chunks (the one you sent, and the one you received),
and order them by placing the one with lower value first.

Append them in the above order to the key file.


------------------------------------------------------------------------
NOTES:

If both persons use the same MINTHRESHOLD and CHUNKSIZE, then they should
send their messages at approximately the same time, but there is no
guarantee of which one will arrive first.  If a keychunk is received before
one has been sent, one is generated and sent, and then compared to the
received key.

For the sake of simplicity, I will assume everyone will use the same
CHUNKSIZE and MINTHRESHOLD.  This is not a requirement, and the proper
operation of the system in now way depends on this.

The purpose of MINTHRESHOLD is to provide a safety margin, so that key
exchange would not interfere with the regular operation of the dc-net.

In choosing CHUNKSIZE and MINTHRESHOLD, the basic tradeoff is space versus
time.  Maximizing these values will reduce the number of transmissions,
possibly making more efficient bulk transmission methods possible.  But, it
will increase the storage requirements of each participant.

Each participant will need to store at most

(MINTHRESHOLD+CHUNKSIZE) * <number of participants>

Each participant will need to obtain new keys approximately every 

RBSIZE/CHUNKSIZE of idle rounds, or MSGSIZE/CHUNKSIZE of messages
transmitted.

For this project I will choose a CHUNKSIZE of 75K, allowing for 600 idle
rounds, or 15 messages transmitted.

MINTHRESHOLD will be 150K.  The storage requirements will be about
2 megabytes of a net of 8 participants, or about 5 megabytes for a net
of 25 participants.



----------------------------------------------------------------------
FUTURE ENCHANCEMENTS:

A more efficient bulk-transfer method may be used, such as dropping the
chunks off to a known ftp site.  As soon as the chunk is picked up, it is
deleted.  Many ftp sites have such "temporary", "incoming", or "dropoff"
directories.  Many sites could be agreed on, in case one fails.  All
participants should not use the same site, so as not to cause too much load
on any single machine.

Some method of randomizing the key transfer could be used, so all
participants would not run out of keys at the same time, causing
unneccessary load on the mail transport system.

If a broadcast medium is used, an efficient variant of Diffey-Hellmann
can be used, in which each participant needs to generate only one secret
random number, and publish the corresponding public value.  Then every one
can combine it with their secret value, in a way that results in each pair
of participants having a common secret key unknown to anyone else.

If feasible, one-time-pads can be transferred in person, using floppy
disks.


--------------------------------------------------------------------
Again, I would appreciate any ideas, comments, suggestions at:


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819







From tribble at xanadu.com  Sun Dec 13 15:48:50 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Sun, 13 Dec 92 15:48:50 PST
Subject: Electronic P.O.Boxes
In-Reply-To: <9212132255.AA13304@tree.egr.uh.edu>
Message-ID: <9212132330.AA04018@xanadu.xanadu.com>


The new remailers will support pseudonymous return addresses, but
they're not ready yet.

dean





From dclunie at pax.tpa.com.AU  Sun Dec 13 16:09:59 1992
From: dclunie at pax.tpa.com.AU (David Clunie)
Date: Sun, 13 Dec 92 16:09:59 PST
Subject: Random numbers
Message-ID: <9212131408.AA00292@britt>


>     It has lately been discussed different ways to construct pure
> random number generators by means of radiactive decay. I must admit
> that this is a very good way to produce such numbers, but for a
> number of reasons it is impractical to use such a device. (High
> radiation levels are needed too produce a significant amount of data.)
> 

It would seem to me that someone somewhere should produce a "random
number server" available via a well-known internet port number. Some
natural phenomenon not readily available to all could be used to generate
such numbers and one could just connect and ask for a number. It would be
interesting to try to devise means by which interception or sequencing
could be prevented.

david





From dclunie at pax.tpa.com.AU  Sun Dec 13 16:10:48 1992
From: dclunie at pax.tpa.com.AU (David Clunie)
Date: Sun, 13 Dec 92 16:10:48 PST
Subject: Paranoia and Cypherpunks
Message-ID: <9212131419.AA00298@britt>


> 
> Headline: "CIA chief hints change needed in ban on probing Americans"
> 
> Excerpts:
>  	WASHINGTON--CIA Director Robert Gates says changes might be  
> needed in the U.S. law that forbids the agency from collecting  
> information about Americans or U.S. companies.
> 	Such changes might enable the CIA to better support the  
> Justice Department and other law enforcement agencies, he said in an  
> interview with the Associated Press.

Juding by what I read in "The Puzzle Palace" the other day, I gather no
such ban exists on the NSA doing this. Hardly seems to matter much
whether one has two "Big Brothers" watching over use or just one !
And the budget of the NSA is a hell of a lot bigger than the CIA.

david





From yanek at novavax.nova.edu  Sun Dec 13 16:18:58 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 16:18:58 PST
Subject: Yes they exist (re: Electronic P.O.Boxes)
Message-ID: <9212140014.AA21225@novavax.nova.edu>


Such systems do exist.  I have info on one handy, but I know at least
one other based on the same software exists in finland.  

This one seems to be still using pgp2.0, I don't know when they will 
upgrade to pgp2.1.

These remailers assign you a pseudony like anon.19, and anyone can
send mail to anon.19 at pax.tpa.com.au and the mail will be forwarded
to you.


Here's the file you can get by sending an empty message
to anon.info at pax.tpa.com.au.

 PAX - Public Access Unix (Adelaide,South Australia) - Anonymous Posting Host
 ============================================================================

Last modified: Fri Nov 20 18:55:52 CST 1992

 Information about Anonymous & Privacy-Enhanced Posting.
 =======================================================

PAX is conducting research into the viability of anonymous privacy-
enhanced mail as a means of providing practical, secure and confidential
electronic mail and news. An experimental server has been setup and
you are encouraged to use it.

There are many anonymous posting services in existence which provide
anonymous electronic mail and posting to specific newsgroups where
posting is sometimes harmful to one's health or reputation ! Such
services allow you to:

 - post anonymously to those news groups

 - reply anonymously to posts by email

 - converse anonymously with another anonymous user, neither of
   you knowing your real identities

Privacy-enhanced electronic mail refers to the concept of encrypting
one's mail prior to sending it off into the ether, presumably to
someone at the other end capable of decrypting it. If one uses a
so-called "public key" method of encryption, then one can make one's
"public" key widely known so that anyone can encrypt mail to you, but only
you can decrypt it using your "secret" key. There is much development
going on in this area, but one quite popular public-domain implementation
is Philip Zimmermann's "Pretty Good Privacy 2.0" which makes use of a
number of cryptographic methods including the RSA algorithm in places
(See Legal Issues later on). PGP allows you to:

 - exchange public keys with another individual

 - encode messages to them that only they can read

 - receive messages from them that only you can read

These tools are all very well for the specific purposes for which they
were designed, but unfortunately your anonymous message or post is not
actually anonymous until it gets to the machine that host's the service.
Anyone in between, including your own administrators, can in theory
read your post, even though they won't know to whom it is directed. What
is more they can also read replies addressed back to you. This can be
highly embarrassing at best, and result in dismissal or disconnection
at worst if your thoughts, beliefs or activities are disapproved of by
the powers that be, even if they are perfectly legal.

PAX's privacy-enhanced anonymous services were conceived in the belief
that free speech and privacy are fundamental rights and that it is
high time the networks to which we are connected provided such services
on a routine basis. Seeing as they don't we have to make a start somewhere.

This service provides:

 - conventional anonymous mailing and posting services via a "normal"
   alias assigned in the usual fashion

 - the ability to post to ANY newsgroup that is carried out of PAX
   (which includes most non-regional groups)

 - PGP 2.0 based privacy-enhanced mail & posting, including:

   - ability to register your "public" key with PAX, so that PAX
     can send encrypted messages to you

   - local generation of a unique public key which is sent to you,
     so that you can send encrypted messages to PAX

   - any encoded messages from you mailed to a user or newsgroup are
     decrypted at PAX before being passed on in anonymous form

   - any anonymous replies to your "pgp" alias are encrypted before
     being mailed to you

For example, once you have obtained your PGP 2.0 software (as described
later) and got it going, and once you have generated and registered
your public key and received PAX's key in response, you will be able
to post to any newsgroup without anyone beyond your machine having
access to the plaintext of your post.

Furthermore, if another user has registered in the same manner, and
you know their anonymous alias or are responding to one of their
anonymous posts, even though you don't know who they are and haven't
exchanged keys to communicate directly, the PAX service will automatically
decrypt any encrypted messages from you and re-encrypt them before
passing them on to the other person !

 How to use it.
 ==============

All transactions are handled by email, and commands are selected by
the name of the alias to which you mail, not by the subject or body
of the message (which are ignored unless sending or posting a message).
The separator between the "anon" and the command is a dot (period,'.')
and nothing else will work ! Not '-', not '_', not ":", only a dot.

The site to address mail is "pax.tpa.com.au". If this fails for some
reason, you may need to address it to the specific host (at present)
ie. "flash.pax.tpa.com.au".

"Normal" (unencrypted) commands:

 - To get information (this message):

    mail anon.info at pax.tpa.com.au

 - To see what your "normal" alias is, or get one:

    mail anon.ping at pax.tpa.com.au

 - To send a reply to another anonymous user:

    mail anon.###@pax.tpa.com.au

    NB:
      - eg. mail anon.36 at pax.tpa.com.au

      - don't be creative ... anon.036 won't work

      - an attempt is made to strip off signature lines by discarding
        everything after a line starting with "--" or "__"

 - To send a post to a newsgroup:

    mail anon.post.groupname at pax.tpa.com.au

    NB:
      - eg. "mail anon.post.talk.abortion" will send a
        post to "talk.abortion"

      - only the Subject field from your post is used, the rest of
        the header is discarded

      - the newsgroup is selected by the alias; Newsgroup header
        fields are discarded; hence cross-posting isn't feasible

      - signatures are stripped as above

"PGP" (encryption) commands:

 - To register your public key with PAX: (ABSOLUTELY NECESSARY)

    mail anon.key at pax.tpa.com.au

    NB:
      - first you have to make install pgp and make a key then send it
        in a "anon.key" command

      - the body of the message MUST contain an ascii encoded public key
        generated by PGP V2.0. You may use your regular public key that
        you give to other people if you wish. The user ID name must be
        unlikely to conflict with one PAX already has, so use your full
        name, or include your email address or something. If you want
        you can use a unique key just for PAX - it makes no difference.
        If PAX already has a key of the same user-id it will reject yours.
        Note that this means that you need different key user-id's on
        different machines (or mail addresses anyway).

        # makes new keys & adds to your "keyring"
        pgp -kg
        Enter a user ID for your public key: First M. Last of somefirm

        # extract key in ascii form suitable for a message body
        pgp -kxa "First M. Last of somefirm" savedfile pubring

        # send it to PAX
        mail anon.key at pax.tpa.com.au <savedfile.asc

      - PAX will respond by sending you a new alias number and a
        public key to add to your keyring to use to encrypt messages
        to PAX. It will have a user ID name of "paxanon.publickey"
        and you should add it to your public key ring by saving the
        message in a file and presenting it as follows:

        pgp -ka savedfile

        Your life will be easier in future if you reply yes to the
        certify question.

      - Note that now you may have two aliases, that sent in response to
        the anon.key command and that sent in response to the anon.ping
        command or previous unencrypted replies or posts. Any sunsequent
        replies or posts that you encrypt before sending will be seen
        to others as having come from the new alias, and replies will be
        encrypted before being passed on to you. Any plaintext messages
        you send will appear to have come from the original alias and
        responses will also come back in plaintext.

 - Sending encrypted posts and replies.

     There are no other commands. If you encrypt a message and send it
     using the "anon.reply" and "anon.post" groups, the software will
     detect that they are encrypted, select the appropriate alias as
     a return address, decrypt the message, and mail or post it.

     You should use PGP 2.0 to encrypt messages sent to PAX, using
     the public key that PAX sent to you. DON'T FORGET TO SIGN your
     message using the secret key corresponding to the public key
     that you sent to PAX !!! Unsigned messages will be rejected
     to ensure that the message is really from you and not someone
     pretending to be you using your account or mailpath.

     Eg.:

        # sign and encrypt message for mailing to pax.
        pgp -east message "paxanon.publickey" -u "First M. Last of somefirm"
        mail -s "A test post" anon.post.alt.test <message.asc

     Note the -a (armor) and -t (text) options. Note also the subject
     flag to mail - PAX will whinge if you post something without a
     subject.

     Similarly, all messages to you will be signed using PAX's secret
     key corresponding to the public key PAX sent to you, hence you
     will know if the message really came from PAX and not someone
     else using your public key.

     ***** NB. The ENTIRE encrypted segment will be passed on after
     it has been decrypted. There is no processing of any contained
     header (though it won't work as a header), nor any removal of
     signature information within the encrypted text. Take great care
     to ensure that there is no identifying information within the
     encrypted text. *****

     Any plain text accompanying the encrypted text will be discarded.
     The Subject header field is still passed on during postings as
     with "normal" unencrypted posts.

     More work may be done on these "features" if there is sufficient
     demand for it :).

Miscellaneous administrative commands:

 - To see the current status of the system (message of the day):

    mail anon.status at pax.tpa.com.au

 - To send mail to a human administrator:

    mail anon.admin at pax.tpa.com.au

 Mailing List
 ============

To send mail to/join/unjoin a mailing list about this service, and
anonymous services in general:

    mail anon.list at pax.tpa.com.au
    mail anon.subscribe at pax.tpa.com.au
    mail anon.unsubscribe at pax.tpa.com.au


 How secure is it ?
 ==================

Not bad. Clearly it depends on the security of the underlying PGP 2.0
software which is discussed at length in its documentation.

The keys are stored, and the messages encrypted and decrypted on
a server which also hosts a Public Access Unix system. These files
are protected by the usual Unix security mechanisms, but in the
event of a security breach could conceivably become visible. The
keys would hence be compromised and any messages passing through
could be decrypted. The PAX administration could theoretically
access the keys and files at will of course.

It is hard to conceive of an alternative implementation which links
anonymity with privacy enhancement however. This is no substitute for
a direct person to person link with certified keys and this service
should not be used as a substitute for such if security is a primary
concern.

 Legal Issues.
 =============

PGP 2.0's use of the RSA algorithm is a problem in the US where a patent
is now held on the algorithm, despite its widespread promulgation before
the patent was obtained. The PGP documentation discusses this issue at
length.

Sufficeth to say, this service is provided by a site in Australia and
hence should not be subject to the constraints imposed by the US patent.
The service is offered to anyone who can reach this site by mail, in
addition to PAX's own users, and there is no intention of obtaining any
commercial gain by providing the privacy-enhanced anonymous service.

Whether individuals in the US can legally use the PGP software to use the
service provided by PAX for their own personal use, without first obtaining
a license to use the RSA algorithm is an untested issue. Certainly the
software is widely available even though it is now maintained outside the
US.

No such concerns should apply anywhere other than the US.

This project is an experiment to see if the concept is feasible and if
there is any demand for it. The software is crude, but functional,
but it is quite possible that it will fail in unforeseen circumstances.
It is designed to loose or fail to pass on a message rather than post or
return plaintext (which would be very undesirable) but there can be no
guarantees. It is conceivable that plaintext might get sent where it
was not intended, and PAX assumes no responsibility for the consequences.
At least this would be no worse than the situation that prevails with
current anonymous services.

THIS IS EXPERIMENTAL SOFTWARE IN A STATE OF FLUX - YOU HAVE BEEN WARNED.

END OF FILE

--
** Anonymity & Privacy by PAX - Public Access Unix (Adelaide,South Australia) **

anon.admin at pax.tpa.com.au (a human)    anon.info at pax.tpa.com.au   (for help)
anon.ping at pax.tpa.com.au  (get alias)  anon.key at pax.tpa.com.au    (register key)
anon.###@pax.tpa.com.au   (reply)      anon.post.g at pax.tpa.com.au (post to g)
anon.list at pax.tpa.com.au  (to mailing list)
anon.subscribe at pax.tpa.com.au          anon.unsubscribe at pax.tpa.com.au

For dialup Unix access phone +61-8-235-9010 - online registration.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From yanek at novavax.nova.edu  Sun Dec 13 16:39:37 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 16:39:37 PST
Subject: Random numbers
In-Reply-To: <9212131408.AA00292@britt>
Message-ID: <9212140035.AA21752@novavax.nova.edu>


> It would seem to me that someone somewhere should produce a "random
> number server" available via a well-known internet port number. Some
> natural phenomenon not readily available to all could be used to generate
> such numbers and one could just connect and ask for a number. It would be

I would not trust someone to generate random numbers for me.  For all
you know, they may be recording the date, time, and who is requesting
the number, and selling the information to the highest bidder (guess who?).








From yanek at novavax.nova.edu  Sun Dec 13 17:04:43 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 17:04:43 PST
Subject: ps -laxww for randmoness?
Message-ID: <9212140100.AA22531@novavax.nova.edu>


How about using ps -laxww as a source of randomness?  Of course it would be
run throug something like MD5 to get rid of the structure.  This would
not be good on a multi-user system because ps command may have been 
modified to log the person invoking it, time, and output to somewhere.

But on a personal workstation that you trust, it could be a pretty
good source of unpredictable data.

This is not my original idea, I think it was suggested in one of the
multiple precision math packages I looked at recently.







From tcmay at netcom.com  Sun Dec 13 18:29:13 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 13 Dec 92 18:29:13 PST
Subject: Random numbers (and big primes, too!)
In-Reply-To: <9212131408.AA00292@britt>
Message-ID: <9212140227.AA04427@netcom2.netcom.com>



David Clunie writes:

> It would seem to me that someone somewhere should produce a "random
> number server" available via a well-known internet port number. Some
> natural phenomenon not readily available to all could be used to generate
> such numbers and one could just connect and ask for a number. It would be
> interesting to try to devise means by which interception or sequencing
> could be prevented.

Announcing a New Service: "Primes 'r Us"

Your full-service crypto dealer.

-specializing in selling large primes to those gullible enough to use
them
-discounts for really big primes!
-we can sell you random numbers, too...and we promise not to tell what
you bought!

Now you can be spared the hassle of generating primes for your RSA
algorithms. Now you can let "someone else do the driving."

Better yet, Primes 'r Us can handle all your cryptographic
needs...we'll generate your primes, computer your keys, and supply
your random numbers!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From wcs at anchor.ho.att.com  Sun Dec 13 19:08:48 1992
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Sun, 13 Dec 92 19:08:48 PST
Subject: Random numbers (and big primes, too!)
Message-ID: <9212140308.AA00536@anchor.ho.att.com>



Timothy May writes:
> Announcing a New Service: "Primes 'r Us"
> Your full-service crypto dealer.
> -specializing in selling large primes to those gullible enough to use them

Actually, I may decide to talk my wife into running such a service. 
It will have at least one customer (me), and any more who want to buy primes
or key pairs, given the level of trust we can provide (moderate, but...).

Why, you ask?  Well, she's about to buy a new computer for her business,
as well as personal use, and the amount you can depreciate or expense depends
on the percentage of time you've used the machine for business.
Calculating primes can take a *large* percentage of your idle time,
and what matters for tax purposes are the percentages and whether you do or
don't make a profit for the year, not *which* activities of the same business
are profitable...
			Signed, Pat Pending

P.S. Yeah, I know, now that I've told you guys the secret, the bottom will
drop out of the market because you can generate primes faster on your Cray
than we can on a 386.  Sigh....






From 74076.1041 at CompuServe.COM  Sun Dec 13 20:43:46 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Sun, 13 Dec 92 20:43:46 PST
Subject: dcnets...
Message-ID: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

I thought I would reply here to Yanek's message about dc-nets
since it is a topic that should be of interest to the list.

I think it's great that someone is going to start experimenting
with these systems.  The sooner we start playing with this technology,
the better.

I have a few general comments about the system.  First, I like the
idea of splitting the key information management from the communication
management.  That way people can choose their level of security, all
the way up to one-time pads if they want.

However, I think there should be another system chosen for exchanging
key information initially than using PGP to send large one-time pads.
Dc-nets really eat up the bandwidth.  Yanek estimates using 125
kb per message sent!  And having to send one-time key information
around doubles the bandwidth.

Also, Eric Hughes pointed out to me in private mail once that a system
like this for key information exchange is only computationally secure.
You are basically relying on RSA and IDEA not to be broken.  As long
as you're doing that for this initial experiment, why not save yourself
a lot of trouble.  Just exchange an IDEA (or DES) seed, then cycle it
repeatedly through IDEA (or DES), taking the low order bit or few bits
as new random ones.  If two people have the same seed, they will generate
the same random bits.  And if IDEA is secure, your bits should be
secure.  If they aren't, PGP isn't secure.  PGP has code to do this.
I think it's in the IDEA.C module.  Also see strong_pseudorandom in
CRYPTO.C.

So, I'd suggest that the key exchange part just exchange a short key
and then a program generates the new random bits as needed for the
messaging.  Keep the key stuff separate, though, so people really can
do one-time pads if they want to eventually.

Another point is the amount of messaging people will do.  I think the
system should be enhanced to allow people to send and receive messages
to/from non-DC-net participants.  Otherwise you have 10 or 20 people
who hardly know each other.  What will they have to say to each other?
You won't get a good picture of message loads.

I don't foresee everybody in the world being hooked into interlocking
DC-nets any time soon (if ever).  But I do think there will be DC-nets
for some interested people.  They will achieve anonymity amongst
the group for messages sent beyond the group.  In other words, it will
be known that a message comes from a certain DC-net group, but it will
be impossible to tell which person in the group sent it.  Likewise,
messages could be sent to a DC-net group without it being known to whom
they are sent.

I think this capability should be added very soon to the DC-net software.
It sounds like the software may include automatic message-sending capability
and if so, something which just recognized a special message header and
took it as "Request-Remailing-To:" should be easy to add.  Likewise,
incoming messages to the Dc-net (which would be sent to some random
person in the group) should be easily forwardable to the DC-net system
from outside.  I don't have a clear picture of the user interface from
Yanek's description so I'm not sure how easy/hard these would be to do.

One other thing I'd mention: the mechanism of reserving a slot and then
sending a message is discussed at some length in the Ph.D. thesis of
Jurgen Bos.  Tim May kindly sent me an excerpt from the thesis which
included this discussion; I think it may have been part of the original
cypherpunk meeting handout.  Bos compares several message reservation
schemes and discusses which are the best.  It might be good for Yanek
to take a look at this document.

Yanek asks about sending encrypted traffic over amateur bands.  This
is definately illegal in the U.S.  The reason is that the amateur bands
can't be used for commercial purposes, so the FCC demands to be able
to know everything that is being sent to make sure this rule is being
complied with.  However, there are some commercial packet-radio systems
starting up and presumably they won't be subject to this limitation.

It may not be practical to incorporate all of these suggestions at first,
but I do think that using PGP to exchange a RNG seed would be better
than using it to exchange one-time pads.  I'm looking forward to seeing
the system in operation.

Hal
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyvk8qgTA69YIUw3AQHyuQP/fXIkyCWR5GCiZsiRvMThcJK5xMbOQEIF
ow9S9xQ+7kiiJuF4dVp7NRyNTBjO2tBiQDh4JRKb4Pl7LGq+KKYQSTDzGgEo7hOw
dkgujwxbCAXjn2XEMewRHprZMPV4XB+iGIZzQ4piqubzWg8hOV8sMhduGaHKnhGc
MlhbbmhToOc=
=+cPN
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From tcmay at netcom.com  Sun Dec 13 22:51:01 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 13 Dec 92 22:51:01 PST
Subject: A minor experimental result
Message-ID: <9212140649.AA12228@netcom.netcom.com>



One of the purposes of setting up remailers is to experiment with
them, see what kind of emergent behavior appears, see what kind of
flaws and obstacles arise, see how they break, etc.

Here's one: the compromise of my "anonymity" by one of the folks
running a remailer. (Who and where don't matter, just the phenomenon
itself.)

I used a single bounce without any encryption to send a message and
got a query from the owner of the remailer saying "I couldn't help
looking through my remailer archives and noticing...." and requesting
more information from me!!

Hoist by my own petard!

Several lessons:

* Multiple bounces help, even without encryption, as then the remailer
sysop can't be sure who originated the message.

* Encryption is of course even more desirable, though a hassle
(especially for Mac users).

* Remailer sysops should make a point to _not_ look at their remailer
archives. In fact, they should discard them immediately (for their own
legal protection, and for slightly greater trust amongst users, though
this is a hazy area...).

(Recall that the "mix" on which our software-based remailers are
loosely patterned are "memoryless," i.e., the tamper-resistant modules
that implement the receive-decrypt-store-forward protocol have no
memory of the mapping between incoming and outgoing messages. In
fact, the outside world cannot possibly compromise the protocols to get
at this information.)  

So, my laziness in using only a single bounce, combined with the
curiosity of a remailer sysop, breaks the anonymity.

Neither surprising nor profound, but I thought you folks would like to know.


--Tim May

--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay at netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From 74076.1041 at CompuServe.COM  Mon Dec 14 10:31:00 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Mon, 14 Dec 92 10:31:00 PST
Subject: Remailers.
Message-ID: <921214165323_74076.1041_DHJ77-1@CompuServe.COM>


Tim's message brings up a point I've been wanting to mention.
The prototype remailer software keeps log files of all messages
passed through it.  There are different reasons why people running
the software might wish to have these logs.  One purpose is for
debugging; the remailers don't produce much in the way of error
messages and the log files can be useful for tracking down errors.

A few weeks ago, for example, one user was having difficulty sending
messages through my remailer, and he posted here about it.  I was
able to confirm that his messages had come in and been sent out.

However, another possible reason is for the case of abusive messages.
I had one message go through that appeared to be directed towards
the sender's boss, and was rather unfriendly in tone.  The remailers
give the outgoing messages the superficial appearance of having
come from me.  This message wasn't that bad, but there's nothing
to stop someone from sending a really vicious, racially or sexually
harrassing message, and I am very concerned that I could get in
trouble for that.

What I've generally done is to delete the log files every few
days, usually after a quick perusal to see if there are any
messages which the recipient might object to.  Sometimes if I see
a message which is of an illegal format so that it didn't get sent,
(like forgetting the ":" in "Request-Remailing-To:") I'll send a
message to the sender telling him what he did wrong.

I feel that people who run remailers should set their own policies
as far as the confidentiality of the messages they forward.  Running
a remailer can be somewhat risky in the current climate and the
operators can legitimately seek whatever level of protection they
are comfortable with.  However, I think it would be good if the users
of the remailers could get some information about what the privacy
policies are.  Maybe some remailers will simply not keep logs; maybe
others will keep logs but not look at them unless a specific circumstance
arises, and so on.  Eric Hollander has been creating a list of remailers;
perhaps he could solicit this kind of information from the operators
and publish it along with the remailer addresses and keys.

Hal
74076.1041 at compuserve.com


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From yanek at novavax.nova.edu  Mon Dec 14 10:31:18 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Mon, 14 Dec 92 10:31:18 PST
Subject: dcnets...
In-Reply-To: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>
Message-ID: <9212141634.AA01103@novavax.nova.edu>



> I have a few general comments about the system.  First, I like the
> idea of splitting the key information management from the communication
> management.  That way people can choose their level of security, all
> the way up to one-time pads if they want.

I tried to make the system as modular as possible, so any part could be
improved or changed with minimal effects on the rest of the system.
 
> Dc-nets really eat up the bandwidth.  Yanek estimates using 125
> kb per message sent!  And having to send one-time key information

This is due to two factors.  First, right now there is no way to specify
the size of a message.  Every message is assumed to be 5K so bandwidth is
wasted for any message smaller than that.  As I mentioned in "FUTURE 
ENHANCEMENTS" section, I will make message size be part of the reservation
block structure, so small messages will be transferred more efficiently.

Second, I am using point-to-point transmission.  When I want to broadcast
a message, I need to send it individually to each participant.  Use of
a broadcast media such as ethernet multicast or satellite or radio will
dramatically decrease communications load.  

> as you're doing that for this initial experiment, why not save yourself
> a lot of trouble.  Just exchange an IDEA (or DES) seed, then cycle it
> repeatedly through IDEA (or DES), taking the low order bit or few bits

This is a good idea.  I will do it this way unless anyone else can
see any problems with this.
 
> Another point is the amount of messaging people will do.  I think the
> system should be enhanced to allow people to send and receive messages
> to/from non-DC-net participants.  

If a broadcast system could be used, anyone that can receive the broadcast
will be able to reconstruct the messages, even if they are not participating
in the net.  If this project works successfully, I will try it using usenet
as the medium.  So anyone can scan alt.dcnets and get the message.

> and if so, something which just recognized a special message header and
> took it as "Request-Remailing-To:" should be easy to add.  Likewise,

Yes it is easy to add.  Eventually you will be able to request forwarding
to a mail address (or a mix-net remailer), an anonymous post to a usenet
newsgroup, or retransmission to another dc-net.

The only small problem is that everyone gets the message, and I don't want
the message sent out 15 times.  So there must be some way to decide who
does the remailing.  I could just have one person act as the forwarder,
but it would be more interesting (and harder to break) if the net somehow
dynamically assigned a random forwarder for each message.

> incoming messages to the Dc-net (which would be sent to some random
> person in the group) should be easily forwardable to the DC-net system

Yes.  Mix-net remailers could also be participants in a dc-net, so a
message could be sent without anyone even knowing which remailer it
came from, for people that want untraceability but don't want to or can't
participate in a net themselves.

> from outside.  I don't have a clear picture of the user interface from
> Yanek's description so I'm not sure how easy/hard these would be to do.

Very easy.  To send out a message on a dc-net you just drop it into it's
outgoing directory, the next round it gets transmitted.  

Any messages received are piped to "incoming" program in that dcnet's 
directory.  That program initially will just put the message in your
mailbox, but you can make it do anything, such as drop it in another
dc-net's incoming directory, or remail it, or post it somewhere.

 
> One other thing I'd mention: the mechanism of reserving a slot and then
> sending a message is discussed at some length in the Ph.D. thesis of
> Jurgen Bos.  Tim May kindly sent me an excerpt from the thesis which
> included this discussion; I think it may have been part of the original
> cypherpunk meeting handout.

Can someone forward it to me?

> Yanek asks about sending encrypted traffic over amateur bands.  This
> is definately illegal in the U.S.  The reason is that the amateur bands
> can't be used for commercial purposes, so the FCC demands to be able
> to know everything that is being sent to make sure this rule is being

But the messages become public.  Anyone can see what the message is, they
just can't see who it came from.  If all messages are transmitted as
plaintext, it is fairly easy to see that no commercial traffic is occurring.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From ncselxsi!drzaphod at ncselxsi.netcom.com  Mon Dec 14 10:31:47 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod)
Date: Mon, 14 Dec 92 10:31:47 PST
Subject: A Quote for the List
Message-ID: <19576.drzaphod@ncselxsi>


     Here's a quote I snagged off an h/p bbs... thought it was particularly
true of cipher-technology as well as computing in general.

>>>
As life moves to this electronic frontier, politicians and corporations are
starting to exert increasing control over the new digital realm, policing
information highways with growing strictness. Before we even realise we're
there, we may find ourselves boxed into a digital ghetto, denied simple
rights of access, while corporations and government agencies make out their
territory and roam free. So who will oppose the big guys? Who's going to
stand up for our digital civil liberties? Who has the techno-literacy
necessary to ask a few pertinent questions about what's going down in
cyberspace? Perhaps the people who have been living there the longest might
have a few answers.

-Mark Bennett
<<< TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized





From lg2g+ at andrew.cmu.edu  Mon Dec 14 10:32:18 1992
From: lg2g+ at andrew.cmu.edu (Liam David Gray)
Date: Mon, 14 Dec 92 10:32:18 PST
Subject: A minor experimental result
In-Reply-To: <9212140649.AA12228@netcom.netcom.com>
Message-ID: <4f=97Zm00Uh7Q1WlJ_@andrew.cmu.edu>


Excerpts from Cypherpunks: 13-Dec-92 A minor experimental result by
Timothy C. May at netcom.com:
>  
> * Multiple bounces help, even without encryption, as then the remailer
> sysop can't be sure who originated the message.
>  

Tim,

    Please tell me if this makes sense:

    If I wanted to be obnoxious, I could set myself up as a remailer,
then screen all incoming messages to see whether they came from other
known remailers.  If not, then I can archive the message, have a look at
it, and maybe compromise the original sender.

    Is this so?

    In this case, everyone wanting to use a remailer should in principle
*own* a remailer, and you'd probably want your own to be the first
remailer.  Then, to avoid compromise of the recipient, maybe you'd want
yours to be the last remailer.  So why not use your own remailer
exclusively?

    To take this to an extreme, set up a remailer and then use this
*all* the time for the mail you originate.  Does this gain you anything?

    Just curious.  I'm new on the list and might be missing something. 
Thanks in advance for replies from anyone.

Liam Gray









From ebrandt at jarthur.Claremont.EDU  Mon Dec 14 13:18:36 1992
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Mon, 14 Dec 92 13:18:36 PST
Subject: Remailers.
In-Reply-To: <921214165323_74076.1041_DHJ77-1@CompuServe.COM>
Message-ID: <9212142118.AA03045@toad.com>


> Eric Hollander has been creating a list of remailers;
> perhaps he could solicit this kind of information from the operators
> and publish it along with the remailer addresses and keys.

(Hey, everybody send your remailer information in!)

I have been deleting the logs every so often, unread since I debugged
the remailer.  If someone asks me if their message made it, I'll look
at them.  If someone gives me evidence of blackmail or the like, I'll
look at them.  Otherwise, to the bit bucket they go.

As usual, you should encrypt your message if you want it to be secure.
This is a multi-user system.  Furthermore, I may read the remail logs
from time to time as I tweak the software.  (eg add PGP, if I can fix
the "keygen error"...)

It may be worth pointing out that this gives me a plausible reason to
stonewall if someone comes asking about something *I* sent through my
remailer.

> Hal

   Eli   ebrandt at jarthur.claremont.edu





From whitaker at eternity.demon.co.uk  Mon Dec 14 13:18:54 1992
From: whitaker at eternity.demon.co.uk (Russell E. Whitaker)
Date: Mon, 14 Dec 92 13:18:54 PST
Subject: MEETING: 2nd Cypherpunks UK
Message-ID: <6405@eternity.demon.co.uk>


[I thought a month's notice on this (second) meeting would draw a little
 more interest.  Our first meeting, 13 December 92, was a good start.
  -- Russell   ;-)  ]

2nd Meeting, Cypherpunks UK
---------------------------

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
Sunday, 10 January 1993, from 1300 onwards, at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

[Note to the novice: don't hand another person your secret key... the
 one named secring.pgp.]

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of PGP public keys in the U.K.
  o   The local development of anonymous remailers and a proposed
        automatic public key repository at Demon Internet Systems
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders
  o   The use of HPACK in securing local file installations

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and established the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding
recently to include all versions of PGP, and "fellow traveller" files).

Hope to see you there!

Semper vigilans,
Semper vigilans,





From andrew_derry at sfu.ca  Mon Dec 14 13:48:53 1992
From: andrew_derry at sfu.ca (andrew_derry at sfu.ca)
Date: Mon, 14 Dec 92 13:48:53 PST
Subject: A minor experimental result
Message-ID: <9212142148.AA13622@whistler.sfu.ca>


>    If I wanted to be obnoxious, I could set myself up as a remailer,
>then screen all incoming messages to see whether they came from other
>known remailers.  If not, then I can archive the message, have a look at
>it, and maybe compromise the original sender.
>
>    Is this so?

Seems quite possible to me..  I think that's why it was suggested a while
back that as many remailers be set up as possible.  That way, one could use
several in a row and virtually eliminate the problem.

>    In this case, everyone wanting to use a remailer should in principle
>*own* a remailer, and you'd probably want your own to be the first
>remailer.  Then, to avoid compromise of the recipient, maybe you'd want
>yours to be the last remailer.  So why not use your own remailer
>exclusively?

I don't think you'd have to worry much about compromising the recipient, if
you encrypt the message with with her public key (except possibly traffic
analysis, which I doubt poses a problem to very many people, and which can
be overcome anyways).

>    To take this to an extreme, set up a remailer and then use this
>*all* the time for the mail you originate.  Does this gain you anything?

Well, it would probably be ok if a lot of other people used your remailer..
but if you were the only one, I doubt it would be very effective.
---
Andrew Derry - derry at sfu.ca       |
ACS at HCC - Simon Fraser University |
Standard disclaimers apply        |






From miron at extropia.wimsey.com  Mon Dec 14 13:55:56 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Mon, 14 Dec 92 13:55:56 PST
Subject: A minor experimental result
In-Reply-To: <9212140649.AA12228@netcom.netcom.com>
Message-ID: <1992Dec14.211716.13061@extropia.wimsey.bc.ca>


lg2g+ at andrew.cmu.edu (Liam David Gray) writes:

>    If I wanted to be obnoxious, I could set myself up as a remailer,
>then screen all incoming messages to see whether they came from other
>known remailers.  If not, then I can archive the message, have a look at
>it, and maybe compromise the original sender.

This is possible only if encryption is not used.  With encryption,
only the first remailer knows the sender (but not the plaintext or
recipient) and only the last remailer knows the recipient (but
not the sender or plaintext).
-- 
	Miron Cuperman <miron at extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron at cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |





From pmetzger at shearson.com  Mon Dec 14 15:43:24 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Mon, 14 Dec 92 15:43:24 PST
Subject: ps -laxww for randmoness?
In-Reply-To: <9212140100.AA22531@novavax.nova.edu>
Message-ID: <9212141856.AA13053@maggie.shearson.com>


>From: yanek at novavax.nova.edu (Yanek Martinson)

>How about using ps -laxww as a source of randomness?

Its a rather bad source. Operations of a computer system are
suprisingly low on entropy. I'd guess that, if I needed to and had
enough resources, I could break such a generator without more than a
few months work, and even get the system to break it semi-automatic.

No one here seems to think in terms of cryptanalysis and how people do
it when they come up with their schemes.

Perry





From hh at soda.berkeley.edu  Mon Dec 14 15:50:57 1992
From: hh at soda.berkeley.edu (Eric Hollander)
Date: Mon, 14 Dec 92 15:50:57 PST
Subject: Remailers.
In-Reply-To: <9212142118.AA03045@toad.com>
Message-ID: <9212142349.AA29938@soda.berkeley.edu>



Since it is possible to archive, I think we should all operate under the
assumption that archiving is being done.  And if we are operating under that
assumption, there is nothing wrong with archiving.  This is why multiple,
encrypted, and possibly overseases boucnes are so important.  The security
of remailing doesn't depend on trusting the operators.  It relies on there
being at least one operator who won't reveal show his logs.  If one of your
bounces happens to be through your own remailer, you can gaurantee this.

e






From Marc.Ringuette at GS80.SP.CS.CMU.EDU  Mon Dec 14 19:04:59 1992
From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU)
Date: Mon, 14 Dec 92 19:04:59 PST
Subject: Remailers.
Message-ID: <9212150304.AA06890@toad.com>


> It relies on there being at least one operator who won't reveal
> his logs.  If one of your bounces happens to be through your own
> remailer, you can guarantee this.

Let's be clear on exactly how useful it is to route your messages
through your own remailer.  It's not as useful as it first appears.

If the Awful Nasties convince all of the remailers downstream of yours
to give up their logs, they trace the message back to your machine.
You then might choose to say, "Hey man, it wasn't my message, it was
just my remailer.  And I'm not giving you the logs."

But if you're going to use this excuse, you needn't really have routed
your message through your remailer at all; you just need to be operating
a remailer and routinely refuse to divulge its logs.


-- Marc Ringuette (mnr at cs.cmu.edu)





From avalon at coombs.anu.edu.au  Tue Dec 15 07:31:35 1992
From: avalon at coombs.anu.edu.au (Darren Reed)
Date: Tue, 15 Dec 92 07:31:35 PST
Subject: ps -laxww for randmoness?
In-Reply-To: <9212141856.AA13053@maggie.shearson.com>
Message-ID: <9212151530.AA05832@coombs.anu.edu.au>


In some email I received from Perry E. Metzger, Sie wrote:
> 
> 
> >From: yanek at novavax.nova.edu (Yanek Martinson)
> 
> >How about using ps -laxww as a source of randomness?
> 
> Its a rather bad source. Operations of a computer system are
> suprisingly low on entropy. I'd guess that, if I needed to and had
> enough resources, I could break such a generator without more than a
> few months work, and even get the system to break it semi-automatic.
>
> No one here seems to think in terms of cryptanalysis and how people do
> it when they come up with their schemes.

Well whenever I try to come up with some nifty crypto scheme, I always
seem to think it is too easy to break if you know its being used but then
I dont like doing too much 'expensive' crypting and I usually find some
cheap algo which uses a more expensive one for key trading.

Has anyone tried using the microsecond counter from unix as a random
source ?  Its obviously *not* going to be good if you want a continuous
stream of random numbers, but if you need them just 'every now and then',
what about it ?

Something like this would be used:

	struct	timeval	tv;
	long	rand;
	...
	gettimeofday(&tv, NULL);
	rand = tv.tv_usec + tv.tv_sec;
	...

Very unlikely to get a duplicate, esp. if you dont need the number
more often than 1 per second.

darren





From yanek at novavax.nova.edu  Tue Dec 15 07:56:18 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 15 Dec 92 07:56:18 PST
Subject: ps -laxww for randmoness?timeofday for randmoness
In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au>
Message-ID: <9212151555.AA10507@novavax.nova.edu>


> 	gettimeofday(&tv, NULL);
> 	rand = tv.tv_usec + tv.tv_sec;

Someone trying to break your code could find out approximately when
the number was generated, then they would have a much smaller search
space to try.






From avalon at coombs.anu.edu.au  Tue Dec 15 09:05:15 1992
From: avalon at coombs.anu.edu.au (Darren Reed)
Date: Tue, 15 Dec 92 09:05:15 PST
Subject: timeofday for randomnessness ?
In-Reply-To: <9212151555.AA10507@novavax.nova.edu>
Message-ID: <9212151704.AA15303@coombs.anu.edu.au>


In some email I received from Yanek Martinson, Sie wrote:
> 
> > 	gettimeofday(&tv, NULL);
> > 	rand = tv.tv_usec + tv.tv_sec;
> 
> Someone trying to break your code could find out approximately when
> the number was generated, then they would have a much smaller search
> space to try.

Thats why you change key 'regularly'...even randomly ?

Then they have to 'guess' when you change keys.  It might be easy
to tell when an application starts, but how can you tell exactly or
even approximately how long ago someone picked a menu that changed
their key or it was otherwise changed ?

By using the microsecound counted as a random number, its almost
completely random unless you take steps to actually make less so.
But a table of the required million entries and 'init' strings
wouldn't be too hard for todays computers, hence the use of the
time in seconds to 'bump' the offset a bit.

For example, if you use a simple xor table for encoding/decoding,
its pretty easy to decode.  If you change the table after it has
been used, every time, then the required time to break the entire
message is significantly larger than it would otherwise have been.

Can anyone do some maths on exactly how long it would take given
a fixed table size (contains random data) ?  And also with key/
table changes at a fixed/random interval ?
(seems 1:1 :( but I maybe wrong).

darren





From barrus at tree.egr.uh.edu  Tue Dec 15 09:43:54 1992
From: barrus at tree.egr.uh.edu (Karl L. Barrus)
Date: Tue, 15 Dec 92 09:43:54 PST
Subject: remailer extension (contact field)
Message-ID: <9212151743.AA20003@tree.egr.uh.edu>



I've added a contact field to my remailer.  To contact me (the
operator of remailer03 <elee7h5 at rosebud.ee.uh.edu>) you can use the
following header:

----cut here----
::
Contact:

----cut here----

Note the colon after contact and the blank line at the end.
Encryption of this header is supported as well; you can reach me by
encrypting this contact header and doing the usual.

For those interested - here are the changes to maildelivery and
remail.pl (I haven't been able to study the remailer code much, and am
just learning perl, so this can probably be improved.)

Changes to maildelivery, before the * on the last line
Add the following: (I spaced everything out in the file)

Contact  ""  pipe R  remail.pl
Contact  ""  file A  archive.remail

Add to remail.pl, before the block that begins
                  if (/^Request-Remailing-To:/ || /^Anon-To:/)

if (/^Contact:/) {
  chop ;
  s/^.*// ;
  $addressee = $_ ;
  $addressee = "my.id at some.other.machine" ;
}

I don't know perl well enough to figure out what can or can't be
deleted (specifically the $addressee = $_ line, etc.)

/-----------------------------------\
| Karl L. Barrus                    |
| barrus at tree.egr.uh.edu (NeXTMail) |
| elee9sf at menudo.uh.edu             |
\-----------------------------------/









From ahawks at nyx.cs.du.edu  Tue Dec 15 15:58:07 1992
From: ahawks at nyx.cs.du.edu (zoiks!)
Date: Tue, 15 Dec 92 15:58:07 PST
Subject: subscribe
Message-ID: <9212152358.AA16200@nyx.cs.du.edu>


Please subscribe me to the list...Heard about it from alt.cp, Mondo,
Paco Xander Nathan, and my own FutureCulture list...
-- 

    ahawks at nyx.cs.du.edu	        FutureCulture:  In/f0rmation
    ahawks at mindvox.phantom.com		future-request at nyx.cs.du.edu






From wendtj at jplpost.Jpl.Nasa.Gov  Tue Dec 15 20:14:52 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Tue, 15 Dec 92 20:14:52 PST
Subject: Inf0
Message-ID: <9211157244.AA724460817@jplpost.jpl.nasa.gov>


          Does anyone know of companies that will sell Tempest
          shielding to a private citizen, and if so; what regulations
          and licensing are required to own this equipment.

          Thanks in advance,

          JPW
          -----------------------------------------------------------
          JPL: 03-90 - 12-31-92.  Goldin + Peace + Politics = Layoff
          Anyone out there looking for an AA?
          -----------------------------------------------------------





From tytso at ATHENA.MIT.EDU  Tue Dec 15 23:15:59 1992
From: tytso at ATHENA.MIT.EDU (Theodore Ts'o)
Date: Tue, 15 Dec 92 23:15:59 PST
Subject: ps -laxww for randmoness?
In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au>
Message-ID: <9212160715.AA09133@tsx-11.MIT.EDU>


   From: avalon at coombs.anu.edu.au (Darren Reed)
   Date: Wed, 16 Dec 92 2:30:49 EST

   Has anyone tried using the microsecond counter from unix as a random
   source ?  Its obviously *not* going to be good if you want a continuous
   stream of random numbers, but if you need them just 'every now and then',
   what about it ?

This should be in an FAQ:  Unixes have different levels of granularity
in the microsecond counter; some systems may only have a 10 ms (that's
10000 microsecond) resolution to their clock.  So you can't necessarily
depend on a getting lot of bits of randomness from this method.

						- Ted





From eichin at cygnus.com  Tue Dec 15 23:46:40 1992
From: eichin at cygnus.com (Mark W. Eichin)
Date: Tue, 15 Dec 92 23:46:40 PST
Subject: ps -laxww for randmoness?
In-Reply-To: <9212160715.AA09133@tsx-11.MIT.EDU>
Message-ID: <9212160740.AA04597@tweedledumber.cygnus.com>


Don Davis, of MIT Project Athena, did some research a number of years
back on getting good (physical) randomness out of a unix workstation.
If I recall correctly, the general idea was to look for trends and
biases, find explanations for them, and then filter them out or
normalize against them. Sources of "real" nondeterminism came from
things like variations in hard drive behavior (such as actual seek
time, which shows up indirectly in the paging system because it does
or does not cause time delays due to missed sectors...) I don't have a
reference handy, but if noone comes up with one I'll send him email
and see if he has it online.
	In other words, 'ps -laxww' itself is relatively useless --
but the underlying data does actually have randomness; you may have to
dig pretty hard for it, though.
							_Mark_

   SUB: Re: ps -laxww for randmoness?
   SUM: <tytso>, tytso (Theodore Ts'o)->avalon at coombs.anu.edu.au, cypherpunks at toad.com

      From: avalon at coombs.anu.edu.au (Darren Reed)
      Date: Wed, 16 Dec 92 2:30:49 EST

      Has anyone tried using the microsecond counter from unix as a random
      source ?  Its obviously *not* going to be good if you want a continuous
      stream of random numbers, but if you need them just 'every now and then',
      what about it ?

   This should be in an FAQ:  Unixes have different levels of granularity
   in the microsecond counter; some systems may only have a 10 ms (that's
   10000 microsecond) resolution to their clock.  So you can't necessarily
   depend on a getting lot of bits of randomness from this method.

						   - Ted






From strat at intercon.com  Wed Dec 16 01:44:48 1992
From: strat at intercon.com (Bob Stratton)
Date: Wed, 16 Dec 92 01:44:48 PST
Subject: Inf0
In-Reply-To: <9211157244.AA724460817@jplpost.jpl.nasa.gov>
Message-ID: <9212160945.AA16858@intercon.com>


>>>>> wendtj at jplpost.jpl.nasa.gov (Jeffrey P Wendt) writes:

	Jeffrey>           Does anyone know of companies that will
	Jeffrey> sell Tempest shielding to a private citizen, and if
	Jeffrey> so; what regulations and licensing are required to
	Jeffrey> own this equipment.

I believe that InterPact, a company operated by Winn Schwartau that
also publishes the "Security Insider Report", does this type of work,

They're in Houston, I think.

--strat






From treason at gnu.ai.mit.edu  Wed Dec 16 07:34:13 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Wed, 16 Dec 92 07:34:13 PST
Subject: remailers
Message-ID: <9212161534.AA18300@spiff.gnu.ai.mit.edu>


   Does anyone have a ongoing list of remailers addresses and functions that
they could send me?  I haven't had time to compile a list myself, but would
appreciate itt greatly if I could get one.

Treason




From treason at gnu.ai.mit.edu  Wed Dec 16 08:46:30 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Wed, 16 Dec 92 08:46:30 PST
Subject: remailers
Message-ID: <9212161646.AA18468@spiff.gnu.ai.mit.edu>


I don't know if this message got through, but I'll repost  it just in case...

What I would like is a list of remailers with maybe a description of the
fucntions(non-standard mail) like pgp abilities or whatever.  A list of
remailers would be good in itself.

treason





From treason at gnu.ai.mit.edu  Wed Dec 16 10:18:50 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Wed, 16 Dec 92 10:18:50 PST
Subject: tempest devices and use
Message-ID: <9212161818.AA18643@spiff.gnu.ai.mit.edu>


     For those who are interested in tempest devices and such...

It is currently legal to create/buy and use tempest devices for any citizen
under any circumstances.  It is also legal to sell such devices, with the exception of selling to non US citizens and governments.  This is the good news.

The bad news is:

It is illegal to use any device as a tempest shield, including lead, 
tesla coils or any other materials that can possibly interfere with tempest
reception!  You need a government license to use these, and then you must have 
reason to have such a device(this is how banks can use such things.)

I have a few tempests, one with a range of about 200 yards using aricraft
vdo's.  If anyone wants a file discussing the legal issues of the tempest,
please ask, and I'll forward it here.

treason at gnu




From pmetzger at shearson.com  Wed Dec 16 11:16:00 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Wed, 16 Dec 92 11:16:00 PST
Subject: tempest devices and use
Message-ID: <9212161854.AA08014@maggie.shearson.com>



> From: treason at gnu.ai.mit.edu
> 
>      For those who are interested in tempest devices and such...
> 
> It is currently legal to create/buy and use tempest devices for any citizen
> under any circumstances.  It is also legal to sell such devices, with the 
> exception of selling to non US citizens and governments.  This is the good 
> news.
> 
> The bad news is:
> 
> It is illegal to use any device as a tempest shield, including lead, 
> tesla coils or any other materials that can possibly interfere with tempest
> reception!  You need a government license to use these, and then you must have 
> reason to have such a device(this is how banks can use such things.)
> 
> I have a few tempests, one with a range of about 200 yards using aricraft
> vdo's.  If anyone wants a file discussing the legal issues of the tempest,
> please ask, and I'll forward it here.

This particular bit of garbage is so malodorous that it can't be left
unchallenged. There are no rules saying that you can't shield your computer
equipment; in fact, there are FCC rules that say that you HAVE to shield
it, though you aren't required to do as well as tempest specs, which, to
my knowledge, are not even public knowledge.

Put up or shut up, Mr. "Treason". Give us one lick of evidence that you know
what you are talking about.

Perry






From karn at qualcomm.com  Wed Dec 16 11:48:04 1992
From: karn at qualcomm.com (Phil Karn)
Date: Wed, 16 Dec 92 11:48:04 PST
Subject: tempest devices and use
Message-ID: <9212161918.AA03733@servo>


>It is illegal to use any device as a tempest shield, including lead, 
>tesla coils or any other materials that can possibly interfere with tempest
>reception!  You need a government license to use these, and then you must have 
>reason to have such a device(this is how banks can use such things.)

Eh? The specific purpose of TEMPESTing a computer that handles
classified information is to contain any incidental information-
bearing electromagnetic emissions so they cannot be received at a
distance. But shielding is not only a security issue, it is also
highly desirable to minimize interference to users of the radio
spectrum (e.g., broadcast TV sets and radios).

Now the FCC Part 15 rules (which govern "incidental radiation devices"
such as computers) are much less stringent than TEMPEST, but this is
only an economic tradeoff because full TEMPEST-level shielding of a
computer can be very expensive. In fact, many classified shops have
instead built "screen rooms" (or entire screened buildings, such as
those at the NSA) so they can use standard commercial-grade computer
hardware. Anyone is free to add as much shielding to their computer
equipment or their entire buildings as they want.  There's absolutely
nothing illegal about it; in fact it's highly commendable to do so.
The FCC (and your neighbors) will thank you for it.

Now if you wanted to "mask" your computer's RF emanations with some
sort of RF noise source (such as a Tesla coil) that's another story.
Most transmitters require licenses for the obvious reason that they
can interfere with other users of the radio spectrum. But this has
nothing to do with your right (or even duty) to shield your computers.

Unfortunately the TEMPEST rules themselves are classified, so we
really don't know how much shielding is necessary, or what one can
pick up from an unshielded system, or exactly how you'd do it.
Obviously this is an attempt to protect NSA's own SIGINT methods. But
there is, to coin a phrase, "equal protection under the laws of
physics".  Star Warriors' claims notwithstanding, they're the same
for everyone, black (classified) or white, and they're open for
all to discover and apply on their own.

Phil









From treason at gnu.ai.mit.edu  Wed Dec 16 12:44:26 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Wed, 16 Dec 92 12:44:26 PST
Subject: tempest file
Message-ID: <9212162044.AA19398@spiff.gnu.ai.mit.edu>


I don't know what is in the file entirely, but it looked like the one I have
read on the legality of using tempest shields and such.  I have other files on the issue as well, I would like you guys to tell me whats you think, and if I 
should post the others as well.

treason at gnu   - You have free will, but you will go to hell if you use it!





From treason at gnu.ai.mit.edu  Wed Dec 16 16:26:15 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Wed, 16 Dec 92 16:26:15 PST
Subject: files
Message-ID: <9212170026.AA20674@spiff.gnu.ai.mit.edu>


   Of course half the problems with realistic discussions are aroused
by idiots flaming without checking their sources....

treason




From yanek at novavax.nova.edu  Wed Dec 16 17:34:17 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Wed, 16 Dec 92 17:34:17 PST
Subject: INFO: TEMPEST companies
Message-ID: <9212170133.AA11380@novavax.nova.edu>


Lindgren RF Enclosures
400 Gigh Grove Blvd.
Glendale Heights, IL 60139

Contact: Wayne Martin
708-307-7200
FAX: 708-307-7571

"LT" Series Shielding System is a complete line of modular enclosures,
equipment cabinets and custom enclosures available in virtually all
shielding materials.  The system features exclusive Double Electrically
Isolated construction for maximum attenuation.  All enclosures are fully
tested and guaranteed.  Aplication assistance available.




Secure Systems & Services
Div. of The R/H Factor Corp.
13990 Goldmark Dr., Ste.401
Dallas, TX 75240

Contact: Ray Helsop
214-907-9288
FAX: 214-669-9160

TEMPEST Products, Systems & Services are for Military/Industrial firms
concerned with threat of information security and protection by [sic]
electronic eavesdroppoing; also commercial EMI/RFI, reduced emissions
products.  We provide TEMPEST service and support, data encryption,
F.I.S.A. Facility Information Security Assessment Studies, site planning,
installation design, facility upgrades, etc.




International Paper Co.
Longmeadow Rd.
Tuxedo, NU 10987

Contact: Larry Fahy
914-577-7247

SAF'N SHIELDED (tm)

International Paper provides a unique wallcovering that prevents
electromagnetic interference (EMI), wireless electronic espionage, and
other forms of electromagnetic eavesdropping.  The new wallcovering, a
composite structure that incorporates a nonwoven mat of metallic fibers,
has been TEMPEST-tested by the U.S. government and can achieve attenuation
levels over 100dB.  The material, which eliminates the added costs of
"hardening" or adding protective shielding to individual pieces of
electronic equipment, is being used both in primary applications and to
upgrade facilities to higher levels of protection.  It also provides a way
to plug EMI leaks quickly and effectively.  Unlike woven or sheet metal,
which typically require gutting entire rooms, this flexible, lightweight
material goes up as quickly as wallpaper.  No special tools are needed, and
downtime is minimal.




Transaction Security, Inc.
21 Industrial Ave.
Upper Saddle River, NJ 07458

Contact: O. Mark Hastings
201-573-1150

Steel TEMPEST-type enclosures for any size computer hardware.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From pmetzger at shearson.com  Wed Dec 16 19:13:38 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Wed, 16 Dec 92 19:13:38 PST
Subject: files
Message-ID: <9212170234.AA14757@maggie.shearson.com>


> From: treason at gnu.ai.mit.edu
>    Of course half the problems with realistic discussions are aroused
> by idiots flaming without checking their sources....
> 
> treason

Gee, who's the fool claiming that its illegal to RF shield your computer...

.pm





From wmo at rebma.rebma.mn.org  Wed Dec 16 22:45:56 1992
From: wmo at rebma.rebma.mn.org (Bill O'Hanlon)
Date: Wed, 16 Dec 92 22:45:56 PST
Subject: A stupid move
Message-ID: <m0n2Dpl-0007g1C@rebma.rebma.mn.org>


Edgar Swank helpfully pointed out that I messed up when I sent my
remailer and personal keys out.  I sent the wrong personal key.
Here's both, once again.  
Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAiq/Z6sAAAEEAL8au0gDOEj8xQbaV8jS1BM+baetvF6RciEeyfb9A/1Csdpz
87PTEN19tIteDOX8bQIS9exwztaEG7Upa9WlPs9bNsn5TITJAtEOIalqRwlWd1Qh
dsrX7jkytL89MFlVTdBWHhlVuKiGTa4yrFcycoiakXPmf51f0xiQVHeOVJ+HAAUT
tCBCaWxsIE8nSGFubG9uIDx3bW9AcmVibWEubW4ub3JnPokAlQIFECsT6HDlC9IM
15aj/QEBiucD/iS5u+7ze0X0QVI3cVMrFDmkQpQDWb5mm7uPcaeYra3VGm7+Cfxn
LkqwMkMwPytxxkNC9NvFCsrndrFFmuP8eLVBSQpZinfs/2d2A9AJsVsZAd4uDvP3
CKXpF415zgCWBHUt6JrT+pjk00sKUhQYSgUKj1z1uyYfw3q1AMWjrP5s
=k9RJ
-----END PGP PUBLIC KEY BLOCK-----
Here's the remailer at rebma.mn.org, signed with mine.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3
jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF
0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv
BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO
=nBQt
-----END PGP PUBLIC KEY BLOCK-----
-- 
Bill O'Hanlon						 wmo at rebma.mn.org




From hkhenson at cup.portal.com  Thu Dec 17 01:21:34 1992
From: hkhenson at cup.portal.com (hkhenson at cup.portal.com)
Date: Thu, 17 Dec 92 01:21:34 PST
Subject: tempest devices and use
Message-ID: <9212170034.1.20498@cup.portal.com>


I just sent email the first time, but hey, guys, does this not look
almost exactly like some of the restrictive proposals?  Someone is pulling
your chains.  Just because they don't put a :-) on it does not keep
a posting from being satirical.  Keith





From hkhenson at cup.portal.com  Thu Dec 17 01:21:36 1992
From: hkhenson at cup.portal.com (hkhenson at cup.portal.com)
Date: Thu, 17 Dec 92 01:21:36 PST
Subject: tempest devices and use
Message-ID: <9212170035.1.20498@cup.portal.com>


Actually the posting is a takeoff on the crypto restrictions.  Keith





From treason at gnu.ai.mit.edu  Thu Dec 17 09:38:58 1992
From: treason at gnu.ai.mit.edu (treason at gnu.ai.mit.edu)
Date: Thu, 17 Dec 92 09:38:58 PST
Subject: No Subject
Message-ID: <9212171738.AA02009@spiff.gnu.ai.mit.edu>


Here is parts of the article I posted regarding the legality of the use
of emf shielding.  Read it carefully, and I suggest you also read the
posted document in full as well.  This poses many problems to the public
in general, and the private sector in specific.
PERRY, I suggest you read this.              
 
               NACSIM 5100A is  classified, as are all  details of TEMPEST.
          To  obtain  access to  it, contractor  must  prove that  there is
          demand within  the government for the specific  type of equipment
          that intend to  certify.  Since  the standard is classified,  the
          contractors can not sell the equipment to non-secure governmental
          agencies or the public.  This prevents reverse engineering of the
          standard  for its physical  embodiment, the  Certified equipment.
          By  preventing  the   private  sector  from  owning   this  anti-
          eavesdropping equipment,  the NSA has  effectively prevented  the
          them from protecting the information in their computers. 
               A number of  companies produce  devices to measure  the
          emanations from electrical equipment.  Some of these devices
          are  specifically   designed  for   bench  marking   TEMPEST
          Certified equipment.  This does not  solve the problem.  The
          question  arises:  how   much  radiation  at   a  particular
          frequency  is compromising?  The  current answer is to refer
          to NACSIM  5100A.   This document  specifies the  emanations
          levels suitable  for Certification.   The  document is  only
          available  to United  States  contractors having  sufficient
          security  clearance  and  an  ongoing  contract  to  produce
          TEMPEST Certified computers  for the  government.   Further,
          the correct levels are specified by the NSA and there  is no
          assurance that, while these levels are sufficient to prevent
          eavesdropping by unfriendly operatives,  equipment certified
          under NACSIM  5100A will have  levels low enough  to prevent
          eavesdropping by the NSA itself.
               The  accessibility  of  supposedly  correct  emanations
          levels  does  not solve  the  problem of  preventing TEMPEST
          eavesdropping.     Access   to  NACSIM   5100A   limits  the
          manufacturer to selling the equipment  only to United States
          governmental  agencies  with  the  need  to  process  secret
          information.[33]  Without  the right to possess  TEMPEST ELINT
          equipment  manufacturers  who  wish to  sell  to  the public
          sector cannot determine what a  safe level of emanations is.
          Further  those  manufacturers with  access  to  NACSIM 5100A
          should  want  to  verify that  the  levels  set  out in  the
          document are, in  fact, low enough to  prevent interception.
          Without an actual  eavesdropping device with which  to test,
          no   manufacturer  will   be   able  to   produce  genuinely
          uncompromising equipment.

PERRY, now I put up, now YOU SHUT UP!

sheesh.

treason at gnu.





From yanek at novavax.nova.edu  Thu Dec 17 10:34:01 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 10:34:01 PST
Subject: TEMPEST not restricted
In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu>
Message-ID: <9212171833.AA11371@novavax.nova.edu>


"Treason" writes:

> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  
[...]
> PERRY, now I put up, now YOU SHUT UP!
> sheesh.
> treason at gnu.

The article you posted is at least 3 years old, if not older.  I have not
checked on the legal references quote in the article, but I called up
Wayne Martin of Lindgren RF Enclosures, and asked him about this.  He
said that he was not restricted to selling TEMPEST equipment to military
or government only, and suggested that if I am looking for TEMPEST-compliant
computers, I should call up a computer manufacturer like IBM or Digital,
and they would be able to sell such systems to me.

Maybe things have changed in the last three years since the article was 
written, or maybe it was incorrect to begin with.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From tcmay at netcom.com  Thu Dec 17 11:04:13 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 11:04:13 PST
Subject: TEMPEST not restricted
In-Reply-To: <9212171833.AA11371@novavax.nova.edu>
Message-ID: <9212171902.AA05048@netcom.netcom.com>


Yanek Martinson makes some very good points about the legality of
TEMPEST:

> "Treason" writes:
> 
> > Here is parts of the article I posted regarding the legality of the use
> > of emf shielding.  
> [...]
> > PERRY, now I put up, now YOU SHUT UP!
> > sheesh.
> > treason at gnu.
> 
> The article you posted is at least 3 years old, if not older.  I have not
> checked on the legal references quote in the article, but I called up
> Wayne Martin of Lindgren RF Enclosures, and asked him about this.  He
> said that he was not restricted to selling TEMPEST equipment to military
> or government only, and suggested that if I am looking for TEMPEST-compliant
> computers, I should call up a computer manufacturer like IBM or Digital,
> and they would be able to sell such systems to me.
> 
> Maybe things have changed in the last three years since the article was 
> written, or maybe it was incorrect to begin with.  

Thanks, Yanek!

And could I suggest to all of us that we be very careful in the
language we use when disagreeing with others? "Treason's" demand that
Perry now "SHUT UP" is intemperate and counterproductive.

Our list is not moderated, that is, there is no censor or moderator
holding people back when they feel the temptation to spew bile all
over the list. With hundred of folks now on this list, great care must
be taken.

Sorry to waste list bandwidth on this point of list etiquette.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From wendtj at jplpost.Jpl.Nasa.Gov  Thu Dec 17 11:10:49 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Thu, 17 Dec 92 11:10:49 PST
Subject: New number for Secure Systems & Services
Message-ID: <9211177246.AA724619264@jplpost.jpl.nasa.gov>


          The new number for SS&S is (214) 907-9288
          Also, Lindgren RF Enclosures informed me that they
          now have exclusive license to market International Paper
          Company's SAF'N SHIELDED; and they give free samples ;-))

          JPW





From tytso at ATHENA.MIT.EDU  Thu Dec 17 11:19:50 1992
From: tytso at ATHENA.MIT.EDU (Theodore Ts'o)
Date: Thu, 17 Dec 92 11:19:50 PST
Subject: 
In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu>
Message-ID: <9212171919.AA27449@tsx-11.MIT.EDU>


   Date: Thu, 17 Dec 92 12:38:34 -0500
   From: treason at gnu.ai.mit.edu
   Apparently-To: cypherpunks at toad.com

   Here is parts of the article I posted regarding the legality of the use
   of emf shielding.  Read it carefully, and I suggest you also read the
   posted document in full as well.  

We have read it carefully.  What your article claims is that NACSIM
5100A is classified, so if something is built to be TEMPEST certified,
the design is classified, and the actual device can not be sold to the
public, in order to prevent reverse-engineering of the standard.

This, however, does not mean that emf shielding is illegal.  How to do
emf shielding is relatively well understood --- what is classified is
how much shielding is enough.  As your article itself admits, having the
the NACSIM standard isn't very useful anyway, since we can't trust the
levels promulgated by the NSA to be sufficient to prevent them from
listening in.  (What you're saying would be like saying that the NSA has
a classified recommendation that RSA keys be at least XXX bits long ---
just because the recommendation is classified doesn't mean that we can't
use RSA, and if the number of bits were something like 512 bits, if we
found out what it was, we'd probably want to use something bigger
anyway.  :-)

As many other people have pointed out, emf shielding can't be illegal,
since it's required for FCC requirements.  If someone wants to spend
additional money, and put a lot more shielding that what's really
needed, there shouldn't be any problem with that.

Finally, I'm not sure about the complete accuracy of that article you've
posted.  We have one of the first BBN Safekeeper (tm) boxes at MIT,
which is a certificate meter which generates X.509 public key
certificates for use in the Privacy Enhanced Mail (PEM) system.  It *IS*
TEMPEST shielded(*) and BBN is planning on selling it to commercial
companies, TEMPEST shielding and all.  Therefore, I suspect that the
information in that article may be out of date.

   PERRY, now I put up, now YOU SHUT UP!

There's no need to be rude --- especially when you're wrong and can't
even interpret the article which you yourself posted.

						- Ted

(*) There is an amusing story about what happened when they took it to
get it certified as a FCC Class A computing device (which they needed to
do since they were planning on selling it commercially); the FCC tester
kept bringing his testing device closer, and closer, and closer to the
Safekeeper(tm), and when he was finally on top of it, he tapped his
meter and asked: ``Are you sure this is turned on?''  As the story was
told to me, the designer of the box was there for the testing, and this
was one of his prouder moments.  :-)





From yanek at novavax.nova.edu  Thu Dec 17 11:38:00 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 11:38:00 PST
Subject: New number for Secure Systems & Services
In-Reply-To: <9211177246.AA724619264@jplpost.jpl.nasa.gov>
Message-ID: <9212171936.AA14894@novavax.nova.edu>


>           The new number for SS&S is (214) 907-9288

I just called them on the old number earlier today, and they answered.
Maybe they have call forwarding.

>           Also, Lindgren RF Enclosures informed me that they
>           now have exclusive license to market International Paper
>           Company's SAF'N SHIELDED;

Makes some sense.  Someone looking for RF shielding is more likely
to buy it from someone named Lindgren RF Enclosures than from a
paper company.

> and they give free samples ;-))

Great.  Now does anyone know of where to get equipment to test how
effective it is?  






From rchilder at us.oracle.com  Thu Dec 17 12:45:34 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Thu, 17 Dec 92 12:45:34 PST
Subject: New number for Secure Systems & Services
Message-ID: <9212172044.AA04823@rchilder.us.oracle.com>



> and they give free samples ;-))

"Great.  Now does anyone know of where to get equipment to test how
 effective it is?  "

I'd guess that virtually any hardware lab that has to test its equipment
to make sure it meets FCC criteria for minimal emissions, would have a
test lab onsite.

Such a test lab normally consists of the following :

	- a very wide frequency range analyzer ( HP makes these )
	- a set of antennas by which to sample the EMF field(s)
	- a platform adjacent to the antenna mount, upon which
		such equipment as is being tested, is rotated,
		to allow the antenna to sample the entire 360-
		-degree field at incremented altitudes and var-
		-iable angles in incidence.

Those test labs I've been acquainted with are usually found at a distance
from production facilities, usually small outbuildings in fields out back,
insulated by distance from the EMF of the surrounding buildings. I can see
how this paper might make it possible to move the lab back indoors ...

To answer your question specifically, I'd check a HP electronic test products
catalog, with an emphasis on signal/frequency/harmonic analyzers.


-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."






From wendtj at jplpost.Jpl.Nasa.Gov  Thu Dec 17 12:50:22 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Thu, 17 Dec 92 12:50:22 PST
Subject: SS&S response to TEMPEST inf0 request
Message-ID: <9211177246.AA724625237@jplpost.jpl.nasa.gov>


          About 30 minutes after I got off the phone requesting
          product information and related materials, I recieved a
          voice mail message from Ray Helsop of SS&S.  When I
          returned his call, he informed me that the address that I
          gave looked like a residential address (Hmmm), and that they
          usually don't send information to private homes, apts,
          bird-baths, e.t.c.

          He then informed me that he had called my employer
          (the Junior Proletarian Laboratory), and varified my name in
          the directory, and the department that I worked in; and that
          since I work for a Federal Research Facility (DoD sinkhole)
          everything was `ok'.

          He then proceded to tell me about foreigners calling the
          company requesting TEMPEST information, and other "spooky"
          callers, and that it was now allright to send the
          product information to my home.

          After I told him my interests in the hardware, he ran down
          a list of avilable equipment, and asked about numbers,
          requirements, and said he'd send it right out to me.

          I hate to be presumptuous... but I think an "I'm trying to
          protect my personal computer from prying eyes" would fall on
          very deaf ears at SS&S, and I'll leave it at that. ;-)

          JPW





From pmetzger at shearson.com  Thu Dec 17 12:53:31 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Thu, 17 Dec 92 12:53:31 PST
Subject: No Subject
Message-ID: <9212171925.AA04923@maggie.shearson.com>


Close, but no cigar, Mr. "Treason". Anyone reading your "proof" can see
for themselves that there is no law making it illegal to shield your computers,
only some regulations on people that sell equipment to the government can't
tell other people what their specifications are. Big deal.

The line in the article saying 
          Without  the right to possess  TEMPEST ELINT
          equipment  manufacturers  who  wish to  sell  to  the public
          sector cannot determine what a  safe level of emanations is.
is mostly bull, in the sense that people can probably judge what is safe
without knowing the government standards. In any case, you have demonstrated
nothing making it illegal to shield your computers, and we've already seen
a post containing a dozen purveyors of shielding equipment. Repeating,
you don't know what you are talking about. Now go away.

Perry

Original message included for reference:


> From cypherpunks-request at toad.com Thu Dec 17 14:13:11 1992
> Date: Thu, 17 Dec 92 12:38:34 -0500
> From: treason at gnu.ai.mit.edu
> Content-Length: 3194
> 
> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  Read it carefully, and I suggest you also read the
> posted document in full as well.  This poses many problems to the public
> in general, and the private sector in specific.
> PERRY, I suggest you read this.              
>  
>                NACSIM 5100A is  classified, as are all  details of TEMPEST.
>           To  obtain  access to  it, contractor  must  prove that  there is
>           demand within  the government for the specific  type of equipment
>           that intend to  certify.  Since  the standard is classified,  the
>           contractors can not sell the equipment to non-secure governmental
>           agencies or the public.  This prevents reverse engineering of the
>           standard  for its physical  embodiment, the  Certified equipment.
>           By  preventing  the   private  sector  from  owning   this  anti-
>           eavesdropping equipment,  the NSA has  effectively prevented  the
>           them from protecting the information in their computers. 
>                A number of  companies produce  devices to measure  the
>           emanations from electrical equipment.  Some of these devices
>           are  specifically   designed  for   bench  marking   TEMPEST
>           Certified equipment.  This does not  solve the problem.  The
>           question  arises:  how   much  radiation  at   a  particular
>           frequency  is compromising?  The  current answer is to refer
>           to NACSIM  5100A.   This document  specifies the  emanations
>           levels suitable  for Certification.   The  document is  only
>           available  to United  States  contractors having  sufficient
>           security  clearance  and  an  ongoing  contract  to  produce
>           TEMPEST Certified computers  for the  government.   Further,
>           the correct levels are specified by the NSA and there  is no
>           assurance that, while these levels are sufficient to prevent
>           eavesdropping by unfriendly operatives,  equipment certified
>           under NACSIM  5100A will have  levels low enough  to prevent
>           eavesdropping by the NSA itself.
>                The  accessibility  of  supposedly  correct  emanations
>           levels  does  not solve  the  problem of  preventing TEMPEST
>           eavesdropping.     Access   to  NACSIM   5100A   limits  the
>           manufacturer to selling the equipment  only to United States
>           governmental  agencies  with  the  need  to  process  secret
>           information.[33]  Without  the right to possess  TEMPEST ELINT
>           equipment  manufacturers  who  wish to  sell  to  the public
>           sector cannot determine what a  safe level of emanations is.
>           Further  those  manufacturers with  access  to  NACSIM 5100A
>           should  want  to  verify that  the  levels  set  out in  the
>           document are, in  fact, low enough to  prevent interception.
>           Without an actual  eavesdropping device with which  to test,
>           no   manufacturer  will   be   able  to   produce  genuinely
>           uncompromising equipment.
> 
> PERRY, now I put up, now YOU SHUT UP!
> 
> sheesh.
> 
> treason at gnu.
> 





From dclunie at pax.tpa.com.AU  Thu Dec 17 13:22:55 1992
From: dclunie at pax.tpa.com.AU (David Clunie)
Date: Thu, 17 Dec 92 13:22:55 PST
Subject: No Subject
Message-ID: <9212172122.AA00432@britt>


> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  Read it carefully, and I suggest you also read the
> posted document in full as well.  This poses many problems to the public
> in general, and the private sector in specific.
> PERRY, I suggest you read this.              
>  
>                NACSIM 5100A is  classified, as are all  details of TEMPEST.


The information may be classified, as perhaps it should be. If I were an
organization of any kind trying to protect my data I wouldn't run around
publicizing the details of the technology required to protect it either.

This does not mean though, that it is illegal to reinvent the wheel and
apply it yourself.

Besides, who is to say what is an "acceptable" level of EM radiation - the
government has clearly chosen what it considers acceptable levels to
facilitate equipment supply by contractors.

If you want more or less protection then you and any other member of the
public are free to define, manufacture or purchase whatever you want.

And if you can't get it from a local source I am sure there are plenty of
governments and manufacturers elsewhere in the world you can deal with,
though of course exporting the technology may be another matter, but there
is nothing new about that.

There are plenty of other government conspiracies to focus on ! This one
seems a bit lame.

david






From warlord at MIT.EDU  Thu Dec 17 13:38:49 1992
From: warlord at MIT.EDU (Derek Atkins)
Date: Thu, 17 Dec 92 13:38:49 PST
Subject: No Subject
In-Reply-To: <9212172122.AA00432@britt>
Message-ID: <9212172137.AA04528@deathtongue.MIT.EDU>


> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
apply it yourself.  In the US it is called "Patent Infringement".
Now, this may not apply to EVERYTHING, but there are cases where
people re-invented something that was classified and their work then
became classified....

(I also believe there are stories where the opposite is true, but I
don't want to belabor the point)







From warlord at MIT.EDU  Thu Dec 17 13:38:54 1992
From: warlord at MIT.EDU (Derek Atkins)
Date: Thu, 17 Dec 92 13:38:54 PST
Subject: No Subject
In-Reply-To: <9212172122.AA00432@britt>
Message-ID: <9212172137.AA04531@deathtongue.MIT.EDU>


> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
apply it yourself.  In the US it is called "Patent Infringement".
Now, this may not apply to EVERYTHING, but there are cases where
people re-invented something that was classified and their work then
became classified....

(I also believe there are stories where the opposite is true, but I
don't want to belabor the point)

-derek





From norm at xanadu.com  Thu Dec 17 13:51:15 1992
From: norm at xanadu.com (Norm Hardy)
Date: Thu, 17 Dec 92 13:51:15 PST
Subject: TEMPEST not restricted
Message-ID: <9212172053.AA26480@xanadu.xanadu.com>


While taxpayers paid for TEMPEST and NACSIM 5100A and it would undoubtedly
be useful to taxpayers were it declassified, it is not true
that compliance with NACSIM 5100A is necessary and sufficient to
be secure from eavesdropping. Some of RSA's charm is that it was not
promulgated by NSA!





From yanek at novavax.nova.edu  Thu Dec 17 13:53:18 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 13:53:18 PST
Subject: 1st dc-net works!
Message-ID: <9212172152.AA20073@novavax.nova.edu>


Finally, I got a dc-net working.  It is now quite primitive, and useful
only as a proof of concept.  It does not yet do any key management, I
just copied the binaries of several unix utilities to be used as one
time pads.  The reservation system does not work yet.  If there is a 
message to be sent, it is sent immediately.  That means only one
of the participants can send a message in one round.  The messages
are not forwarded anywhere, they are just dropped to "outgoing" 
directory.  

It runs on one machine, under three accounts I created just for that 
purpose.  The mail keeps going back and forth constantly between the
three accounts, with null files being deposited to the outgoing
directories.  

Temporary files are being created and deleted.

As soon as I put a file in one of the incoming directories, within one
round it appears in each of the outgoing directories.

So the main function works.

It is written in perl, because of the ease I can manipulate binary data
of any size.

As soon as I add the minimal necessary features (PGP based key exchange,
and reservation blocks) I will be looking for some people to participate
in an experimental dc-net.  People who want to participate in this, should
have fast, reliable, e-mail connections (preferably round-trip time
to any other participant should be less than 10 minutes).  If even one
participant has a slow link, it will hold everyone up.  You also need
the ability to pipe incoming mail with a certain subject header through
an arbitrary program.  You can use any of the various 'slocal' programs,
or you could use elm's filter program, or any other means.  You also need
to have perl working on your system.  You need PGP.  

As someone suggested, an arbitrary group of people might not have much
to talk about amongst themselves, so the next feature will be forwarding
to a mailing address (or list), a newsgroup, or another dc-net.  It is
very simple to do the forwarding, it is a little more complicated,
and interesting, to decide who will do the forwarding.  I would not
want to rely on any single site serving as a gateway, since that
would introduce a single point of compromise.  I would rather have
some dynamic system, similar to the reservation blocks, that would
let the net randomly decide who will forward a particular message.

As soon as this first test network has run for a couple of days, and all
the bugs are fixed, I will release the code, so that anybody can work
on it.  I expect that some people will work on various projects I mentioned
in the "FUTURE ENCHANCEMENTS" section of my initial posting on this
topic.  I hope that people who add features to the system send the mods
back to me, so I can incorporate them in a new version.

When there is a number of networks running, it will be interesting to
experiment with hierarchical nets, or linked networks of networks.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From rchilder at us.oracle.com  Thu Dec 17 14:12:48 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Thu, 17 Dec 92 14:12:48 PST
Subject: Patent Infringement
Message-ID: <9212172211.AA05449@rchilder.us.oracle.com>



> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

"I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
 apply it yourself.  In the US it is called "Patent Infringement"."

Only if you attempt to sell it ...


-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."





From yanek at novavax.nova.edu  Thu Dec 17 14:55:51 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 14:55:51 PST
Subject: enabling technologies
In-Reply-To: <9212172233.AA06614@netcom.netcom.com>
Message-ID: <9212172254.AA21668@novavax.nova.edu>


> I'm amazed at the progress everybody's making on so many fronts.
> 
> --Tim

What we are witnessing (and participating in) here is the synergy of 
enabling technologies.  The availability of quality free software
such as perl, and C compilers makes it easy to quickly build useful
tools.  These can then be combined in various ways, without re-inventing
them.  For example, I do not need to reinvent the strong-pseudorandom
function, I can just "borrow" it from the PGP code.  I do not need to
write a public key system just to distribute seeds for the dc-net 
one-time pads system, I can use PGP.  I don't need to write a program
to take chunks of data and xor them together, perl has this capability.

I just design a system, and put it together from existing blocks.  This
is the reality of what the OOP "building-blocks" people are talking about.

And the important method is not object-oriented anything, but free
software, with source code, and cooperation of people widely separated
in time and space, some even anonymous, all linked through the nets.

My dc-net system will make life easier for people that are doing digital
cash, by providing a ready means of sending untraceable messages.

Many useful systems can be built on top of a working digital cash system.

All this is catalysed by the existence of this mailing list.  For example
I got the idea of reservation blocks from ILF's post of Chaum's article.

That was made possible by the anonymous remailers.

The anonymous remailers can be made more anonymous by linking then into
a dc-net.

There's a positive feedback loop developing here.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From yanek at novavax.nova.edu  Thu Dec 17 15:00:07 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 15:00:07 PST
Subject: Patent Infringement
In-Reply-To: <9212172211.AA05449@rchilder.us.oracle.com>
Message-ID: <9212172259.AA21750@novavax.nova.edu>


> "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
>  apply it yourself.  In the US it is called "Patent Infringement"."
> 
> Only if you attempt to sell it ...

No.  The patent law prohibits anyone from "making, using, or selling" 
anything covered under the patent.  Selling it makes it more likely
that the patent holder will come after you, as they have a greater
chance of getting some money from you.

I am not a lawyer, I am sure someone here can explain all this in
greater detail, or correct me if I'm wrong.






From UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU  Thu Dec 17 15:33:28 1992
From: UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU (UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU)
Date: Thu, 17 Dec 92 15:33:28 PST
Subject: abusing the system?
Message-ID: <9212172333.AA12866@toad.com>


Hiya,
        One of the newsgroups I was reading have this persistant "tester" who
uses the anon service in Finland.  Anyway, there were several different
postings, all with different ids, but same kinds of "this is a test, nyah nyah"
contents.
        As I was one of those "stop it" people, and seeing more of the same
bullshit by that guy, I got slightly pissed off, and started thinking.  Already
that person is using about 3 different anonymous ids.  If he is introduced to
the remailers here, conceivably he could generate more anonymous ids for
himself (ie, kill files won't work then, unless you want to kill a whole site)
by routing his mail thru the remailers.  Each remailer would give him another
userid at that anon service.  And if he uses it to loop back to the
remailers...  And then loop to that Australian anon service... and so on.  He
could "legitimately" have a hundred or so different anon_ids, from one original
userid.
        What if someone who realises this was to use that capability to post
some really "colorful" material to news?  Suddenly you have a hundred or so
weirdos posting "I want nude pictures of a gerbil, please" to alt.binaries.
pictures.erotica... you get the idea.  Is there anyway to stop this from
happening?  And this is on top of the real weirdos (ie, those who know how to
post anonymously, like most of the readers of this list... :))
        So far, the net has functioned as it's own sieve with regards to the
"weirdos" but if the remailers is generally available (as it should be!), the
potential for abuse is much much greater.  Any way to slow it down?  "Hey,
look, a flame war, let's join in..."
        Of course, if someone was to forge a mail to the anon service... don't
even need to know about the remailers...  but with forged mail, the anon
service can at least "check" to see the validity of your address.
        I realise that this is probably not important in the overall scheme of
things... but I am curious about what can be done to reduce such potential
abuse.
        Ciao.

-Tai
ps:  Any tips on tracing anonymous mail and newspostings?  I mean beyond the
"from" and "path" things... ie, trace to the userid...  Someone tried to forge
a posting in my name... (yes, that's what got me thinking :))





From ncselxsi!drzaphod at ncselxsi.netcom.com  Thu Dec 17 15:42:43 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod)
Date: Thu, 17 Dec 92 15:42:43 PST
Subject: Treason's bile spewing
Message-ID: <44511.drzaphod@ncselxsi>


In Message Thu, 17 Dec 92 11:02:42 PST,
  netcom!tcmay at netcomsv.netcom.com (Timothy C. May) writes:

>Our list is not moderated, that is, there is no censor or moderator
>holding people back when they feel the temptation to spew bile all
>over the list. With hundred of folks now on this list, great care must
>be taken.
>
>Sorry to waste list bandwidth on this point of list etiquette.
>
>--Tim

Well said Tim.  Treason's posts, for the past week, have been like the
rantings of a third grader.  I'm just glad some people on this list have the
resources to prove him wrong.

Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
room.. maybe enuf for a workstation and misc. accessories.  |-]

TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized





From Doug.Brightwell at Corp.Sun.COM  Thu Dec 17 15:48:52 1992
From: Doug.Brightwell at Corp.Sun.COM (Doug Brightwell)
Date: Thu, 17 Dec 92 15:48:52 PST
Subject: TEMPEST Question
Message-ID: <9212172348.AA01767@media.Corp.Sun.COM>



Am I correct in understanding that what's actually detected and
reconstructed by TEMPEST surveillance is the EMR having to do with
screen drawing, and not the CPU and other internal components involved
in processing data?

If that's the case, would computers without CRT-type displays still be
succeptible to TEMPEST surveillance? Such as headless servers that
might be running a BBS without a video card inside or a monitor. Or
laptops, such as a Mac PowerBook with an active-matrix screen?

Thanks,
Doug




From eichin at cygnus.com  Thu Dec 17 15:59:41 1992
From: eichin at cygnus.com (Mark W. Eichin)
Date: Thu, 17 Dec 92 15:59:41 PST
Subject: abusing the system?
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212172358.AA07292@tweedledumber.cygnus.com>


>> ps:  Any tips on tracing anonymous mail and newspostings?  I mean beyond the
>> "from" and "path" things... ie, trace to the userid...  Someone tried to forge
>> a posting in my name... (yes, that's what got me thinking :))
	Remember to look at the "Message-Id" -- on typical unix
mailers, that has the IP address encoded into it to help make it more
"unique". 
	A social point to keep in mind, though: one reason we really
*need* signed messages is because there is no real identity attached
to email. It is easy to "believe in" some identity you see on the net,
and for the most part enough of them are real that it is ok... but
I expect this to become even more of a problem than it is now without
signatures.
	A "historical" example -- at MIT, as part of Project Athena,
we have a real-time messaging system called Zephyr (for more details,
look in Usenix proceedings from some time in 87 or 88, or just look at
athena-dist.mit.edu:pub/usenix/zephyr.PS.) It optionally uses kerberos
authentication, and the recipient application will display whether a
message is authenticated or unauthenticated. People tended to ignore
this, until one of the other developers wrote a program that looked at
the database of current users, picked a pair at random, picked a
message at random, and sent it to one, from the other. (It backfired
amusingly once -- it sent a message from him, to me, saying "I'm
stopping at the coffeehouse, want me to get you anything?" to which I
responded sure... and then harassed him about it for years, until he
finally *did* bring me the M&M's I wanted. :-)
	The point was that this program didn't fake the authentication
(it did use privileged access to look at the user database, which is
not available remotely, but the messages themselves were
unauthenticated) but rather noone paid attention to it. The
"unauthenticated" flag was made more visible in a later release, I
believe... but I don't think anyone ever went as far as refusing
unauthenticated personal messages altogether. I could see that
happenning with email...
				_Mark_ <eichin at athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin at cygnus.com>






From eichin at cygnus.com  Thu Dec 17 16:09:11 1992
From: eichin at cygnus.com (Mark W. Eichin)
Date: Thu, 17 Dec 92 16:09:11 PST
Subject: TEMPEST pricing
In-Reply-To: <44511.drzaphod@ncselxsi>
Message-ID: <9212180008.AA07304@tweedledumber.cygnus.com>


>> Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
>> room.. maybe enuf for a workstation and misc. accessories.  |-]
	I don't know about an entire room, but I seem to recall that
Sun has TEMPESTed workstations on the GPO pricelist, as do other
companies... and that a few years ago TEMPESTed PC's (286 boxes)
*started* around $10K. Most of this was because of the limited market
-- I doubt you'll find a mass-market PC that hasn't skimped as much as
possible on the RF shielding if it was cost effective (BYTE, Oct. or
Nov., or maybe the laptop issue, mentions Apple switching from
sprayed-on metallic paint on the inside of their cases to sheet-metal
liners because it ended up being significantly less expensive.) Given
the lack of a large-volume market to produce economies of scale, you'd
expect the prices for TEMPESTed hardware to stay high.
	Over at MIT, in building 20, there's a room that is entirely
RF shielded (built in place, years ago...) I don't know the story
behind it, I don't know if the shielding is even maintained any more,
it is decades old. It's now random lab-space...
							_Mark_





From tcmay at netcom.com  Thu Dec 17 16:23:45 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 16:23:45 PST
Subject: Faraday Cages
In-Reply-To: <44511.drzaphod@ncselxsi>
Message-ID: <9212180022.AA21357@netcom.netcom.com>



> Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
> room.. maybe enuf for a workstation and misc. accessories.  |-]
> 
> TTFN!
> 
> DrZaphod

The usual, and cheaper, approach is to shield a computer or
workstation. This is the approach discussed in the last several days
here.

Shielding a room is common is certain applications, such as at NSA
(where the entire windowless building is so shielded), in component
testing labs, and so on. Such rooms are called Faraday cages.

It so happens that in 1972 I worked inside such a Faraday cage (in the
labs at UCSB of then-young Paul Hansma, now famous in the nanotech
community for his AFM imaging of cells and other biological
materials). The shield consisted of copper screen mesh
(fine-pitch...perhaps .5 mm gaps) mounted on a wooden frame, with 2
layers and an air gap between them. 

Attenuation depends on frequency, of course, and a wire mesh screen
lets through some frequencies (light, for example!). How many dbs of
attenuation at "frequencies of interest" depends on a lot of factors.
Extremely high frequency signals, becoming more common in computers as
processor speeds exceed 50 MHz, are very hard to shield, due to the
short wavelengths.

I suspect if the boys in the antenna-equipped vans are parked outside
your home, nearly any leakage is too much. But there are cheaper ways
for your secrets to be learned. In other words, there are more
pressing concerns.

I would estimate that shielding an entire room would be expensive,
perhaps costing $5K or more ot do a good job. Building a smaller
room-within-a-room might cost a little less.

Listening to a radio is one very crude way of monitoring your own
RF emissions, if you don't have access to specialized gear.

Using a laptop helps. (I have an old GRiD Compass, with plasma
display, bubble memory, and a black magnesium case...it is definitely
less RF-noisy than my PowerBook, and a lot less noisy than my IIci.)

(Perhaps Phil Karn can comment on strategies)

BTW, we've talked about setting up our own "van Eyck radiation"
systems to see just how easy it is to monitor computers. There is a
legend, possibly urban, that the NSA did indeed try to block
publication of papers on the "van Eyck" effect. This fits part of what
"Treason" was saying, though not all of it. (And there is no law
saying you can't try to shield your computers, or speak in a low
voice, for that matter.)

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From yanek at novavax.nova.edu  Thu Dec 17 16:28:15 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 16:28:15 PST
Subject: TEMPEST Question
In-Reply-To: <9212172348.AA01767@media.Corp.Sun.COM>
Message-ID: <9212180027.AA24433@novavax.nova.edu>


> Am I correct in understanding that what's actually detected and
> reconstructed by TEMPEST surveillance is the EMR having to do with
> screen drawing, and not the CPU and other internal components involved
> in processing data?

Cpu signal is the easiest to detect, but not the only one.  Other possible
sources of emissions are all kinds of communications cables.  Unshielded
RS-232 to the modem, possibly even the connections to the disk drives.

I don't think the cpu itself emits much or if it does that it is easy
to interpret it in any easy way, but I don't know for sure.

The monitors are just easiest to detect, since for every pixel, the
electron beam is turned on and off.  These pulses are easy to detect, 
and if your monitor is synchronized with the target, a simple device
could reconstruct the image, without any need for powerful computers
to process the data.

> If that's the case, would computers without CRT-type displays still be
> succeptible to TEMPEST surveillance? 

It would be safe to say that they would be _less_susceptible_.

> might be running a BBS without a video card inside or a monitor. Or
> laptops, such as a Mac PowerBook with an active-matrix screen?

Anyone that knows NSA's capabilities in these areas certainly isn't
talking.  It _may_ be possible to derive at some limits just by
knowing electronics and the laws of physics.  I don't know of any 
independent research team having done such a study.  If it has been
done, or is being done, I would like to know.







From tcmay at netcom.com  Thu Dec 17 16:36:15 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 16:36:15 PST
Subject: The Need for Positive Repuations
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212180034.AA23003@netcom.netcom.com>



Tai (UFLTAI at MEMSTVX1.bitnet) asks about how best to stop people from
generating many, many digital pseuodonyms, thus evading filtering by
"Kill" files. Lots of issues here.

The longterm solution is to use "positive reputations" and not just
"negative reputations" (as in Kill files). This is something Dean
Tribble just talked about at our last physical meeting of the
Cypherpunks ("Bay Area Branch" :-} ).

Think of like a credit rating. People _earn_ trust, they don't just
get assigned a credit rating until they do something bad. 

Positive reputation filtering will still allow digital pseudonyms, but
a reputation will be attached and will be important. Read Vinge's
"True Names" for some insights on this.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From yanek at novavax.nova.edu  Thu Dec 17 17:23:42 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 17:23:42 PST
Subject: my mistake (re: TEMPEST)
In-Reply-To: <9212180027.AA24433@novavax.nova.edu>
Message-ID: <9212180122.AA26838@novavax.nova.edu>


> > reconstructed by TEMPEST surveillance is the EMR having to do with
> > screen drawing, and not the CPU and other internal components involved
> 
> Cpu signal is the easiest to detect, but not the only one.  Other possible

Sorry, I meant "display signal". 






From Doug.Brightwell at Corp.Sun.COM  Thu Dec 17 17:27:21 1992
From: Doug.Brightwell at Corp.Sun.COM (Doug Brightwell)
Date: Thu, 17 Dec 92 17:27:21 PST
Subject: TEMPEST Question
Message-ID: <9212180126.AA01855@media.Corp.Sun.COM>


	>> Cpu signal is the easiest to detect, but not the only
	>> one.  Other possible sources of emissions are all
	>> kinds of communications cables.  Unshielded RS-232 to
	>> the modem, possibly even the connections to the disk
	>> drives.

Synching up to monitor signals, I can understand.

But as a non-technical person, what I'm struggling to understand is how
a surveillance team could monitor the emmisions from such cables and
have any clue as to what they are. Let's say they zeroed in on my
poorly shielded modem cable and were able to tune into a stream of 0's
and 1's. How could they then resolve that digital data into anything
meaningful? It could be one of any number of documents created by one
of any number of programs on one of any number of platforms. How do the
spies know they're dealing with a Frame page layout document created on
a Sun workstation versus a spreadsheet created on a Mac?

Even if it's just a plain text file how could the surveillance team
read it? Does each member of the ASCII character set have specific and
identifiable radiation signatures? For example, does the letter "k" as
it passes through my modem cable have a characteristic EMR that is the
same for all machines?

Sorry if this query is too basic, but I would appreciate any enlightenment...

Doug




From rchilder at us.oracle.com  Thu Dec 17 17:38:36 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Thu, 17 Dec 92 17:38:36 PST
Subject: Treason's bile spewing
Message-ID: <9212180136.AA06221@rchilder.us.oracle.com>



"Treason's posts, for the past week, have been like the rantings of a
 third grader."

This is in itself rather derogatory and does nothing to quell the flames.

"I'm glad some people on this list have the resources to prove him wrong."

I suspect the gentleman in question was not displeased to learn something
new, and, by contributing material that _was_ a few years out of sync, he
was not trying to lower the quality of the discussion ... or dominate it
... he was trying to contribute.

Easy does it, folks.


-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."





From tribble at xanadu.com  Thu Dec 17 17:40:08 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Thu, 17 Dec 92 17:40:08 PST
Subject: abusing the system?
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212180105.AA28598@xanadu.xanadu.com>


	 Date: Thu, 17 Dec 92 17:33 CDT
	 From: uunet!CUNYVM.CUNY.EDU!UFLTAI%MEMSTVX1.bitnet
	 X-Vms-To: IN%"cypherpunks at toad.com"

					 I realise that this is probably not important in the overall scheme of
	 things... but I am curious about what can be done to reduce such potential
	 abuse.

You will be happy to know that solving that problem will be extremely
important (probably even in the short term).  We need a positive
reputation system (kill files filter against negative reputations) so
that you only see mail messages by people who have a reputation for
valuable postings.

I rambled about this topic at the last cypherpunks meeting.  I will be
posting my notes in an effort to get feedback and organizational help
from the people on the list (it will be a few days, however).

The content will eventually be organized into something that I hope
will spread.

dean





From strat at intercon.com  Thu Dec 17 18:03:16 1992
From: strat at intercon.com (Bob Stratton)
Date: Thu, 17 Dec 92 18:03:16 PST
Subject: TEMPEST Question
In-Reply-To: <9212180126.AA01855@media.Corp.Sun.COM>
Message-ID: <9212180202.AA21476@intercon.com>


>>>>> Doug.Brightwell at corp.sun.com (Doug Brightwell) writes:

	Doug> But as a non-technical person, what I'm struggling to
	Doug> understand is how a surveillance team could monitor the
	Doug> emmisions from such cables and have any clue as to what
	Doug> they are. Let's say they zeroed in on my poorly shielded
	Doug> modem cable and were able to tune into a stream of 0's
	Doug> and 1's. How could they then resolve that digital data
	Doug> into anything meaningful? ...

My understanding, being only a moderate RF weenie, is that UARTs, the
devices which, more often than not, are driving your serial ports,
generate an emission very much like good old frequency shift keying.
It makes sense - having listened to computers on radios before. Think
in terms of sound first, as it's easier. A given sound represents a
"1", and another tone is "0". You waver back and forth between the
tones to describe the data you're transmitting. 

The idea is that some of the normal emission characteristics from
components in computers (like UARTs) correspond to this sort of
modulation. 

With regard to machine types, if it's a serial line, it's fairly easy
to map the communications into a set of probably protocol suites. If
you know *anything* about the use of the machine, it becomes a lot
easier. For instance, given an intercept of TCP/IP traffic over a SLIP
line, I could probably reconstruct a TELNET session log, but it's
nowhere as easy as just reading a terminal session on a link to some
BBS.

	Doug> Even if it's just a plain text file how could the
	Doug> surveillance team read it? Does each member of the ASCII
	Doug> character set have specific and identifiable radiation
	Doug> signatures? For example, does the letter "k" as it
	Doug> passes through my modem cable have a characteristic EMR
	Doug> that is the same for all machines?

You might also think in terms of things other than screens and modem
cables. For instance, many keyboards emit RF as they are used. It's
not irrational to suspect that these emissions might be tied in some
way to the use of the keyboard - I have an old FCC Class A Wyse
terminal that sounds different depending on which keys I hit. Since we
know that every piece of equipment has a uniquely identifiable (even
compared to other units of the same type) emission signature, it's not
too outlandish to expect that different key encodings in a keyboard
might generate different emission patterns.

	Doug> Sorry if this query is too basic, but I would appreciate
	Doug> any enlightenment...

It's weird stuff, and some people would rather not have the world
learning how to do this. In fact, Van Eck's original article is known
to have some deliberate misinformation in it, as the author didn't
want to make it "too easy" to learn how to do this kind of ELINT.


--Strat






From yanek at novavax.nova.edu  Thu Dec 17 18:14:38 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 18:14:38 PST
Subject: They have to find you first!
In-Reply-To: <9212180154.AA01889@media.Corp.Sun.COM>
Message-ID: <9212180213.AA29897@novavax.nova.edu>


> I would guess that all efforts towards creating secure, encrypted email
> would only cause surveillance groups to focus their efforts more upon
> what's showing up on your screen in plaintext before encryption and

To do that, they need to know who you are and where you are located. They
can't bug everyone.  If a pseudonymous system is used, then it would
be your top priority to make it impossible to connect your pseudonym with
your legal identity.  If you have not already, read Vinge's _True_Names_.

If "they" know who you are and where you are located, many techniques are
available, TEMPEST eavesdropping being only one of them.  Others are
confiscating your equipment, arresting you, threatening you and using you
to track down other people.

So, instead of concentrating on how to shield yourself from surveilannce
once you have been found, concentrate instead on not being found.  You can
maintain a usual identity that you use for normal conversation, but for
anything dangerous use an alternate identity, secure remailers, etc.

You might want SOME shielding, in case "they" take up the practice of
routinely driving up and down the streets looking to randomly find
something (someone) interesting.  

It should be much easier to protect against a casual search.

It may be nearly impossible, and/or useless to protect oneself from a
determined physical attack by a resourceful enemy.

It is much more profitable to prevent the attack.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819

(not in hiding yet :-)





From rchilder at us.oracle.com  Thu Dec 17 20:48:27 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Thu, 17 Dec 92 20:48:27 PST
Subject: So you want a wide-spectrum signal analyzer ?
Message-ID: <9212180447.AA06689@rchilder.us.oracle.com>



Here's what HP's catalog says :

	Spectrum Analyzers

	Spectrum analyzers take advantage of the frequency-conversion
	properties of the swept-tuned heterodyne receiver to make sig-
	-nificant contributions to frequency-domain signal analysis.
	The following are some of the measurements that can be made with
	spectrum analyzers :

	(1)	Absolute and relative frequency.
	(2)	Absolute and relative amplitude.
	(3)	Noise.
	(4)	Distortion products.
	(5)	AM, FM & pulsed RF modulation.
	(6)	Stimulus response.		( biofeedback ? ed. )
	(7)	Electromagnetic compatibility (EMC).

	These measurements are possible because spectrum analyzers have
	the following characteristics :

	(1)	Broad frequency coverage from 5 Hz to 325 GHz.
	(2)	Wide amplitude range from -138 dBm to +30 dBm.
	(3)	Excellent sensitivity for low-signal detection.
	(4)	Excellent frequency stability.
	(5)	High resolution of frequency and amplitude.

	These capabilities allow spectrum analyzers to provide frequency-
	domain signal analysis for numerous applications, including the
	manufacture and maintenance of microwave communication links, radar,
	telecom equipment, CATV systems, and broadcast equipment ; EMI
	diagnostic testing ; and signal surveillance.

( I can't believe they actually said that. Gee, I wonder if They're going
  to classify test & measurement equipment next. )-:

Prices for these puppies run from @ $ 20,000 to @ $ 50,000. They are very
modularized, and, for the paranoids amongst you, these things are portable.
They are probably devilishly heavy, like most test equipment is, and look
a lot like an oscilloscope, when the cover is off.

	For information about any Hewlett Packard product or service, or
	for additional copies of this catalog, call the Customer Infor-
	-mation Center (CIC) at 800-752-0900 between 6:00 am and 5:00 pm
	PST.

What you want is their 'Test & Measurement Catalog'.

One small tip - if you're calling them up and want to get a catalog sent
to you, you want to make an effort to look like a valid customer. These
catalogs are large and expensive and they may be less inclined to pay for
what is probably a few dollars' shipping if you come across as a college
student ( with apologies to college students :-). Give an address if you
can, give yourself a title - R&D engineer is good - a department - R&D -
and, if they ask for a box or mail dept code, you can make one up or say
that you don't have one. ( Using different box numbers going to a same
address is a great way to see who's sharing their mailing list with whom
else, BTW ).

I'm not encouraging you to spoof these folks, merely noting that it is a
regrettable necessity. If you don't present yourself as a prospect, they
may blow you off, and if you give any hint that you don't represent some
sort of company, you are sure to be blown off, presumed to be a waste of
their time. ( Of course, this posting may lead to three or four analyzers,
$ 100-200 thousand worth of sales, but try to persuade a salescritter of
this. :-)


-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."





From 74076.1041 at CompuServe.COM  Thu Dec 17 22:53:06 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Thu, 17 Dec 92 22:53:06 PST
Subject: Positive reps.
Message-ID: <921218064714_74076.1041_DHJ46-1@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

I was thinking about the idea of positive reputations and thought I'd
mention a few thoughts while waiting to see Dean's notes.

As I understand it, a positive reputation is basically some kind of
recomendation or endorsement of a person by someone else.  It might
be fairly specific, like "so-and-so paid a debt of $50 to me within
the agreed-upon two-week period."  Or it could be more general, like
"so-and-so is, in my opinion, an honest person."

I was thinking of positive reputations that might be relevant to the
problem mentioned of anonymous posting to mailing lists and newsgroups.
As Dean mentions, we can envision a system which uses the opposite of
kill files. Instead, messages would only be displayed from people who
met certain criteria in terms of their reputation credentials.

What would I want to see in the way of such credentials that would help
me decide whether I wanted to read the message?  (The issue of judging
the validity of credentials is discussed below.)  Maybe recommendations
in favor of the poster's intelligence, knowledge, judgment, temperance
(i.e. reluctance to flame), etc. would be useful.  Imagine a system in
which a person was rated from 1 to 10 in each of these categories.  A person's
positive reputation would consist of (digitally) signed statements from
various "endorsers" (or "introducers"), each giving their numeric judgements
about the person in question.

With this system, I could set my ideal mail/news reader to only display
postings from people whose scores met some standards.  Maybe I would
average them; maybe I would weight the different categories according
to my own tastes.  But this would let me filter out time-wasters like
the random poster who was causing problems.

Now, this still leaves open the problem of judging the validity of
various credentials.  This problem is very similar to the problem of
accepting key signatures in PGP.  If I receive a PGP key loaded with
signatures, that doesn't mean much unless I know at least one of the
people involved (either directly, or through the net).  Only then can
I judge how valid the signatures are.

In the same way, if a new person posts on a newsgroup, and includes his
credential loaded with 10/10/10/10's, that doesn't mean anything unless
I know some of these people who are vouching for him.  In the most
extreme case, he could have created a bunch of false identities and had
them provide all the endorsements.  So an endorser unknown to me is
not useful.

It's interesting that the PGP key "web of trust" may have application
to this more general problem.  I wonder if the PEM folks will push for
a centralized "email posting quality" hierarchy in which agencies rate
each person's quality of postings and assign them an official score. :-)
This would be the analog of their solution to the key-signature problem.

That's about as far as I've gotten.  A few more general comments:
Such a system requires an infrastructure of public-key encryption and
digital signatures.  Only in that way will signed credentials be secure
enough to be meaningful.  Since so few people use these tools today,
a positive-credential system would filter out almost everyone, throwing
out the baby with the bath water.

But, remailers are springing up everywhere.  It is an idea whose time
has come, it seems.  So the problem exists today, but the solution can't
be practically applied for at least another year or two, even assuming
rapid acceptance of PGP, RIPEM, PEM, or some other cryptographic standard.
That means that there may be some political pressure against remailers
during this interval.  Perhaps we can turn this to our advantage by describing
the advantages of a credential system, and using that to further encourage
widespread use of cryptographic programs.

Hal Finney
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzFI+KgTA69YIUw3AQEdCQP8DbPD9jrlR1MhlLOOQrSUc8Svcue2DZsj
+DIXiC50bpv+C5pZYtoCa5SuOXX8W6XmZRSkZW3gilvEKDQ2Zt7hH0ol+tFnn8cs
q05T1bYJIZqdMdqia6PZkVyvs+DQLuQSog5rZxAja1XfC/Rq59RnbPp2IViLqDiD
OfiasXA4Egs=
=GVH7
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From marc at Athena.MIT.EDU  Fri Dec 18 01:08:33 1992
From: marc at Athena.MIT.EDU (Marc Horowitz)
Date: Fri, 18 Dec 92 01:08:33 PST
Subject: holiday travel:  sign some keys!
Message-ID: <9212180907.AA07411@portnoy.MIT.EDU>


With the holidays coming up, and many of us traveling to see friends
and relatives, we all have a great chance to sign keys of people who
aren't in our normal circle of contact.  In our web of trust, we need
as many long strands as we can get.

I recommend that all of you write down your MD5 hashes, and, if you
are willing, post your general itinerary if you are traveling so
people can get in touch with you, and your key signing policy.  It
only takes a five minute meeting (unless there's good chinese food
conveniently nearby :-) to exchange hashes, then you can email your
keyring once you get back home.  I'll start.

I'll be visiting friends in the Alexandria, VA area saturday and
sunday (12/19-12/20), but I won't be reachable via phone easily so if
you'll be in that area during that time, email me before noon saturday
with contact information.  From sunday 12/20 to wednesday 12/23 (I may
stay later), I'll be in northern New Jersey (Wayne, to be exact) at my
parents' house, phone 201-694-3152.

I only sign keys I can verify out-of-band, either in person or by
phone with someone I know.  So far, all the keys I've signed are
people I've known for awhile and see often, so it was easy.  I guess
I'll make up a new rule: show me a driver's license and another piece
of ID (sort of like what you need to cash a check), and I'll trust
that you're you.  The harder to fake the better; I suppose passports
rank high on that list.

Maybe I'm crazy for posting all this info saying when I'm going to be
out of town, but I think it's worth it in the interest of getting some
more connections established (and I've been accused of being crazy
many times before, anyway).

		Marc





From mark at coombs.anu.edu.au  Fri Dec 18 01:16:11 1992
From: mark at coombs.anu.edu.au (Mark)
Date: Fri, 18 Dec 92 01:16:11 PST
Subject: TEMPEST/Van Eyck data
Message-ID: <9212180915.AA16502@coombs.anu.edu.au>


From: strat at intercon.com (Bob Stratton)

>It's weird stuff, and some people would rather not have the world
>learning how to do this. In fact, Van Eck's original article is known
>to have some deliberate misinformation in it, as the author didn't
>want to make it "too easy" to learn how to do this kind of ELINT.

Ever realised that some things come along that just tickle your curiosity
nerve and you wont let go until your satisfied? Im sure there are
individuals and organisations out there that would love an excuse to shut
down lists of this type, especially considering the type of information and
the implications in the not too distant future if people start implementing
half the concepts that are presented here.

I would like to see indepth technical information, or at least pointers to
said information presented here. Does anyone know of mailing lists out there
that concentrate on levels of computer emissions and methods of diminishing
them to negliable amounts?

Where would one obtain copies of articles on the subject? I have saved the
article posted by treason at gnu as it does contain a lot of references which
give one something to go on. I commend him for posting it for it's
informational content. It wasnt his fault it may have contained obselete or
inaccurate information.

So, anyone have lists of books, periodicals, email lists or papers that 
discuss the topic of computer RF emissions and how to protect a machine
*AND* monitor the levels of others? 

Mark
mark at coombs.anu.edu.au

P.S. That NASA guy had better watch for list members waiting for the postie
	 so they can collect the goodies before he can :)





From miron at extropia.wimsey.com  Fri Dec 18 02:31:06 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Fri, 18 Dec 92 02:31:06 PST
Subject: New remailer
Message-ID: <1992Dec18.095552.1987@extropia.wimsey.bc.ca>


-----BEGIN PGP SIGNED MESSAGE-----

I've set up a new remailer.  I am currently working on extensions.  Here
are the details:

Address: remail at extropia.wimsey.com
Contact: miron at extropia.wimsey.com
Encryption: PGP 2.1
Syntax:
    Compatible with Hal-standard remailers, except for a couple of things:

    - Encryption MUST be used.
    - Syntax can be simplified.  The pasting operator is assumed.
    The "Encrypted:" header is optional.  Accordingly, you can
    just encrypt plaintext of the following form (without the
    cut-here lines):

    --- cut here ---
    To: <recipient>

    <body>
    --- cut here ---

    In any case, one should be able to use the scripts posted
    on cypherpunks without change.

Availability: continuous, approx 2 hr turnaround or better.

(The keys follow this signed message.)

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzGfiZNxvvA36ONDAQHs0AP9EO5eiynLcTZumU7l4I+uLTvwROHR+DVv
LfFDV5/dKtSaISQpYvj2RSKYK3NHi2JiCM5vnkNYUWFW1uHcX/BpdOte8IJr2zML
/lpEEOYgbi56OGqg2bYhBCbJuh2wY71Ibs5Z5C/1HHsJ8hC334nbOV8pKC+gr+Mi
Am+tEzExRyM=
=Af9o
-----END PGP SIGNATURE-----

Remailer Key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB
mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l
yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR
tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQKysE
i5NxvvA36ONDAQF2AAP+IQlQxQ9MxuO6WDzIPsuzTxOS5LVrdh3MLWeAkbk+QN3l
hrRvEneULh82xOEvZg9whZ+/W8WYtFA4a8g/HbAhuHh4gqQHGakr0SUpKYGpnUWl
EBzZjMb+YKMR4UXpusF6ysWUDZ+f0tDbUDq0ukCoRZRq8wyIf9mndSfaqcsyfyGJ
AEUCBRArKwPUS60iYsR4D/cBATXBAXsFqc8sCpP0gQ8KHF3myZrE+s7oP2nu/FP3
LvZE1+ttF3I9c6jncfWPT6cHpvWEoWk=
=ZZ5t
-----END PGP PUBLIC KEY BLOCK-----

My key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqvJ10AAAED/jXfntqmsRjJRYoxYTxLO7obzMfzgUNtSDEawb3Suj4UO1xq
uARc25PJNAHQhIa83Yxf9z/R/3AjwmYrZqxvB2RkLPTjTmzQd04fypsZToiR/TlM
5F43JCuCM779mAir9Idy1CQzXQ2bn89eUZaVhOUJzNgndl+wLpNxvvA36ONDAAUR
tCxJbW1vcnRhbCBGcmVlZG9tIDxtaXJvbkBleHRyb3BpYS53aW1zZXkuY29tPokA
lQIFECsXPLSTcb7wN+jjQwEBv20D/jIKu8z9DP+wTLLWYZZax9wnJJzRkD9//kFA
C0is6LMNMSSX0yGwOPmqEI710BSovuTAlNBmqBrMrl0Bp5bsxpCN8Fw3Mc0ex5fe
1efockVjXNLMP0G4plr0AFMA4KXNE+MfwLFMd+Gcdxufro0yKoBygsHwQ+om+rut
RPIy89/PiQBFAgUQKwxwHUutImLEeA/3AQGQnQF8D0Zdrrz+kMAguOANBhbnxm5t
zak4TWg37hp/iU2CEfIbW/IUVIPEjNhvM6cjZ1jQ
=/SVk
-----END PGP PUBLIC KEY BLOCK-----
-- 
	Miron Cuperman <miron at extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron at cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |





From pozar at kumr.lns.com  Fri Dec 18 08:28:39 1992
From: pozar at kumr.lns.com (Tim Pozar)
Date: Fri, 18 Dec 92 08:28:39 PST
Subject: So you want a wide-spectrum signal analyzer ?
In-Reply-To: <9212180447.AA06689@rchilder.us.oracle.com>
Message-ID: <m0n2kY8-0002f8C@kumr.lns.com>


Richard Childers wrote:
> 	These capabilities allow spectrum analyzers to provide frequency-
> 	domain signal analysis for numerous applications, including the
> 	manufacture and maintenance of microwave communication links, radar,
> 	telecom equipment, CATV systems, and broadcast equipment ; EMI
> 	diagnostic testing ; and signal surveillance.
> 
> ( I can't believe they actually said that. Gee, I wonder if They're going
>   to classify test & measurement equipment next. )-:
   We use them all the time to track down pirate stations and wierd
emissions (spurs, harmonics...).  BTW... If you have an O-Scope that has
X-Y inputs, it isn't that difficult to design and build a low-end, front-end 
for the scope that will provide the same functions as a spectrum analyzer.

> I'm not encouraging you to spoof these folks, merely noting that it is a
> regrettable necessity. If you don't present yourself as a prospect, they
> may blow you off, and if you give any hint that you don't represent some
> sort of company, you are sure to be blown off, presumed to be a waste of
> their time. ( Of course, this posting may lead to three or four analyzers,
> $ 100-200 thousand worth of sales, but try to persuade a salescritter of
> this. :-)

   I think they partially do this 'cause the catalogs are so bloody
expensive to produce.  They are an education if you get one.

         Tim

-- 
    Internet: pozar at kumr.lns.com     FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
                        Voice: +1 415 788 2022





From warlord at MIT.EDU  Fri Dec 18 08:55:19 1992
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 18 Dec 92 08:55:19 PST
Subject: holiday travel: sign some keys!
In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU>
Message-ID: <9212181654.AA05651@deathtongue.MIT.EDU>


I like the idea!  Anyways, being one of the people who has
cross-signed with marc, and hoping to increase our web of
trust....

I'll be in the NorthEast Ohio region for about 2 weeks, 
21Dec-4Jan, with a small stint in Brampton, Ontario over
New Years...  My Cleveland contact number is (216) 292-5845.
I don't have a contact number in CA, so you'll have to either
e-mail me by this weekend or get ahold of me in Cleveland.

Like marc, I like to sign keys out-of-band.  I'll have my
key fingerprint for anyone who wants it.  

I hope to see some of you over the holiday season!

-derek





From deboni at diego.llnl.gov  Fri Dec 18 09:52:02 1992
From: deboni at diego.llnl.gov (Tom DeBoni)
Date: Fri, 18 Dec 92 09:52:02 PST
Subject: positive reps and paranoia
Message-ID: <9212181748.AA03280@diego.llnl.gov>


I'm just a lurker on this list, trying to pick up on what's happening in this
subset of computing and communications, but my chain's been yanked, and the
subject merits a reply. 

On the matter of the discussion that's been going on vis-a-vis reputations
versus kill files, I'm afraid we're regressing to the bad old days when
everyone was considered bad and worthy of suspicion until they demonstrated
that they were good and trustworthy. I'd personally rather believe people
are basically good than otherwise. Even if I must occasionally suffer getting
burned, it's easier on the nerves, attitude, and karma to assume the best
in those I interact with. I think it's significant that there are really so
few of us on the net who are actually insufferable and refuse to be shouted
down to reasonable behavior by the civil rest of us. Those few who are will
not be prevented from troubling us by the measures being advocated - positive
reps, scores on 1-to-10 scales, etc. - any more than weapon makers are
deterred by manufacturers of armor. someone who really wanted to could still
flood our group with vitriol, using multiple artificial identities vouched for
by other artificial identities. If such neurotic vengeful behavior were really
likely on the net, we'd have seen it already. What, other than good sense and
a low threshold of boredom, prevents any of us from flooding any and all news
groups with garbage? And if it ever becomes a problem, we'll just have to
appoint a moderator, perhaps on a rotating basis, from among those of us who
are personally acquainted with each other.

My point here isn't that we shouldn't prepare for the worst, but that we
shouldn't get crazy about it. The theoretical aspects of the discussion are
interesting to me, but I just thought it was getting a little close to the edge
not to comment.

Tom DeBoni
(Once I figure this stuff all out, I'll get a "protected" identity, too.)
deboni at llnl.gov







From yanek at novavax.nova.edu  Fri Dec 18 10:29:44 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Fri, 18 Dec 92 10:29:44 PST
Subject: Reputation Systems
In-Reply-To: <9212181748.AA03280@diego.llnl.gov>
Message-ID: <9212181828.AA25958@novavax.nova.edu>


> it's easier on the nerves, attitude, and karma to assume the best
> in those I interact with.

But you can not interact with everyone that that has the technical means to
post a message.  If you can now, somehow, (you can't do much else if you
want to keep up with 50MB per day), then in the near future you will not be
able to.

So, you need a way to pick who to interact with.  

> I think it's significant that there are really so
> few of us on the net who are actually insufferable and refuse to be shouted
> down to reasonable behavior by the civil rest of us. Those few who are will

If you are referring to the current state of the UseNet, then I suggest
that you keep in mind that until fairly recently the access was mostly
limited to people in universities, and research departments of hi-tech
corporations.  This is a highly selected group of people, and can not be
compared to the "general public".

As communications technology becomes cheaper, more widespread and
accessible to anyone that wants to, and eventually ubiquitous like the
telephone is now, the number of people that will be able to "interact" will
be much greater.

In general, I view this as a good thing.  Unfortunately, the ratio
of people that I would find _interesting_ or _usefule_ to "talk" to in
relation to the total number of people I _can_ talk to will decrease
dramatically.

> not be prevented from troubling us by the measures being advocated - positive
> reps, scores on 1-to-10 scales, etc. - any more than weapon makers are
> deterred by manufacturers of armor. someone who really wanted to could still

I don't think anyone intends to use reputation systems to prevent someone
from posting a message, instead as a means to easily filter the messages
you personally want to read.  

Or maybe even not filter, but as some suggested, _sort_.  So you would first
read (and reply to) the messages of people with a higher reputation for
writing informative articles, or participating in interesting discussions.  

To some extent, this already is already occurring.  If there are some
people that you remember from the past as interesting people to talk to,
you are more likely to read their messages.  

An automated system would let you benefit from other peoples' memories.

> groups with garbage? And if it ever becomes a problem, we'll just have to
> appoint a moderator, perhaps on a rotating basis, from among those of us who

Think of a reputation system as being a distributed moderator.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From pmetzger at shearson.com  Fri Dec 18 11:24:15 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Fri, 18 Dec 92 11:24:15 PST
Subject: Patent Infringement
Message-ID: <9212181618.AA29313@maggie.shearson.com>


> From: yanek at novavax.nova.edu (Yanek Martinson)
> 
> > "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
> >  apply it yourself.  In the US it is called "Patent Infringement"."
> > 
> > Only if you attempt to sell it ...
> 
> No.  The patent law prohibits anyone from "making, using, or selling" 
> anything covered under the patent.  Selling it makes it more likely
> that the patent holder will come after you, as they have a greater
> chance of getting some money from you.
> 
> I am not a lawyer, I am sure someone here can explain all this in
> greater detail, or correct me if I'm wrong.

This is one of the sillier threads I've seen in a while. Is anyone here
arguing seriously that RFI shielding your equipment is a patented technology?

Perry





From pmetzger at shearson.com  Fri Dec 18 11:49:01 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Fri, 18 Dec 92 11:49:01 PST
Subject: The Need for Positive Repuations
Message-ID: <9212181645.AA29793@maggie.shearson.com>



> From: tcmay at netcom.com (Timothy C. May)
> The longterm solution is to use "positive reputations" and not just
> "negative reputations" (as in Kill files). This is something Dean
> Tribble just talked about at our last physical meeting of the
> Cypherpunks ("Bay Area Branch" :-} ).
> 
> Think of like a credit rating. People _earn_ trust, they don't just
> get assigned a credit rating until they do something bad. 

Indeed, in the long run, when there are billions of people in the nets,
even UseNet newsgroups devoted to people who use musical instruments as
sex toys would have thousands of posts a day because given billions of
possible subscribers, finding a few tens of thousands with a particularly
obscure interest wouldn't be hard. Thus, in the long run, the nets will move
to "closed" newsgroups and mailing lists in which to be a subscriber one
will have to be explicitly subscribed to a list and will only be able to
read with one's private key and post by digitally signing messages. In such
an environment, anonymous abusers will simply be incapable of annoying people.

A weak version of this exists already in the Extropians mailing list, which
considers itself to be a closed list. The list is governed by a privately
produced legal code (its in some ways a test of anarchocapitalist legal theory),
and since the adoption of the code, we've had a reduction of flaming by
a large factor even though we've seen a three fold increase in list size.
The content is improving because people know that sanctions will be applied
for flaming and that they can actually be kicked off the list, and that being
kicked off is meaningful. In the long run, all serious discussion groups
will likely evolve in this direction, with the lists being closed to explicit
subscribers and with meaningful sanctions like ostracism being applied to 
people that behave in an antisocial manner. Such lists have little reason
to fear people hiding behind cloaks of anonymity. With digital signatures,
even the anonymous can develop meaningful reputations and can be sanctioned
for failing to live up to those reputations.

Perry





From MAILER-DAEMON at acf3.NYU.EDU  Fri Dec 18 11:53:19 1992
From: MAILER-DAEMON at acf3.NYU.EDU (Mail Delivery Subsystem)
Date: Fri, 18 Dec 92 11:53:19 PST
Subject: Returned mail: User unknown
Message-ID: <9212180223.AA06621@acf3.NYU.EDU>


   ----- Transcript of session follows -----
>>> RCPT To:<cyperpunks at toad.com>
<<< 550 <cyperpunks at toad.com>... User unknown
550 cyperpunks at toad.com... User unknown

   ----- Unsent message follows -----
Received: by acf3.NYU.EDU (5.61/1.34)
	id AA06619; Thu, 17 Dec 92 21:23:18 -0500
From: habs (Harry A. B. Shapiro)
Message-Id: <9212180223.AA06619 at acf3.NYU.EDU>
Subject: repeater abuse
To: cyperpunks at toad.com
Date: Thu, 17 Dec 1992 21:23:17 -0500 (EST)
X-Mailer: ELM [version 2.4 PL0]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 544       

In reponse to Dean T. message.

I agree.

Re: low tech - The extropians uses several Perry(TM) filters
to prevent unwanted bounces AND unwanted posters OUT.

For a more high tech solution I can imagine some sort of public or
private key needed to make a post 

- An example being some a public key that was in some manner 
signed by a trusted member of a list - I am weak on the techincal
end/side but basically unless the message is "trusted" it doens't
get through.

-- 
habs at acf3.NYU.EDU
habs at gnu.ai.mit.edu
habs at well.sf.ca.us
habs at panix.com







From jthomas at kolanut.mitre.org  Fri Dec 18 12:20:39 1992
From: jthomas at kolanut.mitre.org (Joe Thomas)
Date: Fri, 18 Dec 92 12:20:39 PST
Subject: The Need for Positive Repuations
Message-ID: <9212182019.AA00438@kolanut>


> From: tcmay at netcom.com (Timothy C. May)
> The longterm solution is to use "positive reputations" and not just
> "negative reputations" (as in Kill files). This is something Dean
> Tribble just talked about at our last physical meeting of the
> Cypherpunks ("Bay Area Branch" :-} ).
> 

> Think of like a credit rating. People _earn_ trust, they don't just
> get assigned a credit rating until they do something bad. 


>From: pmetzger at shearson.com (Perry E. Metzger)
>Indeed, in the long run, when there are billions of people in the  
>nets, even UseNet newsgroups devoted to people who use musical  
>instruments as sex toys would have thousands of posts a day because  
>given billions of possible subscribers, finding a few tens of  
>thousands with a particularly obscure interest wouldn't be hard.  
>Thus, in the long run, the nets will move to "closed" newsgroups and  
>mailing lists in which to be a subscriber one will have to be  
>explicitly subscribed to a list and will only be able to read with  
>one's private key and post by digitally signing messages. In such
>an environment, anonymous abusers will simply be incapable of  
>annoying people.

Yes, but there will still need to be a way for new people to join the  
lists, (and the net in general) before they've had a chance to "prove  
themselves."  Allowing all new id's to post to the whole group on a  
probationary basis is unacceptable;  as soon as someone proves  
obnoxious enough to kick off they could just start over with a new  
id.  The obvious answer is that a moderator will be necessary for all  
closed lists that require a positive rep for posting and that don't  
wish to be forever limited to their founding members.  After a few  
lucid posts passed by the moderator, an individual would gain enough  
of a reputation not to be filtered out any longer.

Of course, anyone who's heard Howard Stern fans invade political  
call-in shows will realize there's not much that can be done with  
those weird people who will spend a lot of time and energy to appear  
credible, only to annoy people.

Joe





From habs at acf3.NYU.EDU  Fri Dec 18 12:54:54 1992
From: habs at acf3.NYU.EDU (Harry A. B. Shapiro)
Date: Fri, 18 Dec 92 12:54:54 PST
Subject: The Need for Positive Repuations
In-Reply-To: <9212182019.AA00438@kolanut>
Message-ID: <9212182054.AA11836@acf3.NYU.EDU>


A conscious being, Joe Thomas, wrote in a previous message:
> Yes, but there will still need to be a way for new people to join the  
> lists, (and the net in general) before they've had a chance to "prove  
> themselves." 

There will always be the Sear credit cards of news groups. Those
that will let almost anyone in - just so they can prove themselves.


-- 
habs at acf3.NYU.EDU
habs at gnu.ai.mit.edu
habs at well.sf.ca.us
habs at panix.com




From wendtj at jplpost.Jpl.Nasa.Gov  Fri Dec 18 14:18:16 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Fri, 18 Dec 92 14:18:16 PST
Subject: The Wheel
Message-ID: <9211187247.AA724710372@jplpost.jpl.nasa.gov>




          Has anyone built there own TEMPEST reciever/antenna
          equipment?  I have seen articles that say that you can
          use old television sets, and that you can build more
          advanced TEMPEST unit for a hundred dollars.  This seems
          akin to the carburator that will give you 200 mpg, and
          plans for a particle beam cannon in the back of some zines.

          If this is so cheap and easy or cheaper-quicker-better
          (NASA-Goldin-TQM propoganda), then why haven't we seen an
          article/articles on the construction of a TEMPEST reciever
          and the associated tuning/specs on such an item.

          Is it possible, or nothing more than snake oil?

          JPW





From marc at MIT.EDU  Fri Dec 18 14:53:18 1992
From: marc at MIT.EDU (Marc Horowitz)
Date: Fri, 18 Dec 92 14:53:18 PST
Subject: The Need for Positive Repuations
In-Reply-To: <9212182054.AA11836@acf3.NYU.EDU>
Message-ID: <9212182252.AA06643@tla>


Go read Ender's Game.  They had a seriously electronic society.  There
were public message boards, and positive-reputation-based boards.
Basically, if you demonstrated a clue on the public boards, then
someone already reputable could recommend you for "membership" in the
reputation-based boards.  One of the characters did so anonymously.
She even got paid for writing editorials, etc.  Anybody could watch
the proceeedings of the reputeable boards.  In time, she was competing
in debates with major politicians, et. al.  Sci-fi?  or Reality?  I
believe we could move from the former to the latter.  (And I just
avoided any sort of spoiler about the plot ;-)

Imagine a system where spaf distributed the public key of the
moderator(s) of a moderated newgroup.  News servers would make sure
that the message was signed by the moderator, or that the poster
included some sort of certificate, signed by the moderator, indicating
that he could post without having to go through the moderator first.
Expirations and/or revocation lists would be needed to do things
right, but these are problems with fairly good solutions.

		Marc





From 2FTPHAVOC at kuhub.cc.ukans.edu  Fri Dec 18 15:24:06 1992
From: 2FTPHAVOC at kuhub.cc.ukans.edu (2FTPHAVOC at kuhub.cc.ukans.edu)
Date: Fri, 18 Dec 92 15:24:06 PST
Subject: Patently false rumor
Message-ID: <01GSGW2OK9420056TH@KUHUB.CC.UKANS.EDU>


I just finished reading the Mondo 2k article on cypherpunks.  I was hoping to find out some more info on !encrytption software.  All rumors are built on a grain of truth, aren't they?





From tcmay at netcom.com  Fri Dec 18 15:55:47 1992
From: tcmay at netcom.com (Timothy C. May)
Date: Fri, 18 Dec 92 15:55:47 PST
Subject: The Need for Positive Repuations
In-Reply-To: <9212182252.AA06643@tla>
Message-ID: <9212182354.AA14872@netcom.netcom.com>


Marc writes:

> Go read Ender's Game.  They had a seriously electronic society.  There
> were public message boards, and positive-reputation-based boards.
> Basically, if you demonstrated a clue on the public boards, then
> someone already reputable could recommend you for "membership" in the
> reputation-based boards.  One of the characters did so anonymously.
> She even got paid for writing editorials, etc.  Anybody could watch
> the proceeedings of the reputeable boards.  In time, she was competing
> in debates with major politicians, et. al.  Sci-fi?  or Reality?  I
> believe we could move from the former to the latter.  (And I just
> avoided any sort of spoiler about the plot ;-)

Exactly! "Ender's Game," by Orson Scott Card, and "True Names," by
Vernor Vinge, are the two books I've been recommending since I coined
the term "crypto anarchy" in 1987. I held these books up in a couple
of talks I gave at BayCon (SF convention) and the Hackers Conference
and said "Read these books!"

A couple of folks have said that newcomers will never be listened to,
will never "get in" to positive reputation systems. This simply isn't
true, even with today's "manual" reputation management systems. On the
two main lists I subscribe to, this list and the Extropians list (send
request to Extropians-request at gnu.ai,mit.edu if interested in future
stuff, anarchocapitalism, nanotech, cryonics, etc....about a dozen
folks on this list are also on Extropians, I would guess), newcomers
start making posts and gradually the list gets to know their name,
what to expect of them, etc. This is their "rep." Serious flamers or
abusers see their rep torn down.

(A list I just joined is the Pynchon list...actually, one of them saw
my "W.A.S.T.E. line in my .sig and _invited_ me to join. As a newcomer
to that list, I have no reputation. What I say and how reasonably I
say it will establish my rep. This is as it should be.)

If people want to see the posts and comments of newcomers, even those
without extensive history on the list or glowing reps, then they will
likely set their "agents" to allow the new stuff through. Lots of
variations are possible and will be tried.

Think about positive reputations and you'll see them in action all
around you...where you shop, what you read, who you associate with,
etc. The Net will ultimately be no different.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From tribble at xanadu.com  Fri Dec 18 17:35:03 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Fri, 18 Dec 92 17:35:03 PST
Subject: reputations talk notes
Message-ID: <9212190048.AA04870@xanadu.xanadu.com>


These are the notes from my talk at the last meeting.  
They may only be parsable by people who saw the talk, 
but I'm interested in all comments.

Thanks to Mark Miller and Eric Drexler who helped me put
together these notes the first time.

The need for reputations:
	single Prisoner's Dilemna incentive for defecting
	iterated Prisoner's dilemna incentive for cooperating
	reps put each person in an iterated situation with the group
	better reputations reduce reputation float (see below)

Spreading reputations makes them better at encouraging cooperation

Uses of reputations:
	sorting
	filtering - this is just bad sorting
	collateral - for business and important trust issues
	let me add that reputation appication is largely on the receiving side

Negative reputations:
	don't work with anonymity because you just make another identity
	don't spread for psychological and legal reasons
		many people won't reveal negative opinions about others people
	primarily support filtering and collateral

Positive reputations:
	are safer to reveal and spread
	allow sorting
	can handle anonymous pseudonyms

Anonymity:
	reduces perceived and actual accountability
	breaks many of our trained intutions for trusting others
	implicit but unrevealed assets aren't at risk
	trade names are examples of non-anon. pseudonyms

Reputations systems for sorting mail are less of an issues than
reputations systems for actual business because there is less at risk.
Gaming of a reputation system depends on how much is at risk.

Brilliant Pennies: randomly generated reputations
	the con game:
		start with 1000 pennies
		flip them every day.  head the stock market goes up, tails it goes down
		throw out pennies that 'guessed' wrong
		at the end of ten days you have a penny with a 'reputation' 
			for predicting the stock market
		sell the penny anonymously :-)
	inconsistent positive reputations are better than perfect reputations
		can explain away first several mistakes

Assets that support an identity
	recoverable assets
		anything that can be recovered in the even of a defection
			bank accounts, goods, factories, etc.
		pseudonyms typically won't have recoverable assets
		pseudonyms could keep recoverable assets in a non-anonymous escrow
		can be anonymously and privately committed to more than one party in the
			event of a defection, so value can't properly be assessed
	unrecoverable assets
		Sunk costs
			time, money spent building a reputation
			solves the Brilliant Penny problem: 
				random rep requires huge investment
				a 30day coin-flipping rep requires more pennies than exist
			notarized money-destruction service:
				proves investment with no route for kickbacks to the investor
				demonstrates the comparative cost of running an anon. service
			our intuitions about sunk costs can be very wrong here
				we're used to sunk costs at least looking recoverable (liquidation)
				we're used to eventual personal accountability of decision maker
			sunk costs enable kill files again
				you can only afford so many pseudonyms
				this is relates to the Brilliant Penny solution
		reputation capital (perceived value of reputation)
			customer good will, market share, shelf space, customer mind-space, etc.
			priority settings in receivers's mail handlers (filters, sorters)
			future sales potential
			based on the net present value of the reputation
				perceived differently by different individuals (customers/producer)
				based on discount rate (subjective value of money now vs. money later?)
				perception of discount rate can change radically
					you are told you have 6 months to live

Reputation Float:
	latency between use of a reputation and the effect on the value of the reputation
		how long can you ride on past glory?
	this includes the amount of goods, etc. against which the reputation is collateral
		existing trade-names collateralize the quality of existing goods (i.e. cars)
	estimating reputation float is a public goods problem
		why should I reveal the goods I have outstanding if I can get the info anyway
	insurance (Idea Futures) doesn't help
		the anonymous could collect both from defaulting and from insurance
	our intuitions screw up at estimating this 
		we're not used to untraceable transactions

Miscellaneous:
	filtering/sorting reputations should be wrt to topics
		This generalizes to other criteria
		individuals have different levels of expertise in different areas
	synthesized reputations are reputations composed from multiple reputations
		chaining remailers composes their reputations for security
		voting among key providers composes their uncompromisability reputations





From tribble at xanadu.com  Fri Dec 18 17:35:04 1992
From: tribble at xanadu.com (E. Dean Tribble)
Date: Fri, 18 Dec 92 17:35:04 PST
Subject: reputations
Message-ID: <9212190101.AA04917@xanadu.xanadu.com>


Since I have a reputation for talking about reputations....

You are already engaged in a positive reputation system.  Which email
lists are you on?  Which newsGroups do you bother with?  what TV shows
do you watch?  New instances of all of these pop up and succeed all
the time.

Negative reputation systems work very poorly.  Right now I receive
cypherpunks.  I used to receive Extropians (and will do so again
soon).  The volume can get horrific at times.  Consider all the stuff
that I'm not receiving (that I filtered out).  I don't see
sci.nanotech, sci.crypt, alt.pgp (?), libernet, alt.politics,
alt.sex.bondage, etc. because I haven't the bandwidth.

Ah, but if I could pick and choose among the entire available feed
rather than ignoring most of it just so I have a hope of filtering
down to a manageable mail load....

That's what positive filters are for.  There are lots of gems buried
in the crap of net-news (and remember that my gems may be your crap),
and I want a system that will find them for me.

I think the approach of reputation filtered mailing lists is a bad
one.  That reputation filtering process is simply a poor mechanism to
avail us all of the moderator's taste in email.  If we had a better
mechanism, then such a list is just alt.extropy or sci.crypt where
things are prioritized (using the positive prioritixing information of
such people who would otherwise be moderators) such that I see the
good stuff and ignore the bozoz (whomever they are).  Or in the more
likely case, I just see the creme de la creme of the good stuff
because that's all I have time for.

In such a system, one can think of a magazine as simply purchasing the
editor's priority information.

Paul Baclace built a genetic algorithm thing that would present
netnews from all groups in prioritized order.  As you gave it feedback
on how glad you were to receive each message, it didi pattern matching
on features of the messages to make better sorters.  This ends up
correlating author (anonymous or otherwise), subjet, topic, reply
chain, time of day, whatever seems relevant into the prioritization of
mail.  If those weight could be spread, combined with manually entered
filters ("I'm tired of politics..."), etc. you might actually be able
to spend less time on email/news getting more value from it.

dean





From honey at homey.citi.umich.edu  Sat Dec 19 05:56:01 1992
From: honey at homey.citi.umich.edu (peter honeyman)
Date: Sat, 19 Dec 92 05:56:01 PST
Subject: Reputation Systems
In-Reply-To: <9212181828.AA25958@novavax.nova.edu>
Message-ID: <9212191355.AA24847@toad.com>


i should think that a middle ground would be suitable, in which
people keep a hot list and an "other" list, with perhaps a kill
list as well.

	peter





From edgar at spectrx.Saigon.COM  Sat Dec 19 08:09:32 1992
From: edgar at spectrx.Saigon.COM (Edgar W. Swank)
Date: Sat, 19 Dec 92 08:09:32 PST
Subject: Remailer Policies
Message-ID: <NcD2VB2w165w@spectrx.saigon.com>


I would like to expand on Hal's suggestion that remailer operators
post their policies on a)keeping logs and b) divulging same.
 
Hal says he keeps logs "for a few days" and might divulge logs of
"really vicious, racially or sexually harrassing" messages.
 
Presumably this would also cover anonymous threatening messages,
blackmail, etc.
 
We've already discussed use of PGP by pedophiles to encrypt
incriminating diaries.  It gets better.  PGP and remailers can
be used to encrypt and ship "kiddy porn" GIF files. Even private
possession of such material is a serious crime in the USA. A chain
of anonymous and encrypted remailers could be used to drop kiddy porn
into newsgroups like
 
  alt.sex.pictures
 
I'm sure that would create quite a stir!
 
Perhaps Duncan or another attorney would like to comment on legal
liability of remailers in these kinds of situations. I don't think
there's currently any law on what records remailers would have to
keep; if you didn't have them, you couldn't give them up.
 
If this becomes a problem, expect legislation regulating or even
outright banning remailers. However, if remailer code has spread
over many national boundaries, such legislation may not be effective.
 
By the way, no-one has yet responded to my request to add features
to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously
post to newsgroups available at the remailer site.  Both these
features are present in the Australian remailer at Pax. Unfortunately
that remailer seems less secure than Eric's in that it keeps more or
less permanent records of its users at the remailer site and it
doesn't seem to be able to chain to other remailers.

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From yanek at novavax.nova.edu  Sat Dec 19 10:30:47 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sat, 19 Dec 92 10:30:47 PST
Subject: positive rep
In-Reply-To: <9212191759.AA01309@novavax.nova.edu>
Message-ID: <9212191829.AA02189@novavax.nova.edu>


> but how do you know who to add to the positive rep list?  take netnews,
> e.g.  i generally scan a group for names i know (+ rep), then read

For example, all mail/news reader software would have a function where
after reading the article you could press a key to indicate you found
the article useful/informative/interesting.  What it would do is send
the person a "certificate", which in essence says "I recommend reading
messages by this person", signed cryptographically with your signature.

These certificates could be appended to messages by that person, or 
posted to some special newsgroup just for that purpose (similar to
"control"), or distributed through some other means.  

If several people to whom you have assigned high credibility recommend
messages by a person, then your news software would automatically sort
his messages to appear higher in the list before other people's messages,
and also that person's recommendations would have a higher weight in
computing other people's sort values.

All this pre-supposes widespread use of authenticated messages, so 
someone could not forge himself some certificates from well-known
people.  Also, it would not allow a J. Random to forge a post that
appears to be from a person with high reputation.

The technology for such communication exists now (PGP, MD5, RSAREF, etc)
it is just not integrated into most news/mail software.

Unlike negative reputations, positive reputations are immune to
subversion by creating many anonymous or pseudonymous identities.

You might imagine someone creating two hundred "people" and have them
all send him their "certificates". 

But this would not work, since no-one has recommended these people, their
certificate would carry no weight whatsoever.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From gnu  Sat Dec 19 14:46:06 1992
From: gnu (John Gilmore)
Date: Sat, 19 Dec 92 14:46:06 PST
Subject: TEMPEST
Message-ID: <9212192246.AA05562@toad.com>


> There are plenty of other government conspiracies to focus on ! This one
> seems a bit lame.

Our government should not be our opponent when we try to find out how
to provide high levels of privacy for ourselves, our computers, and
our communications.

Ignoring that, yes, TEMPEST doesn't look like a deep dark conspiracy.
It's legal to shield your equipment and probably legal to export it (if
you didn't use the classified TEMPEST specifications in building it,
but reverse engineered them yourself).  The government is not our enemy
here (like it *is* our enemy in the drug war), but it isn't our friend
either.

	John Gilmore





From dclunie at pax.tpa.com.AU  Sat Dec 19 14:50:47 1992
From: dclunie at pax.tpa.com.AU (David Clunie)
Date: Sat, 19 Dec 92 14:50:47 PST
Subject: Remailer Policies
Message-ID: <9212192250.AA01396@britt>


> I would like to expand on Hal's suggestion that remailer operators
> post their policies on a)keeping logs and b) divulging same.
>  

The anonymous mailing system at pax has the following policy:

  - A log of activities of the remailing software is maintained when
    debugging is in progress (often) which could be used to correlate
    real identities with aliases - this is no more or less information
    than is available in the alias database which is not visible to
    anyone except the root user. Message-id's are NOT stored in this log,
    and the contents of messages and posts are NOT stored anywhere, nor
    are they scrutinized by me or anyone else. I don't care and I don't
    want to know. If someone does something unreasonable and I get
    complaints then I could lock out a particular source of mail if
    I didn't get a good explanation, but I am not going to go reading
    other peoples mail in order to censor it !

  - Under no circumstance short of being arrested and/or the equipment
    commandeered by someone else will the alias database be divulged
    or the contents or routes of messages deliberately intercepted.

david






From 74076.1041 at CompuServe.COM  Sat Dec 19 16:52:59 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Sat, 19 Dec 92 16:52:59 PST
Subject: Remailers.
Message-ID: <921220004532_74076.1041_DHJ42-1@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

Responding to Edgar Swank's message:

> We've already discussed use of PGP by pedophiles to encrypt
> incriminating diaries.  It gets better.  PGP and remailers can
> be used to encrypt and ship "kiddy porn" GIF files. Even private
> possession of such material is a serious crime in the USA. A chain
> of anonymous and encrypted remailers could be used to drop kiddy porn
> into newsgroups like
>  
>   alt.sex.pictures
>  
> I'm sure that would create quite a stir!

This could easily happen soon, as news of these remailers spreads.
There's been talk on the net about a student at an Ivy League college
who is being investigated by the FBI for allegedly posting illegal
images containing child pornagraphy.  Once people find out about
anonymous remailers, especially ours with their chaining capabilities
and encryption, they will realize that such posts can be made with
almost total safety.  Presumably this may increase the number of
people who would attempt it.

> Perhaps Duncan or another attorney would like to comment on legal
> liability of remailers in these kinds of situations. I don't think
> there's currently any law on what records remailers would have to
> keep; if you didn't have them, you couldn't give them up.
>  
> If this becomes a problem, expect legislation regulating or even
> outright banning remailers. However, if remailer code has spread
> over many national boundaries, such legislation may not be effective.

My guess is that it will not be feasible to ban remailers, since it
would be hard to draw the line between completely automated remailers,
and simple manual forwarding of a message that someone sent you, which
happens all the time and can hardly be made illegal.

I suspect that instead the approach would be to claim that remailer
operators are responsible for the material their remailers produce,
regardless of its original source.  So if child porn comes out, I
am guilty of sending child porn.  I can argue that my remailer was
automatic and that I shouldn't be held responsible for what comes out
of it, but my guess is that this argument will be rejected on the
grounds of personal responsibility, and because no one forces me to
run a remailer which sends out anything that comes in to it.

Such a policy would be a plausible extension of current Internet
policies, IMO.  RFC 822, the document which describes the format of
Internet mail message, in session 4.4.2 discusses the "Sender:" field,
and says, "Since the critical function served by the 'Sender' field
is identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their behavior,
it is strongly recommended that when a computer program generates a
message, the HUMAN who is responsible for that program be referenced
as part of the 'Sender' field mailbox specification."  [Capitalization
in the original.]  The need for a person to take responsibility for
each piece of mail that is sent would tend to lead to the policy
I mentioned.

With such a policy in place, if enforced by law, I don't think people
would run remailers in this country because of the legal risks.  There
would still be the international remailers, though.

> By the way, no-one has yet responded to my request to add features
> to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously
> post to newsgroups available at the remailer site.  Both these
> features are present in the Australian remailer at Pax. Unfortunately
> that remailer seems less secure than Eric's in that it keeps more or
> less permanent records of its users at the remailer site and it
> doesn't seem to be able to chain to other remailers.
> 
> --
> edgar at spectrx.saigon.com (Edgar W. Swank)
> SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca

It should be possible to chain from Pax to our remailers, getting the
best features of both.  Pax could be the first remailer in the chain,
stripping the sig.  The message could then go through our remailers,
providing non-traced security, at least if you can find someone who
does not keep logs.

Anonymous posting can be done already.  Anyone can post to most newsgroups
by sending mail to certain addresses.  One such system is at Berkeley.
Send to, e.g., sci-crypt at ucbvax.berkeley.edu to post to sci.crypt.  There
is another such system running in Austin, TX, I believe, but I don't
have the corresponding net address handy.  So this capability is already
provided by our (or anyone's) remailers.

One reason I haven't looked at stripping the .sig is due to an email
discussion I had about a month ago with Eric Hughes.  Eric strongly
felt that message bodies should be preserved as much as possible by the
remailers, in accordance with the general principle of Internet mail
forwarding.  Too much mangling is done already by mail gateways,
and adding more changes might be harmful.  Obviously, the remailers can't
avoid doing some processing of the message body, what with the "::"
pasting tokens and PGP decryption, but Eric felt that unnecessary
changes should be minimized.  I know Eric is working on some new
remailer concepts so I want to defer to him on this issue for now.

Hal Finney
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzOXf6gTA69YIUw3AQEvQQQArHXSwwrkQ3mSGOD60ZBV/p1R9RONqv2x
S64iJjdJB43G2nxLHB2t9xXAKSdCT00shEtil8LWu20XW0rWXqmMXyYudtt3qf3t
2arqlvxdGXlPt3eISFJ97U6jaI1EhswPg29fjuXMMaKv5OO/gBKp1i9Cig7suZDt
EkUDJihLQxc=
=q6zH
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From hh at soda.berkeley.edu  Sun Dec 20 00:02:57 1992
From: hh at soda.berkeley.edu (Eric Hollander)
Date: Sun, 20 Dec 92 00:02:57 PST
Subject: Remailer Policies
In-Reply-To: <9212192250.AA01396@britt>
Message-ID: <9212200800.AA20904@soda.berkeley.edu>




>The anonymous mailing system at pax has the following policy:
>
>  - A log of activities of the remailing software is maintained when
>    debugging is in progress (often) which could be used to correlate
>    real identities with aliases - this is no more or less information
>    than is available in the alias database which is not visible to
>    anyone except the root user. Message-id's are NOT stored in this log,
>    and the contents of messages and posts are NOT stored anywhere, nor
>    are they scrutinized by me or anyone else. I don't care and I don't
>    want to know. If someone does something unreasonable and I get
>    complaints then I could lock out a particular source of mail if
>    I didn't get a good explanation, but I am not going to go reading
>    other peoples mail in order to censor it !

I keep logs on content and origin on my three remailers.  I do read the
logs.  However, I would not censor any transmissions.  I would stop
accepting mail from a site given enough reasonable complaints.

>  - Under no circumstance short of being arrested and/or the equipment
>    commandeered by someone else will the alias database be divulged
>    or the contents or routes of messages deliberately intercepted.

Dido for me.  I would make an attempt to destroy all of my data if an
attempt were made to take the equipment or access the data by a government
or other agency.

e





From miron at extropia.wimsey.com  Sun Dec 20 03:25:01 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Sun, 20 Dec 92 03:25:01 PST
Subject: Remailers and liability
Message-ID: <1992Dec20.105340.11707@extropia.wimsey.bc.ca>


Here is a post which is somewhat relevant:

>Newsgroups: alt.censorship,news.admin.policy,comp.org.eff.talk
>From: nagle at netcom.com (John Nagle)
>Subject: Appeals court declares child pornography law unconstitutional
>Message-ID: <1992Dec17.232618.19727 at netcom.com>
Summary: New decision by Ninth Circuit may affect BBS operators
>Keywords: law pornography
>Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
>Date: Thu, 17 Dec 1992 23:26:18 GMT

     The Ninth U.S. Circuit Court of Appeals ruled, in US vs X-Citement
Video Inc., (CA No. 89-50556), that the sections of the Protection of
Children Against Sexual Exploitation Act of 1977 that deal with 
distribution, transportation, and receipt of sexually explicit 
materials are invalid on First Amendment grounds.  The court let stand the 
prohibition on the production of child pornography.

     This ruling needs to be looked at more closely, but it may help to
remove sysop worries about someone posting such material on their system
without their knowledge, or about network nodes being liable for 
material passing through them.  This is a step forward, because it was
one of the very few real legal risks a US sysop had to face, and now
it appears to be dead. Do the lawyers out there agree with this analysis?

     Producing child pornography remains illegal, which is reasonable.

					John Nagle


Source: Wall Street Journal, 17DEC92, p. B10 (Western edition)







From yanek at novavax.nova.edu  Sun Dec 20 05:45:43 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Sun, 20 Dec 92 05:45:43 PST
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212200800.AA20904@soda.berkeley.edu>
Message-ID: <9212201344.AA26203@novavax.nova.edu>


> logs.  However, I would not censor any transmissions.  I would stop
> accepting mail from a site given enough reasonable complaints.

That would not help in the least.  The person can still send mail 
through your system, they would just not use you as the first hop.
 
> Dido for me.  I would make an attempt to destroy all of my data if an
> attempt were made to take the equipment or access the data by a government

Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
It merely de-allocates the i-nodes.  You need to know which physical
device the filesystem is on, (let's call id /hdxxx) and then do
'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
on that partition.  For that reason it may be preferable to keep all
such information opn a filesystem of their own, so you don't have to
destroy much other data along with it.

If you use swapping or paging, you need to clear out those devices
too, and then turn the machine off to remove all data in RAM.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From honey at citi.umich.edu  Sun Dec 20 07:56:42 1992
From: honey at citi.umich.edu (peter honeyman)
Date: Sun, 20 Dec 92 07:56:42 PST
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212201344.AA26203@novavax.nova.edu>
Message-ID: <9212201556.AA22792@toad.com>


> Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
> It merely de-allocates the i-nodes.  You need to know which physical
> device the filesystem is on, (let's call id /hdxxx) and then do
> 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
> on that partition.  

not quite.  you need something like

  dd if=/dev/null of=/dev/xxx bs=verybig conv=sync

this will zero out every block on the disk.  but this is overkill --
why not just apply this technique to the individual logs, zeroing
out their data blocks?

	peter

ps:  is it certain that zeroing out the data blocks thoroughly destroys
the data?  i've heard that a "shadow" of some sort may remain.






From bart at netcom.com  Sun Dec 20 09:53:45 1992
From: bart at netcom.com (Harry Bartholomew)
Date: Sun, 20 Dec 92 09:53:45 PST
Subject: Destroying Data
Message-ID: <9212201752.AA24549@netcom.netcom.com>


	In audio recording which uses magnetic media similar to disks
	the only way to thoroughly erase a tape is with a so-called
	bulk eraser. This applies a very strong a.c. magnetic field
	and then is gradually withdrawn from the tape to allow the 
	residual magnetism to "follow the hysteresis curve" down to 
	zero. This would be difficult to apply to disks except floppies.

	Consider also the technique used in the Norton Utilities
	program "Diskwipe" which takes a /g switch which "Follows
	certain government rules for wiping". I can't find the manual
	but I think it specifies how many repetitions are used and
	different values to write in each. 





From ncselxsi!drzaphod at ncselxsi.netcom.com  Sun Dec 20 09:54:49 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod)
Date: Sun, 20 Dec 92 09:54:49 PST
Subject: Avoiding snags in the Law : Remailers.
Message-ID: <24020.drzaphod@ncselxsi>


In Message 19 Dec 92 19:45:33 EST,
  Hal <CompuServe.COM!74076.1041 at netcomsv.netcom.com> writes:

>I suspect that instead the approach would be to claim that remailer
>operators are responsible for the material their remailers produce,
>regardless of its original source.

>Such a policy would be a plausible extension of current Internet
>policies, IMO.  RFC 822, the document which describes the format of
>Internet mail message, in session 4.4.2 discusses the "Sender:" field,
>and says, "Since the critical function served by the 'Sender' field
>is identification of the agent responsible for sending mail and
>since computer programs cannot be held accountable for their behavior,
>it is strongly recommended that when a computer program generates a
>message, the HUMAN who is responsible for that program be referenced
>as part of the 'Sender' field mailbox specification."  [Capitalization
>in the original.]  The need for a person to take responsibility for
>each piece of mail that is sent would tend to lead to the policy
>I mentioned.
>

     Perhaps the solution to this is to run encrypted remailers,
anonymously.  The remailer could either run on it's own, or under
instructions by an anonymous source [i.e PGPed instructions and software
updates signed by the owner who has created a second key for his identity
of remailer operator [Let's call him Oz].

Example:

         Joe creates an account on a random system, installing the nessicary
         software to run a PGP remailer.  This software would be modified to
         accept instructions from a specific anonymous identity, for which
         Joe creates one, leaving the public key with the remailer.  The
         remailer also has it's own key pair to decrypt and forward messages
         [of course].

         People could now route their messages through Joe's remailer to
         anywhere they wish.  The remailer should be set up to NOT keeps
         logs, except errors.

         Now Joe decides he wants to update his remailer with the latest
         scripts.  He mails te scripts [thru various remailers], encrpyted
         with the remailers key and signed by Oz's key.  The remailer
         decrypts the mail, verifies that it belongs to Oz, and updates
         itself.

In this way no person can be held responsible for mail passing thru it's
remailer.  The only way to stop such a remailer would be to downright shut
it down, or to communicate to Oz via the remailer [the scripts would allow
Oz to pick up any mail left directly to the remailer withour a forwarding
header -- of course it would reroute the messages, encrypted, thru various
other well-known remailers].

TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized





From sommerfeld at orchard.medford.ma.us  Sun Dec 20 20:56:59 1992
From: sommerfeld at orchard.medford.ma.us (Bill Sommerfeld)
Date: Sun, 20 Dec 92 20:56:59 PST
Subject: DES source for the HP48SX calculator.
Message-ID: <9212210240.AA00086@orchard.medford.ma.us>


I have implemented a version of the core of the DES algorithm for the
HP 48SX calculator; I mentioned this in passing on this list a couple
of weeks ago.  Anyhow, in the general cypherpunks spirit of things,
I'm willing to share this code...

Note that this only ECB-mode encryption and key schedule computation,
and not decryption.  Both operations take about 12 seconds.. mostly
because they're written in user RPL rather than system RPL or machine
code.

If the person at Berkeley who maintains the cypherpunks FTP archive
wants to get in touch with me, I'd be happy to contribute this file to
the archive; also, I'll mail it to anyone with a US or Canadian email
return address.

					- Bill





From wcs at anchor.ho.att.com  Mon Dec 21 08:11:21 1992
From: wcs at anchor.ho.att.com (Bill Stewart)
Date: Mon, 21 Dec 92 08:11:21 PST
Subject: Destroying Data (Re: Remailer Policies)
Message-ID: <9212211610.AA21587@anchor.ho.att.com>


Yanek points out that "rm" doesn't destroy data on disks, just inodes,
and that you have to overwrite the data to destroy it.  However,
he suggests that you do this by
> 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all
as well as overwriting swap space and powering off RAM.  
Won't work, and it's the hard way to do it: 
cat /dev/null produces zero bytes of output (there's a /dev/zero on
some systems which produces lots of bytes of zeros.)

If you're dealing with amateurs (i.e. local cops or maybe FBI, but not NSA/KGB,
who can take the disk apart and use fancy magnetic techniques),
you can get away with overwriting the data once with zeros or other stuff;
a simple approach is to create a file large enough to fill all the
unallocated space on the disk (either using /dev/zero or writing your own);
be sure to be root so you get the last 10% of a BSD file system.
For professionals, overwrite it once with 0s, once with 1s, and once with
some test pattern like Xs or /etc/termcap.  This still won't help
if there are bad blocks which the disk controller is mapping out
transparently to your system, of course, but amateurs can't read them.
Swap space is tougher - you'll need to look at how your kernel allocates it
to know how to fill it all up, or else zap it all after rebooting your system,
if this is practical.

The government's rules for handling, um, special data say that you either need
an officially approved software program, or an Official Big Magnet,
or else you need to physically destroy the magnetic media from the disk.
I don't like having Big Magnets near my lab, but sandblasting has a
real physicality to it, and floppy disks make this satisfying scrunch in a 
paper-shredder :-)  Needless to say, unless you're Ollie North, 
you shouldn't be shredding your data when the cops are busting you ...


			Bill Stewart, somewhere in New Jersey




From jim at tadpole.com  Mon Dec 21 10:08:34 1992
From: jim at tadpole.com (Jim Thompson)
Date: Mon, 21 Dec 92 10:08:34 PST
Subject: Destroying Data
Message-ID: <9212211807.AA25690@tadpole.tadpole.com>


> 	Consider also the technique used in the Norton Utilities
> 	program "Diskwipe" which takes a /g switch which "Follows
> 	certain government rules for wiping". I can't find the manual
> 	but I think it specifies how many repetitions are used and
> 	different values to write in each. 

SunOS 4.X 'format/analyze/purge', (which was done at the request
of SunFed, for some Fed contract) uses 4 repetitions with patterns:

	0xaaaaaaaa	(10101010)
	0x55555555      (01010101)
	0xaaaaaaaa      (10101010)
	0xaaaaaaaa      (10101010)

Followed by a final pass with:

	0x40404040	(10000000)

Consider this secure if you want.  :-)  For Unix variants, one
might consider a 'patch' to libc that scribbled on the file passed
to the 'unlink()' system call before actually performing the syscall.

This will, of course, break Unix semantics because there is no way
to tell from userland that no other process is holding the file open,
so you'll scribble on the file prematurely.  I guess itrunc() is what
really need changing.

Jim






From hkhenson at cup.portal.com  Mon Dec 21 10:21:48 1992
From: hkhenson at cup.portal.com (hkhenson at cup.portal.com)
Date: Mon, 21 Dec 92 10:21:48 PST
Subject: Remailer Policies
Message-ID: <9212210959.1.29952@cup.portal.com>


Re logs and trying to destroy them when the cops are beating down your
door, wouldn't it be a lot better to keep them encrypted?  Keith





From pages!bwebster at uunet.UU.NET  Mon Dec 21 11:30:02 1992
From: pages!bwebster at uunet.UU.NET (Bruce F. Webster)
Date: Mon, 21 Dec 92 11:30:02 PST
Subject: PKP/RSA comments on PGP legality
Message-ID: <9212211904.AA15552@pages.com>


(Cross-posted with permission of Eben Moglen):

Newsgroups: sci.crypt,alt.security.pgp
From: em21 at cunixf.cc.columbia.edu (Eben Moglen)
Subject:  Re: PKP/RSA comments on PGP legality
Message-ID: <1992Dec17.150409.17696 at news.columbia.edu>
Date: Thu, 17 Dec 1992 15:04:09 GMT

I have been following with interest, and distress, the conversation
about legal risks in using PGP set off by Carl Ellison's posting of
a document said to reflect the legal position of PKP.  Perhaps a
Columbia Law professor's views on these questions may be helpful.   
I'm going to discuss the realities of the situation, without jargon,
rather than the legal technicalities.  Those who want to discuss the
legal detail should feel free to contact me, but for legal advice I
usually get paid.

PKP says that any user of PGP is "inducing" infringement.  Here's the
reality of the situation.  PKP is the licensee of a presumptively
valid US patent, which it claims PGP 2.1 infringes.  If the patent is
valid, and PGP infringes, every user is not just inducing
infringement--he/she/it is infringing the patent.  This is not a
crime; it's a civil wrong, for which, as the PKP statement says,
damages are available at law.  But this is true every time a
manufacturer sells or distributes an infringing article.  As you may
recall, for example, an inventor recently won an enormous damages
judgment against a major US auto company for infringing his patent  
for intermittent windshield wipers.  Theoretically, under the patent  
law, he could instead have notified all Ford buyers in the past  
decade that they were personally infringing his patent.  But it is  
grossly impracticable to do that, and a suit against the manufacturer
accomplishes exactly the same result, since the total amount of the
damages available is the same either way, while the litigation cost  
is not.  PKP can test the validity of its patent and recover its  
damages, if any, in a suit against the developers and distributors of  
PGP, if it cares to.  Without any knowledge of their thinking, I  
predict the partners won't want to do that.  It would be expensive,  
the damages to be recovered would be slight or none, and they would  
risk having the only patent anywhere in the world protecting their  
technology declared invalid.  But in any event, it is virtually  
unheard-of to sue individual end-use consumers of allegedly  
infringing technology.  If PKP's investors had $100 million or so  
they wanted to waste in litigation anything could happen, but they  
don't, and it won't.

In any event, in such a situation a lawyer certainly might advise her
client to wait for the patent-holder to assert his rights directly. 

When PKP sends you a personal letter claiming that you are infringing
its patent, and asking you to take out a license, you can decide what
you want to do about it.  In the meanwhile, the patent claim against
end users is mostly, probably entirely, just noise.

The Munitions Act bluster contained in the post is not even that
important.  It's just ridiculous.  Others have said some of the most
important things well, so I'll be brief.  First, even if PKP believes
its own arguments interpreting the ITARs, PKP doesn't have squat to  
do with ITAR enforcement.  This is a question addressed to the  
discretion of the Treasury, the Department of Justice, and local  
United States Attorneys.  ITAR enforcement against distributors of  
PGP would require a decision by all those agencies that the  
highest-priority Munitions Act enforcement problem at some future  
moment is the prohibition of IMPORTATION of a CONSUMER SOFTWARE  
PRODUCT embodying TECHNICAL INFORMATION IN THE PUBLIC DOMAIN.  I  
challenge PKP, or anyone else, to show any past example of such an  
approach to ITAR enforcement by any Administration.  I cannot myself  
imagine any United States Attorney's office wanting to bring such a  
case, which is of nightmarish complexity, would be politically  
unpopular, and does nothing whatever to stem the global arms trade or  
increase the national security of the US.  I very much doubt that PKP  
really believes that the domestic circulation of PGP violates the  
ITARs, since PKP itself terms as "unfortunate" the application of the  
Munitions Act to cryptographic technology.  But even if that's really  
what PKP or its officers think, so what?  The chances that the United  
States Government will ever agree, and put weight behind agreement,  
are within fuzz of zero.

UseNet serves many social purposes.  One, apparently, is the no-cost
distribution of negative advertising and legal chest-pounding,
intended to frighten people away from experimentation with a piece of
interesting freeware.  Myself, I would just put the PKP temper  
tantrum in the bitbucket.  But since other people have taken it  
seriously (much more seriously than it deserves) I thought a few more  
sober comments might be warranted.
_____________________________________________________________________
Fiat Justitia,         "Quoi que vous fassiez, ecrasez l'infame,
ruat Coelum.                           et aimez qui vous aime."
Eben Moglen                       voice: 212-854-8382
Professor of Law & Legal History    fax: 212-854-7946          
Columbia Law School, 435 West 116th Street, NYC 10027           
moglen at lawmail.columbia.edu
-- 






From phiber at eff.org  Mon Dec 21 16:43:07 1992
From: phiber at eff.org (Phiber Optik)
Date: Mon, 21 Dec 92 16:43:07 PST
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212201556.AA22792@toad.com>
Message-ID: <199212220042.AA27413@eff.org>


> 
> > Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
> > It merely de-allocates the i-nodes.  You need to know which physical
> > device the filesystem is on, (let's call id /hdxxx) and then do
> > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
> > on that partition.  
> 
> not quite.  you need something like
> 
>   dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
> 

Unix weenies of old will recall "clri" to clear an inode.  If paranoia is in
effect, try something like the following:

ls -li remailer-log or whatever to get the i-node number,
then 
clri /dev/sdxx #_of_i-node

Of course, care should be taken to then unlink the file immediately, as if the
i-node number is reused on that filesystem, the old entry would still point
to that i-node, and removing the old file would remove the new one (an
inadvertent hard link).  Clri is in /usr/etc, and it's use is obviously
subjected to your permission of the device file (and the file itself), though
that's understood if you were going to use 'dd'.
Not everyone running a remailer will have permission (usually root) to write
directly to filesystem /dev files, so why not just write a little C program
to open the logfile and overwrite it to the end with NULL's?
Simple.
 





From shipley at tfs.COM  Mon Dec 21 17:07:02 1992
From: shipley at tfs.COM (Peter Shipley)
Date: Mon, 21 Dec 92 17:07:02 PST
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <199212220042.AA27413@eff.org>
Message-ID: <9212220106.AA06240@edev0.TFS>



>> 
>> not quite.  you need something like
>> 
>>   dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
>> 
>
>Unix weenies of old will recall "clri" to clear an inode.  If paranoia is in
>effect, try something like the following:
>
>ls -li remailer-log or whatever to get the i-node number,
>then 
>clri /dev/sdxx #_of_i-node

this will zero out the inode it also does NOT clear the data blocks
just the inode pointers to the data blocks. infact if you do this.

(this you *will* need to umnount and fsck your
system [or reboot if you did this to you root partition]).
in fact if you do this with out deleteing the file first you run a good
chance of crashing the system.


normaly I would say "do not try this at home" but then I would rather
you shot yourself in the foot at home (as opposed to shooting yourself
and who ever is on a public system)

I will post some C/Perl code that will work as a /bin/rm replacement in a
few days.


			-Pete





From miron at extropia.wimsey.com  Tue Dec 22 03:11:25 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Tue, 22 Dec 92 03:11:25 PST
Subject: My remailer and ARA's
Message-ID: <199212221104.AA20951@xtropia>


-----BEGIN PGP SIGNED MESSAGE-----

My remailer does not support ARA's.  This is because the requirement
that incoming messages be completely encrypted with its key (any
portion which is not encrypted in this way is dropped).

In any case, the current scheme for ARA's is insecure.  This is
because people can send plaintext messages attached to the ARA.
This allows breaking anonymity by monitoring of the traffic from
all remailers and waiting until the message appears at one of
the outputs.

I will implement a more secure scheme.  The ARA will include
encryption instructions for each remailer.  Since each remailer
will be doing a transformation on the message, the attack above
will not be feasible.
- --
	Miron Cuperman <miron at extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron at cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortalcryptolaissezfaire	    |

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzb2O5NxvvA36ONDAQG/0QP9GVjH8zjBakbYChxCECGRPb02UJvPC9bj
1lS6GF4KTc5Z9yBejYMSLu5E7lVamgcQFuaBFrSusLyl1oXDcJtCUF4TjxgLCAOi
dXnkbu+k5oB9vLqlZK3nTSmxAuddjrOxbg/AS6M+aIY7rtwkyfnTgj+7pq4pYj6P
/nIpWAB9NHE=
=/i5k
-----END PGP SIGNATURE-----





From honey at citi.umich.edu  Tue Dec 22 05:44:41 1992
From: honey at citi.umich.edu (peter honeyman)
Date: Tue, 22 Dec 92 05:44:41 PST
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <199212220042.AA27413@eff.org>
Message-ID: <9212221344.AA03085@toad.com>


> Unix weenies of old will recall "clri" to clear an inode. ...

clri destroys the file "handle" (the inode, thus the owner, mode,
length, pointers to data blocks, etc.) but not the contents of the
data blocks.  stringing them together is another story, but not
impossible if you know what you're looking for.

>                                 -- so why not just write a little C program
> to open the logfile and overwrite it to the end with NULL's?

u.w.o.o. often go to great lengths to avoid writing a few lines of c,
which, i suppose, is not so bad. 

but i agree with hkhenson that the best way to secure the remailer logs
is to encrypt them.

which raises a sticky point, since i don't see an easy way to do that
on a machine that you can't secure physically.

i'm familiar with the andrew environment (e.g., afs or the andrew
toolkit), which is more or less a kerberos environment, wherein secure
service providers run on physically secure machines.  this lets
sysadmins store cleartext passwords (in essence) on their local disks
to support reauthentication daemons (to refresh tokens for long-lived
jobs, since kerberos tickets time out).

this clearly would not achieve the objectives here.  the only option i
see is to enter a password at boot time (or when the remailer is started).

ick.

	peter





From yanek at novavax.nova.edu  Tue Dec 22 07:04:18 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 07:04:18 PST
Subject: Another pax-type remailer
Message-ID: <9212221503.AA26035@novavax.nova.edu>


Forwarded message:
> Date: Tue, 22 Dec 92 15:24:12 +0200
> From: daemon at anon.penet.fi
> Message-Id: <9212221324.AA14827 at anon.penet.fi>
> To: yanek at novavax.nova.edu
> Subject: Anonymous help.
> 
> 
>               The anon.penet.fi Anonymous Server
>               ==================================
> 
> Yes, another anonymous server. Why?  Well, several well-known servers have
> bitten the dust recently. And most of them have served only a very limited
> subset of newsgroups, and mail only to "registered", anonymous users. One
> quite successful attempt at solving this problem was the server running at
> godiva.nectar.cs.cmu.edu, written and operated by Karl Kleinpaste
> <Karl_Kleinpaste at cs.cmu.edu>. Karl's software has been posted to alt.sources.
> 
> Due to reasons too complicated to mention here I wanted to set up an
> anonymous server for the scandinavian user community. I contacted Karl, and
> got a pre-release copy of his software. As the version I got relied heavily
> on the advanced features of MMDFII, I had to modify it quite a bit. While
> hacking around, I removed the restriction of only supporting selected
> newsgroups. Within a week of startup, the server had been discovered by
> transatlantic users, and more recent stats show european users are definitely
> a minority.
> 
> So what does the anon server really do? Well, it provides a front for
> sending mail messages and posting news items anonymously. As you send your
> very first message to the server, it automatically allocates you an id of
> the form anNNN, and sends you a message containing the allocated id. This id
> is used in all your subsequent anon posts/mails. Any mail messages sent to
> your-id at anon.penet.fi gets redirected to your original, real address. Any
> reply is of course anonymized in the same way, so the server provides a
> double-blind. You will not know the true identity of any user, unless she
> chooses to reveal her identity explicitly.
> 
> In the anonymization process all headers indicating the true originator are
> removed, and an attempt is made to remove any automatically-included
> signatures, by looking for a line starting with two dashes (--), and zapping
> everything from there on. But if your signature starts with anything else,
> it's your own responsibility to remove it from your messages.
> 
> There are two basic ways to use the system. The easiest way is by sending a
> message to recipient at anon.penet.fi:
> 
> 	To: alt.sex.bestiality at anon.penet.fi
> 
> 	To: an9999 at anon.penet.fi
> 
> 	To: help at anon.penet.fi
> 
> Of course, in the case of mailing to a known user, you have to use addresses of
> the form user%host.domain at anon.penet.fi, or the pretty obscure source addressing
> construct of @anon.penet.fi:user at host.domain. These constructs are not
> necessarily handled properly by all mail systems, so I strongly recommend the
> "X-Anon-To:" approach in these cases. This works by you sending a message to
> "anon at anon.penet.fi", including a X-Anon-To: header line containing the desired
> recipient. But this really has to be a field in the message header, before the
> first empty line in the message. So:
> 
> 	To: anon at anon.penet.fi
> 	X-Anon-To: alt.sex.needlework,rec.masturbation
> 
> 	To: anon at anon.penet.fi
> 	X-Anon-To: jack at host.bar.edu
> 
> Valid recipients in both cases are fully qualified user addresses in RFC-822
> format (user at host.domain), anon user id's (anNNN), newsgroup names
> (alt.sex.paperclips) or one of the "special" user names of ping, nick, help,
> admin and stat.
> 
> Sending to "ping" causes a short reply to be sent confirming (and
> allocating, if needed) your anon id. "nick" takes the contents of the
> Subject: header and installs it as your nickname. If you have a nickname, it
> appears in the From: header in the anonymized message along with your anon
> id. "help" returns this text, and stat gives some statistics about the
> system. Mail to "anon" goes directly to me unanonymized, and can be used to
> report problems. If you want to send mail to me anonymously, you can use
> "an0".
> 
> When crossposting to several newsgroups, you can list several newsgroups
> separated by commas (no whitespace) as recipients, but this only works using
> the X-Anon-To: header. References: headers do work, so they can (and should)
> be used to maintain reply threads.
> 
> Ah yes, please remember that the posting takes place at my local site, so you
> can only post to groups that are received at penet.fi. I get all "worldwide"
> groups, but various exotic local groups don't make it here. I have gotten
> a couple of comments about permitting anonymous postings to technical groups.
> I can only answer that I believe very firmly that it's not for me to dictate
> how other people ought to behave. Somebody might have a valid reason for
> posting anonymously to a group I might consider "technical". But remember
> anonymous postings are a privilege, and use them accordingly. I believe adult
> human beings can behave responsibly. Please don't let me down.
> 
> As the server was originally intended to be used by scandinavians, it
> includes support for various languages. The system makes an educated guess
> about your local language based on your top level domain. But it can
> misfire. Fortunately the server doesn't (yet) support urdu, swahili or
> basque... Ah, by the way, if you find it doesn't support your local
> language, and you want to volunteer to translate the message files, get in
> touch...
> 
> The user-id database is based on RFC822-ized forms of your originating
> address. This may cause problems for some users, either because their site
> is not properly registered in the name servers, resulting in
> non-deterministic addresses, or because their mail router doesn't hide the
> identity of individual workstations, resulting in different originating
> addresses depending on which workstation you mail from. Talk to your
> administrator. If that doesn't help, let me know, and I will make a manual
> re-mapping.
> 
> You might wonder about the sense of using a server out somewhere, as the
> song goes, "so close to Russia, so far from Japan". Well, the polar bears
> don't mind, and the ice on the cables don't bother too much :-)
> Well, in fact, as we live in a wonderfully networked world, the major delay
> is not going over the atlantic, but my local connection to the Finnish EUnet
> backbone, fuug.fi. Once you reach a well, connected host, such as
> uunet.uu.net, there's a direct SMTP connection to fuug.fi. My connection to
> fuug.fi is currently a polled connection over ISDN, soon to be upgraded to
> on-demand-SMTP/NNTP. But for now, expect a turn-around delay of 2-4 hours for
> trans-atlantic traffic.
> 
> Oh yes, then there's the question of confidentiality/security. The service
> runs on one of the 386 boxes in my back room at home, and the machine is not
> directly accessible from the internet. So the only one who can get to the
> database is myself. Well, if the police or the local Secret Service comes
> knocking at my door, with a court order to hand over the database, I might
> comply. But then I might, of course, accidentally delete the file instead of
> copying it... And maybe possibly there could be cases where, if somebody could
> come up with really hard evidence of activities such as blackmail, I could be
> persuaded...
> 
> Anyway, short of having everyone run a public-key cryptosystem such as PGP,
> there is no way to protect users from malicious administrators. You have to
> trust my personal integrity. Worse, you have to trust the administrators on
> every mail routing machine on the way, as the message only becomes anonymous
> once it reaches my machine. Malicious sysadmins and/or crackers could spy on
> SMTP mail channels, sendmail queues and mail logs. But as there are more
> than 350 messages being anonymized every day, you have to be pretty perverted
> to scan everything...
> 
> Another thing is mail failures. I've had cases of mail routers doing the wrong
> thing with % addresses, "shortcutting" the path to the destination site.
> This could cause your mail to go to the final destination without ever
> touching my server (and thus without getting anonymized). This can be avoided
> by using the X-Anon-To: method.
> 
> And if your return address bounces for some reason (nameservers down,
> temporary configuration failures etc.), the original sender and/or
> postmasters on the way might get error messages showing your true
> identity, and maybe even the full message.
> 
> And crackers are just too clever. Undoubtedly somebody is going to come
> up with some novel method....  Not much I can do about that...
> 
> If you intend to mail/post something that might cost you your job or
> marriage or inheritance, _please_ send a test message first. The software
> has been pretty well tested, but some mailers on the way (and out of my
> control) screw things up. And if you happen to find a problem, _please_ for
> the sake of all the other users, _let me know asap_.
> 
> And _please_ use the appropriate test newsgroups, such as alt.test or
> misc.test. Yes, _you_ might get excited by reading 2000 "This is a test.."
> messages on alt.sex, but I warn you that most psychologists consider this
> rather aberrant...
> 
> And remember this is a service that some people (in groups such as
> alt.sexual.abuse.recovery) _need_. Please don't do anything stupid that
> would force me to close down the service. As I am running my own company,
> there is very little political pressure anyone can put on me, but if
> somebody starts using the system for criminal activities, the authorities
> might be able to order me to shut down the service. I don't particularly
> want to find out, however...
> 
> If you think these instructions are unclear and confusing, you are right. If
> you come up with suggestions for improving this text, please mail me! Remember
> English is my third language...
> 
> Safe postings!
> 
> 	Julf
> 
> - - - ------------------------------------------------------------------- - - -
> Johan Helsingius     Kuusikallionkuja 3 B 25   02210  Espoo  Finland     Yourp
> net: julf at penet.fi   bellophone: int. +358 0400 2605  fax: int. +358 013900166
> 


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From yanek at novavax.nova.edu  Tue Dec 22 07:11:12 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 07:11:12 PST
Subject: Encrypting Remailer Logs
In-Reply-To: <9212221344.AA03085@toad.com>
Message-ID: <9212221510.AA26463@novavax.nova.edu>


> that the best way to secure the remailer logs is to encrypt them.
> 
> which raises a sticky point, since i don't see an easy way to do that
[...] 
> see is to enter a password at boot time (or when the remailer is started).

There is an easier way.  Just generate a public/private key pair.  Store
the public key on the machine, and have the remailer encrypt its logs
with the public key.  Someone seizing the machine could not find anything,
since they do not have the private key.

Store the private key on another machine, or on a floppy.  When there's
a problem, you can transfer the encrypted log to the machine with the
private key, and then you can decrypt the log to see what went wrong.

Generate a new key pair weekly, and destroy the old private key.  You
should never need logs older than a week for troubleshooting.

p.s.

> > Unix weenies of old will recall "clri" to clear an inode. ...
> 
> > -- so why not just write a little C program ...
> 
> u.w.o.o. often go to great lengths to avoid writing a few lines of c,

So how about a few lines of perl?  

 
--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From honey at citi.umich.edu  Tue Dec 22 08:21:43 1992
From: honey at citi.umich.edu (peter honeyman)
Date: Tue, 22 Dec 92 08:21:43 PST
Subject: Cryptology Column -- New and Coming Books
Message-ID: <9212221621.AA05549@toad.com>


Excerpted and reprinted with the author's permission
from SIGACT NEWS, Volume 23, Number 4

Cryptology Column -- New and Coming Books

Gilles Brassard
brassard at iro.umontreal.CA 

Departement d'informatique et de R.O.  
Universite de Montreal 
C.P. 6128, Succ. ``A'' 
Canada H3C 3J7

31 October 1992

Research supported in part by the
E.W.R. Steacie Memorial Fellowship
(Canada's Nserc).

1  Introduction

An outstanding book on cryptology has hit the market this year.
Although the news may be stale to many of my readers, Gustavus J.
Simmons has edited a 640-page mammoth of a masterpiece titled
Contemporary Cryptology: The Science of Information Integrity,
published by IEEE Press.  In addition, other new and exciting books
are expected to come out soon.

2  Simmons' Book

Simmons' Contemporary Cryptology grew out of a special issue of the
Proceedings of the IEEE, which he edited in May 1988.  I remember how
proud -- and rightly so! -- Simmons was concerning that issue: his
favourite line was that ``this is an example where the whole is better
than the sum of its parts''.  As a consequence of the excellent
reception of his special issue, he was commissioned by the IEEE to edit
the book we are now discussing.  Speaking of excellent reception, the
first printing of Simmons' book was sold out in months.  The second
printing, which I have not seen yet, corrected all mistakes that had
been found in the first.  In addition, reference citations for
publications that had appeared after the first printing went to press
were completed, and a number of footnotes, notes added in proof and
inserted paragraphs to update significant statements of fact that had
occurred in the interim were made.

It is amusing to note that the book's cover is very similar to that of
the Proceedings, except that Simmons corrected an embarrassing mistake
that I pointed out to him on the Proceedings cover (see if you can spot
it!).  The book is hard cover, pleasant to manipulate, and handsome.
Unfortunately, I found the binding of my own copy to be slightly
defective, but I was told that this problem was corrected with the
second printing.

Contemporary Cryptology is a collection of chapters, many of which
written by top researchers in the field, which together span most of
the exciting developments that have changed cryptology forever in the
past twenty years.  Simmons himself contributed the foreword and three
chapters.  His master plan -- the table of contents -- is well
conceived as few important topics have been left out.  (Nothing is
perfect, though ... the book is lacking a chapter on quantum
cryptography!) Unfortunately, even a good coach cannot enforce perfect
coordination concerning who says what in a multi-author work.  This
book is no exception: it suffers from many repetitions of the same
concepts across chapters.

The main sections of the book are Cryptography, Authentication,
Protocols, Cryptanalysis, and Applications.  This is preceded by two
essays on the theme ``Contemporary Cryptology'': a foreword by Simmons
and an introduction by James L. Massey.  Massey's introduction to
cryptology is among the clearest and most useful I have ever seen that
can fit on as few as 36 pages (although another particularly noteworthy
concise introduction is Simmons' own entry in the Encyclopaedia
Britannica).  Massey's introduction covers some history, motivations,
all the basic notation, secret key cryptography (both in theory and in
practice, including a review of Shannon's information theory, the DES,
stream ciphers and Ueli Maurer's recent bid to get around Shannon's
discouraging theorem that the one-time-pad is the most economical
system that can provide perfect secrecy), authentication (a section
that I found particularly useful last time I taught on the subject),
public key cryptography (including one-way functions, public key
distribution, RSA and variations on the theme), and protocols.  Massey
even includes an enlightening discussion of secret versus open research
in cryptology.  One thing I learned from Massey's introduction is that
the notion of one-wayness goes back to at least 1873!  On the negative
side, nothing is said about probabilistic encryption and zero-knowledge
protocols, and digital signatures are not covered adequately.  But
then, Massey makes an explicit point that it was not his purpose to
survey research in cryptology.  Moreover, these topics are treated in
other chapters of Simmons' book.

After the foreword and introduction, the first section deals with
cryptography.  The topics covered are ``The DES: Past and Future'' by
Miles E.  Smid and Dennis K. Branstad, ``Stream Ciphers'' by Rainer A.
Rueppel, ``The First Ten Years of Public Key Cryptography'' by
Whitfield Diffie, ``Public Key Cryptography'' by James Nechvatal, and
``A Comparison of Practical Public Key Cryptosystems Based on Integer
Factorization and Discrete Logarithms'' by Paul C. van Oorschot.  The
chapter on DES goes from the birth of the system to predictions
concerning the coming decade, not forgetting to cover the controversy
surrounding it and its many applications.  New, post-DES algorithms are
also discussed.  However, the coverage of attacks against DES is far
from complete; in particular, differential cryptanalysis is not even
mentioned.

Rueppel is a leading expert in stream ciphers, and the author of a
well-known book on the topic; he was therefore the natural choice of
author for Simmon's second chapter.  After introducing all the relevant
background, Rueppel covers information-theoretic, system-theoretic and
complexity-theoretic approaches to stream ciphers.  A large number of
pseudo-random generators are described.  The chapter also considers
randomized stream ciphers, which can provide practical provable
security in the presence of a large,  publicly accessible, body of
randomness.

Diffie's chapter on the history of public key cryptography is a pure
gem, which could only have been told so well by the horse's mouth.  In
my opinion, Simmons' book would be worth buying even if only for those
39 pages.  Of particular interest is the story of how Ralph Merkle,
then at Berkeley, invented as early as 1974 the concept of public key
distribution, and how unsuccessful he was in explaining and publishing
his idea.  (Merkle told me that Bob Fabry, contrary to many others, had
understood the idea and had encouraged him to seek fame and fortune
with it!) Diffie goes on explaining the principles of public key
cryptography and the early solutions, including RSA.  An interesting
section on key management, the main aspect that was sorely missing from
the early papers on public-key cryptography, is provided.  Diffie's
chapter continues with applications, such as the secure phone system,
and implementations.  Finally, Diffie goes beyond what his title
promised, as he tackles new directions for public key cryptography.

The next chapter, by Nechvatal, is by far the longest in this book (120
pages).  It was written as a stand alone piece, which is unfortunate in
this context as it presents significant overlap with other chapters of
the book.  In my opinion, the author would have been better advised to
transform his writing into a monograph of its own.  Nevertheless, this
chapter is well written and contains a wealth of valuable information.

In the last chapter of the first section, van Oorschot reviews the
currently best algorithms for extracting discrete logarithms (both in
GF(2^n) and in elliptic curves) and for factoring, including a detailed
analysis of their efficiency.  This is used as the basis of a
comparison between El Gamal's cryptosystem and RSA.  Elliptic curve
cryptosystems are also considered.

Section 2 deals with authentication.  It is composed of one chapter on
``Digital Signatures'' by Chris J. Mitchell, Fred Piper and Peter Wild,
and ``A Survey of Information Authentication'' by Simmons.  The chapter
on digital signatures provides thorough coverage of the theory,
practice and applications of signatures, including a section on
hashing.  Nonetheless, it is sad that David Chaum's elegant notion of
Undeniable Signature did not find its way in that chapter even though
it was published as early as 1989.  The next chapter was written by the
man I consider to be no less than ``the Shannon of authentication'',
the book's editor himself.  Indeed, Simmons developed in the 1980's a
theory of authentication that parallels that of Shannon for privacy.
This chapter shows a good balance between theory and practice, which
could also be said about its author.  I must admit, however, that I
found Massey's exposition of Simmons' theories in the Introduction
easier to follow than Simmons' own.  Nevertheless, I read this chapter
with particular interest and enjoyment.

The next section deals with protocols.  It consists of an ``Overview of
Interactive Proof Systems and Zero-Knowledge'' by Joan Feigenbaum and
``An introduction to Shared Secret and/or Shared Control Schemes and
Their Applications'' again by Simmons.  It must be pointed out that the
very important (in my opinion) topic of multi-party computation, also
known as ``post-cold war cryptography'', is missing altogether from
this section on protocols and indeed from the entire book as far as I
can tell.  I like Feigenbaum's succinct exposition of interactive
proofs and zero-knowledge, even though it was written more from a
computational complexity point of view than from a cryptographic point
of view.  For instance, the existence of an interactive proof system
for the permanent is of considerable interest in complexity theory, as
it lead the way to Shamir's proof that IP = PSPACE (see my column in
Vol. 21, no. 1, 1990) but I fail to see its direct cryptographic
significance.

Turning now to the chapter on secret sharing, I can think of no one
better suited than Simmons for writing it.  After reviewing Shamir's
and Blakley's (very different) original ideas, he addresses access
structures more general than simple threshold schemes.  Most of the
schemes explained are based upon geometric considerations.  An
application to key distribution is provided.  A comprehensive
bibliography follows.

The fourth section deals with cryptography's sister discipline:
cryptanalysis.  It consists of one chapter on ``Cryptanalysis:  A
Survey of Recent Results'' by Ernest F. Brickell and Andrew M. Odlyzko,
and one chapter on ``Protocol Failures in Cryptosystems'' by Judy H.
Moore.  The chapter on cryptanalysis surveys recent cryptanalytic
achievements.  Particularly thorough treatment is given to the breaking
of the knapsack and of linear congruential generators.  Other
cryptosystems and signature schemes are covered.  Information is also
provided on the state-of-the-art concerning the cryptanalysis of yet
unbroken systems such as RSA, discrete exponentiation schemes, the
McEliece cryptosystem, and the DES.  Recent developments such as the
number field sieve for factoring and the differential cryptanalysis
technique are mentioned, but Biham and Shamir's attack on the full
16-round DES was achieved only after Simmons' book went to press.

Moore's chapter on protocol failures addresses an interesting problem:
it tells you how to cheat an application centered around a cryptosystem
without in fact breaking the cryptosystem itself.  In other words, even
good cryptosystems are potentially vulnerable when improperly used, or
when used according to a badly designed protocol.  Guidelines are given
to avoid such traps.  (Perhaps the most spectacular protocol failure in
history concerned the Enigma during World War II, but this is of course
not treated in Moore's chapter!)

The book closes with a section on applications.  It contains one
chapter on ``The Smart Card:  A Standardized Security Device Dedicated
to Public Cryptology'' by Louis C. Guillou, Michel Ugon and
Jean-Jacques Quisquater, and a chapter on ``How to Insure That Data
Acquired to Verify Treaty Compliance Are Trustworthy'', once more by
Simmons.  The chapter on smart cards describes what a smart card is and
what it can do.  The important issue of standardization is treated at
length.  Significant information is given on the technology behind
smart cards.  Naturally, most of the chapter is concerned with security
issues and cryptographic applications, such as authentication.  The
book's final chapter deals with real life field work pioneered by the
editor at Sandia National Laboratories, which is the result of nearly
two decades of development.  I prefer to say no more so as to keep your
appetite whetted!

In conclusion, this is a remarkable book, which I very strongly
recommend as necessary addition to the library of any serious
researcher in the field of cryptology.

3  Other books

These are exciting times for cryptoreaders.  In addition to Simmon's,
other promising books are due to appear soon.  Even though I prefer to
wait until they have come out to review them in detail (despite the
fact that I have seen preliminary versions), I cannot resist the
temptation to give you an avant gout.

Eli Biham and Adi Shamir have written up in great detail their
differential cryptanalysis technique and how it applies to the full
16-round DES as well as to other cryptosystems and hashing functions.
This is along the lines of Volume 4, number 1 of the Journal of
Cryptology, only more of it and better.  The preliminary title of their
book is Differential Cryptanalysis of the Data Encryption Standard.  It
will be published by Springer-Verlag.

Starting from notes taken by the students of a class he taught at the
University of California, Berkeley, Mike Luby has written
Pseudorandomness and Applications, which will be published by Princeton
University Press.  The book, now complete in the opinion of its author,
is undergoing a review process.  In it, Luby places pseudorandomness at
the heart of cryptography.  He explains how to produce
cryptographically secure pseudorandomness and how to use it for various
cryptographic purposes.  As one of the researchers to whom we owe the
proof that one-way functions are necessary and sufficient to obtain
cryptographically strong pseudorandom generators, Luby was the logical
author to write this authoritative book.

In addition, allow me to indulge in mentioning that my own
Springer-Verlag monograph Modern Cryptology:  A Tutorial is expected to
come out in French this November.  It will be published by Masson under
the title of Cryptologie Contemporaine.  Contrary to the previous
translation into Italian (also published by Masson), the French version
(translated by Claude Goutier) was fully revised and updated by the
author.  For instance, the number of references went up from 250 to 366
(you better tackle them on a leap year if you cannot handle more than
one per day!).

Have you written something lately?  If you have, I would appreciate
hearing about it.





From 74076.1041 at CompuServe.COM  Tue Dec 22 09:02:47 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Tue, 22 Dec 92 09:02:47 PST
Subject: Remailer encryption.
Message-ID: <921222165347_74076.1041_DHJ39-2@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

From: miron at extropia.wimsey.com (Miron Cuperman)

> In any case, the current scheme for ARA's is insecure.  This is
> because people can send plaintext messages attached to the ARA.
> This allows breaking anonymity by monitoring of the traffic from
> all remailers and waiting until the message appears at one of
> the outputs.
> 
> I will implement a more secure scheme.  The ARA will include
> encryption instructions for each remailer.  Since each remailer
> will be doing a transformation on the message, the attack above
> will not be feasible.

I'd like to hear more about this plan.  What kind of encryption
instructions would be used in the ARA?  Would they be public key or
secret key?

Chaum's "Mix" paper in CACM (1981?  I don't have my refs handy) had
a concept where at each step the remailer would encrypt the outgoing
non-address part of the message with a DES key found in the anonymous
address.  The user would remember all the DES keys used in the ARA
and un-apply them in reverse order to reconstruct the original message.
This would require some special software, I'd think, to remember the
DES keys and unapply them (and to construct the anonymous address).
(Actually, Chaum didn't specify DES but rather just an unspecified secret
key system.  If PGP were used for some of this then perhaps IDEA would
be a good choice.)

This system sounded pretty complicated, and it still had the problem
that by sending multiple messages to the same address a remailer could
do some simple traffic analysis and break the ARA.  E.g. it would send
5 messages to an ARA today, and discovers that it later gets 5 messages
for user X (because it happens to be the last remailer in the ARA chain).
Tomorrow, it sends 10 messages to that same ARA, and discovers 10 messages
for that same user.  The next day it sends 7 messages to the ARA, and
discovers 7 messages for that user.  Eventually it can deduce that the
user and the ARA go together.

To avoid this, Chaum calls these "one-time" ARA's and recommends that
mixes not accept messages for the same ARA more than once.  I don't
think this is a practical suggestion, though, since a one-time ARA is
not useful enough.

Hal Finney
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzcdKKgTA69YIUw3AQFK9wP/a27AgcL4ppMpYIbDfBy6Vw8NTjJzKpsL
hQibQ3XO3wPFURS3Mn51eYLyYRuJPY1/Ve+Y1Kbb6oLiW1u8Btw8CxvB1xe05f32
j0JwzSN1yL8blGMh4JxxXZI0t3SViJ1COt6p+I1SYLjftte/0YX0gc6dweFNUnkZ
5VC4FH2WCbQ=
=+Jx9
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From 74076.1041 at CompuServe.COM  Tue Dec 22 09:03:06 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Tue, 22 Dec 92 09:03:06 PST
Subject: Remailers.
Message-ID: <921222165319_74076.1041_DHJ39-1@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

One problem with the current encrypted remailers that people should
be aware of is that, since they operate unattended, they have to be
able to decrypt messages automatically.

This means that when an incoming messages arrives, the remailing software
automatically runs PGP on the incoming message to do the decryption.
But to decrypt, PGP has to be given the pass phrase for the remailer's
secret key.  The only way this can be done is to have the pass phrase,
IN THE CLEAR, in the remailing software scripts.

The scripts are (or should be) protected using the Unix file system
so that only the owner and root can read them.  But it's important to
know that root has access both to the secret key ring which holds the
remailer's key, and to the pass phrase which will activate that key.
This means that, at any time, root can find out the secret key of the
remailer, and read all messages encrypted for that remailer.

I don't think there is any way around this problem if the remailer is
going to run unattended.  The only real solution is to operate on a
machine where it doesn't matter whether root knows the key; that is,
a machine where root is the operator of the mailing list.

Hal
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzcZ0agTA69YIUw3AQEFhAQAlloC1eyaIuJDG91VzPoRv0MjzKlob8Te
C3N7XWLvszypOgKNBoEb1z8fF5ZsS20NhhRhtr7A3J4jxe88vGuea0Kvxzj4NGd4
bQeewhYk01ygoLzZOwv8BnN6pE7/uxk5POWq3XQuX80VQzistePfRRdNozTA09EY
4bBOr3s9Ig8=
=nJ/a
-----END PGP SIGNATURE-----

My public key, signed by PRZ:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From yanek at novavax.nova.edu  Tue Dec 22 10:59:24 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 10:59:24 PST
Subject: IEEE Ordering Info
Message-ID: <9212221858.AA07594@novavax.nova.edu>


If you want to order the book Peter posted about, call 800 678 4333,
press 1, then ask for Contemporary Cryptology book by Simmons.  

It's $79.95 (+$6 s/h).  Probably less if you are a member of IEEE.

I am in no way associated with IEEE Press, I just ordered the
book, and wanted to make it simple for anyone else who wants to.

(I ftp'd an info file from ieee.org, got a non-800 phone number,
called, was transfered and put on hold for x number of times, until
someone was able to give me the above 800 number that can be used
to order their publications.  I didn't want everyone to have 
to do this).


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819







From jim at RSA.COM  Tue Dec 22 12:12:44 1992
From: jim at RSA.COM (Jim Bidzos)
Date: Tue, 22 Dec 92 15:12:44 EST
Subject: RIPEM message for your approval
In-Reply-To: <9212221821.AA16897@scss3.cl.msu.edu>
Message-ID: <9212222010.AA22792@RSA.COM>




Mark-

As you can imagine, many changes have been proposed, and, I think,
some good ones incorporated, in the most current form of the RSAREF
license. These changes are based on constructive comments from over
twenty people. These changes may encourage folks to distribute RSAREF
and RIPEM who otherwise would not have.

We plan to make all RSAREF applications (such as RIPEM) availble WITH
RSAREF.  Why shouldn't someone get all the stuff built on it if they
get RSAREF? (Including helpful code such as the Thompson/Schiller
emacs adapter.) I assume you have no objection.

I'm hopeful that you see these changes as positive; please let me know
if that's not true! I offer a summary of them, the rationale,
perceived benefits, and a complete copy of the revised license.

------------------------------------------------------------------

Here's a summary of the changes between what's attached (the one we
plan to now "standardize" on for RSAREF) and what you sent me:

changed 1(a) and added (8): the license is now perpetual. Some have
claimed RSA might "suddenly" decide to cancel RSAREF licenses. It is
now crystal clear that the license can only be cancelled by violating
the agreement. RSA cannot cancel it at its discretion. And even if you
violate it, it doesn't cancel the license of those who got it from
you. I think this is an importnat clarification, from what I've heard.

changed 1(c) and added 2(d): We don't care about any porting or
performance mods, but we don't feel we should allow automatic access
under the normal interface. We've granted it to you since RIPEM
predates RSAREF (also to John Gilmore for a secure RLOGIN using
Diffie-Hellman) and we'll grant it to anyone for any reasonable use.
(We state so in the Agreement.)  We just want to know what it is we're
allowing to go around the interface.

End of Section 1 - a clarification in the form of an addition is made
here. Some have said that unrelated software on a tape with RSAREF
could be covered by the restrictions imposed on RSAREF Application
Programs. This should clear that up. (I believe this helps you in the
separate distribution of the RIPEM code minus the RSAREF code.)

changed (6): We simply have removed RSA's $5,000 cap on protecting
RSAREF users against charges from some other patent holders. (Like
PKP!) Some have claimed that RSAREF was posibly a way to "set up"
users for PKP (the patent holders) since $5K was hardly enough to
defend against patent infringement.  (They actually thought RSAREF was
a way to get people to infringe just so that PKP could sue them! RSA
pays $5,000, but PKP collects more, therefore it's a 'you hold em, and
I'll hit em' thing, or so I guess they thought.) I believe this makes
it clear we intend to sue no one for using RSAREF, and in fact defend
users ALL THE WAY if someone else does.

I think these are all for the better, and will engender trust in RSA's
intentions with RSAREF, to support free PEM.

---------------------------------------------------------------------

New RSAREF License  (December 1992 version)

----------------------------------------------------------------------
                           RSA LABORATORIES
                      PROGRAM LICENSE AGREEMENT



RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA")
GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM:

1.   LICENSE. RSA grants you a non-exclusive, non-transferable,
     perpetual (subject to the conditions of section 8) license
     for the "RSAREF" program (the "Program") and its associated
     documentation, subject to all of the following terms and
     conditions:

     a.   to use the Program on any computer in your possession;

     b.   to make copies of the Program for back-up purposes;

     c.   to modify the Program in any manner for porting or
          performance improvement purposes (subject to Section 2)
          or to incorporate the  Program into other computer programs 
          for your own personal or internal use, provided that you 
          provide RSA with a copy  of any such modification or 
          Application Program by electronic mail, and grant RSA 
          a perpetual, royalty-free license to use and distribute 
          such modifications and Application Programs on the terms 
          set forth in this Agreement.

     d.   to copy and distribute the Program and Application Programs
          in accordance with the limitations set forth in Section 2.

"Application Programs" are programs which incorporate all or any
portion of the Program in any form. The restrictions imposed on
Application Programs in this Agreement shall not apply to any software
which, through the mere aggregation on distribution media, is
co-located or stored with the Program.

2.   LIMITATIONS ON LICENSE.

     a.   RSA owns the Program and its associated documentation and
          all copyrights therein. You may only use, copy, modify and
          distribute the Program as expressly provided for in this
          Agreement. You must reproduce and include this Agreement,
          RSA's copyright notices and disclaimer of warranty on any
          copy and its associated documentation.

     b.   The Program and all Application Programs are to be used only
          for non-commercial purposes. However, media costs associated
          with the distribution of the Program or Application Programs
          may be recovered.

     c.   The Program, if modified, must carry prominent notices
          stating that changes have been made, and the dates of any
          such changes. 

     d.   Prior permission from RSA is required for
          any modifications that access the Program through ways
          other than the published Program interface or for 
          modifications to the Program interface. RSA will grant
          all reasonable requests for permission to make such
          modifications.

3.   NO RSA OBLIGATION. You are solely responsible for all of your
     costs and expenses incurred in connection with the distribution
     of the Program or any Application Program hereunder, and RSA
     shall have no liability, obligation or responsibility therefor.
     RSA shall have no obligation to provide maintenance, support,
     upgrades or new releases to you or to any distributee of the
     Program or any Application Program.

4.   NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED
     DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR
     PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
     PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF
     THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE
     PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA)
     ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR
     CORRECTION.

5.   LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN
     SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS
     BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE
     PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY
     DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN
     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

6.   PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set
     forth below, RSA, at its own expense, shall: (i) defend, or at
     its option settle, any claim, suit or proceeding against you on
     the basis of infringement of any United States patent in the
     field of cryptography by the unmodified Program; and (ii) pay
     any final judgment or settlement entered against you on such
     issue in any such suit or proceeding defended by RSA. The
     obligations of RSA under this Section 6 are subject to: 
     (i) RSA's having sole control of the defense of any such claim, 
     suit or proceeding; (ii) your notifying RSA promptly in writing
     of each such claim, suit or  proceeding and giving RSA authority
     to proceed as stated in this  Section 6; and (iii) your giving 
     RSA all information known to you relating to such claim, 
     suit or proceeding and cooperating  with RSA to defend any such 
     claim, suit or proceeding. RSA shall have no obligation under 
     this Section 6 with respect to any claim to the extent it is 
     based upon (A) use of the Program  as modified by any person 
     other than RSA or use of any Application Program, where use 
     of the unmodified Program would not constitute an infringement, 
     or (B) use of the Program in a manner other than that permitted 
     by this Agreement.  THIS SECTION 6 SETS FORTH RSA'S ENTIRE 
     OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR  
     PROPRIETARY RIGHTS INFRINGEMENT.

     NOTE: Portions of the Program practice methods described in and
     subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829,
     and all foreign counterparts and equivalents, issued to Leland
     Stanford Jr. University and to Massachusetts Institute of
     Technology. Such patents are licensed to RSA by Public Key
     Partners of Sunnyvale, California, the holder of exclusive
     licensing rights. This Agreement does not grant or convey any
     interest whatsoever in such patents.

7.   RSAREF is a non-commercial publication of cryptographic
     techniques. Portions of RSAREF have been published in the
     International Security Handbook and the August 1992 issue of Dr.
     Dobb's Journal. Privacy applications developed with RSAREF may be
     subject to export controls. If you are located in the United States
     and develop such applications, you are advised to consult with the
     State Department's Office of Defense Trade Controls.

8.   TERM. The license granted hereunder is effective until
     terminated. You may terminate it at anytime by destroying
     the Program and its associated documentation. The termination
     of your license will not result in the termination of the
     licenses of any distributees who have received rights to the
     Program through you so long as they are in compliance with
     the provisions of this license.


-----------------------------------------------------------------










From gnu at cygnus.com  Tue Dec 22 18:00:24 1992
From: gnu at cygnus.com (gnu at cygnus.com)
Date: Tue, 22 Dec 92 18:00:24 PST
Subject: Amtrak San Jose - San Diego for Usenix
Message-ID: <9212230159.AA19415@cygnus.com>


Costs $107 round trip, and takes about 14 hours each way.

FYI.

	John





From edgar at spectrx.Saigon.COM  Tue Dec 22 19:40:22 1992
From: edgar at spectrx.Saigon.COM (Edgar W. Swank)
Date: Tue, 22 Dec 92 19:40:22 PST
Subject: Remailers
Message-ID: <ywm8VB8w165w@spectrx.saigon.com>


I'd like to thank Eric Hughes and Mike Sherwood (who wrote privately)
and Hal Finney (who responded here) to my requests for enhancements to
Eric's remailer code.
 
By the way, Hal, your signature did not match the associated
plaintext:
 
   WARNING: Bad signature, doesn't match file contents!
 
   Bad signature from user "Hal Finney <74076.1041 at compuserve.com>".
   Signature made 1992/12/19 21:43 GMT
 
This is likely due to some trailing blanks in your plaintext. I've
written to Branko to try to get PGP to remove trailing blanks if
-t is active.
 
First, I'm glad Eric agrees that anonymous posting to newsgroups
is a good idea and is on his "to do" list. Until then, thanks to
Hal for posting the info about the ucbvax gateway. I had that info at
one time, before hearing about remailers, but discarded it since I
thought I'd never use it.
 
I'm sorry Eric doesn't agree that stripping the .sig is a good idea.
I respectfully dissent. I've found that I can probably disable
my own automatic .sig, so I suppose this isn't too urgent.
Nevertheless, I would think it desirable to make remailers as easy to
use as posible. Having to remember to disable the automatic .sig is
certainly an inconvenience.  Forgetting to do so could potentially
be very embarrassing or even incriminating!!
 
The pax remailer uses "--" or "__" as sig delimiters (according to
their docs) & apparently this is satisfactory.  I think this means
that "----" would NOT be a delimiter, so it would be unlikely to be
used by mistake.  I wouldn't mind a more explicit delimiter, for
example
 
::--Remailer cut HERE--
 
if Eric thinks "--" is too ambiguous or is likely to be used
inadvertantly in the middle of a msg.  Anyway I guess I can
muddle through for the time being.
 
I agree with Hal that the pax remailer can probably be the first
in a chain to Eric remailers.  Probably also the last in a chain
of Anonymous returns.  But I don't see how pax could be used in
the middle of a chain.  I would encourage Eric to correspond with
the guy running the pax remailer:
 
   anon.admin at pax.tpa.com.au (a human)
 
to see if you couldn't come up with a common remailer code with best
features of both.  Certainly it would be great to have an Eric-style
remailer running in Australia!!

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From dasher at well.sf.ca.us  Tue Dec 22 20:00:22 1992
From: dasher at well.sf.ca.us (D Anton Sherwood)
Date: Tue, 22 Dec 92 20:00:22 PST
Subject: Remailer Policies
Message-ID: <199212230354.AA20595@well.sf.ca.us>


Keith Henson asked:
> Re logs and trying to destroy them when the cops are beating down your
> door, wouldn't it be a lot better to keep them encrypted?  Keith
 
Here's a lame question from a beginner who hasn't even downloaded PGP:
 
Am I supposed to memorize my private key, lest cops beat down the door while
I'm out?
 
Anton Sherwood                                          dasher at well.sf.ca.us
+1 415 267 0685                 1800 Market St #207, San Francisco 94102 USA





From karn at qualcomm.com  Tue Dec 22 20:07:09 1992
From: karn at qualcomm.com (Phil Karn)
Date: Tue, 22 Dec 92 20:07:09 PST
Subject: Signing ascii text
Message-ID: <9212230406.AA28094@servo>


I see some potential problems here as people start signing ASCII text
(e.g., email messages, etc). Is there a convention for the end of line
sequence that is to be used for the copy of the file that is run through
the hash function? If there isn't, then the file hash will depend on the
local end-of-line convention, which is bad.

I'm facing this problem right now in an experimental "XMD5" command that
I've added to my FTP server. The idea is to let you compute a hash on
a remote file so you can compare it with a local file without actually
having to send it. It works great in binary mode, but ascii mode is
problematic.

Phil





From yanek at novavax.nova.edu  Tue Dec 22 20:32:03 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 20:32:03 PST
Subject: Signing ascii text
In-Reply-To: <9212230406.AA28094@servo>
Message-ID: <9212230431.AA25182@novavax.nova.edu>


> (e.g., email messages, etc). Is there a convention for the end of line
> sequence that is to be used for the copy of the file that is run through
> the hash function? If there isn't, then the file hash will depend on the

Canonical Text has a CR and LF at the end of each line.  This is 
documented in some RFC.  All (most?) protocols used on internet such
as smtp, finger, etc, use this format.  The possible justification
is that an extra linefeed or a carriage return is not as bad as a missing
one.  

For e-mail you may have other problems, if the messages go through
gateways that like to munge messages.  For example your tabs could
be expanded into spaces, or the other way around.  Some character
set conversions may be done.

Blank lines may be removed or added.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From karn at qualcomm.com  Tue Dec 22 21:10:41 1992
From: karn at qualcomm.com (Phil Karn)
Date: Tue, 22 Dec 92 21:10:41 PST
Subject: Signing ascii text
Message-ID: <9212230509.AA28220@servo>


Okay, the cr/lf convention is what I suspected was the case. That's what
I'll implement. Can't do much about the munged messages...

Phil





From 74076.1041 at CompuServe.COM  Tue Dec 22 21:53:28 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Tue, 22 Dec 92 21:53:28 PST
Subject: Signing text messages...
Message-ID: <921223054929_74076.1041_DHJ39-1@CompuServe.COM>


My public key, for those wanting to check the sig on the message below:

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNED MESSAGE-----

Phil Karn asks about end-of-line conventions for signed text messages.
PGP uses the convention of lines terminated by carriage-return-line-feed.
On Unix systems or other systems which don't use that convention,
it attempts to change the message into this "canonical" text mode
before calculating or checking the signature.

The issue of trailing blanks is more problematical.  Some mail gateways
and some mail "user agent" software apparently take liberties with
blanks at the end of lines.  The PGP canonical text format does not
include any specification for whether lines could or could not have
blanks at the end.  If mailers will leave trailing blanks alone, then
PGP cleartext signed messages will have correct signatures.  If some
intervening mailer has added or removed trailing blanks, then the
signatures will be wrong.  Presumably something like this has happened
to my signed message on which Edgar found a bad signature.  Perhaps
Edgar could try stripping any trailing blanks from his copy of my
message and see if it then signature-checks OK.  I'll double-check
that this message is signed with no trailing blanks.  Then if you get
a bad signature, I predict that you must have trailing blanks in your
copy of the file.  I'd appreciate hearing whether this prediction is
correct.

It would be possible to change PGP's canonical text format
to specify that lines have no blanks at the end.  In that case, PGP
would, whenever it computed or checked a signature on a text file,
process the file to make sure that each line ended with a CRLF preceded
by no trailing blanks.  I think this would solve a lot of the gateway
problems.  But it would be a somewhat more "aggressive" change to what
the user is asking PGP to sign.

The design of PGP's cleartext signature was influenced by PEM, which
also uses a canonical text format for line terminators, but doesn't
deal with trailing spaces, as far as I know.

The real solution, IMO, is to fix those broken mailers that add
or remove spaces.  I don't see why this behavior has ever been put
into mail gateways.

Hal Finney
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzfNHqgTA69YIUw3AQGNdwP/Q51Lvmee1cTb865aInePsRxMTe4qfjeU
DSP8o5hHlBKbII8mCrU/WHZ7upjO3ak4E6wZDyOexsfJFH4FIMnDueihrVVXevlA
FWUQopZIyG4P5Wzofgra8BSjw5WzVZncW2alPQFuB40D9N9VgyopX8IktktVPs4p
qDkHsn9zIpU=
=K/Ui
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From 74076.1041 at CompuServe.COM  Tue Dec 22 21:55:46 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Tue, 22 Dec 92 21:55:46 PST
Subject: Pax and .fi remailers
Message-ID: <921223054957_74076.1041_DHJ39-2@CompuServe.COM>


Upon more thought, I don't see a really good way to use the PAX
remailer in conjunction with our remailers based on the scripts of
Eric Hughes.  The PAX remailer can only be used to send messages to
those who have "registered" with the remailer to receive an anonymous
ID there.  So, for PAX to work with our remailers we would have to
register.  For example, my remailer at hal at alumni.caltech.edu would
have to register with PAX and receive an anonymous ID, like
"anon.100 at pax.tpa.com.au".

Then, to use a two-hop remailer consisting of first PAX and then mine,
you would prepare a message as usual for my remailer:

====================
::
Request-Remailing-To: dest

This is a message for two-hop anonymous remailing.
====================

Perhaps you would encrypt this using my remailer's public key, getting:

====================
::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.1

hEwCG6rHcT8LtDcBAfwLWYgWXpCoi7TjoeVttBYpk3KPbiYf9L9CCegfYlvj56RA
OFrijYag+jqNlHQXmO52bXL8PaNUowD7a2pFY80WpgAAAGt/RXNzaWkI/b3CkviB
eh/piaUDxgfPd4npcURHtUCEeh8bPpzVaI9qm6xZlxSaJif+CtFqyuaRezj+hcXR
YT9JOl93LAxQJITeYUlPXgkBEvyB4u3HjpCDSS5NETDcqd8rtBspzUvlcmqT1g==
=d356
-----END PGP MESSAGE-----
====================

You would then send this to anon.100 at pax.tpa.com.au.  (NOTE: Don't
try this - I haven't yet gotten an anonymous ID at PAX.)  PAX
would forward it to my remailer, unchanged, which would then decrypt
it and send it onward.  Oh, yes, PAX would also strip the .sig,
which is perhaps why you'd want to do this.

But for this to work, I have to publically announce that my remailer,
hal at alumni.caltech.edu, can be reached at PAX "anonymous" address
anon.100 at pax.tpa.com.au.  This seems a little strange, as the PAX
address is then no longer anonymous.  I have to tell everybody what
the address is in order for it to be useful.

So, the PAX remailer doesn't really add much anonymity, but it does
excise your .sig.  It's not clear that it's worth it just for that.

On a more positive note, the other remailer, in Finland, is much more
promising for our purposes.  It has a remailing capability similar
to ours.  You could send mail to: hal%alumni.caltech.edu at anon.penet.fi,
and it would forward the mail to hal at alumni.caltech.edu.  This is
similar functionality to a non-encrypting form of the remailers we
are operating, and so it can help confuse things.

Also, this remailer could be used in a chain of our remailers by
using an address of the proper form.  For example, mail sent to
the Rebma remailer, then to Finland, then to the Rosebud remailer, could be
done by putting, at the front of your message:

::
Request-Remailing-To: elee7h5%rosebud.ee.uh.edu at anon.penet.fi

::
Request-Remailing-To: <dest>

Then a blank line, then your message itself.  Mail it to remailer at rebma.mn.org.
I haven't tried this but it should work, theoretically.

Hal
74076.1041 at compuserve.com


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From yanek at novavax.nova.edu  Tue Dec 22 22:35:05 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 22:35:05 PST
Subject: Encryption Technology
Message-ID: <9212230634.AA27849@novavax.nova.edu>



> I am going to be teaching a seminar on computer law next quarter. One area
> the casebooks seem to entirely ignore is encryption--the area where
> technology is currently supporting privacy and weakening state power. I would
> appreciate either references to or on line copies of useful material. The
> three main things I need are a clear explanation of the technology (public
> key cryptography in particular),

I assume that you just want an explanation of what the technology does, not
how exactly it works, i.e. I am not going to include the formulas and
algorithms, just a description of what it does and how it can be used.

Here's a summary of a couple of the most relevant technologies:

PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is called
teh public key the other is private.  These two are related in that what is
encrypted with one can only be decrypted with the other.  It is impossible
(computationally infeasible) to derive one knowing the other.  The most
popular public key cryptography algorithm is RSA, which is based on the
ease of multiplying large primes, and the difficulty of factoring the
product.

How it is used: you publish the public key, while keeping the private key
to yourself.  Anyone can send a secret message to you by encrypting it with
your public key.  You are the only one that can decrypt the message, since
only you have the private key.

You can reply by encrypting your message with their public key, and they
can decrypt it with their private key.


DIGITAL SIGNATURES -- techniques that are used to verify that a message
claiming to be from you was actually written by you.  To do that, you
compute a "message digest", which is similar to a "checksum" in that it can
be used to check that the message has not been altered.  Then you encrypt
the "digest" with your private key and attach to the message.  Currently
the most popular "digest" algorithm is MD5.

To verify a signature:  the person verifying computes the same checksum,
then decrypts the checksum attached to the message.  If the two match, the
message must have been signed by you, since no-one else has your private
key, and could not have generated the signature.


DIFFEY-HELLMANN KEY EXCHANGE --  a protocol by which two communicating
parties can arrive at a secret piece of information that can not be known
to a passive eavesdropper (as in a wiretap), and can not be recovered from
analysis of recorded communication.  This secret piece of information is
usually used as the key for a conventional cryptography algorithm such as
DES or IDEA to encrypt following communication.  


SENDER UNTRACEABILITY -- use of a protocol by which one of a group of
commnicating entities can send a public message, while it is impossible
to trace the message to the sender.  This can be used to send messages
anonymously or pseudonymously and untraceably.  One of the protocols that
makes this possible is David Chaum's dc-net protocol, in which every
participant sends some data, and when all the data are combined, the
anonymous message emerges.  Another is the mix-net, or "remailer" approach.
In this case, you send your message to a re-mailer, with encrypted
instructions on where to send it.  By sending your message through a chain
of such remailers, untraceability is achieved.


RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message
sent to you, without anyone having any way of knowing that you received the
message, or indeed if you received any message at all.  

How it works:  anyone wanting to leave a message to you encrypts it with
your public key, and posts it on a "bulletin board".  You download all the
messages from the bulletin board periodically, and see if you can decrypt
any using your private key.  



DIGITAL CASH -- one entity creates some amount of digital "tokens", which
may then be transfered to other people, who can transfer them between each
other, and when they are returned to their creator, he can not trace the
transactions that have occured, only the total balance of a person at the
end of the set of transactions.


> a clear explanation of how it can be used and why it matters,

Each of these technologies by itself can not accomplish much.  But if all
these are put together, any person can send messages to any other person,
without anyone but the two of them knowing that a message was sent, or what
it said.

As for why it matters, I include here Timothy C. May's Crypto Anarchist
Manifesto:


The Crypto Anarchist Manifesto

Timothy  C.  May
tcmay at netcom.com


A specter is haunting the modern world, the specter of crypto 
anarchy. 

Computer technology is on the verge of providing the ability for 
individuals and groups to communicate and interact with each other 
in a totally anonymous manner. Two persons may exchange 
messages, conduct business, and negotiate electronic contracts 
without ever knowing the True Name, or legal identity, of the other. 
Interactions over networks will be untraceable, via extensive re-
routing of encrypted packets and tamper-proof boxes which 
implement cryptographic protocols with nearly perfect assurance 
against any tampering. Reputations will be of central importance, far 
more important in dealings than even the credit ratings of today. 
These developments will alter completely the nature of government 
regulation, the ability to tax and control economic interactions, the 
ability to keep information secret, and will even alter the nature of 
trust and reputation.

The technology for this revolution--and it surely will be both a social 
and economic revolution--has existed in theory for the past decade. 
The methods are based upon public-key encryption, zero-knowledge 
interactive proof systems, and various software protocols for 
interaction, authentication, and verification. The focus has until now 
been on academic conferences in Europe and the U.S., conferences 
monitored closely by the National Security Agency. But only recently 
have computer networks and  personal computers attained sufficient 
speed to make the ideas practically realizable. And the next ten 
years will bring enough additional speed to make the ideas 
economically feasible and essentially unstoppable. High-speed 
networks, ISDN, tamper-proof boxes, smart cards, satellites,  Ku-band 
transmitters, multi-MIPS personal computers, and encryption chips 
now under development will be some of the enabling technologies. 

The State will of course try to slow or halt the spread of this 
technology, citing national security concerns, use of the technology 
by drug dealers and tax evaders, and fears of societal disintegration. 
Many of these concerns will be valid; crypto anarchy will allow 
national secrets to be trade freely and will allow illicit and stolen 
materials to be traded. An anonymous computerized market will 
even make possible abhorrent markets for assassinations and 
extortion. Various criminal and foreign elements will be active users 
of CryptoNet. But this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of 
medieval guilds and the social power structure, so too will 
cryptologic methods fundamentally alter the nature of corporations 
and of government interference in economic transactions. Combined 
with emerging information markets, crypto anarchy will create a 
liquid market for any and all material which can be put into words 
and pictures. And just as a seemingly minor invention like barbed 
wire made possible the fencing-off of vast ranches and farms, thus 
altering forever the concepts of land and property rights in the 
frontier West, so too will the seemingly minor discovery out of an 
arcane branch of mathematics come to be the wire clippers which 
dismantle the barbed wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.


> and a brief summary of the present legal/political
> situation--in particular, attempts and suggestions that have been made to
> control the technology.

The FBI has proposed a "Digital Telephony" bill, which would require all
providers of any kind of communications service to build in a wiretap
capability for the government.  Department of State is restricting the
export of any crypto software, claiming that it is a weapon, and therefore
falls under ITAR (International Traffic in Arms Regulations) rules.  Public
Key Partners (PKP) holds the control of patents that cover RSA, and
possibly the very idea of public key cryptography.  Someone (I can't
provide a reference) has proposed that anyone that uses encryption should
be required to register their key with the Justice Department, so that the
text could be decrypted if a search warrant is issued.  These are all the
attempts to control this technology that come to my mind right now.

The Electronic Frontier Foundation (EFF) can probably provide more
information (e-mail to eff at eff.org).
 
> David Friedman
> DDFr at Midway.UChicago.Edu
> DDFr at AOL.Com



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From yanek at novavax.nova.edu  Tue Dec 22 22:56:29 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 22:56:29 PST
Subject: Pax and .fi remailers
In-Reply-To: <921223054957_74076.1041_DHJ39-2@CompuServe.COM>
Message-ID: <9212230655.AA28469@novavax.nova.edu>


> But for this to work, I have to publically announce that my remailer,
> hal at alumni.caltech.edu, can be reached at PAX "anonymous" address
> anon.100 at pax.tpa.com.au.  This seems a little strange, as the PAX
> address is then no longer anonymous.  I have to tell everybody what

You don't have to tell anyone that your remailer is behind the anon.100
address.  You could just (anonymously, of course) announce that a
remailer is running, and can be reached by sending message to the
anon.100 address.  This way, no-one but the admins at pax can know
where the remailer itself lives.  This could be useful in case 
remailers are banned.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From 74076.1041 at CompuServe.COM  Wed Dec 23 08:42:59 1992
From: 74076.1041 at CompuServe.COM (Hal)
Date: Wed, 23 Dec 92 08:42:59 PST
Subject: Pax and .fi remailer
Message-ID: <921223163446_74076.1041_DHJ35-1@CompuServe.COM>


-----BEGIN PGP SIGNED MESSAGE-----

Yanek points out a purpose for a PAX-hidden remailer:

> You don't have to tell anyone that your remailer is behind the anon.100
> address.  You could just (anonymously, of course) announce that a
> remailer is running, and can be reached by sending message to the
> anon.100 address.  This way, no-one but the admins at pax can know
> where the remailer itself lives.  This could be useful in case 
> remailers are banned.

The problem with this, it seems to me, is that the address of this
"secret" remailer is compromised whenever it sends something out.
I could just send a "Request-Remailing-To: <me>" message to this PAX
anon.100 address, and then look at the return address when the message
comes to me from this remailer.  So again the anonymity provided by
PAX seems to be lost.

Now, one way to avoid this would be for the secret remailer not to send
its outgoing mail directly to the requested destination, but rather
always to insert one or other remailers into the chain.  I think it was
Yanek himself (or Dr. Z?) who suggested this earlier.  This might work,
but as was pointed out, if everyone does this we'll just get into infinite
mail loops.

Still, it might be OK if a well-known public remailer were chosen,
especially one that was likely to be relativelly immune to pressure.
I noted in the discussion of the anon.penet.fi remailer the author made
the point that it was running on a machine in his house, one that he
owned and used in his independent business.  So presumably his machine
is not going to be easy to shut down.

(My remailer, OTOH, is running as part of what is basically a guest account
on a machine which is to be used just for email and a little telnet/ftp
activity.  I figure that the remailer performs an email function, speaking
broadly, so it's OK under the agreement I signed.  But I'm sure that if
the admin received some complaints I'd be kicked off.  So I can't make
any guarantees about how long it will be around.)

(This would be another piece of information that would be useful in the
remailer database being constructed by Eric Hollander - some comments
on how immune the remailer operator would be to political pressure due to
unpopular or illegal messages.)

If this well-known machine guaranteed NOT to do this remail-via-a-remailer
outgoing step, then it could be used by less politically secure remailers
to protect themselves from pressure.  In such a system, Yanek is right
that a remailer could run completely anonymously.

Perhaps someone would like to start up a remailer which runs under such
a system.

Hal Finney
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzhqjKgTA69YIUw3AQFNmAQAgioJMosbMCoit2XflfzK/wgIOkG8qBfG
JO3iTWRskVP5Gp43N1bs7W6YhgEXKWdJ/dqNoWrYV2/181zFhXh0xe7lsGifut1b
UQGW6DipYIMlW0TbNjhpiIWwAQChn/3NvTJtcBGL0GY3l4ZjMZFs2qBonc/Y1Boe
jWfWgQbHSXw=
=6y5/
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM






From jwn2 at qualcomm.com  Wed Dec 23 09:08:22 1992
From: jwn2 at qualcomm.com (John W Noerenberg)
Date: Wed, 23 Dec 92 09:08:22 PST
Subject: Signing ascii text
Message-ID: <9212231707.AA03963@harvey>


At 11:31 PM 12/22/92 -0400, Yanek Martinson wrote:
>> (e.g., email messages, etc). Is there a convention for the end of line
>> sequence that is to be used for the copy of the file that is run through
>> the hash function? If there isn't, then the file hash will depend on the
>
>Canonical Text has a CR and LF at the end of each line.  This is 
>documented in some RFC.  All (most?) protocols used on internet such
>as smtp, finger, etc, use this format.  The possible justification
>is that an extra linefeed or a carriage return is not as bad as a missing
>one.  

Which RFC are you referring to?  While it is true that 821, 822 (and other
RFC's which are concerned with email messages) define the end of line as a
CRLF, I'm not aware of an RFC which defines canonical text.  The style of
late has been to define a line "as described in rfc822" or some such.  But
I don't recall any rfc which defines canonical text spanning session-layer
(or higher) protocols.  Is there one?

john noerenberg
jwn2 at qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================






From ncselxsi!drzaphod at ncselxsi.netcom.com  Wed Dec 23 11:30:19 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (Doctor Zaphod)
Date: Wed, 23 Dec 92 11:30:19 PST
Subject: Signing text messages...
Message-ID: <40694.drzaphod@ncselxsi>


In Message 23 Dec 92 00:49:30 EST,
  Hal <CompuServe.COM!74076.1041 at netcomsv.netcom.com> writes:

>My public key, for those wanting to check the sig on the message below:

By including your public key WITH your signed messages, aren't you inviting
people to intercept it, replace it with they're own public key, and re-sign
the message?  If I didn't have a trusted copy of your public key already I
wouldn't be able to verify your signature.
TTFN!
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized






From eric at parallax.com  Wed Dec 23 11:57:58 1992
From: eric at parallax.com (Eric Messick)
Date: Wed, 23 Dec 92 11:57:58 PST
Subject: Signing ascii text
Message-ID: <9212231902.AA25740@parallax.com>



I would like to argue for a weaker ascii text signature function in
PGP in addition to the current one.  It would canonicalize a file by
turning all sequences of white space into a single space and trimming
leading and trailing whitespace from the file before computing the
hash.  This clearly involves some major changes to the file, allowing
many files to hash to the same value, but a human would presumably
consider all of those files to have the same information content.  The
only case that I can think of where the information content of the
message could be changed with the signature remaining valid is if
information was contained in the pattern of whitespace in the file.
This should make the signature robust to most of the changes that a
mailer could make.  I would not advocate extending this to any
non-whitespace characters.

-- eric messick
eric at toad.com





From mark at coombs.anu.edu.au  Wed Dec 23 13:19:37 1992
From: mark at coombs.anu.edu.au (Mark)
Date: Wed, 23 Dec 92 13:19:37 PST
Subject: Signing ascii text
Message-ID: <9212232118.AA01592@coombs.anu.edu.au>


>Date: Wed, 23 Dec 92 11:02:31 PST
>From: Eric Messick <eric at parallax.com>

>It would canonicalize a file by
>turning all sequences of white space into a single space and trimming
>leading and trailing whitespace from the file before computing the
>hash.

If the message contained a table of figures formatted and seperated with
spaces then that method would destroy the readability of the table. If the
file was processed to change tabs to spaces, according to your .exrc
settings, then the message would be cleared of any ambiguities from
differing lengths of tabs. This is assuming none of the forwarding mail
systems between parties replaces a sequence of spaces with a single tab.
I personally havent seen such behaviour, nor would I expect it. It makes
too many (bad) assumptions.

Trailing spaces should of course be nulled as they serve little purpose.

Mark
mark at coombs.anu.edu.au





From marc at MIT.EDU  Wed Dec 23 13:36:28 1992
From: marc at MIT.EDU (Marc Horowitz)
Date: Wed, 23 Dec 92 13:36:28 PST
Subject: Stripping signatures (was Re: Remailers)
In-Reply-To: <ywm8VB8w165w@spectrx.saigon.com>
Message-ID: <9212232135.AA00768@deathtongue.MIT.EDU>


I think that signatures should be kept.  If you really want to be
anonymous, you have bigger things to worry about than your sig showing
up or not.

And if I want to build a pseudonymous identity for myself, I might
want to have a sig for that identity.  I wouldn't want the remailers
stripping that out.

Perhaps it would make sense to have a header field which indicated if
the sig should be kept or not.

		Marc





From ghsvax!hal at uunet.UU.NET  Wed Dec 23 13:46:51 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Wed, 23 Dec 92 13:46:51 PST
Subject: Signing text messages...
Message-ID: <9212232118.AA23889@nano.noname>


Dr. Zaphod writes:

> By including your public key WITH your signed messages, aren't you inviting
> people to intercept it, replace it with they're own public key, and re-sign
> the message?  If I didn't have a trusted copy of your public key already I
> wouldn't be able to verify your signature.

I'm not sure what attack you are proposing here.  Are you suggesting
that someone else could take credit for my (brilliant?) message by
removing the PGP signature and substituting one of their own?  But
digital signatures can't stop other people from doing this.

Or are you suggesting that someone else could create a bogus public
key claiming to mine, re-sign the message using that public key, and
then get people to think it was from me?  Or, worse, they could create
a whole new message saying "I am a turkey, signed Hal Finney", sign it
with this bogus "Hal Finney" public key, and post it.  Then I'd really
have egg on my face, right?

But no, I wouldn't, because people would (or should) know not to trust
a random public key to be from whom it claims.  My posted key is
signed by Phil Zimmermann.  This doesn't absolutely prove it is from
me, but I think it makes it worthwhile to post the key.

Anyway, the real reason I posted the key in this case was so that
people could check the cleartext signature to see if it had been
mangled by various mail gateways.  That was the topic of discussion in
the message, so I wanted to make it easy for people to try checking
the signature.

Hal
74076.1041 at compuserve.com






From yanek at novavax.nova.edu  Wed Dec 23 14:31:14 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Wed, 23 Dec 92 14:31:14 PST
Subject: Signing ascii text
In-Reply-To: <9212231707.AA03963@harvey>
Message-ID: <9212232230.AA21068@novavax.nova.edu>


> >Canonical Text has a CR and LF at the end of each line.
> Which RFC are you referring to?  

I am not aware of any single RFC that defines this, but every RFC
that I have read, if it mentions end-of-line at all, it is defined
as, or assumed to be, a carriage return followed by a newline.

Even in cases where the native representation is different, it
is converted to this format before transmission through the net,
and then converted back.  This is in some RFC-s referred to 
as "internet tradition", or "NetAscii".

This is similar to the Network Byte Order.  No matter what order
your machine stores bytes (little/big endian), it gets converted
to one standard format.

It is also referred to as "NVT Standard".

The only mention of a different end of line convention is in
relation to EBCDIC, which has an explicit newline <NL> character.

Here are excerpts from various RFCs that deal with, or mention, 
use of CRLF at the end of lines:


Request For Comments: 1078                                       SRI-NIC
                 TCP Port Service Multiplexer (TCPMUX)

   A TCP client connects to a foreign host on TCP port 1.  It sends the
   service name followed by a carriage-return line-feed <CRLF>.  

   acknowledgment, immediately followed by an optional message of
   explanation, terminated with a <CRLF>.  If the reply was positive,

Request for Comments: 1123                             R. Braden, Editor

       Requirements for Internet Hosts -- Application and Support

              To allow interoperability between arbitrary Telnet clients
              and servers, the Telnet protocol defined a standard
              representation for a line terminator.  Since the ASCII
              character set includes no explicit end-of-line character,
              systems have chosen various representations, e.g., CR, LF,
              and the sequence CR LF.  The Telnet protocol chose the CR
              LF sequence as the standard for network transmission.

Request for Comments: 1184                             D. Borman, Editor

                         Telnet Linemode Option

   line should be transmitted with "CR LF" as the line terminator.  When
 
   responsible for doing all output processing.  Specificly, it should
   send "CR LF" when it wants the "newline" function

Request for Comments: 1204                                        D. Lee

                     Message Posting Protocol (MPP)

      USER <SP> <username> <CRLF>
      PASS <SP> <password> <CRLF>
      DATA <CRLF>
      NOOP <CRLF>
      QUIT <CRLF>

      354 Enter mail, end with <CRLF>.<CRLF>

Request for Comments: 1288           Center for Discrete Mathematics and

                  The Finger User Information Protocol

   Any data transferred MUST be in ASCII format, with no parity, and
   with lines ending in CRLF (ASCII 13 followed by ASCII 10).  

Request for Comments: 1312                               Crynwr Software

                        Message Send Protocol 2

		  New lines should be represented using the usual
		  Netascii CR + LF.  (Following the Internet tradition,
		  a server should probably be prepared to accept a
		  message in which some other end-of-line convention is
		  followed, but a conforming client must use CR + LF.)

     NWG/RFC# 561                   AKB KP RST JEW 5-SEP-73 11:19  18516
     Standardizing Network Mail Headers           RFC 561 / NIC 18516

        Formal Syntax:                                               

           <mailtext>    ::= <header> <CRLF> <message>               
           <headeritem>  ::= <item> <CRLF>                           

           <message>     ::= <line> <CRLF> ! <line> <CRLF> <message>
                                                                    
           <line>        ::= a string containing any of the 128 ASCII
                             characters except CR and LF            
           <word>        ::= a string containing any of the 128 ASCII
                             characters except CR, LF, and SP       
           <CRLF>        ::= CR LF                                  
           <SP>          ::= space                                  

   RFC 821
                                    
                     SIMPLE MAIL TRANSFER PROTOCOL

            MAIL <SP> FROM:<reverse-path> <CRLF>

            RCPT <SP> TO:<forward-path> <CRLF>

            DATA <CRLF>

         SEND <SP> FROM:<reverse-path> <CRLF>
         SOML <SP> FROM:<reverse-path> <CRLF>
         SAML <SP> FROM:<reverse-path> <CRLF>
         HELO <SP> <domain> <CRLF>
         QUIT <CRLF>

         The SMTP commands define the mail transfer or the mail system
         function requested by the user.  SMTP commands are character
         strings terminated by <CRLF>.  The command codes themselves are
         alphabetic characters terminated by <SP> if parameters follow
         and <CRLF> otherwise.

     RFC #  822


                        STANDARD FOR THE FORMAT OF
                        ARPA INTERNET TEXT MESSAGES


          A message consists of header fields and, optionally, a body.
     The  body  is simply a sequence of lines containing ASCII charac-
     ters.  It is separated from the headers by a null line  (i.e.,  a
     line with nothing preceding the CRLF).


     field       =  field-name ":" [ field-body ] CRLF

     field-body  =  field-body-contents
                    [CRLF LWSP-char field-body]


        Each header field may be represented on exactly one line  con-
        sisting  of the name of the field and its body, and terminated
        by a CRLF;

Request for Comments: 959                                    J. Reynolds

                      FILE TRANSFER PROTOCOL (FTP)

            In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.  (See the discussion of file structure at the end

               process will interpret appropriately.  <CRLF>, in exactly
               this sequence, also denotes end-of-line.

         the FTP implementation should use the end-of-line sequence,
         <CRLF> for ASCII, or <NL> for EBCDIC text files, as the

      For the purpose of standardized transfer, the sending host will
      translate its internal end of line or end of record denotation
      into the representation prescribed by the transfer mode and file
      structure, and the receiving host will perform the inverse
      translation to its internal denotation.  

      End-of-line in an ASCII or EBCDIC file with no
      record structure should be indicated by <CRLF> or <NL>,
      respectively.  

            information.  The data will be transferred in ASCII or
            EBCDIC type over the data connection as valid pathname
            strings separated by <CRLF> or <NL>.  (Again the user must

Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)

                     Network News Transfer Protocol
                                    

   Each command line must be terminated by a CR-LF (Carriage Return -
   Line Feed) pair.

   that indicates that text will follow.  Text is sent as a series of
   successive lines of textual matter, each terminated with CR-LF pair.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From dmandl at shearson.com  Wed Dec 23 14:49:48 1992
From: dmandl at shearson.com (David Mandl)
Date: Wed, 23 Dec 92 14:49:48 PST
Subject: Interview with Tim May on WFMU
Message-ID: <9212232149.AA23069@tardis.shearson.com>


For interested cypherpunks (or anyone else) in the NYC area, I'm going
to be interviewing Tim May on my radio show this Saturday.  The show's
on WFMU (East Orange, NJ), 91.1 FM, from noon-3:00.  Tim'll be on starting
at 2 PM.

   --Dave.





From wcs at anchor.ho.att.com  Wed Dec 23 15:31:40 1992
From: wcs at anchor.ho.att.com (Bill Stewart +1-908-949-0705 wcs@anchor.ho.att.com)
Date: Wed, 23 Dec 92 15:31:40 PST
Subject: Signing ascii text
Message-ID: <9212232331.AA20426@anchor.ho.att.com>


The problem with signing whitespace-compressed canonicalized text isn't the 
loss of readability, since you can send the non-canonicalized version for humans.
The problem is that sometimes the white space IS significant
	Project-Schedule        1992   1993  1994
	Phase 1                   X
	Phase 2                          X
	Phase 3				       X
would acquire the same signature if you moved the Xs to different columns.
If we're going to treat white space in text as significant, we made need
to adopt a scheme such as MIME's =xx content-transfer-ncodings;
Otherwise we need to declare by fiat that white space is not significant 
unless protected by an encoding.
		Bill Stewart




From whitaker at eternity.demon.co.uk  Wed Dec 23 16:03:21 1992
From: whitaker at eternity.demon.co.uk (Russell Earl Whitaker)
Date: Wed, 23 Dec 92 16:03:21 PST
Subject: Forwarded article.
Message-ID: <7595@eternity.demon.co.uk>



This article was forwarded to you by whitaker at demon.co.uk (Russell Earl Whitaker):

--------------------------------- cut here -----------------------------

Newsgroups: demon.security
From: twillis at pintu.demon.co.uk (Tom Willis)
Path: eternity.demon.co.uk!demon!pintu.demon.co.uk!twillis
Subject: Attempt at a signing policy
Distribution: world
Organization: DGA Ltd
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Lines: 122
Date: Tue, 15 Dec 1992 23:46:16 +0000
Message-ID: <724463176snz at pintu.demon.co.uk>
Sender: usenet at demon.co.uk

I would welcome any comments on the following, as a signing policy.
What do you think?


-----BEGIN PGP SIGNED MESSAGE-----

This is my policy for signing keys
==================================
(dated 12th December, 1992 1992-12-12)

- --Type bits/keyID   Date       User ID
- --pub  1024/6AD0D1 1992/10/24  Tom Willis <twillis at pintu.demon.co.uk>
- --          Key fingerprint =  04 D7 B9 24 50 BE B2 30  BD 23 1A 98 B5 01 F1
 46
- --                             Tom Willis <GBR55N55 at IBMMAIL>
- --                             Tom Willis
- --              </G=WilliTL/S=Willis/PRMD=IBMMAIL/ADMD=IBMX400/C=GB/>
- --                             Tom Willis <100042.446 at Compuserve.com>
- --                             Tom Willis
- --              </CN=Tom Willis/OU=HQ/O=DGA+C=GB/@DGA at Notes>

Introduction
- ------------

It is my intention that you should be able to trust my signature on  any
key that you see.  However, what you mean by trust and what I mean by it
may differ.   In overview, I  will only sign  keys that I  have received
directly from an individual  that claims to own  the key, and that  I am
confident does so.   My confidence is based  upon the policy I  maintain
for signing keys.

Policy
- ------

1.  I will only sign a key that I have received physically during a
    face-to-face meeting with the person claiming to own the key.

2.  I will only sign a key once the claimed key-owner has proved to
    me that they possess the secret key corresponding to the public
    key that they have given me.

3.  I will only  sign a key/ID  pair that I  believe identifies the
    person claiming to own the key.

4.  I do not  claim to have  verified that the  name the person  is
    using is  actually their  own legal  name; I  accept reasonable
    aliases/handles but require that I am confident that the person
    regularly uses the name given in public.

5.  I do not  claim to know  that the key  owner is trustworthy  in
    signing keys, and is not an agent provocateur.

The obvious ones:

6.  I will not allow my secret key and password to fall into anyone
    else's hands.

7.  If I find that my secret  key has been compromised, I shall  do
    my best to  distribute a compromise  certificate to anyone  who
    has received a key with my signature.

Notes on Policy
- ---------------

1.  I will accept keys  presented on paper or  electronically (e.g.
    on diskette), but the key  must have been handed over  during a
    personal meeting with the (claimed) key-owner.

2.  To satisfy me  that the claimed  owner actually *does*  possess
    the secret  key, they  must return  to me  a sequence  of bytes
    (chosen by me) signed with their secret key and encrypted  with
    my public key.

    For example,  if I  meet someone  I do  not know  well, and  we
    exchange keys, I will not sign their key until I have sent them
    a sequence of text bytes (e.g. an item in radix-64 form  signed
    by my key),  and they have  returned the same  item to me  in a
    message that is signed and  encrypted, and I have checked  that
    my  original   `challenge'  and   the  returned   response  are
    *identical*, and that the  message signature agrees with  their
    public key that I posssess.  (Otherwise, the physical  exchange
    could well prove nothing about the person involved except  they
    possess the public key of the person they are claiming to be.)

3.  My signature  says that  the key  and the  associated ID that I
    sign belong together, so  far as I can  tell.  In order  not to
    mislead you, I won't sign  key/ID pairs that look wrong  to me.
    For example, I wouldn't sign  even my own father's key,  if the
    ID  said  something  like  `President  of  the United States of
    America'; because he ain't (and I *know* that!).

    If my father's key  also had a (secondary)  ID on it that  gave
    his name as I know it, I *would* sign that association, even if
    another ID is clearly garbage.

4.  I would cheerfully  sign a key/ID  pair, even if  I *knew* that
    the ID was not the real ID of the owner, if it is a  reasonable
    ID.    For  example,  if  my  Mother  had a stage name, I would
    certainly sign her key with that ID; I would also sign her  key
    with her maiden name.  I wouldn't sign her key/ID where the  ID
    wasn't one  I had  ever heard  her use,  though.   Not even  my
    Mother, much as I trust her otherwise!

5.  My best  friend, known  since childhood,  may be  a gonzo  when
    dealing with security; I have no objection to signing his  key,
    but you should not assume  that says anything about whether  or
    not I would trust *his* signature myself!  (It's OK, mate, just
    joking, I trust you *really*...)

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyqRM6soIBpyatDRAQH96AP/RMa0+MENYZ2EZTHZFiS04mgA40A0ncL5
rpuRePDrhBjAqxN/K5xX9rWWKgxiQgo3OvsY93tjFUZ1mn4ESUEscf57rnXE26cL
B/jEz+Kn4P4en8107ydl5VvZkkqMj3f3Vyfkuu5YN6KX2NIbpVzQgKSrV4Ah8vob
F0GKx8DdsOs=
=O2fB
-----END PGP SIGNATURE-----

--
Tom \/\/illis   | 1. twillis at pintu.demon.co.uk  | Have PGP 2.0 key
DGA Ltd         | 2. GBR55N55 at IBMMAIL           | ... will swap
LONDON UK       | 3. 100042.446 at Compuserve.com  |


--------------------------------- cut here -----------------------------






From ncselxsi!drzaphod at ncselxsi.netcom.com  Wed Dec 23 16:16:27 1992
From: ncselxsi!drzaphod at ncselxsi.netcom.com (Doctor Zaphod)
Date: Wed, 23 Dec 92 16:16:27 PST
Subject: Signing text messages...
Message-ID: <57860.drzaphod@ncselxsi>


In Message Wed, 23 Dec 92 13:18:54 PST,
  uunet.uu.net!ghsvax!hal at netcomsv.netcom.com (Hal Finney) writes:

>Or are you suggesting that someone else could create a bogus public
>key claiming to mine, re-sign the message using that public key, and
>then get people to think it was from me?

     Perhaps they could alter the message, use a bogus public key, and
     re-sign the message.

>But no, I wouldn't, because people would (or should) know not to trust
>a random public key to be from whom it claims.  My posted key is
>signed by Phil Zimmermann.  This doesn't absolutely prove it is from
>me, but I think it makes it worthwhile to post the key.

     I didn't realize you had included a signed key.  Minus one point
     for research.  Yes, people SHOULD know not to use a publicly posted
     key.  But do they?

>Anyway, the real reason I posted the key in this case was so that
>people could check the cleartext signature to see if it had been
>mangled by various mail gateways.  That was the topic of discussion in
>the message, so I wanted to make it easy for people to try checking
>the signature.

     Then posting your public key was clearly the right thing to do.  I
     have noticed; however, that people have posted their public key
     along with a signed message before [there was a discussion on mangled,
     signed plaintext] and thought I would mention this to anybody who
     thought they were using infallible methods or authentication.

     I must urge everybody not to accept any key from a source other then
     person to person [or using a fone call to exchange MD5 hashes] unless
     it is signed by smoebody you HAVE exchanged keys with in this way.
     I hope nobody sees a message with a public key attached to it and says,
     "Oh!  There's a key I can add to my keyring", and abandons the entire
     key-exchange method.  TTFN!


     nobody saw
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod at ncselxsi.uucp]
Technicolorized






From eric at parallax.com  Wed Dec 23 19:01:52 1992
From: eric at parallax.com (Eric Messick)
Date: Wed, 23 Dec 92 19:01:52 PST
Subject: Signing ascii text
Message-ID: <9212232303.AA26569@parallax.com>



I wrote:

>It would canonicalize a file by
>turning all sequences of white space into a single space and trimming
>leading and trailing whitespace from the file before computing the
>hash.

mark at coombs.anu.edu.au resopnded:

> If the message contained a table of figures formatted and seperated with
> spaces then that method would destroy the readability of the table.

The important part here is that the collapsing of whitespace would
only affect the message digest, not the text as seen by the user.  Two
texts which read the same, but differ in whitespace, would have the
same signature.  If you recieved both files, you could see the
difference in spacing, yet the same signature would be valid for both
files.  The main vulnerability is that a message whose meaning is
partially encoded it its whitespace (like an ascii graphic, map, or
chart) could have its meaning altered, without affecting the validity
of the signature.  Clearly one would not want to use this signature
method on such texts.  It would be a good feature for the signature
algorithm to warn the user if it detects a pattern of whitespace that
might convey information.  I am not sure how to detect this reliably,
though.

-- eric messick
eric at toad.com





From rchilder at us.oracle.com  Thu Dec 24 00:28:11 1992
From: rchilder at us.oracle.com (Richard Childers)
Date: Thu, 24 Dec 92 00:28:11 PST
Subject: 1993 RSA Data Security Conference
Message-ID: <9212240826.AA23973@rchilder.us.oracle.com>




( I'm sitting here, waiting for Sequent to call back after a late-night
  systems crash ... may as well put the time to some good use ... )-:


Looking for computer & communications products that have real public-key
security built in ... maybe interested in enhancing your _own_ products
with encryption and authentication technologies ... or just want to know
what all the excitement is about ?

RSA invites end users, developers and OEMs to attend the

		1993 RSA Data Security Conference

The only conference and expo devoted exclusively to public-key cryptography.

Talk to colleagues, developers, potential customers and experts from the
best and the brightest companies in the security business. Get the real
story on licensing, standards, algorithm strength, and export restrictions.
See the newest public-key products from the biggest vendors in the computer
industry. Attend tutorials on secure application design and developing
with RSA's cryptography toolkits, such as TIPEM and the new BSAFE 2.0.
Find out how others in your line of business are using RSA technology to
differentiate their products and improve their own internal security.

The conference is being underwritten by RSA Data Security, Inc., and is free
to all attendees and exhibitors. Interested ? Registration is extremely
limited, and is first-come, first-served.

Call RSA today and reserve your seat. 415/595-8782, ask for Conference
Registration.

		Thursday January 14th : Conference

	   Friday January 15th : Tutorials & Exposition

		  Redwood Shores, California







-- richard

=====
-- richard childers		rchilder at us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."





From miron at extropia.wimsey.com  Thu Dec 24 02:11:40 1992
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Thu, 24 Dec 92 02:11:40 PST
Subject: Belated holiday travel
In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU>
Message-ID: <1992Dec24.092516.2347@extropia.wimsey.bc.ca>


I'll be flying into LA on the 5th of Jan, staying in Santa-Barbara
and flying out of LA on the 14th.  If anyone is interested in swapping
public keys and/or just getting together, please let me know.

My house is protected. ;)

-- 
        Miron Cuperman <miron at extropia.wimsey.com> | NeXTmail/Mime ok
                       <miron at cs.sfu.ca>           | Public key avail
        AMIX: MCuperman                            |
cyberspacecomputingcryptoimmortalitynetworkslaissezfaire





From sdw at sdwsys.lig.net  Thu Dec 24 06:09:09 1992
From: sdw at sdwsys.lig.net (Stephen D. Williams)
Date: Thu, 24 Dec 92 06:09:09 PST
Subject: Signing ascii text
In-Reply-To: <9212232303.AA26569@parallax.com>
Message-ID: <9212241403.AA26014@sdwsys.lig.net>


...
> 
> The important part here is that the collapsing of whitespace would
> only affect the message digest, not the text as seen by the user.  Two
> texts which read the same, but differ in whitespace, would have the
> same signature.  If you recieved both files, you could see the
> difference in spacing, yet the same signature would be valid for both
> files.  The main vulnerability is that a message whose meaning is
> partially encoded it its whitespace (like an ascii graphic, map, or
> chart) could have its meaning altered, without affecting the validity
> of the signature.  Clearly one would not want to use this signature
> method on such texts.  It would be a good feature for the signature
> algorithm to warn the user if it detects a pattern of whitespace that
> might convey information.  I am not sure how to detect this reliably,
> though.

How about two signatures, verbatim and space-collapsed.

That way if the latter was valid but the former was not, you would
know that spacing was altered but other info remained valid.

sdw




From dmandl at shearson.com  Thu Dec 24 06:58:20 1992
From: dmandl at shearson.com (David Mandl)
Date: Thu, 24 Dec 92 06:58:20 PST
Subject: Interview with Tim May on WFMU
Message-ID: <9212241449.AA25477@tardis.shearson.com>


Yipes.  I got a whole bunch of (advance) requests for tapes of the
interview, so I'm posting this to the group to make things a bit
easier for myself...

I'll be more than happy to send copies to anyone for the cost
of postage and the blank tape.  I'll also be sending a copy to
Tim, so if it's easier, you can try to get him to dupe it for you.
Of course, being a worrywart, I'll hold off until Monday to confirm
that the thing went off without a hitch.  I'll post to the group
then and let you know.

   --Dave.





From pmetzger at shearson.com  Thu Dec 24 08:30:25 1992
From: pmetzger at shearson.com (Perry E. Metzger)
Date: Thu, 24 Dec 92 08:30:25 PST
Subject: Signing ascii text
Message-ID: <9212241539.AA23696@maggie.shearson.com>



> From: mark at coombs.anu.edu.au (Mark)
> 
> >Date: Wed, 23 Dec 92 11:02:31 PST
> >From: Eric Messick <eric at parallax.com>
> 
> >It would canonicalize a file by
> >turning all sequences of white space into a single space and trimming
> >leading and trailing whitespace from the file before computing the
> >hash.
> 
> If the message contained a table of figures formatted and seperated with
> spaces then that method would destroy the readability of the table.

The notion was NOT that the text would be altered in transmition, but that
the signature would be computed on canonicalized text. No one was proposing
hacking tabs, only that a version of the text with hacked tabs be used
to compute the checksum as by hacking the tabs we will have an easy to
produce canonical format. The concern Eric presented was that this would allow
two files containing substantially different content from a computer's point
of view to MD5 the same, but he noted that this isn't a problem in
practice because humans don't get much information out of the presense of
multiple spaces versus one space.

Perry





From sommerfeld at orchard.medford.ma.us  Thu Dec 24 09:57:49 1992
From: sommerfeld at orchard.medford.ma.us (Bill Sommerfeld)
Date: Thu, 24 Dec 92 09:57:49 PST
Subject: Signing ascii text
In-Reply-To: <9212241403.AA26014@sdwsys.lig.net>
Message-ID: <9212241705.AA00221@orchard.medford.ma.us>


I don't think space-collapsed signatures make any sense; they're only
going to mess up

If you're going to do any canonicalization, do either exactly what PEM
does, or canonicalize tabs and trailing spaces out of the message at
posting time.  Then do the same canonicalization on the receive end
before the signature is verified.

If a message transfer path is still "lossy", stop using the unencoded
body and just live with radix64 encoding.

				- Bill







From yanek at novavax.nova.edu  Thu Dec 24 11:13:41 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 24 Dec 92 11:13:41 PST
Subject: significance of spaces
Message-ID: <9212241912.AA15402@novavax.nova.edu>


> of view to MD5 the same, but he noted that this isn't a problem in
> practice because humans don't get much information out of the presense of
> multiple spaces versus one space.

This is true for most text, like this message.  But sometimes people
send messages where spacing is VERY important:

This is especially true of tables such as this one:


Name	Yes	No

Smith	X
Jones		X
Brown		X
Xyzzy	X

If the signature algorithm disregarded spaces, the X's could be moved
from one column to the other without affecting the signature.

I know that this information COULD have been represented as:

Smith	Yes
Jones	No
Brown	No
Xyzzy	Yes

But sometimes people use the other format.  Another solution is to
surround all significant spaces with some other character, such 
as the vertical bar:

|Name	| Yes	| No	|

|Smith	| X	|	|
|Jones	|	| X	|
|Brown	|	| X	|
|Xyzzy	| X	|	|

If this were done, an X could not be moved without affecting the signature
even if tabs/spaces were insignificant.

The point is that if whitespace is made insignificant, the users must be
educated about it, and trained to use one of the two last formats
instead of the first one.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From rsteiger at denver.cba.du.edu  Thu Dec 24 12:26:56 1992
From: rsteiger at denver.cba.du.edu (Todd_Steigerwald)
Date: Thu, 24 Dec 92 12:26:56 PST
Subject: Destroying Data
Message-ID: <9212242020.AA13761@ denver.cba.du.edu >





>	Consider also the technique used in the Norton Utilities
>	program "Diskwipe" which takes a /g switch which "Follows
>	certain government rules for wiping". I can't find the manual
>	but I think it specifies how many repetitions are used and
>	different values to write in each. 


	The Norton Utilities Wipedisk /g does three passes writing  
1's and then 0's, it follows this with the hex 'FF'.  This shoud  
pretty much remove any residual traces of the data previously held on  
the disk.





From edgar at spectrx.saigon.com  Mon Dec 28 00:53:59 1992
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:53:59 PST
Subject: Signing ASCII text
Message-ID: <L2kewB4w165w@spectrx.saigon.com>


I was able to verify Hal Finney's signed plaintext message posted here
on Dec 23 with a good signature.  Hal says he prepared the original
plaintext with no trailing blanks.  The editor I use removes trailing
blanks whenever it saves text to disk.  So there could have been
trailing blanks in the plaintext I received (which would have spoiled
the signature match) put there by ASCII uploading (of blank lines) or
otherwise and I wouldn't know it.
 
I can't really fault mailers that remove trailing blanks; they are
trying to avoid consuming bandwidth with null information. I think
the answer is a change to PGP to remove trailing blanks anytime
-t is active. I have written to Branko to suggest this, but his
response was somewhat lukewarm.  Perhaps he would change his mind
if he received the same suggestion from several individual PGP users.

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From edgar at spectrx.saigon.com  Mon Dec 28 00:54:12 1992
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:12 PST
Subject: remailer signature suppression
Message-ID: <N3kewB6w165w@spectrx.saigon.com>


Marc Horowitz wrote on Dec 23:
 
    I think that signatures should be kept.  If you really want to be
    anonymous, you have bigger things to worry about than your sig
    showing up or not.
 
I don't follow Marc's logic here. If the wrong sig shows up, it
obviously negates all other precautions taken in using remailers, etc.
 
    And if I want to build a pseudonymous identity for myself, I might
    want to have a sig for that identity.  I wouldn't want the
    remailers stripping that out.
 
The problem is if you want to send a mixture of anonymous and
regular mail. This involves changing the "sig" on the fly; difficult
to do reliably with an automatic script. With loss of anonymity the
consequence of the wrong sig appearing with either anonymous or non-
anonymous messages.
 
    Perhaps it would make sense to have a header field which indicated
    if the sig should be kept or not.
 
This might be a good compromise.  Of course I would prefer the
signature-screen: Yes to be the default.  Also don't forget that
for those of us who can't specify net-headers at will this new
header would also have to be specifiable within text via the ::
convention or otherwise.

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From edgar at spectrx.saigon.com  Mon Dec 28 00:54:14 1992
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:14 PST
Subject: Miron's Remailer
Message-ID: <k5RawB6w165w@spectrx.saigon.com>


-----BEGIN PGP SIGNED MESSAGE-----

I tried Miron Cuperman's remailer, which requires encrypted input.
I noted happily that my automatic signature did not echo back, because
it was not part of the encrypted text.

I was going to ask how this effected ARA, but Miron has already
recognized this problem and proposed a solution.

Except for messages to be posted to newsgroups or sent to lists,
message bodies are likely to be encrypted with the public key
of the recipient. Certainly anyone sending or posting an ARA
should also post an "anonymous" public key for the body of the
reply. (An anonymous public key is just a key with some nom de
plume in the User ID field).

Another topic: signed plaintext.  Miron's signed plaintext failed
the signature check here.  This is probably because my editor
eliminates trailing blanks. Someone here pointed out that
a trailing blank in a blank line may be introduced by an
ASCII upload. Until PGP is fixed to eliminate trailing blanks
in text, I may have another solution.

The editor on this WAFFLE system has an ability to UPLOAD files
using (for example) ZMODEM. I have modified the Telix SLT file I
use so I have a choice of ASCII or Zmodem upload. Proof of pudding
is in eating.  Check the signature on this upload, which contains
several blank lines.  I will be checking with you when I get the
echo back.

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzi5VN4nNf3ah8DHAQH+dAP/eD8opIrO19Led9SwNDIX6LOiZqlmpOZV
jX/30PJ50/1n8BlYowvDaDcPSp6R0JNggYcOg17G88MrpYHq0ODxw0w/wXd+1MHS
Twhu2HUy03tJFmbOOX+kVlk2N2RFGag3063QV6SaweVMLg9DEMyPDHiSbeCTxFR7
RapDSiNV/w4=
=imWV
-----END PGP SIGNATURE-----

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From edgar at spectrx.saigon.com  Mon Dec 28 00:54:17 1992
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:17 PST
Subject: Secret PGP Keys
Message-ID: <s1kewB3w165w@spectrx.saigon.com>


In response to Anton Sherwoods Dec 22 posting:
 
    Here's a lame question from a beginner who hasn't even downloaded
    PGP:
 
    Am I supposed to memorize my private key, lest cops beat down the
    door while I'm out?
 
You would find it difficult to memorize your PGP secret key.
It's 384-1024 bits assigned by PGP when it generates a key pair.
There's not even any provision for manually entering your secret
key. It's only useful in electronic form, on your disk. Which is not
to say it may be useful to store it on a floppy at some location
removed from the computer in some situations.
 
However, PGP has added something called a "pass phrase" which you
can assign to your secret key when you generate a key pair. The
pass phrase is optional, but strongly advised. Since you make it up,
it should be easy to memorize, so *don't* write it down or store it
anywhere where unfriendly forces could find it.
 
PGP uses the pass phrase you assign to encrypt the stored version of
the secret key it generates for you.  The pass phrase is therefore
required (and is prompted for) before the secret key can be used to
either decrypt incoming mail or sign outgoing mail.
 
This is your defense against the cops beating down the door.  They
will find the (encrypted) secret key on your disk.  The pass phrase is
in your head and you have a right to remain silent; use it.
 
There might be some situation where a judge could order you to give
up the pass phrase: you are granted immunity from criminal prosecution
(but you don't want to incriminate your friends) or in a civil
discovery action.  In this case, just claim to have forgotten the
pass phrase in the stress of the situation. Stick to that; no-one
can prove otherwise.

--
edgar at spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca






From hugh at domingo.teracons.com  Mon Dec 28 01:32:42 1992
From: hugh at domingo.teracons.com (Hugh Daniel)
Date: Mon, 28 Dec 92 01:32:42 PST
Subject: A solution remailer signature suppression
In-Reply-To: <N3kewB6w165w@spectrx.saigon.com>
Message-ID: <9212280931.AA08065@domingo.teracons.com>


  There are very good reasons to build remailers (and all mail tools)
to pass on all the bytes they can, trailing spaces and .sigs included.
  Might I sugjest that we set up the remailers with a feature where it
tests mail sent from its owner to make sure there is no "compromising"
content and that the outer shell verifies correctly, if it fails
either of these tests it is dumped in a file and a note returned to
you saying someings not right.
  This has two good features, first you know that what you send out is
good looking stuff and that if someone complains that its likely the
falut of some machine between the two of you and not you.  Second
this gets folks running remailers everywhere just as part of the
infrastructure of using cryptoware.
  Does this sound like something we can build upon for everyone?

		||ugh Daniel





From yanek at novavax.nova.edu  Mon Dec 28 05:58:52 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Mon, 28 Dec 92 05:58:52 PST
Subject: INFO: Encryption Technology
Message-ID: <9212281358.AA06947@novavax.nova.edu>


The following was written by me in response to David Friedman's request
for an overview of various encryption technologies, what they can do,
and why they are important.

This summary does not discuss any mathematics of this technology, it is
meant for someone that wants to know what it is, and what it can do,
without having to know all the mathematical details.

This message can be stored in the exi-essay ftp archive.

Forwarded message:

PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is
called the public key the other is the private key.  These two are
related in that what is encrypted with one can only be decrypted with
the other.  It is impossible (computationally infeasible) to derive one
knowing the other.  The most popular public key cryptography algorithm
is RSA, which is based on the ease of multiplying large primes, and the
difficulty of factoring the product.

How it is used: you publish the public key, while keeping the private
key to yourself.  Anyone can send a secret message to you by encrypting
it with your public key.  You are the only one that can decrypt the
message, since only you have the private key.

You can reply by encrypting your message with their public key, and
they can decrypt it with their private key.


DIGITAL SIGNATURES -- techniques that are used to verify that a message
claiming to be from you was actually written by you.  To do that, you
compute a "message digest", which is similar to a "checksum" in that it
can be used to check that the message has not been altered.  Then you
encrypt the "digest" with your private key and attach to the message.
Currently the most popular "digest" algorithm is MD5.

To verify a signature:  the person verifying computes the same
checksum, then decrypts the checksum attached to the message.  If the
two match, the message must have been signed by you, since no-one else
has your private key, and could not have generated the signature.


DIFFEY-HELLMANN KEY EXCHANGE --  a protocol by which two communicating
parties can arrive at a secret piece of information that can not be
known to a passive eavesdropper (as in a wiretap), and can not be
recovered from analysis of recorded communication.  This secret piece
of information is usually used as the key for a conventional
cryptography algorithm such as DES or IDEA to encrypt following
communication.

This can be used, for example, for secure telephones.  Two people with
these phones connect through the usual telephone network, push the "go
secure" button, the phones perform Diffey-Hellmann key exchange, and
encrypt the following conversation with the resulting secret key.

Not that these two people did not have to meet in person, or transmit a
key through any other channel.  The key was generated as needed.

After the conversation is finished, both phones erase the key from
their memory.  For the next conversation, a new key is set up.

Someone who has a recording of a wiretap has absolutely no way of
knowing what they key was, and therefore can not decode the
conversation.

This technology makes wiretaps obsolete.


SENDER UNTRACEABILITY -- use of a protocol by which one of a group of
communicating entities can send a public message, while it is impossible
to trace the message to the sender.  This can be used to send messages
anonymously or pseudonymously and untraceably.  One of the protocols
that makes this possible is David Chaum's dc-net protocol, in which
every participant sends some data, and when all the data are combined,
the anonymous message emerges.  This has been called the "cryptographic
ouja board", because a message appears, but it is impossible to find
out who sent it.  If one-time pads are used, this system is
unconditionally secure, which means that even an enemy with an infinite
amount of time and processing power van not deduce the sender from
available information.

Another sender untraceability system is the mix-net, or "remailer"
approach.  In this case, you send your message to a re-mailer, with
encrypted instructions on where to send it.  By sending your message
through a chain of such remailers, untraceability is achieved.  This
depends on the remailers not keeping logs that can correlate incoming
and outgoing messages, or unwillingness to reveal such logs to your
enemy.


RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message
sent to you, without anyone having any way of knowing that you received
the message, or indeed if you received any message at all.

How it works:  anyone wanting to leave a message to you encrypts it
with your public key, and posts it on a "bulletin board".  You download
all the messages from the bulletin board periodically, and see if you
can decrypt any using your private key.

Since everyone downloads all the messages, and THEN attempts to decrypt
them on their own machine, no-one observing the communications link has
any way of knowing who received what message, or even if someone
received any messages at all.  This system, along with the dc-net, can
provide completely untraceable global communications.  It does,
however, require substantial communications bandwidth and storage
capacity.



DIGITAL CASH -- one entity creates some amount of digital "tokens",
which may then be transferred to other people, who can transfer them
between each other, and when they are returned to their creator, he can
not trace the transactions that have occurred, only the total balance of
a person at the end of the set of transactions.

This combines the anonymity and untraceability of cash with the
convenience and efficiency of electronic transactions.  In combination
with the above systems, it is superior to cash since any person can pay
anyone else, anonymously and untraceably, without having to meet in
person.

David Friedman asks: "How can it be used, and why does it matter?"

Each of these technologies by itself can not accomplish much.  But if
all these are put together, any person can send messages to any other
person, or transact business without anyone but the two of them knowing
what occurred, or, even that something at all occurred between these two
persons.

Furthermore, these two people don't need to know anything about each
other, but their public key.  They can be completely anonymous, or use
a pseudonym.

As for why it matters, I include here Timothy C. May's Crypto Anarchist
Manifesto:


The Crypto Anarchist Manifesto

Timothy C. May
tcmay at netcom.com


A specter is haunting the modern world, the specter of crypto anarchy.

Computer technology is on the verge of providing the ability for
individuals and groups to communicate and interact with each other in a
totally anonymous manner. Two persons may exchange messages, conduct
business, and negotiate electronic contracts without ever knowing the
True Name, or legal identity, of the other.  Interactions over networks
will be untraceable, via extensive re- routing of encrypted packets and
tamper-proof boxes which implement cryptographic protocols with nearly
perfect assurance against any tampering. Reputations will be of central
importance, far more important in dealings than even the credit ratings
of today.  These developments will alter completely the nature of
government regulation, the ability to tax and control economic
interactions, the ability to keep information secret, and will even
alter the nature of trust and reputation.

The technology for this revolution--and it surely will be both a social
and economic revolution--has existed in theory for the past decade.
The methods are based upon public-key encryption, zero-knowledge
interactive proof systems, and various software protocols for
interaction, authentication, and verification. The focus has until now
been on academic conferences in Europe and the U.S., conferences
monitored closely by the National Security Agency. But only recently
have computer networks and  personal computers attained sufficient
speed to make the ideas practically realizable. And the next ten years
will bring enough additional speed to make the ideas economically
feasible and essentially unstoppable. High-speed networks, ISDN,
tamper-proof boxes, smart cards, satellites,  Ku-band transmitters,
multi-MIPS personal computers, and encryption chips now under
development will be some of the enabling technologies.

The State will of course try to slow or halt the spread of this
technology, citing national security concerns, use of the technology by
drug dealers and tax evaders, and fears of societal disintegration.
Many of these concerns will be valid; crypto anarchy will allow
national secrets to be trade freely and will allow illicit and stolen
materials to be traded. An anonymous computerized market will even make
possible abhorrent markets for assassinations and extortion. Various
criminal and foreign elements will be active users of CryptoNet. But
this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of
medieval guilds and the social power structure, so too will cryptologic
methods fundamentally alter the nature of corporations and of
government interference in economic transactions. Combined with
emerging information markets, crypto anarchy will create a liquid
market for any and all material which can be put into words and
pictures. And just as a seemingly minor invention like barbed wire made
possible the fencing-off of vast ranches and farms, thus altering
forever the concepts of land and property rights in the frontier West,
so too will the seemingly minor discovery out of an arcane branch of
mathematics come to be the wire clippers which dismantle the barbed
wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


--
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.


David Friedman asks for a brief summary of the present legal/political
attempts and suggestions that have been made to control the
technology.

The FBI has proposed a "Digital Telephony" bill, which would require
all providers of any kind of communications service to build in a
wiretap capability for the government.  Department of State is
restricting the export of any crypto software, claiming that it is a
weapon, and therefore falls under ITAR (International Traffic in Arms
Regulations) rules.  Public Key Partners (PKP) holds the control of
patents that cover RSA, and possibly the very idea of public key
cryptography.  Someone (I can't provide a reference) has proposed that
anyone that uses encryption should be required to register their key
with the Justice Department, so that the text could be decrypted if a
search warrant is issued.  These are all the attempts to control this
technology that come to my mind right now.

The Electronic Frontier Foundation (EFF) can probably provide more
information (e-mail to eff at eff.org).


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From eric at parallax.com  Mon Dec 28 11:19:24 1992
From: eric at parallax.com (Eric Messick)
Date: Mon, 28 Dec 92 11:19:24 PST
Subject: Signing ascii text
Message-ID: <9212281831.AA14733@parallax.com>



Stephen D. Williams writes:

> How about two signatures, verbatim and space-collapsed.
> 
> That way if the latter was valid but the former was not, you would
> know that spacing was altered but other info remained valid.
> 
> sdw

This seems to be the correct solution to me.  If PGP did this
automatically in text signature mode, then it would be up to the
reciever to decide if spaces were significant or not, and they would
be prompted to think about this when the verbatim signature
verification failed.  If one often recieved messages with mangled
spacing, one could become desensitized to this, but there's not much
to be done about that.

-- eric messick
eric at toad.com





From wendtj at jplpost.Jpl.Nasa.Gov  Mon Dec 28 12:01:22 1992
From: wendtj at jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Mon, 28 Dec 92 12:01:22 PST
Subject: TEMPEST companies
Message-ID: <9211287255.AA725572669@jplpost.jpl.nasa.gov>


          I have recieved information from Veratec re: the product
          Safe`n'Shield, and I have to say that for an inf0 packet,
          they have done a great job.

          The folder comes with 2 sample squares of the Safe`n'
          Shield material, and the specs for their product are as
          follows:
          >-----------------------------------------------------------
          > Shielding Effectiveness of SAFE`N'SHIELDED (R)
          >(in dB Attenuation)
          >___________________________________________________________
          >SAF`N'40 tm             10' x 20' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100       76        53         57       62
          >___________________________________________________________

          >___________________________________________________________
          >SAF`N'60 tm              8' x 8' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100      N/T*       67         72       87
          >___________________________________________________________

          >___________________________________________________________
          >SAF`N'80 tm              8' x 8' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100      >81        100        90       90
          >___________________________________________________________

          In addition to some general notes and a customer list, they
          provide a 25 page booklet on construction techniques; both
          new and existing.  The material is very thin, about the same
          weight and feel as good bond paper.  The manufacturer states
          that this material meets the NSA 65-6 spec using this
          nonwoven material as the priamary shield.

          The material is applied just like wall paper, with comercial
          wallpaper glue, and from a construction point of view this
          stuff looks like you could do an 8x8x8 romm in a few hours.
          Alas, I did not recieve a price list on the material, but I
          am sure it will be a hell-of-a-lot cheaper that buying
          TEMPEST certified computers, and best of all...you don't
          have to register a damn thing ;-)).

          The address is:  Veretec
                           Long Meadow Road
                           Tuxedo, New York 10987
                           (919) 577-7447





From dmandl at shearson.com  Mon Dec 28 12:54:50 1992
From: dmandl at shearson.com (David Mandl)
Date: Mon, 28 Dec 92 12:54:50 PST
Subject: Radio Interview w/Tim May
Message-ID: <9212282013.AA05024@tardis.shearson.com>


OK, folks, the interview went off beautifully (thanks Tim).
As mentioned earlier, if anyone wants a copy of the tape,
I'll be happy to send one.  Unfortunately, I'm going to be
a little slow making copies because my cassette deck is 
crippled at the moment, so be patient.  Email me if you're
interested.

** Important request: Is there a kind soul out there who would
be willing to transcribe the interview (~40 minutes total)???
I just don't have the time.  If you can do it, I will mail you 
a copy of the tape gratis (total value: $1.50 + postage!).

   --Dave.





From eric at parallax.com  Tue Dec 29 14:06:03 1992
From: eric at parallax.com (Eric Messick)
Date: Tue, 29 Dec 92 14:06:03 PST
Subject: Self Addressed Stamped Envelopes
Message-ID: <9212292048.AA19819@parallax.com>



||ugh and I were talking (over an unsecure phone line :-) last night
and came up with an interesting idea.

The problem:  anonymous replies.

Under the current system, the solution is simple:  create an
`envelope' which implements a path back to you.  You include this
envelope with your outgoing message, and the respondant places the
envelope at the front of any messages to be sent back to you.  The
envelope is a nested encrypted set of Anon-To: lines that remailers
strip off as the message is routed back to you.

This system has at least two weaknesses for future use, however.  The
most serious is that the body of the reply is not altered by the
remailers, allowing the message to be more easily traced.  The second
is that there is no provision for remailers to charge for the service.
If postage is included in the envelope itself, it becomes a single use
device; it is useless for posting to a newsgroup, for example.

Both of these problems can be solved by having each remailer forward
the message *with*postage*due*.  What that means is that the remailer
encrypts the message before sending it on, and saves the key used in
an account file along with a message id and the amount due.  The body
is thus altered on each hop, complicating the process of tracing the
message.  You also are unable to read the message until you have paid
the postage on it, which you do by sending a message to yourself via a
similar envelope.  That message contains stamps which get removed at
each step by the remailers, and replaced with the necessary key for
reading the mail.  When you recieve the second message back, you have
the necessary info to read the first, and have paid for its delivery.

A variation would allow the respondant to include the necessary
postage (you need to specify how much, thus compromising at least the
hop count of your route).  To keep each remailer's postage seperate,
key pairs could be generated, with the public portion kept outside the
envelope, and the secret portion sealed within the envelope, openable
only by a single remailer.  The postage would be wrapped up in
successive keys as specified on the outside of the envelope.  The
envelope would then specify the keys to be used by each remailer to
transform the body.

All of this requires defining a message as containing an envelope and
a contents.  The envelope must be able to specify how the contents are
to be encrypted at each hop. Perhaps the envelope could be placed in
the header of the message as a single field.

Details still need to be worked out.  Comments?

-- eric messick
eric at toad.com





From Marc.Ringuette at GS80.SP.CS.CMU.EDU  Tue Dec 29 15:10:54 1992
From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU)
Date: Tue, 29 Dec 92 15:10:54 PST
Subject: Self Addressed Stamped Envelopes
Message-ID: <9212292310.AA23801@toad.com>


If the remailer is willing to keep some state information around for
a limited time, auto-reply can be even simpler:  when a remailer
forwards mail, it saves the return address and replaces it with a 
unique ID for that mail, which it creates and saves.  The recipient
can just use the 'reply' command of his mailer.  When the remailer
gets mail with this unique ID, it plugs in the old return address, 
encrypts the message to the new destination, and sends it along,
retracing its original path.

This does provide a weaker security guarantee than if the remailer
_throws away_ the correspondence with input and output, though, so
a slightly more complicated alternative is probably better.


-- Marc Ringuette (mnr at cs.cmu.edu)






From hugh at domingo.teracons.com  Tue Dec 29 16:16:27 1992
From: hugh at domingo.teracons.com (Hugh Daniel)
Date: Tue, 29 Dec 92 16:16:27 PST
Subject: Crypto Bus to Winter Usenix in San Diego
Message-ID: <9212300014.AA08503@domingo.teracons.com>


  [The Bays (SF and Monteray) area CypherPunks are thinking of takeing
a bus to Usenix, if you don't live near the Bays you might want to
ingore this message.]
  Ok a bus will cost about $2500 round trip (keeping the bus in the
parking lot for the three or four days of Usenix).  If we get 20
people to ride the bus the cost per person is about $125, if we get 30
folks the cost per person is about $83, both of these are ROUND trip
prices.
  If you are interested in rideing the Crypto Bus I need a commitment
from you as to a price point.  If you are willing to ride the bus at
say, $115, then send me <hugh at toad.com> (and NOT the group!) email
saying what your price point is and if we get enough people then we
will do a bus.  I need as many commitments as possable this week
(before the new year) to get a bus reserved, if you don't read this
before the new year then respond on monday or tuesday next week.  Late
commers will be taken on a first come first served basis, if there are
enough folks to do a bus in the next few days.
  Bus will leave SF Bay area and make a day trip into Mexico, and
return to SF Bay area.  We get to stop and eat where we want!  If you
are willing to leave early Sunday, Monday, Thursday or Friday so that
we can do a long streach of Mexico coast or something please include
that in your email to me.
  If you have questions please feal free to contact me.

		||ugh Daniel
		Just a 555 acting as a Bus Driver...






From yanek at novavax.nova.edu  Tue Dec 29 16:33:58 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Tue, 29 Dec 92 16:33:58 PST
Subject: Anonymous Reply Capability (re: Self Addressed Stamped...)
In-Reply-To: <9212292310.AA23801@toad.com>
Message-ID: <9212300033.AA07511@novavax.nova.edu>


> unique ID for that mail, which it creates and saves.  The recipient
> can just use the 'reply' command of his mailer.  When the remailer
> gets mail with this unique ID, it plugs in the old return address, 
> retracing its original path.

For best security with a mix-net remailer, it should immediately
forget where a message came from.  

So if you want anonymous reply capability, the remailer could create
that unique id, but instead of associating it with a return address,
associate it with a public key (transmitted along with the message).

Then when someone sends a reply, the remailer would encrypt it with
the public key, and broadcast it.  You monitor the broacasts for
ones with public keys that match private keys you have.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From ghsvax!hal at uunet.UU.NET  Wed Dec 30 13:36:33 1992
From: ghsvax!hal at uunet.UU.NET (Hal Finney)
Date: Wed, 30 Dec 92 13:36:33 PST
Subject: Return addresses
Message-ID: <9212302111.AA09802@nano.noname>


-----BEGIN PGP SIGNED MESSAGE-----

Eric Messick has an interesting idea in his "postage due" anonymous
addresses, where the forwarders would encrypt the message contents as
it passed through, and then the receiver would have to pay them to get
the message decrypted.

Chaum's idea was that the message contents would be encrypted at each
step, as Eric suggests, but Chaum would have the encryption key be
part of the anonymous address, created by the same person who made the
anonymous address.  The idea would be, after decrypting the incoming
message, the remailer would see something like:

	Anon-To: <next destination>
	Encrypt-With: <some DES or IDEA key>

It would then encrypt the message "contents" (but not the "envelope",
as Eric points out) using the specified key.  When the owner of the
anonymous address received the message, he would decrypt it using the
chain of "Encrypt-With" keys that he put into the anonymous address.

This does not support Eric's feature of allowing remailers to charge
for anonymous addresses, but it does provide more security than the
current remailers by changing the message contents at each step.

Hal
74076.1041 at compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK0IQLqgTA69YIUw3AQHqawQAozCAXrHB1+dksB2fQKeqIoY530340chd
PZlznNGv0wp5gZdIJnFqJ/40scABHjuMc7B7e9QnUglMm1j59b6ZJOGON8kOaYsm
J19vsCOWEWuQhFtMl6oC4hXxPtjZ1BOdm8lr+RQ7KZlpBTe4eusoEMaV5zMMk1TI
vkAT6A4YZ5o=
=DZE1
-----END PGP SIGNATURE-----





From gnu at cygnus.com  Wed Dec 30 23:52:29 1992
From: gnu at cygnus.com (gnu at cygnus.com)
Date: Wed, 30 Dec 92 23:52:29 PST
Subject: Random number generators
In-Reply-To: <199212310057.AA02517@eff.org>
Message-ID: <9212310751.AA21888@cygnus.com>


>                       MONTE CARLO TECHNIQUES,
> widely used in computer simulations of physical systems, entail the
> wholesale generation of random numbers.  A new study by scientists at
> the University of Georgia (Alan Ferrenberg, 404-542-8460) shows that
> even the most advanced random-number generators are biased under
> certain circumstances (A.M. Ferrenberg et al., 7 Dec. Physical Review
> Letters).  Using one state-of-the-art program, the Marsaglia-Zeman
> random-number generator, Ferrenberg discovered that a simulated
> performance of the two-dimensional Ising model (which models the
> behavior of a plane of neighboring spins) did not agree with the
> results when calculated exactly by mathematical methods.  He traced the
> discrepancy to the random- number generator.  Other generators tried
> had differing faults.
> (Science News, 19 & 26 Dec.)

Can someone get the paper(s) and/or talk to the researcher?  Does he
have any programs he can throw into the pot for generating or testing
random numbers?

	John





From whitaker at eternity.demon.co.uk  Thu Dec 31 07:51:30 1992
From: whitaker at eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 31 Dec 92 07:51:30 PST
Subject: MEETING: Cypherpunks UK (2nd)
Message-ID: <7971@eternity.demon.co.uk>


2nd Meeting, Cypherpunks UK
---------------------------

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
Sunday, 10 January 1993, from 1300 onwards, at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

[Note to the novice: don't hand another person your secret key... the
 one named secring.pgp.  Read the documentation.]

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of public key cryptography in the U.K.
  o   The local development of anonymous remailers and a proposed
        automated public key repository at Demon Internet Systems
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders
  o   The use of HPACK in securing local file installations

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and established the /pub/pgp and /pub/ibmpc/pgp archives on
gate.demon.co.uk (expanding recently to include all versions of PGP,
and interesting related files).

Hope to see you there!

Semper vigilans,
Semper vigilans,





From yanek at novavax.nova.edu  Thu Dec 31 16:02:03 1992
From: yanek at novavax.nova.edu (Yanek Martinson)
Date: Thu, 31 Dec 92 16:02:03 PST
Subject: CFP'93 Electronic Brochure 1.2 (fwd)
Message-ID: <9301010001.AA16211@novavax.nova.edu>


Forwarded message:

> From: Bruce R Koball <bkoball at well.sf.ca.us>
> 
>   The Third Conference on Computers, Freedom and Privacy -- CFP'93
> 9-12 March 1993, San Francisco Airport Marriott Hotel, Burlingame, CA
> 
> Sponsored by: Association for Computing Machinery, 
>               Special Interest Groups on:
>               Communications (SIGCOMM)
>               Computers and Society (SIGCAS)
>               Security, Audit and Control (SIGSAC)
> 
> Co-Sponsors and Cooperating Organizations:
> 
>       American Civil Liberties Union
>       American Library Association
>       Asociacion de Technicos de Informatica
>       Commission for Liberties and Informatics
>       Computer Professionals for Social Responsibility
>       Electronic Frontier Foundation
>       Freedom to Read Foundation
>       IEEE Computer Society
>       IEEE-USA Committee on Communications and Information Policy
>       Internet Society
>       Library and Information Technology Association
>       Privacy International
>       USD Center for Public Interest Law
>       U.S. Privacy Council
>       The WELL (Whole Earth 'Lectronic Link)
> 
> Patrons and Supporters (as of 24 December 1992):
> 
>       American Express Corp.
>       Apple Computer, Inc.
>       Dun & Bradstreet Corp.
>       Equifax, Inc.
>       Information Resource Service Company
>       Mead Data Central, Inc.
>       National Science Foundation (pending)
>       RSA Data Security, Inc.
> 
> 
> CFP'93 Electronic Brochure 1.2
> 
> 
> SCOPE:
> 
> The advance of computer and telecommunications technologies holds great 
> promise for individuals and society. From convenience for consumers and 
> efficiency in commerce to improved public health and safety and 
> increased participation in democratic institutions, these technologies 
> can fundamentally transform our lives.
> 
> At the same time these technologies pose threats to the ideals of a free 
> and open society. Personal privacy is increasingly at risk from invasion 
> by high-tech surveillance and eavesdropping. The myriad databases 
> containing personal information maintained in the public and private 
> sectors expose private life to constant scrutiny.
> 
> Technological advances also enable new forms of illegal activity, posing 
> new problems for legal and law enforcement officials and challenging the 
> very definitions of crime and civil liberties. But technologies used to 
> combat these crimes can pose new threats to freedom and privacy.
> 
> Even such fundamental notions as speech, assembly and property are being 
> transformed by these technologies, throwing into question the basic 
> Constitutional protections that have guarded them. Similarly, 
> information knows no borders; as the scope of economies becomes global 
> and as networked communities transcend international boundaries, ways 
> must be found to reconcile competing political, social and economic 
> interests in the digital domain.
> 
> The Third Conference on Computers, Freedom and Privacy will assemble 
> experts, advocates and interested people from a broad spectrum of 
> disciplines and backgrounds in a balanced public forum to address the 
> impact of computer and telecommunications technologies on freedom and 
> privacy in society. Participants will include people from the fields of 
> computer science, law, business, research, information, library science, 
> health, public policy, government, law enforcement, public advocacy and 
> many others.
> 
> 
> General Chair
> -------------
> Bruce R. Koball
> CFP'93
> 2210 Sixth Street
> Berkeley, CA 94710
> 510-845-1350 (voice)
> 510-845-3946 (fax)
> bkoball at well.sf.ca.us
> 
> Steering Committee
> ------------------
> John Baker                          Mitch Ratcliffe
> Equifax                             MacWeek Magazine
> 
> Mary J. Culnan                      Peter G. Neumann
> Georgetown University               SRI International
> 
> Dorothy Denning                     David D. Redell
> Georgetown University               DEC Systems Research Center
> 
> Les Earnest                         Marc Rotenberg
> GeoGroup, Inc.                      Computer Professionals
>                                     for Social Responsibility
> Mike Godwin
> Electronic Frontier Foundation      C. James Schmidt
>                                     San Jose State University
> Janlori Goldman
> American Civil Liberties Union      Barbara Simons
>                                     IBM
> Mark Graham
> Pandora Systems                     Lee Tien
>                                     Attorney
> Lance J. Hoffman
> George Washington University        George Trubow
>                                     John Marshall Law School
> Donald G. Ingraham
> Office of the District Attorney     Willis Ware
> Alameda County, CA                  Rand Corp.
> 
> John McMullen                       Jim Warren
> NewsBytes                           MicroTimes & Autodesk, Inc.
> 
> Simona Nass
> Student - Cardozo Law School
> 
> Affiliations are listed for identification only.
> 
> 
> Pre-Conference Tutorials:
> On Tuesday 9 March, the day before the formal conference begins, CFP'93
> is offering a number of in-depth tutorials on a wide variety of subjects
> on four parallel tracks. These presentations will range from interesting
> and informative to thought-provoking and controversial. The tutorials
> are available at a nominal additional registration cost.
> 
> Conference Reception:
> Following the Tutorials on Tuesday evening, you are invited to meet new 
> and old friends and colleagues at an opening reception. 
> 
> Single Track Main Program:
> The technological revolution that is driving change in our society has
> many facets and we are often unaware of the way they all fit together,
> especially the parts that lie outside of our own expertise and interest.
> The primary goal of CFP'93 is to bring together individuals from
> disparate disciplines and backgrounds, and engage them in a balanced
> discussion of all CFP issues. To this end our main program, starting on
> Wednesday 10 March, is on a single track enabling our attendees to take
> part in all sessions.
> 
> Registration is Limited:
> CFP'93 registration will be limited to 550 attendees, so we advise you 
> to register as early as possible and take advantage of the early 
> registration discounts.
> 
> Luncheons and Banquets:
> A key component of the CFP conferences has been the interaction between
> the diverse communities that constitute our attendees. To promote this
> interaction CFP'93 is providing three luncheons and evening two banquets
> with the cost of conference registration.
> 
> EFF Pioneer Awards
> All conference attendees are invited to the Awards Reception sponsored 
> by the Electronic Frontier Foundation (EFF) on Wednesday evening, 10 
> March. These, the second annual EFF Pioneer Awards, will be given to 
> individuals and organizations that have made distinguished contributions 
> to the human and technological realms touched by computer-based 
> communications.
> 
> Birds of a Feather Sessions:
> CFP'93 will provide a limited number of meeting rooms to interested 
> individuals for special Birds of a Feather sessions after the formal 
> program each evening. These sessions will provide an opportunity for 
> special interest discussions that were not included in the formal 
> program and will be listed in the conference materials. For further 
> information contact CFP'93 BoF Chair:
> 
>       C. James Schmidt
>       University Librarian
>       San Jose State University
>       One Washington Square
>       San Jose, CA 95192-0028
>       voice        408-924-2700
>       voice mail   408-924-2966
>       e-mail       schmidtc at sjsuvm1.sjsu.edu
> 
> 
> CFP'93 Featured Speakers:
> 
> Nicholas Johnson 
> 
> Nicholas Johnson was appointed head of the Federal Communications 
> Commission by President Johnson in 1966, serving a seven year term. In 
> his role as commissioner, he quickly became an outspoken consumer 
> advocate, attacking network abuses and insisting that those who use the 
> frequencies under the FCC license are the public's trustees. He has been 
> a visiting professor of law at the College of Law at the University of 
> Iowa since 1981 and is currently co-director of the Institute for 
> Health, Behavior and Environmental Policy at the University of Ohio.
> 
> Willis H. Ware
>  
> Willis H. Ware has devoted his career to all aspects of computer 
> science--hardware, software, architectures, software development, public 
> policy and legislation. He chaired the "HEW committee" whose report was 
> the foundation for the Federal Privacy Act of 1974. President Ford 
> appointed him to the Privacy Protection Study Commission whose report 
> remains the most extensive examination of private sector record-keeping 
> practices.  Dr. Ware is a member of the National Academy of Engineering, 
> a Fellow of the Institute of Electronic and Electrical Engineers, and a 
> Fellow of the American Association for Advancement of Science.
> 
> John Perry Barlow 
> 
> John Perry Barlow is a retired Wyoming cattle rancher, a lyricist for 
> the Grateful Dead, and a co-founder of the Electronic Frontier 
> Foundation. He graduated from Wesleyan University with an honors degree 
> in comparative religion. He writes and lectures on subjects relating to 
> digital technology and society, and is a contributing editor of numerous 
> publications, including Communications of the ACM, NeXTworld, 
> MicroTimes, and Mondo 2000.
> 
> Cliff Stoll
> 
> Cliff Stoll is best known for tracking a computer intruder across the 
> international networks in 1987; he told this story in his book, "The 
> Cuckoo's Egg" and on a Nova television production. He is less known for 
> having a PhD in planetary science, piecing quilts, making plum jam, and 
> squeezing lumps of bituminous coal into diamonds.
> 
> 
> CFP'93 Tutorials:
> 
> Tuesday 9 March - Morning Tutorials
> 
> Information Use in the Private Sector
> Jack Reed, Information Resource Service Company
> Diane Terry, TransUnion Corp.    Dan Jones, D.Y. Jones & Assoc.
> 
> This tutorial will deal with the use of personal information from the
> point of view of some private sector information vendors and users. It
> will include a discussion of the Fair Credit Reporting Act and the
> "Permissible Purposes" for obtaining a consumer credit report.
> Information used for purposes outside the FCRA will be discussed in
> relationship to privacy and societal needs for businesses and
> individuals.
> 
> Access to Government Information:
> James Love, Director, Taxpayer Assets Project
> 
> The tutorial will examine a wide range of problems concerning citizen 
> access to government information, including how to ask for and receive 
> information under the federal Freedom of Information Act, what types of 
> information government agencies store on computers, what the barriers 
> are to citizen access to these information resources, and how citizens 
> can change government information policy to expand access to taxpayer-
> funded information resources.
> 
> Exploring the Internet -- a guided journey
> Mark Graham, Pandora Systems	Tim Pozar, Late Night Software
> 
> This tutorial will give participants a practical introduction to the 
> most popular and powerful applications available via the world's largest 
> computer network, the Internet.  There will be hands-on demonstrations 
> of communications tools such as e-mail, conferencing, Internet Relay 
> Chat, and resource discovery and navigation aids such as Gopher, WAIS, 
> Archie and World Wide Web. Extensive documentation will be provided.
> 
> Constitutional Law for Non-lawyers (1/2 session):
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> 
> This tutorial is designed to inform non-lawyers about the Constitutional 
> issues that underlie computer-crime and computer civil-liberties cases.  
> The tutorial focuses on the First and Fourth Amendments, but includes a 
> discussion of the Fifth Amendment and its possible connection to the 
> compelled disclosure of cryptographic keys. It also includes a 
> discussion of the appropriateness of "original intent" as a method for 
> applying the Constitution in the modern era.
> 
> Civil Liberties Implications of Computer Searches & Seizures (1/2 ses.):
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> 
> This tutorial assumes only a very basic knowledge of Constitutional law 
> (the prior tutorial provides an adequate background), and outlines how 
> searches and seizures of computers may raise issues of First and Fourth 
> Amendment rights, as well as of federal statutory protections. It 
> includes a discussion of what proper search-and-seizure techniques in 
> such cases may be. 
> 
> 
> Tuesday 9 March - Afternoon Tutorials
> 
> Practical Data Inferencing: What we THINK we know about you.
> Russell L. Brand, Senior Computer Scientist, Reasoning Systems
> 
> What do your transaction trails reveal about you?  Are you a good risk 
> to insure?  Are you worth kidnapping, auditing or suing?  Which products 
> should I target at you?  Are you a member of one of those groups that I 
> would want to harass or discriminate against? This tutorial will be a 
> hands-on approach to digging for data and to piecing it back together.  
> Time will be divided between malicious personal invasions and sweeping 
> searches that seek only profit, followed by a brief discussion about 
> improper inferences and their practical impact on innocent files and 
> lives. Legal and moral issues will not be addressed.
> 
> Telecommunications Fraud
> Donald P. Delaney, Senior Investigator, New York State Police
> 
> Illegal call sell operations in New York City are estimated to be a 
> billion dollar industry. This tutorial will provide an overview of the 
> problem, from finger hacking to pay phone enterprises, and will include 
> an up-to-date assessment of the computer cracker/hacker/phone phreak 
> impact on telephone company customer losses. Also discussed will be 
> unlawful access of telephone company switches; unlawful wiretapping and 
> monitoring; cards, codes and 950 numbers; New York State law and police 
> enforcement; methods of investigation and case studies.
> 
> Private Sector Marketplace and Workplace Privacy 
> Ernest A. Kallman, Bentley College, H. Jeff Smith, Georgetown University
> 
> This tutorial will give participants a general overview of privacy 
> issues affecting uses of personal information (e.g., medical 
> information, financial information, purchase histories) in the 
> marketplace as well as privacy concerns in the workplace (e.g., privacy 
> of electronic and voice mail, work monitoring).  The tutorial will also 
> set the boundaries for privacy arguments in the middle and latter 1990s.
> 
> SysLaw
> Lance Rose, Attorney and Author "SysLaw"
> 
> The SysLaw tutorial session will explore in depth the freedom and
> privacy issues encountered by computer bulletin boards (BBS), their
> system operators and their users.  BBSs are estimated to number over
> 45,000 today (not counting corporate systems), and range from small,
> spare-time hobby systems to systems with thousands of users, grossing
> millions of dollars.  BBSs are a grassroots movement with an entry cost
> of $1,000 or less, and the primary vehicles for new forms of electronic
> communities and services. Subjects covered will include: First Amendment
> protection for the BBS as publisher/distributor; data freedom and
> property rights on the BBS; how far can sysops control BBS user
> activities?; and user privacy on BBSs today.
> 
> Note: Tutorial presenters will offer expert opinions and information.
> Some may advocate particular viewpoints and thus may put their own
> "spin" on the issues. Caveat Listener. 
> 
> 
> CFP'93 Main Program Sessions: 
> 
> Wednesday 10 March
> 
> Electronic Democracy
> Chair - Jim Warren, MicroTimes and Autodesk, Inc.
> 
> The effects of computer and telecommunications technologies on 
> democratic processes and institutions are increasing dramatically. This 
> session will explore their impacts on political organizing, campaigning, 
> access to representatives and agencies, and access to government 
> information that is essential for a free press and an informed 
> electorate.
> 
> Electronic Voting -- Threats to Democracy
> Chair - Rebecca Mercuri, University of Pennsylvania
> 
> This panel session will invite representatives covering a broad spectrum 
> of involvement with the controversial subject of electronic vote 
> tallying to address such issues as: Is a secure and reliable electronic 
> voting system feasible? What threats to these systems are identifiable? 
> Should electronic voting systems be open for thorough examination? Can 
> auditability be assured in an anonymous ballot setting? Can voting by 
> phone be practical and confidential? Did Congress exempt voting machines 
> from the Computer Security Act?
> 
> Censorship and Free Speech on the Networks
> Chair - Barbara Simons, IBM
> 
> As online forums become increasingly pervasive, the notion of "community 
> standards" becomes harder to pin down. Networks and BBSs will link--or 
> create--diverse, non-geographic communities with differing standards, 
> laws, customs and mores. What may be frank discussion in one forum may 
> be obscenity or defamation or sexual harassment in another. This session 
> will explore the questions of what kinds of freedom-of-speech problems 
> face us on the Net and what kinds of legal and social solutions we need.
> 
> Portrait of the Artist on the Net
> Chair - Anna Couey, Arts Wire
> 
> Computer forums and networks make possible both new artforms and new 
> ways of remote collaboration and exhibition. The growth of the Net 
> creates opportunities for the blossoming of dynamic and interactive 
> artforms and of artistic cultures -- provided that networks become 
> widely accessible and remain open to artistic expression without 
> political interference. This session will examine the potentials and the 
> problems of art and artists on the Net.
> 
> 
> 
> Thursday 11 March
> 
> Digital Telephony and Crypto Policy
> Chair - John Podesta, Podesta and Associates
> 
> The increasingly digital nature of telecommunications potentially 
> threatens the ability of law enforcement agencies to intercept them when 
> legally authorized to do so. In addition, the potential widespread use 
> of cryptography may render the ability to intercept a communication 
> moot. This session will examine these issues and the proposals that 
> have been put before Congress by law enforcement agencies to address 
> these perceived problems.
> 
> Health Records and Confidentiality
> Chair - Janlori Goldman, American Civil Liberties Union
> 
> As the new Administration and Congress consider proposals to reform the 
> United States health care system, it is imperative that confidentiality 
> and security safeguards be put in place to protect personal information. 
> Currently, no comprehensive legislation exists on the confidentiality of 
> health information. This session will explore the current and potential 
> uses of health care information, and proposals to safeguard the 
> information.
> 
> The Many Faces of Privacy
> Chair  - Willis Ware, Rand Corp.
> 
> Privacy at any cost is foolish, unwise and an untenable position, and 
> privacy at zero cost is a myth. This two-part session will explore the 
> balancing act between the two extremes and the costs and benefits that 
> accrue. The first part will present several examples of systems and 
> applications in the public and private sectors that stake out a position 
> in this continuum.   The second part will be a panel discussion 
> exploring the issues raised by the examples previously presented.
> 
> The Digital Individual
> Chair - Max Nelson-Kilger, San Jose State University
> 
> We are all represented by personal records in countless databases. As 
> these records are accumulated, disseminated and coalesced, each of us is 
> shadowed by an ever larger and more detailed data alter-ego, which 
> increasingly stands in for us in many situations without our permission 
> or even awareness. How does this happen? How does it affect us? How will 
> it develop in the future? What can we do? This session will investigate 
> these questions.
> 
> 
> Friday 12 March
> 
> Gender Issues in Computing and Telecommunications
> Chair - Judi Clark, Bay Area Women in Telecommunications
> 
> Online environments are largely determined by the viewpoints of their
> users and programmers, still predominantly white men. This panel will
> discuss issues of freedom and privacy that tend to affect women -- such
> as access, identity, harassment, pornography and online behavior -- and
> provide recommendations for gender equity policies to bulletin board
> operators and system administrators.
> 
> The Hand That Wields the Gavel
> Chair - Don Ingraham, Asst. District Attorney, Alameda County, CA
> 
> An inevitable result of the settlement of Cyberspace is the adaptation
> of the law to its particular effects. In this session  a panel of
> criminal lawyers addresses the fallout from a hypothetical computer
> virus on the legal responsibilities of system managers and operators.
> The format will be a simulated court hearing. Attendees will act as
> advisory jurors in questioning and in rendering a verdict.
> 
> The Power, Politics, and Promise of Internetworking
> Chair- Jerry Berman, Electronic Frontier Foundation
> 
> This session will explore the development of internetworking 
> infrastructures, domestically and worldwide. How will this 
> infrastructure and its applications be used by the general public?  What 
> will the global network look like to the average user from Kansas to 
> Kiev?  How will politics, technology and legislation influence the 
> access to, and cost of, the Net?  How can the potential of this powerful 
> medium be fully realized?
> 
> International Data Flow
> Chair - George Trubow, John Marshall Law School
> 
> The trans-border flow of information on international computer networks 
> has been a concern for governments and the private sector. In addition 
> to concerns for privacy and data security, the economic and national 
> security implications of this free flow of information among scientists, 
> engineers and researchers around the world are also cause for concern. 
> This session will assemble a number of speakers to compare the various 
> perspectives on the problem 
> 
> 
> 
> Some of the Speakers in the CFP'93 Main Program: 
> 
> Phillip E. Agre, Dept. of Communication, Univ. of California, San Diego
> Jonathan P. Allen, Dept. of Information & Computer Science, 
>       University of California, Irvine
> Sheri Alpert, Policy Analyst, author: "Medical Records, Privacy, and 
>       Health Care Reform"
> William A. Bayse, Assistant Director, Federal Bureau of Investigation
> William Behnk, Coordinator, Legislative Information System, State of 
>       California
> Paul Bernstein, Attorney
> Kate Bloch, Hastings College of the Law
> Anita Borg, DEC Network Systems Lab
> Richard Civille, Computer Professionals for Social Responsibility
> Roger Clarke, Reader in Information Systems, Department of Commerce, 
>       Australian National University
> Dorothy Denning, Chair, Computer Science Department, Georgetown 
>       University
> Janet Dixon, Stanford Linear Accelerator Center
> Robert Edgar, Simon and Schuster Technology Group
> Kathleen Frawley, American Health Information Management Association
> Emmanuel Gardner, District Manager, Government Affairs, AT&T 
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> Joe Green, University of Minnesota
> Sarah Grey, Computer Department, We The People, Brown presidential 
>       campaign organization (invited)
> Will Hill, Bellcore
> Carl Kadie, Co-editor, Computers and Academic Freedom News newsletter
> Mitch Kapor, Chairman, Electronic Frontier Foundation
> David Lewis, Deputy Registrar, Department of Motor Vehicles, 
>       Commonwealth of Massachusetts
> James Love, Director, Taxpayers Assets Project
> Judy Malloy, Associate Editor, Leonardo Electronic News
> Irwin Mann, Mathematician, New York University
> David McCown, Attorney
> Rob Mechaley, Vice President, Technology Development, McCaw Cellular 
>       Communications, Inc.
> Robert Naegele, Granite Creek Technology Inc., Voting Machine Examiner, 
>       consultant to NY State
> Barbara Peterson, Staff Attorney, Joint Committee on Information 
>       Technology Resources, Florida Legislature
> Jack Reed, Chairman, Information Resource Service Company
> Virginia E. Rezmierski, Assistant for Policy Studies to the Vice 
>       Provost for Information Technology, University of Michigan
> Jack Rickard, Editor, Boardwatch Magazine
> Randy Ross, American Indian Telecommunications
> Roy Saltman, National Institute of Standards and Technology
> Robert Ellis Smith, Publisher, Privacy Journal
> David Sobel, Computer Professionals for Social Responsibility
> Ross Stapleton, Research Analyst, Central Intelligence Agency
> Jacob Sullum, Associate Editor, Reason Magazine
> Greg Tucker, Coordinator, David Syme Faculty of Business, 
>       Monash University, Australia
> Joan Turek-Brezina, Chair, Health and Human Services Task Force on 
>       Privacy of Private-Sector Health Records
> 
> 
> Registration:
> Register for the conference by returning the Conference Registration
> Form along with the appropriate payment. The registration fee includes
> conference materials, three luncheons (Wednesday, Thursday and Friday),
> two banquet dinners (Wednesday and Thursday) and evening receptions
> (Tuesday, Wednesday and Thursday). Payment must accompany registration.
> 
> Registration Fees are: 
>       If mailed by:       7 February        8 March         on site 
>       Conference Fees:      $300             $355             $405
>       Tutorial Fees:        $135             $165             $195
>       Conference & Tutorial $435             $520             $600
> 
> Registration is limited to 550 participants, so register early and save!
> 
> By Mail:                               By Fax:
> (with Check or Credit Card)            (with Credit Card only)
> CFP'93 Registration                    Send Registration Form
> 2210 Sixth Street                      (510) 845-3946
> Berkeley, CA 94710                     Available 24 hours
> 
> By Phone:                              By E-Mail:
> (with Credit Card only)                (with Credit Card only)
> (510) 845-1350                         cfp93 at well.sf.a.us
> 10 am to 5 pm Pacific Time
> 
> CFP'93 Scholarships:
> The Third Conference on Computers, Freedom and Privacy (CFP'93) will 
> provide a limited number of full registration scholarships for students 
> and other interested individuals. These scholarships will cover the full
> costs of registration, including three luncheons, two banquets, and all
> conference materials. Scholarship recipients will be responsible for
> their own lodging and travel expenses. Persons wishing to apply for one
> of these fully-paid registrations should contact CFP'93 Scholarship
> Chair, John McMullen at:  mcmullen at mindvox.phantom.com
> 
> Hotel Accommodations:
> The Third Conference on Computers, Freedom and Privacy will be held at 
> the San Francisco Airport Marriott Hotel in Burlingame, CA. This 
> facility is spacious and comfortable, and is easily accessible from the 
> airport and surrounding cities. Because of the intensive nature of the 
> conference, we encourage our attendees to secure their lodging at the 
> conference facility. Special conference rates of $99/night, single or 
> multiple occupancy, are available. Our room block is limited and these 
> conference rates are guaranteed only until 9 February 1993, so we urge 
> you to make your reservations as early as possible. When calling for 
> reservations, please be sure to identify the conference to obtain the 
> conference rate. Hotel Reservations: (415) 692-9100 or (800) 228-9290. 
> 
> Refund Policy:
> Refund requests received in writing by February 19, 1993 will be 
> honored. A $50 cancellation fee will be applied. No refunds will be made 
> after this date; however, you may send a substitute in your place.
> 
> Registration Form
> 
> Name (Please print):__________________________________________________
> 
> Title:________________________________________________________________
> 
> Affiliation:__________________________________________________________
> 
> Mailing Address:______________________________________________________
> 
> City, State, Zip:_____________________________________________________
> 
> Country:______________________________________________________________
> 
> Telephone:_____________________________Fax:___________________________
> 
> E-mail:_______________________________________________________________
> 
> Privacy Locks:
> We will not sell, rent, loan, exchange or use this information for any 
> purpose other than official Computers, Freedom and Privacy Conference 
> activities. A printed roster will be distributed to attendees. Please 
> indicate the information you wish to be excluded from the roster:
>       __Print only name, affiliation and phone number
>       __Print name only
>       __Omit all information about me in the roster
> 
> Registration Fees  (please indicate your selections):
>       If mailed by:       7 February         8 March         on site 
>       Conference Fees:      $300__            $355__          $405__
>       Tutorial Fees         $135__            $165__          $195__
>       Conference & Tutorial $435__            $520__          $600__
> 
> If you have registered for the Tutorials, select one from each group:
> 9:00 AM - 12:00 Noon 
>       __Information Use in Private Sector
>       __Constitutional Law for Non-lawyers & Civil-liberties 
>           Implications of Computer Searches and Seizures
>       __Access to Government Information
>       __Exploring the Internet
> 
> 1:30 PM - 4:30 PM
>       __Practical Data Inferencing: What we THINK we know about you.
>       __Telecommunications Fraud
>       __Private Sector Marketplace and Workplace Privacy 
>       __SysLaw
> 
> Payments:        Total Amount____________
> 
> Please indicate method of payment:     __Check (payable to CPF'93)
> (payment must accompany registration)  __VISA
>                                        __MasterCard
> 
> Credit card #______________________________Expiration date____________
> 
> Name on card__________________________________________________________
> 
> Signature_____________________________________________________________
> 
> 


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819