From jamesd at netcom.com  Wed Feb  1 00:11:56 1995
From: jamesd at netcom.com (James A. Donald)
Date: Wed, 1 Feb 95 00:11:56 PST
Subject: The security characteristics of crypto modules with secrets
In-Reply-To: <199502010607.WAA04942@largo.remailer.net>
Message-ID: <Pine.3.89.9501312316.A19818-0100000@netcom4>


From: Matt Blaze <mab at research.att.com>
On Tue, 31 Jan 1995, Eric Hughes wrote:
> Let's take as our model general purpose computers which can't store
> secrets connected directly to crypto modules which can.  Furthermore,
> let us assume that these general purpose computer are subject to
> intrusion.  In other words, it's today's servers with attached crypto.
> 
> Now, the crypto module can't authenticate the machine it's plugged
> into, because, by definition, that machine can't keep a secret.

The model does not work, because that is not what we
want to do.

True:  Matt's proposal cannot authenticate a machine.  But
one does not really want to authenticate a machine.  One
wants to authenticate data, that one might choose
to transmit from that machine.  For this purpose a 
tamper resistant crypto module that can be connected 
to a machine, but which is under user
control, not under the control of the machine, is the
only totally bullet proof solution.

Of course expensive tamper proof crypto modules already exist:  A 
Dos computer in a room with a key, running virtually no 
network software and possessing almost no utilities, though
doubtless what Matt had in mind was a PCI card that one
could keep in ones wallet.

> The prevalent use of modules further reduces the likelihood of initial
> attacks based on spoofing.  Since active IP attacks require the
> subversion of routers, and since router software is much more
> difficult to subvert than general purpose servers, adding crypto
> modules to routers would be a big win.

This does not make sense:  The advantage of a tamper resistant module
is that if somebody physically gets to the system, he still cannot
get the key.  But if he physically gets to the router, he can
make it do his will, even if he does not get the key.  So one
might as well have the key in software in the router.

If the router is hard to subvert, and the attacker cannot 
physically get to it, then there is little need for a separate
tamper resistant module.  Software will do fine.

If the router can be got at, you are stuffed regardless, tamper
resistant module or not.

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From skaplin at mirage.skypoint.com  Wed Feb  1 00:45:08 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 1 Feb 95 00:45:08 PST
Subject: Minnesota Cypherpunks Get Together and Bull Session
Message-ID: <LKqBlKjqRWXF078yn@mirage.skypoint.com>


Well folks, I've been on the list over a year and haven't seen a get
together for those of us in MN. So being the masochist that I am, I'm going
to try to put one together. Granted it won't be nearly as elaborate as those
in the Bay area, but it'll be a start.

Tentatively:

Date: Saturday March 4, 1995

Place: Applebees - Calhoun Village Shopping Center, Minneapolis

Time: 5:00pm 'til they throw us out.


This may change, depending on how many (or how few) respond. Let me know if
you are interested or have suggestions. This also will be a good
opportunity for some key signing too.


Sam

--
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
                Architecture is the art of how to waste space.






From danisch at ira.uka.de  Wed Feb  1 01:18:54 1995
From: danisch at ira.uka.de (Hadmut Danisch)
Date: Wed, 1 Feb 95 01:18:54 PST
Subject: CD-ROM [brief addition]
Message-ID: <9502010918.AA00196@elysion.iaks.ira.uka.de>


> 	I forgot to mention that the CD-ROM in development will be
> export restricted. It isn't going to be sold outside the united states
> and canada.


:-(





From hkhenson at cup.portal.com  Wed Feb  1 01:27:27 1995
From: hkhenson at cup.portal.com (hkhenson at cup.portal.com)
Date: Wed, 1 Feb 95 01:27:27 PST
Subject: Surety (authentication)
Message-ID: <9502010126.2.19816@cup.portal.com>


Thanks to all of you who replied to my request.  I have what I 
needed.  Keith





From homer at math.cornell.edu  Wed Feb  1 04:23:52 1995
From: homer at math.cornell.edu (Homer Wilson Smith)
Date: Wed, 1 Feb 95 04:23:52 PST
Subject: A proposal....
In-Reply-To: <199502011144.AA03317@xs1.xs4all.nl>
Message-ID: <Pine.SUN.3.91.950201064928.14234A-100000@math>




On Wed, 1 Feb 1995, Remailer Operator wrote:

> I'll not block addresses based on information supplied here. You forget
> that there is no -formal- system, just a loose collection of operators.
> There is no single policy, that operators use. 

     Certainly, each operator is responsible for his own site and must
act or not act as he sees fit, accepting the full consequences of those
decisions.  That is as it should be.

     No one is DEMANDING that anyone block an address, except the
complainer's of course. :)

     However there is no harm in global reporting of spams or abuse,
as each operator can choose to act or not act on the data as he will.

> >     Perhaps there could be a blocking mailing list, and all remailers
> > could advertise that list in their headers, and anyone who wants to
> > be blocked can send mail to that list and we would all get it.
> 
> Perhaps. But I think it is a matter between the operator of a specific
> site and the to be blocked address, not something for the world to know.

     Well in general I would guess that complainers WANT all reops to know
about the complaint, they only complain to the one they got the abuse
from, but they figure the abuser will just go to the next remailer and
start there.  They would prefer a way to contact all reops immediately to
stop this sort of thing from happening.

     Complainer's are often so mad at the abuse that they not only
write the remailer operator but also his sysadmin.  Rahul for example
has gotten at least two things 'on his desk' in the last two days,
because of stuff going through my remailer, and that's two two many
for me.  That doesn't include all the ones he's gotten that he didn't
forward to me because it was already handled.
 
     Further various and sundry turkeys are going to be complaining
both to ME and possibly to Rahul for the next month about the
Valentine's spam, as late readers come up to it in their news.  I am
STILL getting complaints and the guy was hung out to dry 10 hours ago.

     The complainer almost always wants ALL remail to that address
stopped, and he certainly doesn't want to have to send repeated
messages to various remailers as the abuser keeps jumping around.
That would infuriate me no end if I were a postmaster.

     I would suggest that those of us who are interested, provide such
a common list for complainers, it would make them feel one hell of a
lot better about remailers, and keep the borderline cases on the side
of free speech.  A lot of people would like to see remailers shut
down, but for many of them its mainly because remailers make them feel
hysterical when things go out of control.  

     THEY DON'T KNOW WHERE TO GO TO BRING THINGS BACK INTO CONTROL,
AND THEY ARE NOT SURE THEY WILL BE PAID ATTENTION TOO.  This leads to
cc's to sysadmins and things, which I for one find INTOLERABLE.
 
     If we can bring a sense of immediate (even if partial) response
and control to the remailer network, then this hysteria may subside a
bit.

     I would distinguish between two kinds of abuse.
 
     Individual abuse, and spams.
 
     On the individual abuse I would agree that personal data should
probably be kept confidential.  Certainly one does not give away
the complainee to the complainer so of course one does not post
the complainee's name here or elsewhere.  I have taken to posting
the letters that I write them however, to show newbies possible
ways of dealing with these things.
 
     However I see nothing wrong with posting the complainer's name.  Some
complainer's might object, but I think they understand the need to widely
distribute, at least to the reop's, their address so that we can all
effectively block them IF WE CHOOSE. 

     In any case, such individual abuse is usually from one person to
another, and its easy to block the TO: line without revealing the From:
line, so there is no need to post the complainee's name. 
 
     In the case of spams, its different.  Spammers usually spam from one
address (forged or not), but post to many sites. Blocking the To: line is
impossible, but the From: line is easy. 
 
     In this case I am for posting the From: line, not only here but as
far and wide as possible.  If I am wrong, I am sure you will let me know. 
 
     I propose a mailing list, public or not, which those of you who wish
to can subscribe, and which we advertise in the headers of all outgoing
mail, saying that complaints should be sent to the mailing list.  That way
we all get to see spammers and complainers at once, making for much more
effective action. 

     This reduces the wear and tear on the postmasters, who surely do not
deserve the brunt of the abuse.  Like the Credit Card reporting agencies,
one call is all it takes to report all your cards gone, one mail is all it
takes to inform all operators of a spam or abuse. 
 
     I am not suggesting that all reops join this list, or act on the
data posted to it if they do, or advertise the list in their headers.  I 
propose that THOSE OF US WHO WANT TO DO THIS, do it.
 
     Sort of a loose coalition or alliance amongst reops to show
solidarity and personal responsibility towards the net.

     I KNOW people would appreciate it.

     How say any of you?
 
     Homer
 
P.S.  groupname at bull.com went down after the Valentine spam.
 
     Not very nice.  I have already gotten warm mail commending US
on how fast we nuked the guy.
 
    I say have no mercy for spammers.

    Homer







From usura at replay.com  Wed Feb  1 05:18:47 1995
From: usura at replay.com (Alex de Joode)
Date: Wed, 1 Feb 95 05:18:47 PST
Subject: CD-ROM [brief addition]
Message-ID: <199502011233.AA16433@xs1.xs4all.nl>


In article <199502010224.SAA24809 at infinity.c2.org> sameer stated:

: 	I forgot to mention that the CD-ROM in development will be
: export restricted. It isn't going to be sold outside the united states
: and canada.

Why not produce it outside the US and import it ?

Regards,
--
Alex de Joode					    
usura at replay.com	                               Hate mail appreciated,
http://www.xs4all.nl/~usura             weekly contest for best death threat.







From danisch at ira.uka.de  Wed Feb  1 05:56:14 1995
From: danisch at ira.uka.de (Hadmut Danisch)
Date: Wed, 1 Feb 95 05:56:14 PST
Subject: PGP Question
Message-ID: <9502011343.AA00578@elysion.iaks.ira.uka.de>



Is there any simple way to glue a binary file and its detached pgp
signature together into a single pgp file (as produced by non-detached
signing) ?

thanks
Hadmut





From danisch at ira.uka.de  Wed Feb  1 05:56:47 1995
From: danisch at ira.uka.de (Hadmut Danisch)
Date: Wed, 1 Feb 95 05:56:47 PST
Subject: CD-ROM [brief addition]
Message-ID: <9502011353.AA00592@elysion.iaks.ira.uka.de>



> Why not produce it outside the US and import it ?

:-)




From perry at imsi.com  Wed Feb  1 06:18:28 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 1 Feb 95 06:18:28 PST
Subject: VoicePGP cracked in 10 minutes?...
In-Reply-To: <199502010348.VAA00506@einstein.ssz.com>
Message-ID: <9502011418.AA26570@snark.imsi.com>




root says:
> I heard a rumor hear in Ctl. Tx. that the VoicePGP project was cracked in the
> last couple of days in approx. 10 minutes. Anyone have any info on this other
> than one of those wild rumors that occur?

Considering that VoicePGP hasn't even been released, this is
fascinating news. Perhaps the same team could work next on cracking
things that haven't even been invented yet.

.pm





From perry at imsi.com  Wed Feb  1 06:35:42 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 1 Feb 95 06:35:42 PST
Subject: How the cypherpunks nearly got me fired (long)
In-Reply-To: <v03001102ab54e8d6db82@[140.174.229.210]>
Message-ID: <9502011435.AA26645@snark.imsi.com>



Michael Sattler says:
> At 22:10 1/31/95, David Mandl wrote:
> 
> [really horrid story about true life at a corporate dinosaur deleted]
> 
> >I just thought
> >you might enjoy this little story, and would want to keep it in mind if
> >you're ever considering employment at Bear-Stearns.
> 
> Part of my job-interviewing procedure has become grilling a would-be
> employer (or whoever is asking for a contractor) about their net
> connections.

I'm a consultant. However, I won't take on clients with sufficiently
distasteful business practices. This is something I consider to be
sufficiently distasteful.

Perry





From mab at crypto.com  Wed Feb  1 07:27:03 1995
From: mab at crypto.com (Matt Blaze)
Date: Wed, 1 Feb 95 07:27:03 PST
Subject: The security characteristics of crypto modules with secrets
In-Reply-To: <Pine.3.89.9501312316.A19818-0100000@netcom4>
Message-ID: <199502011528.KAA23229@crypto.com>


>> The prevalent use of modules further reduces the likelihood of initial
>> attacks based on spoofing.  Since active IP attacks require the
>> subversion of routers, and since router software is much more
>> difficult to subvert than general purpose servers, adding crypto
>> modules to routers would be a big win.
>
>This does not make sense:  The advantage of a tamper resistant module
>is that if somebody physically gets to the system, he still cannot
>get the key.  But if he physically gets to the router, he can
>make it do his will, even if he does not get the key.  So one
>might as well have the key in software in the router.
>
>If the router is hard to subvert, and the attacker cannot 
>physically get to it, then there is little need for a separate
>tamper resistant module.  Software will do fine.
>
>If the router can be got at, you are stuffed regardless, tamper
>resistant module or not.

The advantage of a secure crypto module on an insecure server (or
router or whatever) is in limiting the scope of successful attack. 
As Eric pointed out, if you can subvert a general purpose machine that
does all its crypto through a secure module that you can't subvert,
you can still add a covert "service" to the machine that lets
a future spoofer use the module remotely.  The main important
difference between this attack and just learning the server's secret
is that it only remains useful as long as the attack is undiscovered.
In the case of software keys, it is sufficient for the attacker to subvert
the machine that knows the secret ONCE.  He or she can put things back
to normal on the original machine and still know the secret forever, with
little chance of future detection.  With a secure module, the attacker has
to either steal (physically) the hardware (which will be discovered when
the real server stops working) or set up the kind of future access that
Eric mentioned (which, once discovered, will likely be turned off or
investigated).

If you have secure crypto hardware, you only have to worry about and
detect whether the server is being compromised continuously.  Otherwise,
without special hardware, you have to worry about and detect whether the
server was ever compromised since it was last rekeyed.  Personally,
the former seems like a realistic thing to try to do while the latter
doesn't, at least in the environments in which I live.

If the server hardware or software is insecure, cryptographic techniques
can't provide any absolute guarantees, period.   In the real world, though,
you're not interested in absolute guarantees, you just want to
reduce risks.   How effective the mechanisms to do this are depends on
how accurately they reflect the real world threats.

-matt





From ssteele at eff.org  Wed Feb  1 07:38:08 1995
From: ssteele at eff.org (Shari Steele)
Date: Wed, 1 Feb 95 07:38:08 PST
Subject: your membership renewal letter
Message-ID: <199502011537.KAA27134@eff.org>


February 1, 1995

Dear David,

We received your response to our membership renewal reminder and would like
to thank you for taking the time to actually write a letter explaining why
you have chosen not to renew.  We are sorry that you are unhappy with the
role EFF played in the Digital Telephony negotiations.  We were not totally
comfortable our role, but we do believe we did the right thing and that
there would be a much more intrusive bill if EFF had done nothing.

However, I'm sure that you've heard the arguments by now, and I'm not
writing to change your mind about our role in Digital Telephony but,
instead, to let you know about a lawsuit we're about to file against the
State Department and others claiming the ITAR listing of encryption as a
munition is unconstitutional.  Our plaintiff wanted to post an encryption
algorithm he developed to sci.crypt.  The State Department informed him
that he would need an export license before he could post the algorithm on
the Net and then told him that he would be denied the license because the
algorithm was too strong.  We see this as a critical First Amendment
challenge to a regulation that undermines secure communications on the
networks.  The suit should be filed before the end of the month.

We don't expect to please all of the people all of the time, and it is
clear that we didn't please you with Digital Telephony.  But we really are
trying to make Cyberspace a better place to be, and we hope you'll
reconsider your decision regarding your renewal.  You can earmark your
contribution to be applied only to litigation or some other particular
function, if that would make you feel more comfortable.

Take care.

Sincerely,
Shari

----------------------------------------------------------------------------
Shari Steele, Director of Legal Services                ssteele at eff.org
Electronic Frontier Foundation                 202/861-7700 (voice)
1667 K Street, N.W., Suite 801                    202/861-1258 (fax)
Washington, DC  20006-1605                    202/861-1224 (BBS)







From hughes at CSUA.Berkeley.EDU  Wed Feb  1 08:36:15 1995
From: hughes at CSUA.Berkeley.EDU (Eric Hughes)
Date: Wed, 1 Feb 95 08:36:15 PST
Subject: Mystery files in the incoming/ directory
Message-ID: <199502011636.IAA15941@soda.CSUA.Berkeley.EDU>


I'm doing some archive maintenance at long last.  Be warned, you can't
upload right now because of some mystery configuration error that I
can't fix myself.

What I'm asking about are some files that were not uploaded with
descriptions.  I'll delete them in a week or so if I haven't got mail
indicating what they are.  This list is at the bottom of this message.
(Yes, some of them are quite old.)

Note that the archive maintainers have their own address now (see
header).  Please use it for all archive maintenance mail.  And please
read README.UPLOAD if you're going to upload in the future.

Eric
-----------------------------------------------------------------------------
-rw-rw-r--  1 hughes   remailer   119940 May 16  1994 contrib.zip
-rw-rw-r--  1 hughes   remailer    16360 Jun 23  1994 cpremailer.tar.gz
-rw-rw-r--  1 hughes   remailer    68968 Dec 16 09:07 dc-irc.alpha.tar.gz
-rw-rw-r--  1 hughes   remailer    14946 Dec  1 15:29 mkpgp.txt.uu.gz
-rw-rw-r--  1 hughes   remailer    75424 May 16  1994 pgp10.zip
-rw-rw-r--  1 hughes   remailer   233854 Jul 16  1994 pgpw26.zip
-rw-rw-r--  1 hughes   remailer    58033 May  7  1994 pwf11.zip
-rw-rw-r--  1 hughes   remailer     2913 Dec  1 15:27 signtools.tgz





From eric at remailer.net  Wed Feb  1 08:54:28 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 1 Feb 95 08:54:28 PST
Subject: The security characteristics of crypto modules with secrets
In-Reply-To: <199502011528.KAA23229@crypto.com>
Message-ID: <199502011653.IAA05730@largo.remailer.net>


   The advantage of a secure crypto module on an insecure server (or
   router or whatever) is in limiting the scope of successful attack. 

Just to expand on this, the scope is limited in _time_, not space.
That's, when you pull out the module (literally or figuratively), the
attack is known to be over -- and don't plug it back into a machine of
unknown state.

   The main important
   difference between this attack and just learning the server's secret
   is that it only remains useful as long as the attack is undiscovered.

Yes.  Typically, once the attack is discovered, the method used in the
attack is also discovered.  The particular hole is then patched.  The
system can now be put back online without fear of immediate
re-compromise.

Eric





From eric at remailer.net  Wed Feb  1 08:58:07 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 1 Feb 95 08:58:07 PST
Subject: ESP Unix encrypted session protocol software
In-Reply-To: <Pine.SUN.3.91.950201020755.4492A-100000@reggae.src.umd.edu>
Message-ID: <199502011656.IAA05742@largo.remailer.net>


   From: Thomas Grant Edwards <tedwards at src.umd.edu>

   I am thinking of the 
   use of a trusted adjudicator who could receive information from both the 
   original participants and check to see if the two keys matched.

How do you authenticate the adjudicator?

You'll have to communicate with the adjudicator and verify one of
their signatures.  You can just as easily exchange signed DH
parameters directly with the other party and verify the signature of
your correspondent.

This is another one of those problems where potential solutions often
just lead to infinite regress.

Eric







From alt at iquest.net  Wed Feb  1 09:43:00 1995
From: alt at iquest.net (Al Thompson)
Date: Wed, 1 Feb 95 09:43:00 PST
Subject: "bad" government
Message-ID: <m0rZj0d-000E8pC@dorite.use.com>



>> If strong government resulted in liberty and freedom, then the
>> most intrusive, all-encompassing governments would result in 
>> its citizens having the most liberty.  Is this the case?  I would
>> look at the (former) Soviet Union, Iran, Cuba, East Germany, etc., 
>> for your answer.

>Unrestricted individual freedom leads to unrestricted freedom of 
>`private' corporations.  Private corporations uncurbed by society's law are 
>autarkies: internally totalitarian, externally predatory, as amoral as 
>amoebas.
>
>Is this the shape of the future you seek?
  
'Tis better to err on the side of liberty.
 
To suggest otherwise would indicate that the origin and true meaning of 
"rights" or "liberty" is not understood.  
 
You can NOT restrict someone's rights simply because they MIGHT harm another 
(prior restraint).  If they do cause actual harm to someone, they should be 
brought to justice.  To place restrictions on someone based on the 
possibility that may may cause harm introduces restrictions based solely on 
the authorities' opinions (political philosophy, religion, race, etc).
 
That that the shape of the future YOU seek?
************************************************************
*           Just your basic signature block                *
*                                                          *
*  Al Thompson                                             *
*  Fidonet 1:231/110                                       *
*  alt at iquest.net                                          *
************************************************************






From rrothenb at ic.sunysb.edu  Wed Feb  1 09:53:27 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 1 Feb 95 09:53:27 PST
Subject: VoicePGP cracked in 10 minutes?...
In-Reply-To: <199502010348.VAA00506@einstein.ssz.com>
Message-ID: <199502011753.MAA21825@libws2.ic.sunysb.edu>


> 
> Hi all,
> 
> I heard a rumor hear in Ctl. Tx. that the VoicePGP project was cracked in the
> last couple of days in approx. 10 minutes. Anyone have any info on this other
> than one of those wild rumors that occur?
> 
> Thanks and take care.
> 
Nope. That was "Call Security" which used something called Quick Public
Key (QPK?) that was apparently homemade.







From rrothenb at ic.sunysb.edu  Wed Feb  1 09:58:08 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 1 Feb 95 09:58:08 PST
Subject: What's with anon.penet.fi??
Message-ID: <199502011757.MAA21864@libws2.ic.sunysb.edu>


Subject says it. Every message I post to the list gets a reply saying
that I am abusing the remailer by posting chain letters etc.

All replies to admin at anon.penet.fi are also getting bounced back too.






From ortenzi at interactive.net  Wed Feb  1 10:54:36 1995
From: ortenzi at interactive.net (Anthony Ortenzi)
Date: Wed, 1 Feb 95 10:54:36 PST
Subject: Fundamental Question?
Message-ID: <Pine.BSI.3.91.950201135326.29214A-100000@ns.interactive.net>


Although I understand the need for remailers for anonymity, is it not 
true that the whole idea of encryption (good encryption, that is) is that 
no matter who gets the encrypted text, it really doesn't matter?  Does 
this not mean that something like USENET is *perfect* for this?

				-Anthony








From A5113643667 at attpls.net  Wed Feb  1 10:59:25 1995
From: A5113643667 at attpls.net (Tom Jones)
Date: Wed, 1 Feb 95 10:59:25 PST
Subject: The security characteristics of crypto modules withsecrets
In-Reply-To: <199502011528.KAA23229@crypto.com>
Message-ID: <3573AD49>


Matt and Cypherpunks, etal.

I have been designing secure crypto modules for many years.  The
primary difficulty has been getting anyone to shell out the money to
buy them.  Perhaps things will be different with PC Cards.

Peace. Tom






From adam at bwh.harvard.edu  Wed Feb  1 11:12:48 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Wed, 1 Feb 95 11:12:48 PST
Subject: Fundamental Question?
In-Reply-To: <Pine.BSI.3.91.950201135326.29214A-100000@ns.interactive.net>
Message-ID: <199502011911.OAA09754@bwnmr5.bwh.harvard.edu>



| Although I understand the need for remailers for anonymity, is it not 
| true that the whole idea of encryption (good encryption, that is) is that 
| no matter who gets the encrypted text, it really doesn't matter?  Does 
| this not mean that something like USENET is *perfect* for this?

	Its awfully expensive to send messages all over creation so
one person can read them.  Much better to send it to the person who
wants to read it.  Besides, USENET propagation can be slower than
remailers; the far ends of the chain can often take around a week.

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From andrew_loewenstern at il.us.swissbank.com  Wed Feb  1 11:28:22 1995
From: andrew_loewenstern at il.us.swissbank.com (Andrew Lowenstern)
Date: Wed, 1 Feb 95 11:28:22 PST
Subject: Fundamental Question?
Message-ID: <9502011924.AA02931@ch1d157nwk>


>  Although I understand the need for remailers for anonymity, is it
>  not true that the whole idea of encryption (good encryption, that
>  is) is that no matter who gets the encrypted text, it really doesn't
>  matter?  Does this not mean that something like USENET is *perfect*
>  for this?

Usenet may be provide good untracability for the recipient, but the if the  
sender desires untracability she needs to use a remailer or some other  
service to get the message into Usenet.  Also, the recipient needs to know if  
and where to look for the message.  If the recipient isn't anticipating the  
receipt of a message untracably, or doesn't care if 'they' know she is  
receiving the message, then Usenet isn't necessary.


andrew





From jltocher at CCGATE.HAC.COM  Wed Feb  1 11:31:47 1995
From: jltocher at CCGATE.HAC.COM (jltocher at CCGATE.HAC.COM)
Date: Wed, 1 Feb 95 11:31:47 PST
Subject: Clipper Revived?
Message-ID: <9501017916.AA791667001@CCGATE.HAC.COM>


     From Edupage:
     
     REPLACEMENT FOR CLIPPER
     AT&T and VLSI Technology Inc. will collaborate to develop microchips 
     that use a triple-strength version of DES (data encryption standard), 
     which previously had been rejected by the National Security Agency. 
     VLSI is the designated contractor to make the government-favored 
     Clipper chips, but this latest announcement reveals their doubts over 
     whether there's a market for the Clipper. "These companies have 
     basically made the determination that Clipper is dead and there's 
     going to be the proliferation of encryption anyway, so they might as 
     well take advantage of it," says one observer, who predicts the market 
     for such technology "could reach hundreds of millions" of dollars in 
     annual sales by the end of the decade. (Wall Street Journal 1/31/95 
     A3)
     
John L. Tocher                THE CITY-a bounded infinity.   A labyrinth where
JLTocher at Earthlink.net        you are never lost. Your private map where every
PGP:  CE 72 1A 11 07 47 35    block bears exactly the same number. Even if you
35 9A C1 DE EA 64 21 BC 94    lose your way, you cannot go wrong.   --Kobo Abe








From cactus at seabsd.hks.net  Wed Feb  1 12:11:00 1995
From: cactus at seabsd.hks.net (Todd Masco)
Date: Wed, 1 Feb 95 12:11:00 PST
Subject: Fundamental Question?
Message-ID: <199502012007.PAA13259@bb.hks.net>


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

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

In article <199502011911.OAA09754 at bwnmr5.bwh.harvard.edu>,
Adam Shostack <adam at bwh.harvard.edu> wrote:
>	Its awfully expensive to send messages all over creation so
>one person can read them.  Much better to send it to the person who
>wants to read it.  Besides, USENET propagation can be slower than
>remailers; the far ends of the chain can often take around a week.

1.  Let's have some perspective here.  Remailer traffic can't really be
expected to exceed the traffic in, for example, alt.binaries.pictures.erotica.
Additionally, with USENET it's trivial to control when are whether you
receive particular groups.  Don't want to carry alt.anonymous.remailer.channel?
No problem.  Don't.

2.  USENET propogation is not that slow;  Between well connected sites
(IE, just about any Internet host that isn't swamped for other reasons
like Netcom frequently is) I haven't seen a larger lag than a few hours.

The biggest reason to use remailers is not to avoid interception of
traffic: that's a trivial problem with PGP.  The biggest threat is that
of traffic analysis: Alice doesn't want her boss Charlie to know she's
having an ongoing discussion with Bob about a new "career opportunity."

As I've said, I think USENET is perfect for this.  Add some reordering to
the processing and a hidden way to define the intended recipients and no
way that passive traffic analysis is going to succeed.
- - --
Todd Masco     | "Schooling serves to reduce the risk of being eaten."
cactus at hks.net |                           - Scientific American, June, 1982
     Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLy+w1xNhgovrPB7dAQFjcgQAqc6eu22NAB8wE5iAyyGMTFbwlXLbiHF0
FUmJlWXQ4J8EkPXEa+ZUKGlcbCETjQ2rXxzHh3cOiVxjRVnKKh5Q/VmU4JOALPXE
lBIfH+W8ty0LxaXBue9KkXh4cFvoehW7UXhq9oitNgSqiTmf/EoCbjJc5A7w7YHd
Aqu7sgyyPFQ=
=4UNd
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLy/p3CoZzwIn1bdtAQGkNgGAtR+F+nkckmLHgvrlurrHsGng24kdBu4R
20AwntDjdEcZjNHAqrc/aCf8TKVhUUJV
=o09G
-----END PGP SIGNATURE-----





From norm at netcom.com  Wed Feb  1 13:03:39 1995
From: norm at netcom.com (Norman Hardy)
Date: Wed, 1 Feb 95 13:03:39 PST
Subject: ESP Unix encrypted session protocol software
Message-ID: <ab559e8c000210040b91@DialupEudora>


At 11:49 PM 1/31/95, Thomas Grant Edwards wrote:
>On Tue, 31 Jan 1995, Eric Hughes wrote:
>
>> Just because plain old Diffie Hellman is subject to active attack
>> doesn't mean it's useless.  Some protection is better than no
>> protection at all.  It's still worthwhile implementing some security
>> to make an opponent's task harder than to implement no security.
>
>I'm curious though if there is some way to reduce the risk or at least
>increase the detectability of active DH spoofing.   I am thinking of the
>use of a trusted adjudicator who could receive information from both the
>original participants and check to see if the two keys matched.
>
>Does anyone see a good solution to this problem?
....
I trust that that the attack refered to is the "man-in-the-middle". I find
it very curious that there is a simple fix to the attack for the enctrypted
voice channel. Each unit displays to its human a few bits of g^(xy). One
human quotes them vocally to the other. If there is a man in the middle the
bits are unlikely to match. What I find curious is that there seems to be
no automated analog to this precaution. It has to do with the difficulty of
substituting the vocal signals that code these bits. This is too hard for
either computer or man (in the middle). I write to stimulate a solution. I
have none.







From mab at crypto.com  Wed Feb  1 13:37:44 1995
From: mab at crypto.com (Matt Blaze)
Date: Wed, 1 Feb 95 13:37:44 PST
Subject: ESP Unix encrypted session protocol software
In-Reply-To: <ab559e8c000210040b91@DialupEudora>
Message-ID: <199502012138.QAA26261@crypto.com>



>I trust that that the attack refered to is the "man-in-the-middle". I find
>it very curious that there is a simple fix to the attack for the enctrypted
>voice channel. Each unit displays to its human a few bits of g^(xy). One
>human quotes them vocally to the other. If there is a man in the middle the
>bits are unlikely to match. What I find curious is that there seems to be
>no automated analog to this precaution. It has to do with the difficulty of
>substituting the vocal signals that code these bits. This is too hard for
>either computer or man (in the middle). I write to stimulate a solution. I
>have none.
>
>
The reason there's no "computer" analog to the "anti-spoofing vector"
for human-human voice communication lies in the definition of
authentication.  In a formal sense authentication here means binding a
secret that only you know to the encrypted channel.  In the case of voice
communication over an encrypted link, that "secret" consists of the ability
to hold a convincing exchange that sounds like your voice.  You bind the
secret to the channel by speaking a hash of the key.  Computers, not
pre-equipped with biological mechanisms for establishing who they are,
need to use another secret (like knowledge of the secret part of a public
key signature pair) to which only the computer you want to authenticate has
access.

The encrypted human voice authentication scheme is only as strong as it
is hard to spoof voices.  Digital signature authentication is only as
strong as it is hard to break the signature scheme or compromise the
signing key.

-matt





From cactus at hks.net  Wed Feb  1 13:47:13 1995
From: cactus at hks.net (Todd Masco)
Date: Wed, 1 Feb 95 13:47:13 PST
Subject: FMP
Message-ID: <199502012143.QAA14255@bb.hks.net>


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


Can anybody tell me where I might be able to find the FMP library (
Riordon's PD GMP-a-like)?  Archie turns up empty.

Thanks,
- --
Todd Masco     | "Schooling serves to reduce the risk of being eaten."
cactus at hks.net |                           - Scientific American, June, 1982
     Cactus' Homepage

- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzAAXyoZzwIn1bdtAQHjuwF+JHUY0HeNtzptxC2hTuVRrNV/s9/k1DeZ
F0XE3PUFvSTBCyo9iv++O31td0xt1YWj
=3iAP
-----END PGP SIGNATURE-----





From kevin at elvis.wicat.com  Wed Feb  1 15:23:59 1995
From: kevin at elvis.wicat.com (kevin at elvis.wicat.com)
Date: Wed, 1 Feb 95 15:23:59 PST
Subject: Fundamental Question?
Message-ID: <9502012323.AA00271@toad.com>


>2.  USENET propogation is not that slow;  Between well connected sites
>(IE, just about any Internet host that isn't swamped for other reasons
>like Netcom frequently is) I haven't seen a larger lag than a few hours.

Consider the incoming directory on my local news host:

--
jlc:/usr/spool/news/in.coming$ ls -l
total 401
-rw-r--r--   1 news     news       172237 Feb  1 16:08 21705-000000.t
drwxr-xr-x   2 news     news         1024 Jan 31 13:43 bad/
-rw-r--r--   1 news     news        79792 Jan 27 12:35 nntp.a00606
-rw-r--r--   1 news     news       130025 Feb  1 16:09 nntp.a21731
drwxr-xr-x   2 news     news        21504 Jan 21 12:57 save/
-rwxr-xr-x   1 news     news          194 Nov 30 14:22 unz*
jlc:/usr/spool/news/in.coming$ grep Date 21705-000000.t | more
Date: Mon, 30 Jan 1995 18:28:21 GMT
Date: Mon, 30 Jan 1995 18:34:30 GMT
Date: 30 Jan 1995 11:03:14 -0800
Date: 30 Jan 95 13:25:19 +0200
Date: 30 Jan 1995 13:35:59 -0500
Date: 30 Jan 95 17:59:27 GMT
Date: 30 Jan 1995 13:25:40 -0500
Date: 27 Jan 1995 14:11:51 -0600
Date: 27 Jan 1995 14:50:32 -0500
--

The majority of incoming messages are two days old (this was on Feb 1 at
16:10, GMT -7); the worst instance in this particular batch was six days
old (posted from a backwater site in Sweden).

Before you object that this is obviously a poorly-connected site, we're
on a leased 56K line two hops from the backbone (we're fed by BYU, who
is in turn fed by the University of Utah, one of the original four
internet sites and as well fed as you get). Our server is keeping up
with the incoming news. I suspect this is a pretty typical scenario.

--
    Kevin







From kevin at elvis.wicat.com  Wed Feb  1 15:48:30 1995
From: kevin at elvis.wicat.com (kevin at elvis.wicat.com)
Date: Wed, 1 Feb 95 15:48:30 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <9502012348.AA00549@toad.com>


>Without quoting the entire message, I think I better solution, in terms of
>ease to implement as well as conserving bandwidth would be to have a
>sophisticated remailer script-language.
>
>For instance, the script language could tell the remailer to check if a
>site is on-line (perhaps within certain GMT hours or dates) and use the
>next site if not available, or to randomly choose from a list of sites
>the active ones, etc.

Aye, there lies the rub. How exactly does one determine if a site is
active or generate a current list of active sites? It is not enough to
ping the site or even to successfulyl deliver mail to it: the fact that
something is alive and running sendmail does not make it a remailer.

Likewise, a remailer cannot select an alternate site on behalf of the
user if the routing is chosen by the user, as each "envelope" is
encrypted specifically for a given remailer. I suppose one could develop
client software that built several redundant "envelopes" for alternate
mailers, but that would get out of hand pretty quickly, both in terms of
the effort of generating a secure message and in term of the size of a
message.

Scripting is useful (hell, the ::Request-Remailing lines are effectively
a script) but not until there is data to operate on.

>Maybe even have it work with a data haven? Mail the message to a data haven
>and send another message to a remailer chain to pull the message from the
>data haven and post the data (not flaws in this: don't want remailers getting
>files from people's accounts and posting them to usenet etc.).

Not a bad idea, actually.

--
    Kevin





From kevin at elvis.wicat.com  Wed Feb  1 16:17:20 1995
From: kevin at elvis.wicat.com (kevin at elvis.wicat.com)
Date: Wed, 1 Feb 95 16:17:20 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <9502020017.AA00895@toad.com>


>1.  Broadcasting every couple of minutes isn't necessary and is undesirable
>due to the real limitations of the Internet.  A remailer could broadcast
>its location with a time-out on the location without a constant stream
>of availability announcements.  In your position for example, you'd
>broadcast a message at 5 pm with a 16 hour valid time.

True, but this has two basic assumptions that I disagree with: first,
that we can guarantee delivery of a broadcast message to all interested
sites; and second, that remailers never go down for unexpected reasons.
When the day comes that both networks and software are perfect, this
method will be reliable. Of course, you are also right that broadcasting
is undesirable; that is why I am pondering a way to minimize the impact.

>2.  This is actually unnecessary for your situation: All you need to do is
>advertise your location as a "real" remailer and then have a cron job that
>kill sendmail at 5pm on your remailer machine (assuming you have a spare
>machine that doesn't need to run sendmail).  The mail network is flexible
>enough that things will Just Work.  Mail won't go through instantly during
>the day, of course, but that just helps to muddy up the mix.

But, if my understanding of remailer operation is correct, this has two
potential problems: first, I will still receive mail during the day,
causing a bandwidth concern (I know, it's probably not a problem right
now, particularly since users will probably choose to avoid a remailer
with a possible 16 hour delay); and second, the machine delivering mail
to me simply has to trust that a remailer will in fact pop up on this
machine to process the stored mail. There is no way of determining that
mail is not simply going into a black hole. And even if I try to be nice
when the mailer goes down permanently and tell everyone not to route
mail through it any more, that news still has to travel via word of
mouth to all users of the web.


>
>3.  Broadcasting over live IP isn't all that great a model.  Ideally,
>you'll use a mechanism that doesn't require instant communication among
>hosts.  I favor USENET for this: messages have a naturally long life-
>time and the network is self-adjusting.  If a direct route is temporarily
>unavailable, an indirect one will often manifest itself.  I also favor
>using USENET store-and-forward for the messages themselves for the same
>reasons: traffic analysis is impossible inside the web and direct routes
>are not necessary.

I am not happy with my proposed advertising methods, and was quietly
hoping for some guidance from internet gurus in this point (the irc
suggestion in particular is a pretty shaky straw man). However, see my
earlier message (on some other thread) about Usenet propagation times.
Propagation times in days do not seem to be rare (post to misc.test and
see when the last reply comes back). While this is better than
word-of-mouth propagation, it does not offer the very low latency I was
looking for.

>4.  Using a PGP-style web-of-trust is important.  In the ideal situation,
>one human in an extended web can certify individual remailers and all other
>remailers close enough on the same web of trust would pick up the message
>immediately.

It strikes me as critical; right now, a user has to choose to trust a
set of remailers, given no assistance other than a list of "reliable"
ones. Given an extended web of trust between remailers, the user can
choose to trust one remailer (I have no idea how to make this process
more palatable) and immediately gain the security of a large web of
remailers (maybe you are right about that instant gratification
thing...)

    Kevin






From cactus at seabsd.hks.net  Wed Feb  1 16:29:32 1995
From: cactus at seabsd.hks.net (Todd Masco)
Date: Wed, 1 Feb 95 16:29:32 PST
Subject: Fundamental Question?
Message-ID: <199502020025.TAA15949@bb.hks.net>


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

In article <9502012323.AA00271 at toad.com>,  <kevin at elvis.wicat.com> wrote:
>Consider the incoming directory on my local news host:
...
Strictly speaking, you've really only demonstrated
that there are a lot of poorly connected sites on the USENET.  The
primary characteristic that really needs to be considered is the time
for news to reach one remailer site from another.

My experience is that new propogation is fast enough that close to
real-time conversations happen all the time.  I take part in them on
the newsgroups I still read and observe them all the time.

I don't have a ready explanation for why my experience differs so much
from yours.  The worst-connected site I've ever read from was 9 mo.s ago
with a batched feed from uunet.  Even then the vast majority of posts I
saw were from the day just ending.

What are other people seeing as news delays?
- --
Todd Masco     | "life without caution/ the only worth living / love for a man/
cactus at hks.net |  love for a woman/ love for the facts/ protectless" - A Rich
Cactus' Homepage
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzAmeSoZzwIn1bdtAQHHiwGAxL13i5YYjZxREU1XwnAp81+XWgir7H92
enbDeqFQwjddTeEgHX+fKZWoZJBe4wy6
=pmE5
-----END PGP SIGNATURE-----





From warlord at ATHENA.MIT.EDU  Wed Feb  1 16:53:34 1995
From: warlord at ATHENA.MIT.EDU (Derek Atkins)
Date: Wed, 1 Feb 95 16:53:34 PST
Subject: PGP Question
In-Reply-To: <9502011343.AA00578@elysion.iaks.ira.uka.de>
Message-ID: <199502020053.TAA06783@charon.MIT.EDU>


> Is there any simple way to glue a binary file and its detached pgp
> signature together into a single pgp file (as produced by non-detached
> signing) ?

Uhh, this would sort of defeat the purpose of a detached signature; in
which case why not use the regular signature??  Alternatively, you
could use MIME multiparts to encode the binary file (in one part) and
the signature (in another part) in a single message.  Is this what
you want???

-derek






From nzook at bga.com  Wed Feb  1 16:58:23 1995
From: nzook at bga.com (Nathan Zook)
Date: Wed, 1 Feb 95 16:58:23 PST
Subject: Lucky primes & omlets on my face...
Message-ID: <Pine.3.89.9502011814.A8923-0100000@jake.bga.com>


-----BEGIN PGP SIGNED MESSAGE-----
 
Considering the general temperature of this list, I'm amazed that I didn't
get torched over my algorithm.  sigh.  The c-punks are all too busy
debating operating systems to worry about effiency in their remailers.
 
Unless, of course, Hal's "I don't understand" was from the Moore school?
 
Let's try this again.
 
Let 2*x be the target number of bits in the modulous.
 
Let n be a large random number with x+2 digits.
Let n1 be the next multiple of 0x10001.
Let t2 be n1 mod 8, t3 be n1 mod 9, t5 be n1 mod 25, t7 be n1 mod 49.
 
Loop:
For i = 2 to 7
 If n1 = 1 mod i and (n1-1)/i + 1 is not a multiple of {2,3,5,7}
    If (n1-1)/i + 1  is prime.
      {
        Let k = 0's in n1/0x10001.
        If k is in range, save and exit.
      }
    EndIf
 EndIf
Next
n1 += 0x10001;
EndLoop
 
Recall:  x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is:
(x^e)^d = x^ed = x^(p-1)*i+1 = x mod p.  
 
ie: ed = (p-1)*i+1
or: (ed - 1) / i + 1 = p
 
Now 0x10001 inverts easily, it is just n1/0x10001.  By keeping track of
various quantities, we can eliminate all multiprecision divisions except
for the original one needed to get n1 and the t's, and doing increments
instead.
 
>Yes, I see that you are right about this.  It would be easy to generate
>e,d pairs and get a d which is significantly short on 1's by 10% or more.
>I did not quite follow your algorithm to do this (was n the modulus or
>was it phi, the sum of the modulus' divisors?).  The one caveat is that
>if "high-zero" decryption exponents are widely used, it could conceivably
>reduce the search space somehow, although I don't see offhand how to
>exploit this.
>
>Hal
 
>>     (you may wish to ensure that k is _above_ a certain threshhold...)
 
I don't either, but if >80% of the digits were 0, I'ld probably start to
get nervous.  But I don't need a fast-key for my home system, I'm barely
handing 10 signatures a day.  I only advocate using high 0's when you are
in a high usage environment.
 
Nathan
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
 
iQEVAwUBLzA2NnmgMs8UcStNAQEyjQf/aOPBXcN6/M9cmh3aQHXeIr5uY3DEwvRw
WHBtWv0dVE1jfSS/4i71apWi2+Gm7iRyLGc/G4Y03RkcqMhePGSHgN6NHEHC3QaR
qoKMsa/h6z5nSMd/t8umTiSUJxFX2/1z8k29j7bM5gduUTqHPdFwcVnQnE8Rhy72
hwF+r3g9lFIhavsLFnT7KPeQ1ozVFJ+ItoTDWOOjjA8/MSGFi5JFkViw+saP2F/j
2JEbMhmMcjtTchu+s/yNVGJeL0C0DMjh2Ysh/wS/GwbcoXK1RFb602lXtCp2AUz5
Mzn9Xsdv4bUyyoumN5wT6YDdwu6QwvvU5Fh9sTZUwFHsY9RrMy53jQ==
=lK0s
-----END PGP SIGNATURE-----






From nzook at bga.com  Wed Feb  1 16:59:39 1995
From: nzook at bga.com (Nathan Zook)
Date: Wed, 1 Feb 95 16:59:39 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <Pine.3.89.9502011857.B8923-0100000@jake.bga.com>


Hal <hfinney at shell.portal.com>
 
>I still don't quite follow this. 
 
Clearly.  ;)
 
Okay.  You are right that the first remailer derives no primary benefit,
and engages in no primary risks from verifying signatures.  Alice, however
does, and Chaum is, after all, providing a service to Alice (and Frank).
He does wish to provide all the benefits that he can to them.
 
What benefit does Alice gain?
1) Plausible deniability.  Remember, "reasonable doubt."  Remember Abscam?
   The gov't is in a good position to fake source info.  This squishes
   that.  (It squishes even better if Chaum _requires_ signatures.)
 
2) If Chaum sends Alice a copy of the message that failed the signature
   check, Alice knows that someone is trying to spoof her.  This
   information may be critical in determining how serious her opponents
   are.
 
What risks does Alice take?
If the final message to Bob is encrypted, and Chaum is not compromised,
none.  If Chaum _is_ compromised, Alice is chaining anyway, so it still
doesn't matter.
 
What might Chaum gain from checking or requiring signatures?
Various net abuses often involve faking names.  Requiring validated
signatures would pressure these abuses away from the remailers.  Reducing
the net abuses going through the remailers is a PR goal.
 
 
>PGP already includes a cryptographically protected length field in the
>message.  It will ignore any data past that, according to my experiments.
>All that is needed is a simple patch to add junk data to the end.
 
Soapbox mode:
It seems to me that hacking PGP requires considerably more cooperation
between remailers, and more work than just allowing recursive opening of
PGP packets, automatic padding (or concatenating) of data, and automatic
encryption of out-goin mail. Subways and MixMaster both appear to have far
more working required to implement, far more cooperation between remailers,
and far more room for failure than my idea.  (Emphasis: appear.  I've not
seen Lance's paper, yet.  He's getting it to me.)
 
I also believe that hacking PGP is a bad thing (tm), because it means that
every time an upgrade comes out, it will need to be re-hacked, and once you
start hacking, when do you stop?  Although, it would be nice to have a
STD_LEN variable for such things.
 
 
OTOH, you seem to be agreeing with me here.  Who hacks PGP?  Who is PGPing
their outgoing stuff?  Don't we have to have standard packet _inside_ the
net?  And you achieve this by using PGP?  ?????
 
 
>I still don't quite follow this.  Exactly what attack would be possible
>against Miron's remailer if it allowed encrypted reply blocks (as all
>others do) which would fail if the messages were wrapped as you suggest?
 
The most obvious one: Eve checks messages (in vs out) for matching tails.
If the tails match, the messages match.  The only way around this is for
the entire message to be wrapped.  Thus, the extropian requirement.  
 
 
When I say that the Mark I remailers are laughably easy to crack, I mean
laughably easy.
 
Is the message a clear set of ::Request-Remail-To:?  Pull & log.
Is the message clear, with encrypted headers?  Match, pull, and log.
Is the message encrypted separately from the headers?  Match, pull, log.
Is the whole message encrypted?  Take the ones that are left, match the
largest.  Match the next largest.  Match the next largest. Pull & log.
 
Get stuck?  Need a hint?  Resend a message.  Watch for the repeat on the
out.
 
Laugh.
 
 
The only reason that our systems are actually able to do any good is that
our threat model _is not_ an LEA--with government resources, and government
patience.
 
 
>Alice may not have a key whe wants the general public to use - she may
>just be using one for her private correspondents.  
 
If she wants to be able to recieve untraceable mail, she is going to have
to have a key that remailers can use when forwarding mail to her.  See
below.
 
>                                                  Actually it seems to
>me given the nature of remailing that it would be superior if it were
>easy for people to "spoof" my use of the remailer.  That would give me
>more credence to claim innocence.  The more useless return addresses are,
>the less we even need remailers.
 
I think you are arguing to ignorance here.  The assumption so far on the
list has been that if Alice is root, she is in the best possible postion to
protect herself.  I disagree.
 
Alice has been hauled into court.  The Feds claim that she is the one that
actually sent messages M1,...Mx to Bob through Chaum, even though these
messages have varied From: (and From) lines.  As root, she cannot claim
that this is not possible.  OTOH, if Chaum requires a match, the Feds would
have to claim that she compromised the secret keys of all of all the
cooresponding From: addresses.  Much tougher.
 
 
>It's not my job to fix the damn Internet.  So what if I get mail claiming
>to be from abc when it's actually from def?  I of all people care the
>least, specifically because I throw away this data.  Virtually everyone
>else on the net cares where their mail comes from, but I don't.  My whole
>purpose is to discard the information about where it comes from.  That is
>why I am so confused about your emphasis on checking signatures.
 
We care because we are good people.  ;-)
 
Seriously, if a sight is being shadowed, then it is insecure.  It is to our
advantage to know this.  You are right that we "don't care" where a message
comes from only if we assume that the message _didn't_ come from an LEA.
(Or a big corporation.  Some of them probably have the power to do this,
too.)  If it did, then the remailer net is under attack, and we most
definitely _do_ care about that.
 
 
>Although I agree with Wei Dai's mathematics, to my mind it points up the
>importance of successful countermeasures rather than implying that the
>remailer network is inherently insecure.  For example, if you send one
>identical message every batch, Wei's math shows clearly that you can't be
>traced.  Let's not get rumors started about how the remailers don't
>work.
 
I'm lost here.  I thought that sending an identical message (producing
identical output) every tick would be the equivalent to an attack.
 
But what exactly constitutes "successful countermeasures"?  How do you
prevent an attacker from taking over a sight, thus compromising it, w/o
the knowlege of the operator?  How do you prevent long/short matching of
the remailer net _as a whole_?  How do you prevent tail matching?  How do
you prevent middle matching, for that matter?  How do you prevent the
repeated message attack?
 
 
>Do you see your suggestion as protecting against Wei's in/out correlation
>attack?  
 
Yes!  Well, not by itself.  My suggestions about "rational use of garbage"
do that.  If Bob recieves x messages each tick, 0 to x of which are real,
Eve is hosed--if all messages are standard sized & encrypted!.  Eve is even
more hosed if the x messages are concatenated & superencrypted.  If Alice
sends y messages each tick, Eve is hosed.  Even more so if the messages are
concatenated & superencrypted.
 
>        I don't see it.  If fixed-sized packets are used, with chained
>encryption, I think you have as good a system as you do with all of your
>inter-node encryption and signing.
>
 
The way you suggest to standardize packet sizes leaves the system
vulnerable to matching the top of the body of the messages in a repeated-
message attack.
 
>Suppose one good encrypted message enters the net with 10 unencrypted
>ones.  Won't the full path of each of the 10 be visible to an outsider?
>Even if the remailer helps out those 10 doltish users by encrypting them
>from there on out, the outsider already saw their whole paths!  They will
>know how many unencrypted messages are going out to each destination, and
>from that determine where the encrypted message is going.
 
Not with rational use of garbage.  With rational use of garbage, the system
could protect a single encrypted message--if the recipient or sender is "in
the box".  BTW, it may be impractical for senders to be "in the box", as
described, as they cannot know exactly when ticks occur.  I believe it can
be done, though.
 
>Of course it was Chaum himself in his 1981 paper (which I think is available
>from the CP FTP site) who described the duplicate-message attack.  I don't
>see that inter-remailing encryption helps much, because the attacker can
>still notice that whenever they inject message A, _something_ goes to
>Bob.  The real solution, as Chaum pointed out, is that the remailer must
>reject duplicate messages, even when separated by days.  Doing this without
>keeping a database of all messages ever sent is left as an exercise.
>
 
I disagree.  If identical input to Chaum does not produce identical output
to Bob, how does Eve coorelate them?  Repeating, she can match the top of
the body of messages, so random tails reveal the actual encrypted message,
for whatever that is worth.
 
And if Bob receivs x packets per tick, or a BIG packet every tick, how does
Eve trace it?
 
 
>Another aspect worth mentioning is that message splitting can make the
>kinds of statistical correlations that Wei Dai was looking at more of
>a danger. 
 
More than being the ONLY file in the net of your (approximate) size?
 
>          It's one thing if I send a message along with thousands of
>other people, and Bob gets a message along with everyone else.  But if I
>send 10 messages and Bob gets 10 from that batch, that fact alone can
>help to link us up.  So splitting my big message into 10 standard ones
>isn't that great if they're all sent at once.  Ideally you'd want to
>dribble them out at some standard rate, a rate at which you always send
>a message whether you have something to send or not.  But this may introduce
>unacceptable latency.
 
"Dribble them out at some standard rate".  Yes.  y packets per tick.  Set y
equal to your average number of real packets per tick, plus 3 standard
deviations.  Since you are chaining, the latency of you input will be less
than the latency of the remailernet.
 
Nathan
 
"PGP?"                        "ITAR!"                          "Oh, RKBA!"
 
 
                   |--------------------------------------------------+
  ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook at bga.com> )
 |44B3D866 3D551E2E ---------------------------------------------------
 |F89222A6 338CDE24/ |
  -----------------
 






From nzook at bga.com  Wed Feb  1 17:00:02 1995
From: nzook at bga.com (Nathan Zook)
Date: Wed, 1 Feb 95 17:00:02 PST
Subject: Ending the Crusade
Message-ID: <Pine.3.89.9502011825.C8923-0100000@jake.bga.com>


Here is an idea to tone down the dos crusade for those of you with procmail
and a vindictive streak:  Instead of routing all of those messages to
/dev/null, forward them back to the authors, perhaps with a notice that the
message appears to have been mistakenly routed to you?
 
Nathan






From nzook at bga.com  Wed Feb  1 17:00:35 1995
From: nzook at bga.com (Nathan Zook)
Date: Wed, 1 Feb 95 17:00:35 PST
Subject: Thanks for not flaming  !??!?
Message-ID: <Pine.3.89.9502011858.D8923-0100000@jake.bga.com>


Adam Shostack <adam at bwh.harvard.edu>
 
>YOu're right, I did miss the attack.  I'll be responding in depth
>tomorow, when I'm awake, but I wanted to say thanks for not flaming.
>:)
>
>Adam
 
Is it just me, or does this message have a rather disturbing social
implication?  Crimeny, no one's perfect around here.  Well, maybe James or
Perry.
 
Nathan
 






From kevin at elvis.wicat.com  Wed Feb  1 17:00:38 1995
From: kevin at elvis.wicat.com (kevin at elvis.wicat.com)
Date: Wed, 1 Feb 95 17:00:38 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <9502020100.AA01613@toad.com>


>I have some concerns about Kevin's frothing remailers.  Like so many of
>the proposals we see to put more responsibility into the remailer net,
>this opens vulnerability to a single bad remailer.  If I trust the first
>remailer in the net to choose my path for me, as I might be tempted to
>do with a froth, then if that remailer is corrupt my anonyminity is lost.
>With user-supplied chaining I am secure unless all of the remailers on
>the chain are corrupt.

Firstly, I certainly do not propose that we remove user-supplied
chaining; it is obviously vital to true anonyminity. What I am
suggesting is that we allow remailers to introduce more noise into the
mix using information that users cannot easily obtain for themselves
(e.g. which remailers are in operation at this moment). In the
apparently common case of unencrypted messages crossing the net, this is
at least no worse than the current situation. Of course, we would also
have to allow users to specify that no munging of the route be allowed
(some form of scripting). Trusting remailers to obey this request
requires no more trust than we already place in them (which, I believe,
is considerably more than most seem willing to admit).

If you succumb to the temptation and trust remailer #1 totally, then you
of course run the risk of sacrificing anonyminity. However, if you do
not trust remailer #1 so completely and specify a chain of remailers,
but allow remailer-generated routing between the points on that chain,
you gain resistance to traffic analysis as well as making it possible
for smaller transient remailers to play a useful role.

>I also do not like the kind of close-knit, cozy cooperation among the
>guild of remailer operators which seems to be envisioned in this and
>similar proposals.  Do you like the idea of messages on the remailer
>operators list saying, I am getting objectionable messages from your
>remailer, would you mind dropping in a log so we can see who is sending
>these messages which violate the Politically Correct Speech Act?

I don't see what would prevent this from happening now. The only degree
of cooperation I require from remailer operators is that they agree on
some software standards and that, if they choose, they create extended
webs of trust via signing one another's keys. There is no requirement
that all remailers or remailer operators trust all other remailer
operators; in fact, I think this would be undesirable, even if the trust
were justified.

Again, remember that control lies with the user. If you choose, you can
allow a remailer to bounce your mail through its web of trust before
forwarding it to the next point on your chain. I do not believe that
this increases the risk of losing anonyminity. I do also propose that
this be the default behavior in order to provide naive users with some
degree of security, as well as using their traffic to obscure that of
more sophisticated users.

>I do like Kevin's ideas about a dynamic remailer net, but I think
>another approach would put more smarts into the client program used by
>the originator.  Granted, his information will be somewhat more out of
>date as the message makes its way through the network.  But depending
>on thie time scale at which the froth, um, froths, this should still
>allow a lot more dynamism among the set of remailers.  Using either IRC
>or, as Todd suggested, Usenet to maintain an active remailer list might
>work.  We could also have a distributed set of sites which provide the
>information by finger like the pinging sites we have now.

True, all true (I seem to be saying this a lot today). My transient
remailer problem can be solved by publishing the times of availability
(assuming, of course, that my remailer will always be up when
scheduled). My only serious objection to this is that there will always
be more clients with more operating systems and platforms than there
will be servers. I don't expect that it will be easy to create new
standards for remailers and get significant numbers of operators to
implement or use them, but I do believe that that task is easier than
making smart clients available on all possible platforms.

[ Safe-TCL comments deleted]

>What you need then is some way for various messages to interact with each
>other, so that, for examle, a message could wait until there were a
>certain number of other messages inside the machine before it sent itself
>out.  You would also want a way for a message to suspend itself until
>some future event, such as having a certain amount of time passing, or
>waiting until some message with desired properties arrived.

This is a fine suggestion; as I mentioned in an earlier message,
scripting is not useful without data to operate on. You have suggested a
number of data that a remailer could usefully provide to a message,
making scripting more useful. Of course, you have to trust that the
remailer is not lying to your script.

[ More Safe-TCL comments and a plea for smarter clients rather than
smarter servers, to which I reply with the earlier argument, deleted.]

--
    Kevin





From cactus at seabsd.hks.net  Wed Feb  1 17:03:28 1995
From: cactus at seabsd.hks.net (Todd Masco)
Date: Wed, 1 Feb 95 17:03:28 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <199502020059.TAA16283@bb.hks.net>


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

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

In article <9502020017.AA00895 at toad.com>,  <kevin at elvis.wicat.com> wrote:
>>1.  Broadcasting every couple of minutes isn't necessary and is undesirable

>True, but this has two basic assumptions that I disagree with: first,
>that we can guarantee delivery of a broadcast message to all interested
>sites; 

I had the USENET model of propogation in mind when I wrote this.  Delivery
is considerably better assured with such a store-and-forward over

>and second, that remailers never go down for unexpected reasons.

True, if you append "for extended periods of time."  The key detail is the
boundary condition: IE, how long does it take a "downed" remailer to come
off the web.  Since each site has the best idea of their own stability,
they are in the best position to set the time-out period.  A very flaky
site might set a time-out to 6 hours.  I'd suggest that a site flakier
than that shouldn't be running a remailer.

>>2.  This is actually unnecessary for your situation: All you need to do is
>>advertise your location as a "real" remailer and then have a cron job that
>>kill sendmail at 5pm on your remailer machine

>But, if my understanding of remailer operation is correct, this has two
>potential problems: first, I will still receive mail during the day,
>causing a bandwidth concern (I know, it's probably not a problem right
>now, particularly since users will probably choose to avoid a remailer
>with a possible 16 hour delay);

No, not at all.  The attempted connections to your sendmail with fail and
the mail will attempt redilvery for some period of time (usually 3 days) 
at a certain interval (usually 30min. - 1 hour).

>And even if I try to be nice
>when the mailer goes down permanently and tell everyone not to route
>mail through it any more, that news still has to travel via word of
>mouth to all users of the web.

Sure.  It's important to note that you've got two seperable problems to
address here: 1) a recurring limited window of up-time, and 2) handling
permanent down-times.

My suggestion only covers the first.  The USENET model I'm pushing is
designed to cover the second.

>[PGP web-of-trust] strikes me as critical;...
>Given an extended web of trust between remailers, the user can
>choose to trust one remailer (I have no idea how to make this process
>more palatable) and immediately gain the security of a large web of
>remailers. 

Absolutely, that's what I was trying to express.

Best regards,
- - --
Todd Masco     | "Let me get this straight.  You're making a crypto toolkit,
cactus at hks.net |  and you're worried about it being _obscure_?" - Eric Hughes
Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLy/1gRNhgovrPB7dAQGZCQQA47ADvvuXRvlq5Qw3MSZaUJqqk2KJbUKk
nV1mnTVIbvBbCt5PczoSFKkO/O6wMfS/4zzkoTqpvpIvwYvZ6ds75yBwhIyxvTvx
gygKFi5ZwysYGz/49vs0BdJSHMqUA+/HVHE2zfcYP+yvbnbTdryQJXLrOdlGhH3a
R0LvGJVgCSw=
=k+vP
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzAuayoZzwIn1bdtAQFa4gF8Cl9yuHttaTqmcy9Be+9EWa4qp3zHCP5n
pgWiNvOt7reobq42ZluxFgTlWrFG0SKa
=oFTV
-----END PGP SIGNATURE-----





From kevin at elvis.wicat.com  Wed Feb  1 17:18:11 1995
From: kevin at elvis.wicat.com (kevin at elvis.wicat.com)
Date: Wed, 1 Feb 95 17:18:11 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <9502020118.AA01956@toad.com>


[deletia]

>Now, dynamic rerouting is good for better delivery, but is bad for the
>trust in silence.  Trust in externally unverifiable properties is
>_not_ transferrable.  Just because I believe that my regular remailer
>is OK does not mean you do.  The creation of these links of trust is
>not something that can be automated solely by the remailer operators.
>The end users of the remailers are the endpoints of this trust
>relationship.  The end users must be involved, either directly or
>through some (legal) agent, in the manipulation of these relationships.

First, I must admit to being somewhat out of my depth here; this seems
to be becoming a philosophical problem. With that shameful admission out
of the way, let me bull ahead regardless.

It seems to me that I can choose to trust in the fact that *your* trust
in other remailers is well founded. This then becomes a third category
of trust for a given remailer: trust that it will deliver (verifiable);
trust that it will be silent (unverifiable); and trust that its
operator has good judgement in choosing who to trust (unverifiable).
These latter two are, and should be, the end users responsibility.

Now, as I have mentioned in an earlier message (I'm being far too
verbose today) I am proposing that dynamic routing be optional, though
the default behavior, for reasons mentioned there. Thus, if I, as user,
choose to allow dynamic routing (through omission - I must admit, I am
becoming less fond of the notion of this as default behavior - it begins
to smack of the heresy of "implied consent") I am expressing the third
flavor of trust, just as by using the remailer at all, I am expressing
the second variety.

Of course, I still have to trust that a remailer will honor my routing
requests. However, I believe this falls fair and square into the second
category (trust in silence)

>Any solution which tries to do this independent of the end user is
>broken, by definition.

--
    Kevin

    ( I have no joke here, I just like saying "I trust a remailer if
      it is trusted by an entity I trust to trust remailers".)






From mjwohler at netcom.com  Wed Feb  1 17:57:46 1995
From: mjwohler at netcom.com (Marc Wohler)
Date: Wed, 1 Feb 95 17:57:46 PST
Subject: NYC area C'Punks meet 2/11/95
Message-ID: <199502020150.RAA29578@netcom14.netcom.com>


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

Attn.: New York City area Cypherpunks

NYC C'punks meeting:

Sat Feb 11, 3:00 P.M., at the home of Linn & Barbara  Stanton
315 West 106 Street  Apt 2A 
(Between West End Ave & Riverside Drive)
212-316-1958.

Once again the gracious Stanton's invite local area Cpunks to
their lovely home which is smoke free and feline friendly.

The agenda is still open and suggestions can be made to
mjwohler at netcom.com
or phone Marc Wohler @ 212-362-0690. Let me know if you plan to
attend.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLy+PL2eikzgqLB7pAQGHigP9HW1Py30O2fcZH/f1SAOToOBZYVZMiB9c
buGQrujaicGVJlvGb1Le/OjJ872JB69BQD1MMsemABSYi4swL15w9qj1rhoTAHIg
yTRDFJD16g1lqqLvEJZ0RijOh1dXLaUg8HNue0JoSAbARkQed8I3+mklP4C4saYn
qW2Fa/kDuZY=
=Rl9C
-----END PGP SIGNATURE-----





From hfinney at shell.portal.com  Wed Feb  1 18:13:38 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Feb 95 18:13:38 PST
Subject: Lucky primes & omlets on my face...
Message-ID: <199502020213.SAA17094@jobe.shell.portal.com>


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

From: Nathan Zook <nzook at bga.com>

> Recall:  x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is:
> (x^e)^d = x^ed = x^(p-1)*i+1 = x mod p.  

This would only be true for prime p, but with RSA we are dealing with
composite moduli.  What we want is ed=1 mod phi(n), where
phi(n)=(p-1)(q-1).  (Actually you want to use (p-1)(q-1)/gcd((p-1),(q-1)).
I forget what that is called.)

Conceptually, I gather you are setting e = 0x10001, then finding its
multiplicative inverse d mod phi(n) (or mod p-1 in your example).  Then
you are looking for other possible values for d.  I am a little unclear
on what the interval would be between suitable values of d.  I think it
would be phi(n)/gcd as above, or p-1 in your example, but I am not sure.

> Let's try this again.
>  
> Let 2*x be the target number of bits in the modulous.
>  
> Let n be a large random number with x+2 digits.
> Let n1 be the next multiple of 0x10001.
> Let t2 be n1 mod 8, t3 be n1 mod 9, t5 be n1 mod 25, t7 be n1 mod 49.
>  
> Loop:
> For i = 2 to 7
>  If n1 = 1 mod i and (n1-1)/i + 1 is not a multiple of {2,3,5,7}
>     If (n1-1)/i + 1  is prime.
>       {
>         Let k = 0's in n1/0x10001.
>         If k is in range, save and exit.
>       }
>     EndIf
>  EndIf
> Next
> n1 += 0x10001;
> EndLoop
>  
> Recall:  x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is:
> (x^e)^d = x^ed = x^(p-1)*i+1 = x mod p.  
>  
> ie: ed = (p-1)*i+1
> or: (ed - 1) / i + 1 = p
>  
> Now 0x10001 inverts easily, it is just n1/0x10001.  By keeping track of
> various quantities, we can eliminate all multiprecision divisions except
> for the original one needed to get n1 and the t's, and doing increments
> instead.

I still don't follow this.  Is k claimed to be d?  Where do we verify
that ed=1 mod (p-1)?  ed would be n1, right?  When you said "If (n1-1)/i
+ 1 is prime" did you mean "is p"?  I really don't think this whole thing
works.

Let me tell you what I tried.  I inverted e to get a correct d.  Then I
looked at different d's to find one with lots of 0's.  This turned out
to be useless!  The reasons is that PGP does not use d.  It uses the
Chinese Remainder Theorem to do its exponentiation.  The two
exponentiations it does use exponents d mod (p-1) and d mod (q-1).
Adding multiples of phi to d does not change these values (since it is
a multiple of both p-1 and q-1).

Now one thing you could do is to use in place of d mod (p-1),
(d mod (p-1)) + k*(p-1) where we choose k to minimize the sum of the number
of bits and the number of 1 bits in this expression.  Unfortunately the
PGP data structures do not store d mod (p-1), it is constructed on the
fly when you do a decryption.  So there is no where to save a
pre-computed optimal value for the two exponents used in the CRT
exponentiations.  So, this was a good idea, but the implementation does
not fit into the current structure very well.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzA/mhnMLJtOy9MBAQEjmAIAzQbwkia3F7+4F7tNUewKnZVYsBEhgoBk
h5jem/qjUxFeGhYNUL/pSLKJPR+PlzleZmBQJyOlk3q7KL0ety851g==
=EHVe
-----END PGP SIGNATURE-----





From jrochkin at cs.oberlin.edu  Wed Feb  1 18:19:09 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Wed, 1 Feb 95 18:19:09 PST
Subject: Frothing remailers, the advertising and pinging problems
Message-ID: <ab55e6d7010210043e93@[132.162.201.201]>


At 5:50 PM 02/01/95, kevin at elvis.wicat.com wrote:
>I am not happy with my proposed advertising methods, and was quietly
>hoping for some guidance from internet gurus in this point (the irc
>suggestion in particular is a pretty shaky straw man). However, see my
>earlier message (on some other thread) about Usenet propagation times.
>Propagation times in days do not seem to be rare (post to misc.test and
>see when the last reply comes back). While this is better than
>word-of-mouth propagation, it does not offer the very low latency I was
>looking for.

I tried to discuss this very issue a few months ago, with little interest.
But I'm glad there's someone to discuss it with now. (read, someone who
will listen when I spout volumes to the list :)   )

Here follows my treatise. :)


We already have a solution, actually.  Raph's remailer list.  If you know
your remailer is going down, tell Raph about it, and he'll remove you from
the list.  [Better would be an automatic way of removing remailers from the
list upon receiving a PGP-signed message from the op, without Raph's
intervention].  Presumably, if your remailer never returns his ping, it
will move to the bottom of his list.  So applications like his "premail",
which use this list, won't send to those remailers.

This is really an excellent solution, and what it doesn't do, could easily
be added to it.  The problem is that it's too centralized. We like
decentralized things hereabouts, and Raph's list requires you to trust Raph
not to lie to you, or withhold information to you. And of course a
centralized solution is more subject to attack too; if someone mangaged to
subvert Raph's list (either by subverting his data collection methods, or
the report he generates), then an increasingly large portion of the
remailer-using-public is up shit creek.   Single point of failure.

A partial solution is for lots of people to run remailer pinging and
reporting services like Raph's.  Then you could use which ever one you
want, or even write a script to get info from them all and average em
together (throwing out extremely oddball scores, using some sort of
statistical method).  A better solution to the centralization problem would
be for _everyone_ to run their own remailer pinging service.  This solves
the centralization problem, but now when a remailer op knows his remailer
is going down, he can't simply tell Raph, he's got to tell _everyone_,
which is the same problem he had originally.  Also, this is somewhat
realistic.  People have been saying for ages that the remailer net is much
more secure when every user runs their own remailer, but it still hasn't
happened. For obvious reasons.

So we've still got the problem of how users are to tell when remailers go
down.  That's what I see as the basic problem here.   It really divides
into two problems: the "advertising" problem, and the "pinging" problem.
Which actually aren't at all completely seperate.

*THE ADVERTISING PROBLEM*

The advertising problem consists of how remailers are to get info out to
the Remailer-Net-At-Large.  I run a remailer, and I know my remailer is
going out of business soon (temporarily, or permanently), and I want to
tell people.  Or, my remailer has returned (or just started started
business for the first time), and I want to tell people.

        ++Usenet. Non-IP, but slow. ++
Usenet is an obvious solution, but the latency is too low.   But usenet
does work really nicely, aside from the latency problem. Remailers post
messages to alt.remailer.auto-announce, giving one of a number of
standardized machine-readable messages.  For instance FriendlyRemailer
might post that it's going down, and expects to be down for about 24 hours.
Clients, which could be other remailers, or chaining applications like
premail, would periodically check this newsgroup and keep track of info.
My client software might decide to stop routing through FriendlyRemailer,
and completely ignore the "for 24 hours" thing, and start sending through
there again when it gets an "I'm back" message over the usenet.  Or it
might decide to record the "for 24 hours" thing somewhere for human
reading.  If a new remailer appears and broadcasts "I'm here", it might add
it to the list of useable remailers, or it might ignore it, or it might ask
for human approval of adding it to the list. Whatever the user wants it to
do.

        ++Direct TCP.  IP-required, complicated, but fast.++
But there's still a latency problem.  The only way I can think of to solve
that is with direct TCP connections of some kind.  IRC would be one way.
Remailers could broadcast "I'm here" every 20 seconds on an IRC channel,
and clients could keep an eye on this IRC channel to see what's up.  Of
course, then a client would need to wait up to 20 seconds before sending a
piece of mail, which is kind of a pain. So, instead, you might have a
background program running always, and tabulating data, so it's got data
stored and doesn't need to wait at all. (If the remailer said "I'm here" a
minute ago, that's good enough, dont' need to wait another minute for the
next "I'm here").  And then remailers wouldn't need to broadcast as often
as 20 seconds; something like 5 minutes would probably do.  So bandwith is
more reasonable.  If a remailer goes down, and you send a message to it
within 5 minutes, you are shit out of luck, unfortuantely.   The problem
with this solution is that everyone using it needs to be on the internet.
People haven't wanted to exclude UUCP connections and such from
participating in the remailernet (as remailer or client) in the past, and I
think they're probably right.  And IRC might not be that reliable, I don't
know.  And it requires a lot of proccessing power; remailers have got to be
constantly sending out "I'm here", client programs have to be constantly
running and scanning for this info.  Might not be that scalable either,
when you have 100 remailers broadcasting, and 20,000 users listening. Or
more.

*THE PINGING PROBLEM*

The pinging problem consists of how clients (which could be other
remailers) can querry remailers about whether they are up or not. (and what
features the particular remailers support, which is also something that
might be advertised above, incidentally.)  The user is taking the
initiative, as opposed to the remailer.  Because maybe someone subverted
your usenet or IRC or other broadcasting medium, so you don't want to place
too much trust on it, and you want to check it yourself.   And maybe the
"advertising" medium is slow usenet, so you the last "I'm here" you got
from a remailer was a dated day ago. Is it still there? You'd like a quick
way of pinging it to see.

Again, we have two solutions: Slower simpler, being-on-the-net unneccesary,
pinging with mail; and Faster, More Complicated, need-to-be-on-the-net TCP.


        ++Mail ping. Non-IP, simple, slow. ++
 A mail ping simply consists of sending a message to a remailer with a
Request-Resending-To: yourself.  When you get it back, you know the
remailer is alive.  This has the advantage that it's hard for the remailer
to trick you, even if it is an evil NSA remailer that wants you to believe
it is alive, even though it really throws messages in the trash.   It can't
differentuate between your "ping" (to be returned), and a normal message
(to be thrown in the trash).  And you can do it with a UUCP connection, or
some other kind of store-and-forward non-IP connection.  The problem is
that it's slow.  Especially with the latency that secure remailers have to
put into the mix.  This could be solved if you could tell the remailer
somehow that this is a ping message which should be sent relatively quickly
and not re-ordered and latency-added like a normal message. Of course, then
you lose the advantage that the remailer can't tell the difference between
a ping and a normal message.

The way to deal with the high latency, would again be to have each client
have a background process running and pinging periodically, and storing
data.  Again, if it's gone down since your last ping, you are out of luck.
And this is kind of complicated, and high-bandwith.

        ++TCP transaction ping. IP required, complicated, but fast.++
Again, the other alternative is a direct TCP connection. Connect to a
certain port, say "are you there", get an answer.  I believe mixmaster will
soon support direct TCP traffic transactions, it would probably be trivial
to add a "pinging" feature too. Although really unneccesary. If you contact
the host directly, and it answers, you know it's there, you don't need to
ping.  The disadvantage is again that IP is required.


**CONCLUSION**

Advertising and pinging methods are needed.   There should be a way for a
new remailer to announce itself to the net (might not be trusted or used by
software, but it's up to the user), and a way for existing remailers to
announce that they are going down (and announce when they come back up).
There also needs to be a way for a user to "querry" a remailer
individually, instead of relying on advertising, _especially_ if the
advertising method is high-latency.

Both the slower store-and-forward (mail, news) techniques, and the faster
direct-socket-connection techniques both have advantages and disadvantages.
Ideally, _all_ of them would be exist.  Some remailers might only support
or deal with some of them (out of choice or lack of IP connectivity or
bandwith), but client software could gather info from all or some of the
pinging and advertising mediums, and make choices about whether to use
remailers, based on how much info it has, and what the info says.

And the issue not even discussed here, is that of having a succesful way to
bounce messages.  If all of your advertisment-gathering and pinging fail
anyhow, you should be notified that your message didn't make it through. It
actually seems possible that a succesful bounce method would remove the
need for advertising and/or pinging completely.  But a succesful bounce
method seems even more remote then succesful pinging/advertising methods.







From rfb at lehman.com  Wed Feb  1 18:21:10 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Wed, 1 Feb 95 18:21:10 PST
Subject: Ending the Crusade
In-Reply-To: <Pine.3.89.9502011825.C8923-0100000@jake.bga.com>
Message-ID: <9502020220.AA18342@cfdevx1.lehman.com>


    Date: Wed, 1 Feb 1995 18:59:54 -0600 (CST)
    From: Nathan Zook <nzook at bga.com>
    
    Instead of routing all of those messages to /dev/null, forward
    them back to the authors, perhaps with a notice that the message
    appears to have been mistakenly routed to you?

And then all LD has to do to have lots-o-fun is to send you a whole
bunch of "your OS sucks" messages with the From: line set to
alt.religion.scientology at some.mail2news.site . . . .

			Rick





From remail at desert.xs4all.nl  Wed Feb  1 19:08:30 1995
From: remail at desert.xs4all.nl (remail at desert.xs4all.nl)
Date: Wed, 1 Feb 95 19:08:30 PST
Subject: No Subject
Message-ID: <199502020308.AA13869@xs1.xs4all.nl>


##
Subject: Re: Frothing remailers - an immodest proposal
In-reply-to: <199502010520.VAA04884 at largo.remailer.net> (eric at remailer.net)

> Date: Tue, 31 Jan 1995 21:20:28 -0800
> From: eric at remailer.net (Eric Hughes)
> 
>    In article <9501312152.AA10208 at toad.com>,  <kevin at elvis.wicat.com> wrote:
>    >It seems to me that the current remailer web suffers a fundamental flaw.
>    >It is simply too static.
> 
> Now, dynamic rerouting is good for better delivery, but is bad for the
> trust in silence. [...] The end users must be involved, either directly or
> through some (legal) agent, in the manipulation of these relationships.
> 
> Any solution which tries to do this independent of the end user is
> broken, by definition.
> 
> Eric

  Well, pgp support multiple recipients of messages.  Supose that the
remailers would choose at random only one of the addresses the user
(or their client program) requested in a header line like:

Request-ND-Remailing-To: RM1 at a.b.c, RM2 at c.d.e, RM3 at e.f.g

and try to deliver.  If the mail fails right away, then it tries
another address.  Etc.

  The very paranoid user would avoid this feature, and stick with the
old fashioned system.  The paranoid would list two remailers, and
encrypt the folowing message to both of them, and probably add a few
more levels to the chain, just to be sure.  The compleatly trusting
would only have two levels of remailing, but which listed every
remailer as a posible recipient of the message they send to the first
in the chain.

  In this way we get better reliability, but still have user control
over selecting the remailers.  In fact, the user can select arbitrary
message reliability, and remailer trust parameters, and should be able
to come up with a set of nd-hops to meet the parameters.

  Hey Wei, Hal: What is the cost of this in terms of likelyhood that
the whole path of remailers actually selected is compromised?  Is this
about right?  If 50% of the remailers are run by the enemy, then with
only one remailer listed in each hop, the odds of the path being
compromised is (.5)^h (where h is number of hops).  The odds of
successfull delivery are .90^h (asuming every remailer is 90% up).  If
at each step there were two remailers, and the evil remailers always
selected other co-operating evil remailers, then the odds of the path
being compromized is larger at ((1-.5^2)==.75)^(h).  But the odds of
sucessfull delivery are much better, (1-((1-.90)^2)==.99)^(h).  To
keep the same chance of the path being compromised, the user would
need to have 'x' times more hops where x is such that (.75)^x == .5,
or about 2.4 times as many.

  Hmmm...

  Noyb





From rrothenb at ic.sunysb.edu  Wed Feb  1 20:00:37 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 1 Feb 95 20:00:37 PST
Subject: Fundamental Question?
In-Reply-To: <Pine.BSI.3.91.950201135326.29214A-100000@ns.interactive.net>
Message-ID: <199502020400.XAA03916@libws2.ic.sunysb.edu>


Anthony Ortenzi wrote:
> 
> Although I understand the need for remailers for anonymity, is it not 
> true that the whole idea of encryption (good encryption, that is) is that 
> no matter who gets the encrypted text, it really doesn't matter?  Does 
> this not mean that something like USENET is *perfect* for this?

Well, it's happened in the past. Doesn't mean Usenet is perfect for it,
since nobody wants to sift through several thousand messages a day for
messages encrypted to him/her.  Also, imagine all the traffic sent to a
remailer duplicated on overy site that carries that Usenet group...

Rob






From rrothenb at ic.sunysb.edu  Wed Feb  1 20:35:08 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 1 Feb 95 20:35:08 PST
Subject: Clipper Revived?
In-Reply-To: <9501017916.AA791667001@CCGATE.HAC.COM>
Message-ID: <199502020434.XAA04359@libws2.ic.sunysb.edu>


> 
>      From Edupage:
>      
>      REPLACEMENT FOR CLIPPER
>      AT&T and VLSI Technology Inc. will collaborate to develop microchips 
>      that use a triple-strength version of DES (data encryption standard), 
>      which previously had been rejected by the National Security Agency. 
>      VLSI is the designated contractor to make the government-favored 
>      Clipper chips, but this latest announcement reveals their doubts over 
>      whether there's a market for the Clipper. "These companies have 
>      basically made the determination that Clipper is dead and there's 
>      going to be the proliferation of encryption anyway, so they might as 
>      well take advantage of it," says one observer, who predicts the market 
>      for such technology "could reach hundreds of millions" of dollars in 
>      annual sales by the end of the decade. (Wall Street Journal 1/31/95 
>      A3)

So, the question is, are these chips escrowed like Clipper (ie, are they
abandoning the standard because the phones are awful)? Or are they abandon-
ing the escrowed encryption altogether?






From rfb at lehman.com  Wed Feb  1 20:48:07 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Wed, 1 Feb 95 20:48:07 PST
Subject: Fundamental Question?
In-Reply-To: <199502020400.XAA03916@libws2.ic.sunysb.edu>
Message-ID: <9502020446.AA06471@cfdevx1.lehman.com>


    Date: Wed, 1 Feb 95 23:00:18 EST
    From: Robert Rothenburg Walking-Owl <rrothenb at ic.sunysb.edu>

    Well, it's happened in the past. Doesn't mean Usenet is perfect for it,
    since nobody wants to sift through several thousand messages a day for
    messages encrypted to him/her.

It's easy to automate and you are incorrect in saying that nobody does
it.  alt.anonymous.messages was created as an implementation of an
anonymous message pool.  I wouldn't go so far as to say that it's
perfect, but it's simple and it works.  If you post a message
encrypted for my public key and include my name and/or my key id in
the subject, I'll get it.  And, no, I'm not the only one who uses it.

			Rick





From hfinney at shell.portal.com  Wed Feb  1 23:14:37 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Feb 95 23:14:37 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <199502020714.XAA15798@jobe.shell.portal.com>


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

From: Nathan Zook <nzook at bga.com>
[ Re: remailers checking signatures on incoming messages ]
> What benefit does Alice gain?
> 1) Plausible deniability.  Remember, "reasonable doubt."  Remember Abscam?
>    The gov't is in a good position to fake source info.  This squishes
>    that.  (It squishes even better if Chaum _requires_ signatures.)

She doesn't get that.  A signature lets her prove that she sent a
message.  It doesn't let her prove she didn't send a message.

> 2) If Chaum sends Alice a copy of the message that failed the signature
>    check, Alice knows that someone is trying to spoof her.  This
>    information may be critical in determining how serious her opponents
>    are.

I don't really understand this threat that Alice may be "spoofed".  Why,
of all places, would her opponents try to spoof her through an anonymous
remailer?  Isn't this kind of like sending mail with no return address,
and pretending it comes from someone else?  This seems terribly subtle.

> What might Chaum gain from checking or requiring signatures?
> Various net abuses often involve faking names.  Requiring validated
> signatures would pressure these abuses away from the remailers.  Reducing
> the net abuses going through the remailers is a PR goal.

This would be a good thing, agreed.  And requiring signatures probably
would weed out a lot of the flakes, largely by raising the threshold of
cluefulness needed to use the network.

> It seems to me that hacking PGP requires considerably more cooperation
> between remailers, and more work than just allowing recursive opening of
> PGP packets, automatic padding (or concatenating) of data, and automatic
> encryption of out-goin mail. Subways and MixMaster both appear to have far
> more working required to implement, far more cooperation between remailers,
> and far more room for failure than my idea.  (Emphasis: appear.  I've not
> seen Lance's paper, yet.  He's getting it to me.)

This is not clear to me.  My hope would be to persuade the PGP developers
(many of whom read this list) to incorporate a pad feature in future
versions so that messages can be easily rounded up to a standard size.
Alternatively the mixmaster client may include this capability.

> OTOH, you seem to be agreeing with me here.  Who hacks PGP?  Who is PGPing
> their outgoing stuff?  Don't we have to have standard packet _inside_ the
> net?  And you achieve this by using PGP?  ?????

I can see the problem with standard packets in a chaining context, that
they would shrink slightly in size as each successive remailer stripped
off its envelope.  Re-encrypting would solve this by providing more
padding.  OTOH you can actually stick padding into a PGP packet if you
know what you're doing.  I have a perl script around somewhere which will
do this.

> >I still don't quite follow this.  Exactly what attack would be possible
> >against Miron's remailer if it allowed encrypted reply blocks (as all
> >others do) which would fail if the messages were wrapped as you suggest?
>  
> The most obvious one: Eve checks messages (in vs out) for matching tails.
> If the tails match, the messages match.  The only way around this is for
> the entire message to be wrapped.  Thus, the extropian requirement.  

It is true that encrypting messages intra-remailer would prevent this
attack as far as that one remailer in the chain is concerned.  But it
seems to me that the message still suffers from this attack against the
remailer network as a whole.  This points up the fundamental problem with
this form of encrypted reply block.  They are really not secure unless
the body itself gets transformed at each step as in Chaum's model.

> When I say that the Mark I remailers are laughably easy to crack, I mean
> laughably easy.

None of this is news.  We have been discussing these attacks for years.
Even with intra-remailer encryption I think these attacks work against
the remailer net.

> Is the message a clear set of ::Request-Remail-To:?  Pull & log.
This will work when the message is heading to the net in the clear, even
if it is encrypted between nodes.

> Is the message clear, with encrypted headers?  Match, pull, and log.
You can still match the message entering and leaving the net, even if it
is encrypted within.

> Is the message encrypted separately from the headers?  Match, pull, log.
As above.

> Is the whole message encrypted?  Take the ones that are left, match the
> largest.  Match the next largest.  Match the next largest. Pull & log.
Encryption with padding between nodes would protect against size
matching, I agree.  But it is the padding which is important, not the
encryption.

> Get stuck?  Need a hint?  Resend a message.  Watch for the repeat on the
> out.
That's why Chaum identified one of the main features of a remailer being
that it would reject duplicates.  Mixmaster does some version of this,
although that needs improvement to really meet this attack.

> Alice has been hauled into court.  The Feds claim that she is the one that
> actually sent messages M1,...Mx to Bob through Chaum, even though these
> messages have varied From: (and From) lines.  As root, she cannot claim
> that this is not possible.  OTOH, if Chaum requires a match, the Feds would
> have to claim that she compromised the secret keys of all of all the
> cooresponding From: addresses.  Much tougher.

OTOH, if Alice actually has signed those messages, her jig is up pretty
good, wouldn't you say?  Do we really want to force people to use the
nets in a mode in which they can be incriminated like this by a hostile
government?

> Seriously, if a sight is being shadowed, then it is insecure.  It is to our
> advantage to know this.  You are right that we "don't care" where a message
> comes from only if we assume that the message _didn't_ come from an LEA.
> (Or a big corporation.  Some of them probably have the power to do this,
> too.)

Hell, Detweiler has the power to do this!  He's spoofed messages plenty
of times.  How do we know?  Because of remailer logging.  That's the real
threat, IMO (the logging).

> If it did, then the remailer net is under attack, and we most
> definitely _do_ care about that.

Even if a message comes from a fake address that is hardly evidence of an
attack by a powerful opponent.  It could just be an extra-paranoid
legitimate remailer user who doesn't want to extend any more trust than
necessary.

> >Although I agree with Wei Dai's mathematics, to my mind it points up the
> >importance of successful countermeasures rather than implying that the
> >remailer network is inherently insecure.  For example, if you send one
> >identical message every batch, Wei's math shows clearly that you can't be
> >traced.  Let's not get rumors started about how the remailers don't
> >work.
>  
> I'm lost here.  I thought that sending an identical message (producing
> identical output) every tick would be the equivalent to an attack.

I meant to refer to encrypted messages identical in size and otherwise
opaque, so that your apparent rate of output is constant.

> But what exactly constitutes "successful countermeasures"?  How do you
> prevent an attacker from taking over a sight, thus compromising it, w/o
> the knowlege of the operator?  How do you prevent long/short matching of
> the remailer net _as a whole_?  How do you prevent tail matching?  How do
> you prevent middle matching, for that matter?  How do you prevent the
> repeated message attack?

I was referring specifically to the correlation attack described by Wei.
The other attacks you describe need to be met by the kinds of
countermeasures we have been discussing: standard-sized messages,
remailer chains, not using encrypted reply blocks which leave message
bodies alone, rejecting matching messages.  All of these were discussed
in Chaum's 1981 paper.

> >Do you see your suggestion as protecting against Wei's in/out correlation
> >attack?  
>  
> Yes!  Well, not by itself.  My suggestions about "rational use of garbage"
> do that.  If Bob recieves x messages each tick, 0 to x of which are real,
> Eve is hosed--if all messages are standard sized & encrypted!.  Eve is even
> more hosed if the x messages are concatenated & superencrypted.  If Alice
> sends y messages each tick, Eve is hosed.  Even more so if the messages are
> concatenated & superencrypted.

How can Bob arrange to receive a constant number of messages each tick?
Do all his messages come from one remailer?  Or do all of the remailers
which might send to him check among themselves before sending to him so
they can mutually know how many fake messages to send?

IMO the real solution to the correlation attack is to have a constant
message generation rate.  That is sufficient.  Solutions to the other
attacks mentioned in Chaum are described in Chaum.  (This attack was not
described in Chaum's paper.)

> >Of course it was Chaum himself in his 1981 paper (which I think is available
> >from the CP FTP site) who described the duplicate-message attack.  I don't
> >see that inter-remailing encryption helps much, because the attacker can
> >still notice that whenever they inject message A, _something_ goes to
> >Bob.  The real solution, as Chaum pointed out, is that the remailer must
> >reject duplicate messages, even when separated by days.  Doing this without
> >keeping a database of all messages ever sent is left as an exercise.
> >
>  
> I disagree.  If identical input to Chaum does not produce identical output
> to Bob, how does Eve coorelate them?  Repeating, she can match the top of
> the body of messages, so random tails reveal the actual encrypted message,
> for whatever that is worth.

I'm not sure what you mean by "matching the top of the body of messages".
Are you referring to an encrypted reply block, which might be the same
for two different messages to the same user?  Or are you suggesting that
messages would have some headers or some other structures at their top
which would be preserved through a remailer?

> And if Bob receivs x packets per tick, or a BIG packet every tick, how does
> Eve trace it?

If the input to Bob really can be made constant across the whole remailer
net then this does seem to largely protect against duplicate-message
insertion, in conjunction with the intra-remailer encryption.  However it
would apparently also be necessary for every remailer to send a constant
number of packets to every other remailer.  Otherwise a bolus of
duplicates into one remailer would all leave to go to the next remailer
at once and would show up.  This means that the net as a whole has to
carry a constant traffic load on all inter-node links, which could mean a
large cost in bandwidth load.  I still think that rejecting matching
messages is a better solution.

> >Another aspect worth mentioning is that message splitting can make the
> >kinds of statistical correlations that Wei Dai was looking at more of
> >a danger. 
>  
> More than being the ONLY file in the net of your (approximate) size?

No, of course message size standardization is a necessary step.  This has
been recognized for 15 years.

> >          It's one thing if I send a message along with thousands of
> >other people, and Bob gets a message along with everyone else.  But if I
> >send 10 messages and Bob gets 10 from that batch, that fact alone can
> >help to link us up.  So splitting my big message into 10 standard ones
> >isn't that great if they're all sent at once.  Ideally you'd want to
> >dribble them out at some standard rate, a rate at which you always send
> >a message whether you have something to send or not.  But this may introduce
> >unacceptable latency.
>  
> "Dribble them out at some standard rate".  Yes.  y packets per tick.  Set y
> equal to your average number of real packets per tick, plus 3 standard
> deviations.  Since you are chaining, the latency of you input will be less
> than the latency of the remailernet.

OK, but chances are your average number of real packets per tick is < 1,
e.g. if a tick is a few hours and you only send one or two messages
a day.  So when you do need to send that 500KB GIF it's going to take a
lot of ticks.

I would sum up by agreeing with several points: the need for standard
message sizes, and for a standard rate of message output.  I am neutral
on whether a remailer may want to super-encrypt a message to the next
link in the chain (whether a remailer or an end user) if it happens to
have a key handy.  I don't see any harm in this and the remailer
software will already handle this transparently on the receiving end.
I disagree with the idea of remailers checking signatures.  I don't
agree that inter-node remailer encryption provides significantly more
protection than padding.  I think that encrypted reply blocks are
unsafe even with inter-node remailer encryption.  See Chaum's paper for
ways that encrypted reply blocks can be used safely.  We have also had
some suggestions here for modifications to Chaum's method.  And I don't
see how you can arrange to receive a constant load from the net without
a highly centralized system, which would have its own dangers.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzCGHRnMLJtOy9MBAQEzlwH/XUYi0mhSUl0Dd4hMp/dE9KFEDQd3jNQs
Zby7ZIDl3qQn1EK1f81pLSHUYdQgGflMrMaDS9QTrRXSR/mYqx3HeQ==
=ZyWU
-----END PGP SIGNATURE-----





From an158409 at anon.penet.fi  Thu Feb  2 05:46:08 1995
From: an158409 at anon.penet.fi (beacher)
Date: Thu, 2 Feb 95 05:46:08 PST
Subject: computer underground digest stuff
Message-ID: <9502021305.AA25319@anon.penet.fi>



Date: Fri, 20 Jan 1995 00:13:29 -0600 (CST)
From: David Smith <bladex at BGA.COM>
Subject: File 1--ACM Computers Seized by IIT (fwd)

               ---------- Forwarded message ----------

ACM Computers Seized By Illinois Institute of Technology

  "And let it be known throughout the world what was done this day..."

Dateline January 17, 1995

Today sometime before noon today, the Illinois Institute of Technology
seized the computer systems of the Association for Computing Machinery
student chapter at IIT.

700 Student and Faculty users are not happy.

And are now without their Email and other private files. The locations
of the ACM systems is currently unknown, and the security of the
system and the accounts on it is highly questionable, as it was quite
literally riped out of the wall. ( a piece of the modem was found
lying on the table ).

The reasons given by IIT where that members of ACM are suspected of
hacking into the computer of another IIT student group, and pulling
several pranks.  The memo sent to the Dean of Students details the
hacking attempt, but no evidence points to ACM's systems or to any of
their users, but the memo does make several unbacked accusations. And
at this time, we can see no reason ACM would even be tied to the
events. However because ACM members are suspect, the systems where
unlawfully seized by IIT.

IIT has no legal right to seize ACM's systems, nor anyone else, as
they contain private accounts, files, and Email.  Such rights are
protected under the Electronic Communications Privacy Act (ECPA),
which extended most of the protections of the federal Wiretap Act
("Title III") to electronic mail.  Precidence established in the case
Secret Service vs. Steve Jackson Games decided March 12, 1993

Needless to say, ACM members are not too happy about all of this.  And
the other 700 people don't seem happy either.

            ---------------------------------------------

Dateline January 18, 1995

   o Members realize that along with Troll, which is physicaly
     considered IIT's property even tho it was purchased with student
     funds, property of ACM members was also seized includind a
     network card, SIMM modules, and the modem that was broken by IIT
     during the seizure.

   o ACM recieves writen copy of allegations and supposed proof that
     ACM systems where used in the attempt. However the evidence
     clearly shows that other IIT owned systems where used and NOT
     ACM's systems.

   o Electronic Frontier Foundation is called and informed of the
     situation, and begins investigating the situation.

   o ACM HEARS THAT THE COMPUTER SYSTEM IS IN THE PROCESS OF BEING
     SEARCHED BY IIT STAFF, AND ACM MEMBERS NOW CONSIDER THE SYSTEM
     COMPROMISED. STILL NO EVIDENCE SHOWING ACM INVOLVEMENT.

   o Word continues to spread amung the IIT community, many more
     students and faculty are outraged about the seizure of their
     accounts and files.

   o Continued stress to students due to the lack of access to their
     Email, addressbooks, and other files. Email is now being lost in
     mass due to the

   o ACM systems removal, much of which is considered critical by many
     people.  ACM members miss the Chicago ACM meeting due to the fact
     that all the info concerning time/location was stored on the
     seized systems.

   o ACM members miss the Chicago ACM meeting due to the fact that all
     the info concerning time/location was stored on the seized
     systems.

-------------------------------------------------------------------------
To find out more about the anon service, send mail to help at anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin at anon.penet.fi.





From greg at ideath.goldenbear.com  Thu Feb  2 06:09:53 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Thu, 2 Feb 95 06:09:53 PST
Subject: Frothing remailers and trust
Message-ID: <199502020934.AA25847@ideath.goldenbear.com>


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

kevin at elvis.wicat.com writes:

> It strikes me as critical; right now, a user has to choose to trust a
> set of remailers, given no assistance other than a list of "reliable"
> ones. Given an extended web of trust between remailers, the user can
> choose to trust one remailer (I have no idea how to make this process
> more palatable) and immediately gain the security of a large web of
> remailers (maybe you are right about that instant gratification
> thing...)

For what it's worth, I'm a remailer operator and I don't know any of
the other operators well enough to say that I'm sure that they're
trustable with respect to preserving privacy. (no offense intended.) 
I do, for the most part, trust them to forward almost all messages
but my conclusion is based in large part on Raph's list. Absent that
list, I don't think I'd have enough information on delivery reliability
to comment about that either. This "web of trust" thing sounds nice but
I can't participate because I don't know the other people involved. I 
think other remailer operators may be in a similar situation.

Your scheme seems to conflate two tasks/roles I think are separable -
remailing messages and specifying a trustable path for messages to 
take. The latter requires more information than I have - but it is
information someone could gather. I think it'd be possible for someone
to perform "remailer audits", and then report their findings. Some
part of that report might be in the form of a "Anon-To:" chain,
or probabilites for creating your own chain of messages; or maybe
the auditor would serve as a first-hop-but-never-the-last remailer,
passing the message along to remailers it believes to be reliable and
trustworthy. Premail seems to be a step in this direction, but it
chooses hops on the basis of reliability, not reliability + privacy.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzCm8X3YhjZY3fMNAQEjnwP/T//KwPuvnzlRYgV8MgltJIaisM78zMjU
J+Q+ARuvBudBS9ah8Z2p/MtxClj6nBYXEMFWtqwQbICBzDwxfpQAwahz5Vlay3qi
QouRKx0ZJonvdi1LpIYYS8ElH8SdWEERMItfDyFDe2HDjFTXjL6fUbrIyLBvdzdl
PCSmID/WYq0=
=ukpf
-----END PGP SIGNATURE-----




From eric at remailer.net  Thu Feb  2 06:45:22 1995
From: eric at remailer.net (Eric Hughes)
Date: Thu, 2 Feb 95 06:45:22 PST
Subject: Remailer encryption module
In-Reply-To: <Pine.3.89.9502011857.B8923-0100000@jake.bga.com>
Message-ID: <199502021444.GAA07493@largo.remailer.net>


   From: Nathan Zook <nzook at bga.com>

   I also believe that hacking PGP is a bad thing (tm), because it means that
   every time an upgrade comes out, it will need to be re-hacked, and once you
   start hacking, when do you stop?

I agree.  PGP just does not have the support for the encryption
required for mixing remailers.  These deficiencies have been known for
about two years at this point and still nothing has happened.  I
expect this not to change anytime soon.

That means that we have to replace PGP as the encryption module for
remailers.  The first thing to do is to design a data format which
supports what the remailers need now, and nothing speculative.  Since
this data format has a single purpose, we can make new revisions more
easily than for a general purpose package.

Once we get a data format, implementations will follow.

Eric





From perry at imsi.com  Thu Feb  2 06:53:24 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Thu, 2 Feb 95 06:53:24 PST
Subject: Remailer encryption module
In-Reply-To: <199502021444.GAA07493@largo.remailer.net>
Message-ID: <9502021453.AA28522@snark.imsi.com>



Eric Hughes says:
> 
> Once we get a data format, implementations will follow.
> 

The obvious data format is MIME's "Security Multiparts".

Perry





From Nobody at eniac.ac.siue.edu  Thu Feb  2 07:04:00 1995
From: Nobody at eniac.ac.siue.edu (Anonymous)
Date: Thu, 2 Feb 95 07:04:00 PST
Subject: How much entropy in a key press?
Message-ID: <199502021456.IAA01951@eniac.ac.siue.edu>


Can anyone tell me how many bits of entropy there are per 7-bit ASCII
character.  More specifically, a program wishes to generate a session
key by prompting the user to type N random key presses.  The characters
entered are hashed down to 128 bits by MD5 for subsequent use as a key.

What should the value of N be, such that the entropy of the user's
string does not unnecessarily exceed the entropy of the hash?







From allan at elvis.tamu.edu  Thu Feb  2 07:08:49 1995
From: allan at elvis.tamu.edu (Allan Bailey)
Date: Thu, 2 Feb 95 07:08:49 PST
Subject: Remailer encryption module
In-Reply-To: <199502021444.GAA07493@largo.remailer.net>
Message-ID: <9502021508.AA28912@elvis.tamu.edu>


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

>    From: Nathan Zook <nzook at bga.com>
>    I also believe that hacking PGP is a bad thing (tm), because it means that
>    every time an upgrade comes out, it will need to be re-hacked, and once you
>    start hacking, when do you stop?

Sounds like the UNIX philosophy to me.  :) 

> I agree.  PGP just does not have the support for the encryption
[...]
> That means that we have to replace PGP as the encryption module for
> remailers.  The first thing to do is to design a data format which
> supports what the remailers need now, and nothing speculative.  Since
> this data format has a single purpose, we can make new revisions more
> easily than for a general purpose package.
> 
> Once we get a data format, implementations will follow.

Isn't this what the forthcoming PGP RFC is about?  Also, what about
the PEM "standard"?  If remailers agree to follow one or more of those
standard data format specifications, then someone could just
ripup PGP and implement modules to produce those data formats.

Consider what CP did with his(her?) PGPTools kit.  As long as we have
an agreeable dataformat "standard", the implementation becomes
irrelevant.  

Maybe I'm just confused and not following the thread closely
enough....

- --
Allan Bailey, allan at elvis.tamu.edu        | "Freedom is not free."  _O_
Senlima Diverseco je Senlimaj Kombinajxoj.| allan.bailey at tamu.edu    |
KC5KSF                                    |nefud-the-delirious at tamu.edu
GCS w+ v-/+ C++++ U@$ P+++ L++ E++ N++ po--- Y++ b++

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzD1ghDxfDCMTq7JAQH9SgQA1K0i/PndcdaZFHkRwP2IrWbMihXvCTRc
0G0xf3GUH4KLlR5HC/qUBurvreoRCF2PjM6cDpx1Ao2pRbB/jeiRINC/5OuhZtrJ
A1KpWN51XR2c4BXRTxXvNGCUMzzH7B8uLjR01n3EWabHljoKX8HHwWKKXTe5S/1Q
AQlh00/0iA0=
=+b0t
-----END PGP SIGNATURE-----






From paul at poboy.b17c.ingr.com  Thu Feb  2 08:18:34 1995
From: paul at poboy.b17c.ingr.com (Paul Robichaux)
Date: Thu, 2 Feb 95 08:18:34 PST
Subject: Video encryption & QTC
Message-ID: <199502021617.AA27746@poboy.b17c.ingr.com>


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


[ for cypherpunks: Apple's now beta testing a video conferencing
product called QuickTime Conferencing, or QTC. The Mac crypto
interface list (mcip at feeley.cc.utexas.edu) started a discussion on
video encryption, hence this crosspost. Feel free to chime in. ]

Here are a couple of additional things to consider.

This is a pretty classic application for stream ciphers. Since QTC is
transport-independent (and I'd bet it's using OpenTransport calls,
too), I'm assuming that QTC is using streams for video data, and that
any packetization happens at the transport layer. Just before you call
UDPSend(), ATPSend(), or whatever, just whack that outgoing block
through the crypto function and off you go.

As mentioned, RC4 might be a good choice. It's fast, plus Apple's
already licensed it. It probably provides adequate tactical security,
but as Adam pointed out, it has not been well analyzed in the open
literature. However, there are many other stream ciphers out there:
Diamond, Blowfish, RC5, etc. My gut feel is that RC4 is probably
adequately secure with a 128-bit key; then Apple can dumb down to 40
bits for export approval. After all, they're not likely to build a
product which they can't export.

What about using a PCMCIA card like the National Semi Persona 100? It
includes RSA signatures & verification, Diffie-Hellman key exchange (I
think) and single DES; future versions will include 3DES and IDEA.
Hardware encryption is fast, fast, fast. Don't forget AT&T's recent
announcement of a similar product which does 3DES.

One MCIP reader proposed just using PGP: RSA the session key and send
it along. IMHO Diffie-Hellman is a better way to do this. Rather than
using the PGP metaphor, where RSAing the session key allows you to
send the session key as part of the message, DH allows you to
establish the session key over an insecure channel, then start sending
messages.

- -Paul

- -- 
Paul Robichaux, KD4JZG       | Good software engineering doesn't reduce the 
perobich at ingr.com            | amount of work you put into a product; it just 
Not speaking for Intergraph. | redistributes it differently.
                  ### http://www.intergraph.com ###

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzEFkKfb4pLe9tolAQEtEAP/bxEHw+fwPaJJPyHaRRtuZqlxmzvEyD+w
5cmB9c75gzkY9SpSSLkbtawwUjCCiKynMAX76uSRaDRkVeTILelJ3gvdguRMS3Id
MYQI162mPvCN+lTvsMoXVJAdZzC14WE9JE0t9FC+ovYE8M+/yZ16EGEnvtWbnNYQ
pO8GkvNpR+g=
=n3fX
-----END PGP SIGNATURE-----





From eric at remailer.net  Thu Feb  2 08:36:40 1995
From: eric at remailer.net (Eric Hughes)
Date: Thu, 2 Feb 95 08:36:40 PST
Subject: Why encrypt intra-remailernet.
In-Reply-To: <Pine.3.89.9502011857.B8923-0100000@jake.bga.com>
Message-ID: <199502021635.IAA07634@largo.remailer.net>


   From: Nathan Zook <nzook at bga.com>

   When I say that the Mark I remailers are laughably easy to crack, I mean
   laughably easy.

By whom?  I am hearing a general denunciation of the current remailer
system.  These blanket denials are false on their face, because they
are not true in every circumstance.

   The only reason that our systems are actually able to do any good is that
   our threat model _is not_ an LEA--with government resources, and government
   patience.

_Our_ threat model?

There is not one threat model.  Each person has their own threat model
and their own desired level of security.  An individual also desires
more security for some messages than others.  The current remailer
network is good for some purposes and bad for others.

Every evaluation of security _must_ include the nature of the security
desired, because there is no single concept called "security" which is
the same in every situation.

Eric





From adam at bwh.harvard.edu  Thu Feb  2 08:37:22 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Thu, 2 Feb 95 08:37:22 PST
Subject: How much entropy in a key press?
In-Reply-To: <199502021456.IAA01951@eniac.ac.siue.edu>
Message-ID: <199502021639.LAA15114@hermes.bwh.harvard.edu>


Shannon estimates roughly 1 bit per character of English.  

RFC 1750  D. Eastlake, S. Crocker, J. Schiller,
"Randomness Recommendations for Security" is probably useful.

Adam

| Can anyone tell me how many bits of entropy there are per 7-bit ASCII
| character.  More specifically, a program wishes to generate a session
| key by prompting the user to type N random key presses.  The characters
| entered are hashed down to 128 bits by MD5 for subsequent use as a key.
| 
| What should the value of N be, such that the entropy of the user's
| string does not unnecessarily exceed the entropy of the hash?
| 
| 

-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From eric at remailer.net  Thu Feb  2 08:48:23 1995
From: eric at remailer.net (Eric Hughes)
Date: Thu, 2 Feb 95 08:48:23 PST
Subject: Remailer encryption module
In-Reply-To: <9502021453.AA28522@snark.imsi.com>
Message-ID: <199502021647.IAA07663@largo.remailer.net>


   From: "Perry E. Metzger" <perry at imsi.com>

   > Once we get a data format, implementations will follow.

   The obvious data format is MIME's "Security Multiparts".

That's not a complete answer.  That's kind of the obvious package, but
it addresses nothing of the interior.

Eric





From hfinney at shell.portal.com  Thu Feb  2 08:49:39 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 2 Feb 95 08:49:39 PST
Subject: Adding padding to PGP files
Message-ID: <199502021648.IAA05417@jobe.shell.portal.com>


Here are a couple of perl scripts I wrote last year to add padding to PGP
encrypted files.  The usage would be:

perl pgppadt.pl filename bytestoadd

The output file is filename.pad.

It only works on binary ".pgp" public-key encrypted files (not ascii armored
files).  So there would be some work needed to make it a really useful tool.
It would also be better to use a strong source of random numbers.  I
think Carl Ellison recently posted some tools that could help with this.
The two files are pgppad.pl, which does the work, and pgppadt.pl, a very
simple test driver to show how to use it.  They are in a shar archive.

Hal

---------------cut here----------------
#!/bin/sh
# to extract, remove the header and type "sh filename"
if `test ! -s ./pgppad.pl`
then
echo "writing ./pgppad.pl"
cat > ./pgppad.pl << '\End\Of\Shar\'
# Perl module to allow padding and some other manipulation of PGP
# files.
#
# Include this with the statement:
# require 'pgppad.pl'
#
# 10/16/93
# Hal Finney


# Read a PGP Cipher Type Byte and the following length.
# One argument: file to read from
# Returns several things, in this order:
# CTB, with the length information removed, as a number.
# Length of following packet.
# Name of this kind of packet, made up, see list below.
# Packed CTB/length packet, suitable for writing out.
# Returns an empty string on error.
sub read_ctb {
    local($file) = @_;
    local($ctb, $length, $name, $rctb, $rlength, $lengthlength);

    if (read ($file, $rctb, 1) != 1) {		# Raw ctb
	return "";
    }
    $ctb = unpack ("C", $rctb);
    if ($ctb < 128) {
	return "";		# Must have high bit set
    }
    $lengthlength = $ctb % 4;
    $ctb -= $lengthlength;
    if ($lengthlength == 0) {
	$lengthlength = 1;
    } elsif ($lengthlength == 1) {
	$lengthlength = 2;
    } elsif ($lengthlength == 2) {
	$lengthlength = 4;
    } else {
	$lengthlength = 0;
	$length = -1;	# Unknown length
    }
    if (read ($file, $rlength, $lengthlength) != $lengthlength) {
	return "";
    }
    if ($lengthlength==1) {
	$length = unpack("C", $rlength);
    } elsif ($lengthlength==2) {
	$length = unpack("n", $rlength);
    } elsif ($lengthlength==4) {
	$length = unpack("N", $rlength);
    }
    $rctb = pack ("C a".$lengthlength, $rctb, $rlength);  # Packed data
    if ($ctb==0x84) {
	$name = "pubkey header";
    } elsif ($ctb==0x88) {
	$name = "signature";
    } elsif ($ctb==0x8c) {
	$name = "message digest";
    } elsif ($ctb==0x94) {
	$name = "secret key";
    } elsif ($ctb==0x98) {
	$name = "public key";
    } elsif ($ctb==0xa0) {
	$name = "compressed";
    } elsif ($ctb==0xa4) {
	$name = "conventional encrypted";
    } elsif ($ctb==0xa8) {
	$name = "plaintext";
    } elsif ($ctb==0xb0) {
	$name = "trust";
    } elsif ($ctb==0xb4) {
	$name = "user id";
    } elsif ($ctb==0xb8) {
	$name = "comment";
    } else {
	return "";
    }
    return ($ctb, $length, $name, $rctb);
}

# Write a CTB and length field out.
# 3 arguments: file handle, ctb value, and length in bytes.
# No return value.
# Length gets output as 1, 2, or 4 bytes, the smallest in which it
# will fit.
# If length is negative we output no length field, but an "indefinite
# length" code is added to ctb.
sub write_ctb {
    local($file, $ctb, $length) = @_;
    local($rctb);

    $ctb = $ctb - ($ctb % 4);	# Be sure 2 low bits are clear
    if ($length < 0) {
	$rctb = pack ("C", $ctb+3);		# Packed data
    } elsif ($length > 65535) {
	$rctb = pack ("C N", $ctb+2, $length);  # Packed data
    } elsif ($length > 255) {
	$rctb = pack ("C n", $ctb+1, $length);  # Packed data
    } else {
	$rctb = pack ("C C", $ctb+0, $length);  # Packed data
    }
    print $file $rctb;
}

# This entry point always outputs a 4-byte count.  Length must be > 0.
# Otherwise like write_ctb.
sub write_ctb_4 {
    local($file, $ctb, $length) = @_;
    local($rctb);

    $ctb = $ctb - ($ctb % 4);	# Be sure 2 low bits are clear
    if ($length < 0) {
	die ("write_ctb_4 called with negative length\n");
    }
    $rctb = pack ("C N", $ctb+2, $length);  # Packed data
    print $file $rctb;
}


# Pad a PGP public-key-encrypted file to the specified length.
# Arguments: input file handle; output file handle; new size.
# Returns negative value on error.  See the code for what the
# different values mean.
# Returns 0 on success.
sub pgppad {
    local($infile, $outfile, $size) = @_;
    local($ctb, $length, $name, $rctb, $insize, $buf);

    # Read ctb & length of pubkey header
    ($ctb, $len, $name, $rctb) = &read_ctb($infile);
    if ($ctb == 0) {
	return -1;	# Error
    }
    if ($name ne "pubkey header") {
	return -2;	# Error
    }
    if ($len < 0) {
	return -3;	# Error
    }

    $insize = length($rctb) + $len;

    # Read packet of pubkey header
    if (read ($infile, $data, $len) != $len) {
	return -3;
    }

    # Write out pubkey header, unchanged
    &write_ctb($outfile, $ctb, $len);
    print $outfile $data;

    # Read ctb and length of conventional packet
    ($ctb, $len, $name, $rctb) = &read_ctb($infile);
    if ($ctb == 0) {
	return -4;	# Error
    }
    if ($name ne "conventional encrypted") {
	return -5;	# Error
    }

    # Calculate size of outgoing conventional packet.
    # Assume rctb won't change size; it may grow by 1 or 2 in some
    # rather rare cases, in which case we'll be a byte or two too big.
    $size -= $insize + length($rctb);
    if ($size < $len) {
	return -6;	# Error
    }

    # Output CTB with new length
    &write_ctb_4($outfile, $ctb, $size);

    # Copy remainder of input file
    while (read ($infile, $buf, 32768)) {
	print $outfile $buf;
    }

    # Note that this random number generator is probably not
    # cryptographically strong.
    srand (time|$$);
    while ($len < $size) {
	print $outfile pack ("C", int(rand(256)));
	++$len;
    }

    return 0;		# Success
}

1;	# Non-zero return for 'require'
\End\Of\Shar\
else
  echo "will not over write ./pgppad.pl"
fi
if `test ! -s ./pgppadt.pl`
then
echo "writing ./pgppadt.pl"
cat > ./pgppadt.pl << '\End\Of\Shar\'
# Test program for pgppad.pl, showing how to use it.
require 'pgppad.pl';

open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n");
open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n");

$padding = $ARGV[1];

@stat = stat(IN);
$size = $stat[7];
print "Input file $ARGV[0] has size $size bytes\n";
print "Output file $ARGV[0].pad will have size ".$size+$padding." bytes\n";

if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) {
    die ("pgppad returns code $code\n");
}

close (IN);
close (OUT);
print ("Done\n");

\End\Of\Shar\
else
  echo "will not over write ./pgppadt.pl"
fi
echo "Finished archive 1 of 1"
exit





From perry at imsi.com  Thu Feb  2 08:53:15 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Thu, 2 Feb 95 08:53:15 PST
Subject: Remailer encryption module
In-Reply-To: <199502021647.IAA07663@largo.remailer.net>
Message-ID: <9502021652.AA28840@snark.imsi.com>



Eric Hughes says:
>    From: "Perry E. Metzger" <perry at imsi.com>
> 
>    > Once we get a data format, implementations will follow.
> 
>    The obvious data format is MIME's "Security Multiparts".
> 
> That's not a complete answer.  That's kind of the obvious package, but
> it addresses nothing of the interior.

It does specify the interior.

.pm





From xpat%vm1.spcs.uma.thurman.edu at vm1.spcs.umn.edu  Thu Feb  2 09:23:33 1995
From: xpat%vm1.spcs.uma.thurman.edu at vm1.spcs.umn.edu (xpat%vm1.spcs.uma.thurman.edu at vm1.spcs.umn.edu)
Date: Thu, 2 Feb 95 09:23:33 PST
Subject: Frothing remailers, the advertising and pinging problems
Message-ID: <9502021723.AA10432@toad.com>


jrochkin at cs.oberlin.edu (Jonathan Rochkind) wrote:

>        ++Mail ping. Non-IP, simple, slow. ++
> A mail ping simply consists of sending a message to a remailer with a
> Request-Resending-To: yourself.  When you get it back, you know the
> remailer is alive.
> This has the advantage that it's hard for the remailer
> to trick you, even if it is an evil NSA remailer that wants you
> to believe it is alive, even though it really throws messages in
> in the trash. It can't differentuate between your "ping"
> (to be returned) and a normal message (to be thrown in the trash).

Sure it can.

   if (message_origin==request-resending-to)
     forward_message;

To get around this you would have to chain, thereby relying on
an additional remailer. Of course your origin and resend addresses
could become are different through net.sorcery, but to rely on
existing (and most likely transient) security loopholes are
unsound foundations to construct a persistent reliable remailer net.

Of course, clever Evil Remailer (tm) operatives might have their
machines work *most* of the time, and have more than one, so that
the entire network of remailers *seems* unreliable, or subtlely mangle
encrypted messages so that the ball drops somewhere else.

----------------------------------------------------------------------
P M Dierking | "Emptiness is consistent with everything" --Nagarjuna





From hfinney at shell.portal.com  Thu Feb  2 09:46:29 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 2 Feb 95 09:46:29 PST
Subject: Remailer encryption module
Message-ID: <199502021745.JAA10726@jobe.shell.portal.com>


From: "Perry E. Metzger" <perry at imsi.com>
> Eric Hughes says:
> > 
> > Once we get a data format, implementations will follow.
> > 
> 
> The obvious data format is MIME's "Security Multiparts".
> 
> Perry

For those wishing to follow this debate, here is a URL for this document:

<URL:http://info.internet.isi.edu/in-drafts/files/draft-ietf-pem-sigenc-03.txt>

I had trouble finding it since the filename does not contain "mime" or
"security".

Hal





From ortenzi at interactive.net  Thu Feb  2 10:18:38 1995
From: ortenzi at interactive.net (Anthony Ortenzi)
Date: Thu, 2 Feb 95 10:18:38 PST
Subject: Fundamental Question?
In-Reply-To: <199502020400.XAA03916@libws2.ic.sunysb.edu>
Message-ID: <Pine.BSI.3.91.950202131351.27000B-100000@ns.interactive.net>



I guess that I don't have any real idea about how much traffic goes 
through remailers, myself having only used anon.penet.fi, and even that 
only to reply to others who were anonymized...  anyone have any 
approximate statistics about traffic through other remailers?

And although I know it might be a pain, could there be simple encryption 
(read: fast) that could be implemented so messages could be doubly 
encrypted, the plaintext by pgp, and the pgp text by something else and 
have the identity of the recipient inside the second encryption, where 
each message coming in could be checked to see if it should be pgp decrypted?

Maybe using a simple hash of the recipient's name or other identifying mark?

					-Anthony

On Wed, 1 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> Anthony Ortenzi wrote:
> > 
> > Although I understand the need for remailers for anonymity, is it not 
> > true that the whole idea of encryption (good encryption, that is) is that 
> > no matter who gets the encrypted text, it really doesn't matter?  Does 
> > this not mean that something like USENET is *perfect* for this?
> 
> Well, it's happened in the past. Doesn't mean Usenet is perfect for it,
> since nobody wants to sift through several thousand messages a day for
> messages encrypted to him/her.  Also, imagine all the traffic sent to a
> remailer duplicated on overy site that carries that Usenet group...
> 
> Rob
> 
> 
> 





From lperez at oswego.Oswego.EDU  Thu Feb  2 13:27:56 1995
From: lperez at oswego.Oswego.EDU (Luis Agustin Perez)
Date: Thu, 2 Feb 95 13:27:56 PST
Subject: info
Message-ID: <Pine.3.89.9502021627.A17221-0100000@cloy.oswego.edu>


I recently read an atricle in HT magazine called cyberbucks. I was 
wondering if you could send me some information on the topic of the 
article.                                                          
                                                          thanx





From perry at jpunix.com  Thu Feb  2 13:29:14 1995
From: perry at jpunix.com (John A. Perry)
Date: Thu, 2 Feb 95 13:29:14 PST
Subject: MX'ing and jpunix.com
Message-ID: <199502022127.PAA14199@jpunix.com>


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


	JPUNIX.COM (soon to be alias.net) offers a MX service for
individuals that want to run an anonymous remailer but don't want the
domain they are operating from to be immediately apparent. By making
application to perry at jpunix.com, a remailer operator will be granted a DNS
MX record pointing to the domain address of the requestor's choice and 
will appear to reside in the jpunix.com (alias.net) domain. 

	Additional masking can be provided by having the MX record point
to myriad.pc.cc.cmu.edu. What good does this do? I have an agreement with
myriad.pc.cc.cmu.edu (Matt Ghio) where myriad will take the MX-pointed
record and additionally alias it through the smail daemon on myriad. This
function adds the unique benefit where determining the actual location of
the remailer in question will be foiled when using nslookup.  Since an
additional alias is performed the result of an nslookup will always point
to myriad. The actual location of the remailer remains hidden inside the
alias on myriad. Lastly, Matt has the EXPN function of his sendmail daemon
disabled so the identity of the remailer can't be determined by alias
expansion. 

	Future modifications to this scheme include adding an addition
step whereby the MX-alias process will cause a version of Raph Levien's
premail to post-process the message to add one or more random remailer
paths the the overall path that the message travels. This step in still in
the planning stages and has not been implemented yet. 

	If you have and questions, or want to set up an MX record, send
email to: 

perry at jpunix.com or ghio at myriad.pc.cc.cmu.edu

John Perry < perry at jpunix.com>


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzFN6lOTpEThrthvAQHfAAQAkzoGHz7iaJKHMzB5GEQr8OvEwhDY0F9s
lCZUJhTw3KV2hVWDoUtZNPwiSf4vcsDhGx0CDQrDUon2vXC0mOHj4zBbDhhuUD5l
/NCPOmtWKFSnWiny2JbD0esNIuxIaWfa/tVTkDoDq/zPtsG0awmHTpGMSeIkkxvy
II1mDwnZ9n0=
=2jQD
-----END PGP SIGNATURE-----





From mg5n+ at andrew.cmu.edu  Thu Feb  2 14:11:13 1995
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Thu, 2 Feb 95 14:11:13 PST
Subject: null
In-Reply-To: <199501311018.EAA01333@rebma.rebma.mn.org>
Message-ID: <UjAJVAi00WDJ4bQUw3@andrew.cmu.edu>


nobody at rebma.rebma.mn.org wrote:
> The current status of this is that I get the remailed receipt, but the
> message never shows in the group.  Is mail2news at demon.co.uk down?

Yes.

Try using mail2news at news.demon.co.uk or mail2news at myriad.pc.cc.cmu.edu





From nobody at myriad.pc.cc.cmu.edu  Thu Feb  2 14:56:26 1995
From: nobody at myriad.pc.cc.cmu.edu (Anonymous)
Date: Thu, 2 Feb 95 14:56:26 PST
Subject: Remailer Unreliability
Message-ID: <m0raAVp-000vl1C@myriad.pc.cc.cmu.edu>


What if it was possible to specify an alternate remailer?  In the case that
a remailer went down, you could specify an alternate.  For example:

::
Anon-To: remailer at foo.com
Alternate-To: remailer at bar.com

::
Encrypted: PGP

---pgp msg---

If foo.com was down, the message would be delivered to bar.com instead.
The PGP message would have to be readable to both of them, so it would
decrease security, but reliability would be better, especially for
reply blocks.  Comments?





From eric at remailer.net  Thu Feb  2 15:44:26 1995
From: eric at remailer.net (Eric Hughes)
Date: Thu, 2 Feb 95 15:44:26 PST
Subject: Remailer encryption module
In-Reply-To: <9502021508.AA28912@elvis.tamu.edu>
Message-ID: <199502021935.LAA07891@largo.remailer.net>


   From: Allan Bailey <allan at elvis.tamu.edu>

   [re: not using PGP for remailers]

   Isn't this what the forthcoming PGP RFC is about?  

Not to my knowledge.  As I understand it, they're just trying to
standardize a PGP format by documenting what the code can actually
handle and what was already planned into it.

   Also, what about the PEM "standard"?

PEM carries too much identification on the outside of the encryption
wrapper to be of good practical use against traffic analysis for
regular mail, much less remailer mail.

   Consider what CP did with his(her?) PGPTools kit.  As long as we have
   an agreeable dataformat "standard", the implementation becomes
   irrelevant.  

I expect someone to have library come out that does the format.  The
format need not be very complicated.  Getting rid of all the key
distribution features makes a format much easier indeed.

Eric





From CCGARY at MIZZOU1.missouri.edu  Thu Feb  2 16:01:21 1995
From: CCGARY at MIZZOU1.missouri.edu (Gary Jeffers)
Date: Thu, 2 Feb 95 16:01:21 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
Message-ID: <199502022357.SAA28764@bb.hks.net>


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

         THE FIREWALL CHIP!  U'RE PHONE ALWAYS OFFHOOK?

   We have potential bugging devices in all our houses - The telephone!
Of course, when it is onhook, the microphone does not transmit... or
does it? Would the phone have to be rewired to render it always
"offhook" or would it be an operation at the central phone company?
If the present models would have to be rewired, then how about future
models? Much function is done thru chips & so could many of the models
on the current market be remote programmable? See the latest issue of
Mondo 2000.

   This problem demands a hardware solution. How about an adapter module
between microphone & the rest of phone?

                     THE FIREWALL CHIP

   The Clipper chip architecture was secret! Cypherpunks demand source
code with their security software! How about a demand for the "visable"
chip. That is - a chip with a known architecture - that can be tested
for integrity & is a general computer chip for doing software
operations & for doing i/o with electronic devices? With our property
being loaded up with sophisticated "trust me" electronics, it may be
necessary to have a general electronic "FIREWALL CHIP".

   The FIREWALL CHIP could have its applications software supplied by
various companies which would specialize in fields for
detecting electronic intrusion. Some specializing in phone audio, others
in vision telephones, cell phone tracking, & many others to be
considered.

   The FIREWALL CHIP will be a future necessity. It & its software
suppliers will probably constitute an outlaw industry.

                                         PUSH EM BACK! PUSH EM BACK!
                                         WWWAAAYYY  BBBAAACCCK!
                                         BBBEEEAAATTTT  STATE!

                                         Gary Jeffers
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzFxYCoZzwIn1bdtAQG0ewF/RUMJZU1qXc+31XVQLfetSZst4j+S55/i
tq6j/JN5t3rjXa873mY5lT4cHCFBukfv
=NSeZ
-----END PGP SIGNATURE-----





From hfinney at shell.portal.com  Thu Feb  2 16:15:01 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 2 Feb 95 16:15:01 PST
Subject: Remailing in safe-tcl
Message-ID: <199502030014.QAA22049@jobe.shell.portal.com>


Suppose someone runs safe-tcl to process incoming mail, and supports the
"delivery-time" mode, where incoming mail programs are executed as soon
as they arrive.  (Support for this mode doesn't really exist yet, but
I am putting together a simple script to enable it.)  Here then is an
example of how a self-remailing message might look:

[Other headers]
Content-Type: multipart/enabled-mail; boundary="----- =_791623442"
Content-ID: <2269.791623082.4 at cryo>

------- =_791623442
Content-Type: application/Safe-Tcl; version="7.3"; evaluation-time=delivery
Content-ID: <2269.791623082.2 at cryo>

# Get the other sub-part of this message and send it to the desired address
SafeTcl_sendmessage -to hfinney at shell.portal.com \
        -subject {Remailed message} -body [SafeTcl_getbodyprop 1.2 all]

------- =_791623442
Content-Type: text/plain
Content-ID: <2269.791623082.3 at cryo>

This is the body of the message, which will get remailed.  It could be
a PGP message if the server supported automatic decryption of incoming
PGP mail.  Then it could have nested remailing instructions in it.

------- =_791623442--


This is a MIME format message with two sub-parts.  The first is the
script which gets run on delivery, and the second is the "payload", the
message to be remailed.  The script is a simple one-liner which sends
the second subpart to my email address.

Safe-Tcl does allow (rather vaguely) for automatic decryption of incoming
mail, as well as authentication (so you might allow messages signed by
certain people to get access to some special functions).  There is a
rudimentary mechanism for communication between scripts and server, and
(I think) among scripts themselves, with SafeTcl_getconfigdata and
SafeTcl_setconfigdata.  These let you put in {key, value} pairs that
other scripts can read.

I don't see any straightforward way for a script to suspend itself and
re-activate on some future event (such as the arrival of another
message).  Maybe it could put its whole self into the config database as
a {key, value} pair and rely on future messages to pull it out and
execute it.  But that doesn't seem too great.

There is a lot of interest in this notion of mail messages as scripted
agents which go zipping about the network gathering data which they send
home.  I am optimistic that we will be able to get remailing capabilities
out of this infrastructure largely for free.

Hal





From unicorn at access.digex.net  Thu Feb  2 17:00:14 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Thu, 2 Feb 95 17:00:14 PST
Subject: "bad" government
In-Reply-To: <m0rZj0d-000E8pC@dorite.use.com>
Message-ID: <Pine.SUN.3.91.950202195912.3944C-100000@access3.digex.net>


On Wed, 1 Feb 1995, Al Thompson wrote:

> Date: Wed, 01 Feb 1995 12:31:20 -0600
> From: Al Thompson <alt at iquest.net>
> To: Charles Bell <quester at eskimo.com>
> Cc: cypherpunks at toad.com
> Subject: Re: "bad" government
> 
> 
> >> If strong government resulted in liberty and freedom, then the
> >> most intrusive, all-encompassing governments would result in 
> >> its citizens having the most liberty.  Is this the case?  I would
> >> look at the (former) Soviet Union, Iran, Cuba, East Germany, etc., 
> >> for your answer.
> 
> >Unrestricted individual freedom leads to unrestricted freedom of 
> >`private' corporations.  Private corporations uncurbed by society's law are 
> >autarkies: internally totalitarian, externally predatory, as amoral as 
> >amoebas.
> >
> >Is this the shape of the future you seek?

Yes, orginization by choice, not by design.

> You can NOT restrict someone's rights simply because they MIGHT harm another 
> (prior restraint).  If they do cause actual harm to someone, they should be 
> brought to justice.  To place restrictions on someone based on the 
> possibility that may may cause harm introduces restrictions based solely on 
> the authorities' opinions (political philosophy, religion, race, etc).

Precisely.

>  
> That that the shape of the future YOU seek?
> ************************************************************
> *           Just your basic signature block                *
> *                                                          *
> *  Al Thompson                                             *
> *  Fidonet 1:231/110                                       *
> *  alt at iquest.net                                          *
> ************************************************************
> 
> 

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From warlord at MIT.EDU  Thu Feb  2 17:23:58 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Thu, 2 Feb 95 17:23:58 PST
Subject: Remailer encryption module
In-Reply-To: <199502021444.GAA07493@largo.remailer.net>
Message-ID: <9502030123.AA02022@josquin.media.mit.edu>


> I agree.  PGP just does not have the support for the encryption
> required for mixing remailers.  These deficiencies have been known for
> about two years at this point and still nothing has happened.  I
> expect this not to change anytime soon.

Hmm -- I clearly haven't been reading this thread close enough!  How
is PGP deficient?  What do you need PGP to do in order to get it to
work right with remailers?  I've never seen a bug-report/ feature
request of this sort sent to pgp-bugs at mit.edu, so clearly no one
considered this for the MIT PGP release.

So, what does PGP need to be able to do?

-derek





From nzook at bga.com  Thu Feb  2 18:01:19 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 2 Feb 95 18:01:19 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <Pine.3.89.9502022036.D23979-0100000@vern.bga.com>


>We had some concerns here a while back that someone was trying to exploit
>such a feature to create an exponentially-growing message that would
>totally overload the remailers.  A message of the form:
>
>::
>Request-Remailing-To: <list of remailers here>
>
>::
>Request-Remailing-To: <list of remailers here>
>
><repeat about 20 times>
>
>was sent.  If all remailers had observed and honored the multiple
>requests, there would have been uncounted trillions of messages flying
>about.  So I would caution anyone considering implementing this feature.
>
>Hal
 
Was this Detweiller's "exponentially growing message"?
Note that requiring pgp wrappers kills this...
 
Nathan






From nzook at bga.com  Thu Feb  2 18:03:03 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 2 Feb 95 18:03:03 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <Pine.3.89.9502022004.E23979-0100000@vern.bga.com>


 
kevin at elvis.wicat.com:
 
>Be gentle, though - it's my first time.
 
Here?  You jest.  ;)
 
>It seems to me that the current remailer web suffers a fundamental flaw.
>It is simply too static. When a remailer disappears, service is
>disrupted and messages are lost. Humans have to statically route their
>messages through the web either by hand or using relatively primitive
>tools such as the chain script (not to belittle the useful work that has
>been done, but it is by no means idiot proof yet). Basically, the
>current web of mailers shows nothing of the dynamic nature that has kept
>the internet alive and has offered us a decent chance at truly anonymous
>communications, nor is it easy to use to its full potential.
>
>Consider a more dynamic web of remailers. I envision remailers that
>actively advertise their presence on the web so that all active
>remailers are aware of all other active remailers. This advertising is
>to have very low latency so that a new mailer can be known to the web
>within minutes (I will address the implementation of this later). Thus,
>remailers can constantly be appearing and disappearing without impact on
>the web as a whole (I refer to this dynamic web of remailers as a
>"froth"). Imagine also that remailers are allowed to dynamically perform
>the routing functions that are currently done statically offline (for
>reasons I will discuss shortly).
>
 
Some version of this discussion came up a few months ago, and I passed on
it then, but I think I've heard enough to comment now:
 
The remailers are based on an inherently different model than the InterNet.
Some of these differences, in fact, are crucial.
 
1) The InterNet is based on mutual cooperation/mutual trust.  Cypherpunks
   trust no one that they don't have to.
 
This is not just a result of our twisted psyche.  If we could trust
everyone, we wouldn't _need_ remailers.  Since we don't even know who is
whom out there, we avoid extending trust.
 
2) The InterNet is concerned first about reliability, and not at all about
   privacy.  The remailers are concerned first about privacy, and can leave
   reliability to the users, if need be.
 
There is nothing to prevent Alice and Bob agreeing to send each other ACK
statements, and retransmitting messages if they don't get the ACK.  There
has been some mention of remailers doing the same with each other, in an
attempt to improve net-wide reliability.  BTW, with T1, sending ACKs is not
unreasonable between remailers.
 
3)  From 1) and 2).  The remailers are heading towards mandatory PGP,
    possibly nested.  All InterNet messages are world-readable--although
    this may be changing as the model breaks down.
 
Again, this has to do with the intrinsic diffences.
 
>The use of such transient routers implies allowing dynamic routing. If
>any given remailer may go down or move at any point, it is impractical
>to expect users to keep track of which are up at the moment and create
>static routes in the current manner. The only reasonable solution I have
>come up with is to allow the remailers themselves to choose routing,
>given that they have full knowledge of the current state of the froth.
 
Here we have the real head of the problem, as Hal so asutely points out:
in your model, if the first remailer is bad, the message is compromised.
If user encrypt to all remailers, they might as well encrypt directly to
mole at snakeoil.nsa.gov.  If they don't, they severly limit who can pick out
their messages.  In particular, they bypass transient remailers.
 
But that isn't all.  If the remailers pick the route, they are in a no
better state than the users.  Since the flushing attack requires remailers
to operate on ticks, with carryover, an hour delay per remailer is almost
minimal, untill traffic really picks up.  So if some message routes through
four remailers, a minimum of four hour delay results.  In your case, this
could easily move between in/out of service modes.
 
 
>                 Think about the proposed extension to MixMaster to
>allow separate parts of a multi-part message to be routed separately,
>and consider whether you really want to have to do this by hand. I
>strongly suspect that most messages are currently routed via boilerplate
>scripts, which has to make the job of traffic analysis much easier for
>our good friend Eve.
 
Stupid is as stupid does.
 
 
>By the way, a brief rant on a related topic; people speak of not
>trusting remailers any further than necessary, while I am clearly
>suggesting granting more authority and trust to the remailers. This
>notion of not assigning trust is simply nonsense. When you send a piece
>of mail to a remailer, encrypted or not, you are assigning complete
>trust in that remailer to keep you anonymous and not to forward your
>mail to the NSA immediately.
 
NOT TRUE.  With proper use of encryption, you are trusting your first
remailer only to not reveal that you sent a message, and not to correlate
that message to the one it sends out.  With rational use of garbage running
two deep, you can even suffer this loss without significant harm.
 
 
>This does lead to a related problem, however; if we allow remailers to
>pop up at random and join in the froth, how do we know that Deitweiller
>won't set up a number of black hole remailers that take your mail and
>throw it away, disrupting the froth, or forward it to nphard at nsa.gov?
 
How indeed?  The reason we chain is because we _don't_ really trust our
first remailer--or any other.
 
>Fortunately, we already have the PGP web of trust model in place and can
>use it to good effect in this case. Remailers should simply not route
>mail through any remailer whose public key is not trusted unless
>explicitly ordered otherwise. This ring
remailers to the user--with an exception list for those not "live".
 
Nathan






From sinclai at ecf.toronto.edu  Thu Feb  2 18:04:17 1995
From: sinclai at ecf.toronto.edu (SINCLAIR DOUGLAS N)
Date: Thu, 2 Feb 95 18:04:17 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
In-Reply-To: <199502022357.SAA28764@bb.hks.net>
Message-ID: <95Feb2.210355edt.6007@cannon.ecf.toronto.edu>


>    We have potential bugging devices in all our houses - The telephone!
> Of course, when it is onhook, the microphone does not transmit... or
> does it? Would the phone have to be rewired to render it always
> "offhook" or would it be an operation at the central phone company?
> If the present models would have to be rewired, then how about future
> models? Much function is done thru chips & so could many of the models
> on the current market be remote programmable? See the latest issue of
> Mondo 2000.

The Mondo article ("Total Surveillance" by Charles Ostman) was a joke.
Among other things, he claims the Teledesic project is a massive
satellite surveilance scheme.  Those birds are going to be in
geo-synchronous orbit!  What's more, even a LEO spy-sat weighs many
tons.  Nobody could launch 840 satellites of that weight without being
noticed.

>From the innacuracies in what I do know about, I assume all of the
phone-paranoia is also unjustified.





From rrothenb at ic.sunysb.edu  Thu Feb  2 18:12:33 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 2 Feb 95 18:12:33 PST
Subject: The FNORDWALL CHIP.
Message-ID: <199502030212.VAA22129@libws2.ic.sunysb.edu>



>    ----- Transcript of session follows -----
> ... while talking to toad.com.:
> >>> RCPT To:<cyberpunks at toad.com>
> <<< 550 <cyberpunks at toad.com>... User unknown
> 550 <cyberpunks at toad.com>... User unknown

Talk about lame. I accidentally CC'd this to "cyberpunks". *sigh*

[ More header snipped! ]

> 
> > 
> >          THE FIREWALL CHIP!  U'RE PHONE ALWAYS OFFHOOK?
> 
> Fnorjd!
> 
> > 
> >    We have potential bugging devices in all our houses - The telephone!
> > Of course, when it is onhook, the microphone does not transmit... or
> > does it? Would the phone have to be rewired to render it always
> > "offhook" or would it be an operation at the central phone company?
> 
> I believe there is a way to get regular analog phones to go "off hook"
> by sending the right kind of signal down the wire. Apparently not that
> reliable if you've got multiple extentions.  I think some newer phone
> systems and/or newer phones don't work that well for the method, though
> I never tried it myself.
> 
> 
> >    This problem demands a hardware solution. How about an adapter module
> > between microphone & the rest of phone?
> 
> How about disconnecting the phone when uneeded? Or, filter the calls through
> an answering machine (which may also defeat such a method described above).
> 
> [ Snip! ]
> > 
> >    The FIREWALL CHIP could have its applications software supplied by
> > various companies which would specialize in fields for
> > detecting electronic intrusion. Some specializing in phone audio, others
> > in vision telephones, cell phone tracking, & many others to be
> > considered.
> > 
> >    The FIREWALL CHIP will be a future necessity. It & its software
> > suppliers will probably constitute an outlaw industry.
> 
> I don't think it will be a necessity. I can think of several alternatives
> that don't require trusting an "outlaw industry".
> 
> Rob
> 
> 
> --VAA00527.791777197/abel.ic.sunysb.edu--
> 
> 






From hfinney at shell.portal.com  Thu Feb  2 18:26:30 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 2 Feb 95 18:26:30 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <199502030225.SAA06856@jobe.shell.portal.com>


One point re remailer reliability:  Even though in my discussions with
Nathan I did not really agree with his suggestion to have remailers check
signatures on incoming messages, actually Chaum did propose something
similar in his 1981 paper.

He would have each remailer sign the batch of messages it outputs each
cycle.  (Chaum's remailers used a straight batching approach.)  The idea,
as I recall, was to allow a remailer to prove that it had not engaged in
a denial-of-service attack by purposely dropping some message into the
bit bucket.  If some customer put his message in here and it didn't ever
come out over there, I guess the remailer could prove that it didn't lose
the message by showing its signed batch.  I'm not clear on the details
though.  Anyway, here is an area where message signing and reliability
have some intersection.

Hal





From rrothenb at ic.sunysb.edu  Thu Feb  2 18:26:52 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 2 Feb 95 18:26:52 PST
Subject: How much entropy in a key press?
In-Reply-To: <199502021456.IAA01951@eniac.ac.siue.edu>
Message-ID: <199502030226.VAA22341@libws2.ic.sunysb.edu>


> 
> Can anyone tell me how many bits of entropy there are per 7-bit ASCII
> character.  More specifically, a program wishes to generate a session
> key by prompting the user to type N random key presses.  The characters
> entered are hashed down to 128 bits by MD5 for subsequent use as a key.

Depends. You could use a fast timer and sample between keystrokes, then
use the least significant byte of the difference like PGP does (for DOS,
anyway).  You could change that so it samples bits instead of bytes,
but it's conceivable that you'll have less randomness that way.

I've experimented with speeding up the timer IRQs on my PC for that but
found it was superficially less random (in a pool of 256 bytes there
were more duplicates).

> What should the value of N be, such that the entropy of the user's
> string does not unnecessarily exceed the entropy of the hash?

With a decent timerr that samples bytes, I'd say 16 keystrokes. Use
a cypher overtha random data to garbe it a bit.

Rob

> 






From rrothenb at ic.sunysb.edu  Thu Feb  2 18:36:54 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 2 Feb 95 18:36:54 PST
Subject: Remailer Unreliability
In-Reply-To: <m0raAVp-000vl1C@myriad.pc.cc.cmu.edu>
Message-ID: <199502030236.VAA22498@libws2.ic.sunysb.edu>


> 
> What if it was possible to specify an alternate remailer?  In the case that
> a remailer went down, you could specify an alternate.  For example:
> 
[ Snip! ]
> 
> If foo.com was down, the message would be delivered to bar.com instead.
> The PGP message would have to be readable to both of them, so it would
> decrease security, but reliability would be better, especially for
> reply blocks.  Comments?
> 
Hmmm. Not as secure, but how about this... (a kind of script)

begin A
  if active(mailer at foo.com) mail(mailer at foo.com,B,C)
  elseif active(mailer at bar.com) mail(mailer at bar.com,B,C)
end

begin B
 { next block of scripts for chain... remailer would encrypt B and C
 blocks for appropriate mailer }
end

begin C
 { this block would be cargo... could even contain multiple messages? }
end

That's a pseudoscript, but you get the idea... (no pun intended ;)







From anonymous-remailer at shell.portal.com  Thu Feb  2 19:01:25 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Thu, 2 Feb 95 19:01:25 PST
Subject: Remailer Unreliability
In-Reply-To: <m0raAVp-000vl1C@myriad.pc.cc.cmu.edu>
Message-ID: <199502030300.TAA10357@jobe.shell.portal.com>


> Date: Thu, 2 Feb 95 18:00 EST
> From: nobody at myriad.pc.cc.cmu.edu (Anonymous)
> 
> What if it was possible to specify an alternate remailer?  In the case that
> a remailer went down, you could specify an alternate.  For example:

  Well, *I* think it is a good idea.  But how does remailer1 know that
remailer2 is both a remailer and down?

  Noyb





From ortenzi at interactive.net  Thu Feb  2 20:16:54 1995
From: ortenzi at interactive.net (Anthony Ortenzi)
Date: Thu, 2 Feb 95 20:16:54 PST
Subject: 1995-02-02 President Names Members to Intelligence Commission (fwd)
Message-ID: <Pine.BSI.3.91.950202231722.8718A-100000@ns.interactive.net>


[Thought Intelligence would be something of interest to the list... ]
[Note the sneaking in of Zoe Baird (umm... can you say favor?)      ]
[...................................................................]

---------- Forwarded message ----------
Date: Thu, 2 Feb 1995 18:53-0500
From: The White House <Publications-Admin at WhiteHouse.Gov>
To: Public-Distribution at CLINTON.AI.MIT.EDU
Subject: 1995-02-02 President Names Members to Intelligence Commission




                            THE WHITE HOUSE

                     Office of the Press Secretary

________________________________________________________________________
For Immediate Release					February 2, 1995


      STATEMENT BY THE PRESIDENT NAMING MEMBERS OF THE COMMISSION
    ON THE ROLES AND CAPABILITIES OF THE U.S. INTELLIGENCE COMMUNITY


     I am announcing today appointments to the Congressionally- mandated
Commission on the Roles and Capabilities of the United States
Intelligence Community.  The Commission will be chaired by the current
chairman of my Foreign Intelligence Advisory Board, Les Aspin.  Former
Senator Warren Rudman will serve as the vice chairman and I have asked
General Lew Allen, Jr., Zoe Baird, Ann Caracristi, Stephen Friedman,
Anthony S. Harrington, Robert J. Hermann, and Ambassador Paul Wolfowitz
to serve as well.

     These distinguished Americans will join the eight members appointed
by the leadership of the 103rd Congress.  They are Tony Coelho, David
Dewhurst, Representative Norm Dicks, Senator James Exon, former Senator
Wyche Fowler, Representative Porter Goss, General Robert Pursley and
Senator John Warner.

     Intelligence remains a critical element of our national power and
influence.  For over 40 years bipartisan support for the work performed
by U.S.  intelligence has been essential to the creation of an
intelligence capability that is second to none.  While the world has
changed in dramatic ways, our need to retain the advantage that U.S.
intelligence provides our country remains constant.

     With the end of the Cold War we must renew and reinvigorate this
bipartisan support.  The foundation for this support must begin with a
thorough assessment of the kind of intelligence community we will need
to address the security challenges of the future.  Our objective is to
strengthen U.S. intelligence, to ensure it has the management, skills
and resources needed to successfully pursue our national security
interests through the next decade and beyond.  It is an effort to which
I attach the highest personal priority.

     I am confident that Les Aspin, Warren Rudman and the other
outstanding members of this Commission will work cooperatively with the
leadership of the intelligence community and the Congress to ensure
continued bipartisan support for this critical mission.  And I know that
their effort will ensure the continued trust of the American people in
the outstanding and often unheralded work performed by the men and women
of U.S. intelligence.

# # #

Attachment:
     Biographic Information





	      THE COMMISSION ON THE ROLES AND CAPABILITIES
	      OF THE UNITED STATES INTELLIGENCE COMMUNITY
                            
                            

		   Members Appointed by the President 


Honorable Les Aspin, Chairman.  Mr. Aspin, of Milwaukee, Wisconsin, is a
Distinguished Professor of International Policy at Marquette University
and a Counsel at the Center for Strategic and International Studies.  He
served as Secretary of Defense from 1993 to 1994.  As the US
Representative from Wisconsin's 1st District, his congressional career
spanned twenty two years.  He was Chairman of the House Armed Services
Committee from 1985 to 1993.  Prior to his election to the US Congress
in 1970, Mr. Aspin was a staff assistant to the chairman of President
Kennedy's Council of Economic Advisors.  He also serves as Chairman of
the President's Foreign Intelligence Advisory Board (PFIAB).
  
Warren B. Rudman, Vice Chairman.  Senator Rudman, of Washington, DC and
Manchester, New Hampshire, is a partner in the Washington law firm of
Paul, Weiss, Rifkind, Wharton & Garrison.  He served as a U.S.
Senator from 1980 to 1992, where he was a member of the Select
Committee on Intelligence.  He previously was Attorney General of the
State of New Hampshire.  He also serves as Vice Chairman of the PFIAB.

General Lew Allen, Jr., USAF (Ret.).  General Allen, of Pasadena,
California, served as Chief of Staff of the Air Force and Director of
the National Security Agency.  He retired in 1991 as a Vice President
of the California Institute of Technology and Director of the Jet
Propulsion Laboratory.  He was a member of President Bush's PFIAB and
is a current PFIAB member.

Zoe Baird.  Ms. Baird, of Hartford, Connecticut, is Senior Vice
President and General Counsel of the Aetna Life & Casualty company.
She is a former counselor and senior staff executive of the General
Electric Corporation, a former partner in the Washington, DC law firm
of O'Melveny & Myers, and a former Associate Counsel to President
Carter.

Ann Caracristi.  Miss Caracristi, of Washington, DC, is a former Deputy
Director of the National Security Agency, where she served in a variety
of senior management positions over a 40 year career.  She recently
chaired a DCI Task Force on intelligence training and is a member of
the DCI/Secretary of Defense Joint Security Commission.  She is a
current PFIAB member.

Stephen Friedman.  Mr. Friedman, of New York City, is Senior Chairman
and Limited Partner of Goldman, Sachs & Co., which he originally joined
in 1966.  He served as Chairman and Senior Partner from December 1992
to November 1994 when he retired from active management of the firm.

Anthony S. Harrington.  Mr. Harrington, of Washington, DC, is a partner
in the law firm of Hogan & Hartson.  He is a former General Counsel to
the Democratic National Committee, the former General Counsel to the
Clinton/Gore Campaign, a founding Director of the Center for Democracy,
and a former Assistant Dean of the Duke Law School.   He is a current
PFIAB member.

Robert J. Hermann.  Dr. Hermann, of Hartford, Connecticut, is the
Senior Vice President for Science and Technology of the United
Technologies Corporation.  He is a former Director of the Defense
Department's National Reconnaissance Office and a former senior
official at the National Security Agency.  He is a current PFIAB
member.

Paul D. Wolfowitz.  Dr. Wolfowitz, of Chevy Chase, Maryland, is the
dean of the Paul H. Nitze School of Advanced International Studies at
The Johns Hopkins University.  He served as Under Secretary of Defense
for Policy from 1989 to 1993 and has held a variety of positions in
government beginning in 1966.


             Members Appointed By Congress

Honorable Tony Coelho.  Mr. Coelho is President and CEO of Wertheim
Schroder Investment Services, Incorporated, and a Managing Director of
Wertheim Schroder & Co, Inc.  He a former US Representative from
California and a former Majority Whip of the US House of
Representatives.

David H. Dewhurst.  Mr. Dewhurst is Founder, Chairman, and CEO of
Falcon Seaboard Resources, Inc., a Houston- based, integrated energy
company.  He served as a Case Officer with the Central Intelligence
Agency in the early 1970s, and was recently elected to the National
Board of Directors of the Jewish Institute for National Security
Affairs.  Mr. Dewhurst served as Chairman of the Texas Product
Development Advisory Board.

Representative Norman D. Dicks.  Mr. Dicks, of Washington, was first
elected to the House in 1976.  He has served on the Appropriations
Committee since his freshman term, and currently sits on three
subcommittees -- Defense, Interior and Military Construction. He
currently is the ranking minority member of the Select Committee on
Intelligence.  Mr.  Dicks also was an Administrative Assistant to
Senator Warren Magnuson from 1973 to 1976.

Senator J. James Exon.   Senator Exon, of Nebraska, was elected to his
first term in 1978.  He currently is a member of the Armed Services
Committee (where he chairs the Subcommittee on Nuclear Deterrence, Arms
Control & Defense Intelligence), the Committee on Commerce, Science &
Technology and the Budget Committee.  He is a former two-term Governor
of Nebraska, and a World War Two veteran of the US Army Signal Corps.

Honorable Wyche Fowler.  Mr. Fowler is a partner in the law firm of
Powell, Goldstein, Frazer & Murphy.  He served 16 years in the US
Congress.  Elected to the Senate in 1986, he was Assistant Floor Leader
and was a member of the Appropriations, Budget, Energy and
Agricultural Committees.  During his nine years in the House, he served
on the Select Committee on Intelligence and the Foreign Relations and
Ways and Means Committees.

Representative Porter J. Goss.  Mr. Goss, of Florida, was first elected
to the House in 1988.  He currently is a member of the Select Committee
on Intelligence, the Ethics Committee and the Rules Committee, where he
chairs the Subcommittee on the Legislative Process.  He is a former
Clandestine Service Officer with the Central Intelligence Agency, where
he served for ten years.  Mr. Goss is a former Councilman of Sanibel,
Florida, where he also was elected the city's first mayor.

Lt. Gen. Robert E. Pursley, USAF (Ret.)  General Pursley is President
of the Logistics Management Institute, and a former Vice Chairman of
USAA, a private financial service company, and a former Executive Vice
President of Insilco Corporation.  In twenty five years of military
service, he served as Military Assistant to Secretaries of Defense
Laird, Clifford and McNamara, and was Commander of US Forces Japan and
the Fifth Air Force.

Senator John Warner.  Senator Warner, of Virginia, was elected to his
seat in 1978.  He is the second most senior member of the Senate Armed
Services Committee and the Environment and Public Works Committee.  He
served as Vice Chairman of the Senate Select Committee on Intelligence
from 1992 to 1994.  He also is a former Secretary and Undersecretary of
the Navy.  Senator Warner sponsored the legislation creating this
commission.


# # #









From daleh at ix.netcom.com  Thu Feb  2 20:44:04 1995
From: daleh at ix.netcom.com (Dale Harrison AEGIS)
Date: Thu, 2 Feb 95 20:44:04 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
Message-ID: <199502030441.UAA17143@ix2.ix.netcom.com>


You wrote: 

>>    We have potential bugging devices in all our houses - The telephone!
>> Of course, when it is onhook, the microphone does not transmit... or
>> does it? 
>
>The Mondo article ("Total Surveillance" by Charles Ostman) was a joke.
>
>From the innacuracies in what I do know about, I assume all of the
>phone-paranoia is also unjustified.

Actually, there is a germ of truth in this.  On older phones (don't know if 
this works on newer electronic phones) when the handset is 'on-hook' a 
switch opens and breaks the voice circuit.  This of course only works for 
DC circuits.  If you drive that same circuit with an AC signal (from 
further up the line) then that 'open' switch becomes a capacitor and acts 
as a band-pass filter.  Signals from the mic will then modulate that AC 
current and can be extracted and reconstructed.  Supposedly the Dutch 
police have perfected this and use it in investigations to circumvent legal 
restrictions on physically bugging suspects homes; or so was alleged a 
couple of years ago during a narcotics trial in Amsterdam.

Dale H.







From Nobody at eniac.ac.siue.edu  Thu Feb  2 20:47:02 1995
From: Nobody at eniac.ac.siue.edu (Anonymous)
Date: Thu, 2 Feb 95 20:47:02 PST
Subject: Adding padding to PGP files
In-Reply-To: <199502021648.IAA05417@jobe.shell.portal.com>
Message-ID: <199502030438.WAA09561@eniac.ac.siue.edu>


> Date: Thu, 2 Feb 1995 08:48:49 -0800
> From: Hal <hfinney at shell.portal.com>
> 
> It only works on binary ".pgp" public-key encrypted files (not ascii armored
> files).  So there would be some work needed to make it a really useful tool.
> 
> Hal

  I just tried adding random characters at the end of a pgp ascii
armoured message.  I had to cut out the checksum, but pgp was able to
decrypt the message just fine.  So a very simple program (ideally with
a strong source of random numbers) should be able to pad ascii
armoured files.

  Noyb





From jordyn at alinc.com  Thu Feb  2 21:11:34 1995
From: jordyn at alinc.com (Jordyn A Buchanan)
Date: Thu, 2 Feb 95 21:11:34 PST
Subject: Remailer Unreliability
Message-ID: <ab57699300021004facc@[204.99.128.203]>


>> Date: Thu, 2 Feb 95 18:00 EST
>> From: nobody at myriad.pc.cc.cmu.edu (Anonymous)
>>
>> What if it was possible to specify an alternate remailer?  In the case that
>> a remailer went down, you could specify an alternate.  For example:
>
>  Well, *I* think it is a good idea.  But how does remailer1 know that
>remailer2 is both a remailer and down?

The issue of whether or not the alternate address is a remailer seems to
be largely irrelevant.  It doesn't really hurt anyone to be able to specify
an alternate address, and the feature would even seem to have some practical
value as you could specify alternate addresses for an end-recipient if
you suspect an address might be unreliable.

As long as the alternate address is only invoked if the first mail delivery
fails, the problem of the exponentially-growing message is avoided as well.

Jordyn

-------------------------------------------------------------------------
Jordyn A. Buchanan                      Environmental Studies (B.U.S.)
jordyn at alinc.com                        University of Utah -- '95 (hope)

PGP Public Key: 0xADEEC1 ED 3D 36 5A 98 CE 9D B4  4B 37 0B 9B B5 D6 F3 4B







From hfinney at shell.portal.com  Thu Feb  2 21:15:55 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 2 Feb 95 21:15:55 PST
Subject: Adding padding to PGP files
Message-ID: <199502030514.VAA24599@jobe.shell.portal.com>


From: Nobody at eniac.ac.siue.edu (Anonymous)
> > Date: Thu, 2 Feb 1995 08:48:49 -0800
> > From: Hal <hfinney at shell.portal.com>
> > 
> > It only works on binary ".pgp" public-key encrypted files (not ascii armored
> > files).  So there would be some work needed to make it a really useful tool.
> > 
> > Hal
> 
>   I just tried adding random characters at the end of a pgp ascii
> armoured message.  I had to cut out the checksum, but pgp was able to
> decrypt the message just fine.  So a very simple program (ideally with
> a strong source of random numbers) should be able to pad ascii
> armoured files.

Unfortunately, this approach is easy but doesn't really succeed in adding
undetectable padding.  The PGP message, once the ascii armor is stripped
away, has a byte count in it.  Anyone can de-armor the message and see
that this byte count does not match the size of the file.  So you also
need to bump this byte count to match the added bytes.  That's all my
perl script does that I posted.

Hal





From jordyn at alinc.com  Thu Feb  2 21:16:56 1995
From: jordyn at alinc.com (Jordyn A Buchanan)
Date: Thu, 2 Feb 95 21:16:56 PST
Subject: Remailer Unreliability
Message-ID: <ab576c25020210049573@[204.99.128.201]>


>> Date: Thu, 2 Feb 95 18:00 EST
>> From: nobody at myriad.pc.cc.cmu.edu (Anonymous)
>>
>> What if it was possible to specify an alternate remailer?  In the case that
>> a remailer went down, you could specify an alternate.  For example:
>
>  Well, *I* think it is a good idea.  But how does remailer1 know that
>remailer2 is both a remailer and down?

The issue of whether or not the alternate address is a remailer seems to
be largely irrelevant.  It doesn't really hurt anyone to be able to specify
an alternate address, and the feature would even seem to have some practical
value as you could specify alternate addresses for an end-recipient if
you suspect an address might be unreliable.

As long as the alternate address is only invoked if the first mail delivery
fails, the problem of the exponentially-growing message is avoided as well.

Jordyn

-------------------------------------------------------------------------
Jordyn A. Buchanan                      Environmental Studies (B.U.S.)
jordyn at alinc.com                        University of Utah -- '95 (hope)

PGP Public Key: 0xADEEC1 ED 3D 36 5A 98 CE 9D B4  4B 37 0B 9B B5 D6 F3 4B







From jlasser at rwd.goucher.edu  Thu Feb  2 22:31:34 1995
From: jlasser at rwd.goucher.edu (Jon Lasser)
Date: Thu, 2 Feb 95 22:31:34 PST
Subject: A simple idea
Message-ID: <Pine.SUN.3.91.950203012421.8112A-100000@rwd.goucher.edu>



Maybe this has been discussed before, but if so I wasn't around for it 
and would like to know:

What if: (assuming trusted remailers, but still worried about traffic 
analysis of those remailers):

One mailed a message to one remailer. This remailer held onto all 
messages until some predestined hour or kilobyte size or whatever, and 
then forwarded ALL its messages to this other remailer, in one packet 
(.TARred and PGPed separately, say), but NOT IN THE ORDER RECIEVED?

While this wouldn't solve all the problems (to some extent, the sizes of 
files might be correlated, but this could probably be foiled by other 
means), wouldn't it at least foil the easy to/from traffic analysis that 
is (I believe) the greatest threat?

Jon
==============================================================================
                     Jon Lasser <jlasser at goucher.edu>
This is an advanced .signature virus -- please attach to your .signature and
add your last initial to the list: l
------------------------------------------------------------------------------






From samman at CS.YALE.EDU  Thu Feb  2 23:01:25 1995
From: samman at CS.YALE.EDU (Ben)
Date: Thu, 2 Feb 95 23:01:25 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
In-Reply-To: <199502022357.SAA28764@bb.hks.net>
Message-ID: <Pine.SUN.3.91.950203015859.20431A-100000@jaguar.zoo.cs.yale.edu>


On Thu, 2 Feb 1995, Gary Jeffers wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
>          THE FIREWALL CHIP!  U'RE PHONE ALWAYS OFFHOOK?
> 
>    We have potential bugging devices in all our houses - The telephone!
> Of course, when it is onhook, the microphone does not transmit... or
> does it? Would the phone have to be rewired to render it always
> "offhook" or would it be an operation at the central phone company?
> If the present models would have to be rewired, then how about future
> models? Much function is done thru chips & so could many of the models
> on the current market be remote programmable? See the latest issue of
> Mondo 2000.

Use an encrypted cordless phone.  When its not in use, take the battery 
out of the phone.  As long as the model you own doens't have a speaker 
phone you're cool.

If you start thinking that all phones that you buy have other hidden 
mikes in them, then I start wondering about paranoia.

Ben.






From rrothenb at ic.sunysb.edu  Fri Feb  3 00:20:26 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Fri, 3 Feb 95 00:20:26 PST
Subject: Adding padding to PGP files
In-Reply-To: <199502030438.WAA09561@eniac.ac.siue.edu>
Message-ID: <199502030820.DAA07843@libws4.ic.sunysb.edu>


> 
> > Date: Thu, 2 Feb 1995 08:48:49 -0800
> > From: Hal <hfinney at shell.portal.com>
> > 
> > It only works on binary ".pgp" public-key encrypted files (not ascii armored
> > files).  So there would be some work needed to make it a really useful tool.
> > 
> > Hal
> 
>   I just tried adding random characters at the end of a pgp ascii
> armoured message.  I had to cut out the checksum, but pgp was able to
> decrypt the message just fine.  So a very simple program (ideally with
> a strong source of random numbers) should be able to pad ascii
> armoured files.

Probably can calculate a new checksum too... or binary PGP, add junk
and mime/uu/xx-encode....?

Rob





From nobody at tower.techwood.org  Fri Feb  3 07:16:12 1995
From: nobody at tower.techwood.org (Anonymous)
Date: Fri, 3 Feb 95 07:16:12 PST
Subject: Why encrypt intra-remailernet.
In-Reply-To: <Pine.3.89.9502022036.D23979-0100000@vern.bga.com>
Message-ID: <199502031504.HAA15462@tower.techwood.org>


Nathan Zook <nzook at bga.com> wrote:
> Was this Detweiller's "exponentially growing message"?

Yes.

> Note that requiring pgp wrappers kills this...

No, just encrypt to multiple recipients.





From nsb at nsb.fv.com  Fri Feb  3 07:26:27 1995
From: nsb at nsb.fv.com (Nathaniel Borenstein)
Date: Fri, 3 Feb 95 07:26:27 PST
Subject: Remailing in safe-tcl
In-Reply-To: <5122.791772273.1@nsb.fv.com>
Message-ID: <MjAYfK70Eyt5AxSd8B@nsb.fv.com>


Excerpts from mail: 2-Feb-95 Remailing in safe-tcl Hal at shell.portal.com (2397)

> I don't see any straightforward way for a script to suspend itself and
> re-activate on some future event (such as the arrival of another
> message).  Maybe it could put its whole self into the config database as
> a {key, value} pair and rely on future messages to pull it out and
> execute it.  But that doesn't seem too great.

The problem is that this is a very hard -- perhaps impossible -- thing
to build in at the level of a safe-tcl interpreter, because the safe-tcl
interpreter is supposed to be a relatively stand-alone thing.  To
activate something based on a future event requires some hooks into
external event management -- e.g. a cron job, or the message receipt
facilities of a specific mail tool, etc.   The challenge, I think, is to
figure out how to make sure safe-tcl has the right hooks for such an
external environment without REQUIRING one particular such environment
in order to run safe-tcl.

In other words, I think the best to be hoped for is for safe-tcl to have
the facilities that are needed by such an environment.  I'm not entirely
sure what those facilities are, but I'm optimistic that this could be
layered on using the "declareharmless" mechanism of safe-tcl.  Thus, you
could write (in full tcl) a procedure that essentially queues an event
for future processing, and make that procedure available to the safe-tcl
environment.  Is this plausible in your application context?

> There is a lot of interest in this notion of mail messages as scripted
> agents which go zipping about the network gathering data which they send
> home.  I am optimistic that we will be able to get remailing capabilities
> out of this infrastructure largely for free.

I think there's a good chance of that, yes.  Part of the safe-tcl
experiment, actually, is the attempt to figure out, cooperatively, what
all is needed in the way of infrastructure.  So what I'm most interested
in knowing is whether there are features you can imagine adding to
safe-tcl that would make this easier to do on your end...  -- Nathaniel





From nobody at myriad.pc.cc.cmu.edu  Fri Feb  3 08:50:25 1995
From: nobody at myriad.pc.cc.cmu.edu (Anonymous)
Date: Fri, 3 Feb 95 08:50:25 PST
Subject: Remailer Unreliability
Message-ID: <m0raRHW-0006WvC@myriad.pc.cc.cmu.edu>


>From: anonymous-remailer at shell.portal.com
>  Well, *I* think it is a good idea.  But how does remailer1 know that
>remailer2 is both a remailer and down?

By attempting a connection to the SMTP port and using the alternate if
it fails?





From jltocher at CCGATE.HAC.COM  Fri Feb  3 09:12:52 1995
From: jltocher at CCGATE.HAC.COM (jltocher at CCGATE.HAC.COM)
Date: Fri, 3 Feb 95 09:12:52 PST
Subject: No Subject
Message-ID: <9501037918.AA791831560@CCGATE.HAC.COM>


     From Edupage:
     
     THE NEW ETHOS OF THE NET
     A professor at St. Cloud University in Minnesota calls for overhauling 
     business school curricula to stress ethical concerns in the electronic 
     age the same way they stress finance or economic theory. The end 
     result? "Information systems will be protected because most people 
     will no longer be willing to purposefully contaminate a program or 
     network; they will protect others' confidentiality, privacy, and 
     copyright as they protect their own; they will refuse to plagiarize, 
     fabricate, and perpetrate other types of fraud; and they will not 
     tolerate such activities in others." The alternative is bleak: "...We 
     will degenerate into secretive, encrypted, overly protective 
     information hoarders, unwilling to share and disseminate knowledge -- 
     except for profit." (Information Week 2/6/95 p.64) 
     
     But, how do you really feel...
     John

John L. Tocher                THE CITY-a bounded infinity.   A labyrinth where
JLTocher at earthlink.net        you are never lost. Your private map where every
PGP:  CE 72 1A 11 07 47 35    block bears exactly the same number. Even if you
35 9A C1 DE EA 64 21 BC 94    lose your way, you cannot go wrong.   --Kobo Abe








From anonymous-remailer at shell.portal.com  Fri Feb  3 09:15:23 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Fri, 3 Feb 95 09:15:23 PST
Subject: to hfinney
Message-ID: <199502031714.JAA01901@jobe.shell.portal.com>


mr finney , do you know if that perl prog of yours to add stuff to .pgp
files can be ported to messy dos ?
many thanx





From peb at netcom.com  Fri Feb  3 09:28:27 1995
From: peb at netcom.com (Paul E. Baclace)
Date: Fri, 3 Feb 95 09:28:27 PST
Subject: THROUGH THE LOOKING GLASS
Message-ID: <199502031709.JAA20821@netcom20.netcom.com>


Recently a relative of mine was battered/assulted in a park.  The
perp, after a personal item broke, called a friend at the police on 
his cel phone and an officer charged my relative for assault! The 
perp is also trying to sue for damages.  The relative is nearly at 
retirement age and the perp had 3 large attack dogs at the time.
This is a bad cop with a vindictive mentality and the court so far 
believes the cop. (My relative should be suing for psychological damages
after weeks of nightmares about being attacked and then betrayed
by the police and fear of retribution for pursuing justice.  This
is a very expensive process in money, time and emotions.)

A personal recording of what happened would make a lot of difference.

Paul E. Baclace
peb at netcom.com





From rishab at dxm.ernet.in  Fri Feb  3 09:54:26 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Fri, 3 Feb 95 09:54:26 PST
Subject: Tribes, cyberspace and the communication society
Message-ID: <gate.eiDZZc1w165w@dxm.ernet.in>


The Internet develops its own order...

Electric Dreams
Weekly column for The Asian Age by Rishab Aiyer Ghosh
#46, 30/January/1995: Tribes, cyberspace and the communication society

Industrialization brought with it many social changes.
Concentrating power in cities, it expanded the value of
property rights and built a complex formal legal system to
enforce them. It gave birth to the powerful police force
as the means for keeping law and order in the urban
population of gathered strangers, and, while spreading
democracy, distanced people from the process of
legislation that affected them. All this is going to
change as the information revolution engulfs the planet.
Perhaps surprisingly, the social changes to come will more
closely reflect humans as they interacted millennia ago,
rather than as they did in the more recent past.

Before industrialization, cities were much less important.
The village (in an idealized history) was the key social
unit, as the tribe was in pre-agricultural communities.
Economic power, being geographically distributed, resulted
in considerable control by people over the informal rules
that governed them and their immediate environment,
despite the absence of democracy as we now know it.
Property rights were lax, especially in tribal society;
villages placed great importance on common land. There was
correspondingly little emphasis on a police force or
formal law. Order was maintained primarily through systems
of social punishment - reputation and taboo.

As cities formed, the value of owned property increased,
as there was little sense of community or common benefit
among strangers. Crime increased, property rights became
important to enforce, and taboo was no longer an effective
preserver of order primarily because unlike villages, the
city is not what I call a communication society. People
don't depend on each other in cities as much as in
villages, nor does the threat of ostracization work, as
social interaction is a far greater component of rural
than urban life. Urban society needed, and developed,
modern forms of centralized law enforcement.

As mainstream media and the general public discover the
relative anarchy of the Internet, they take fright at its
apparent disorder and suggest the need for government if
cyberspace is to have a future - people fear freedom. At
least until they experience it - after all, the Net has
been around long before it became front-page news, and has
evolved its own, distributed, law. Based on principles of
total freedom of expression and a strong dislike of
irrelevant content outside clearly defined zones,
infractions are met sometimes by the guerrilla action of
spontaneous protest, sometimes by ostracization.

This works because cyberspace is also a communication
society. While McLuhan's Global Village has become
extremely cliched, in this aspect cyberspace does resemble
a village. People on the Net may not be dependent on each
other for food and clothing, but they are for almost
anything else concerned with a cyber life. Cyberspace is
full of vibrant communities that do little else but talk,
and with social interaction at a higher level than at any
time in history, it is well suited to a system of social
punishment such as taboo; indeed, this may become the only
practical form of wired justice, and could be very
effective - in cyberspace, if nobody talks to you, you're
dead.

The similarity to pre-industrial communities does not end
with modes of governance, but extends to basic issues of
economics. Property rights in the infosphere are
contentious; they keep getting more impractical to
enforce, and will play a diminished role in a post-
industrial world as technology and people work around
attempts at formal legislation. Without realizing it, the
denizens of the Net have already created a vast 'cooking-
pot' market in software, news and information, based on
the very tribal notion of shared property and benefit.
That government and industry will work with such
disorganized economies is extremely unlikely, but they are
so inherent to the communication society that cyberspace
is, that they will survive, though perhaps occasionally
going underground.

Technology and society go hand in hand, but sometimes
history repeats itself, if not without variation. Though
the realm of information forms but part of our lives, that
part will increase, and affect the rest. If we are a
communication society while in the ocean of information,
what might we be outside?

Rishab Aiyer Ghosh is a freelance technology consultant
and writer. You can reach him through voice mail (+91 11
3760335) or e-mail (rishab at dxm.ernet.in).
--====(C) Copyright 1994 Rishab Aiyer Ghosh. ALL RIGHTS RESERVED====--
 This article may be redistributed in electronic form only, PROVIDED 
 THAT THE ARTICLE AND THIS NOTICE REMAIN INTACT. This article MAY NOT 
 UNDER ANY CIRCUMSTANCES be redistributed in any non-electronic form,
 or redistributed in any form for compensation of any kind, WITHOUT 
PRIOR WRITTEN PERMISSION from Rishab Aiyer Ghosh (rishab at dxm.ernet.in)
--==================================================================--


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From rishab at dxm.ernet.in  Fri Feb  3 09:56:58 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Fri, 3 Feb 95 09:56:58 PST
Subject: Compromising the first remailer
Message-ID: <gate.0gDZZc1w165w@dxm.ernet.in>


Nathan Zook wrote:
> >notion of not assigning trust is simply nonsense. When you send a piece
> >of mail to a remailer, encrypted or not, you are assigning complete
> >trust in that remailer to keep you anonymous and not to forward your
> >mail to the NSA immediately.
>  
> NOT TRUE.  With proper use of encryption, you are trusting your first
> remailer only to not reveal that you sent a message, and not to correlate
> that message to the one it sends out.  With rational use of garbage running
> two deep, you can even suffer this loss without significant harm.
 
Actually any remailer, with NSA-modified operating software, can correlate the
message it receives to the one it sends out, by keeping track of the message
past any decryption until it's posted out. With rational use of garbage and
chaining, all you do is stop the NSA from knowing your final destination from
the first remailer, but they _would_ know the identity of the second remailer
(assuming the first is compromised) and could try to attack the second, ad
nauseum. Of course this was always known to be the problem, to which chaining
and traffic analysis evasion are partial solutions.


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From turcotte at io.com  Fri Feb  3 10:02:45 1995
From: turcotte at io.com (Brett Turcotte)
Date: Fri, 3 Feb 95 10:02:45 PST
Subject: 1995-02-02 President Names Members to Intelligence Commissi
Message-ID: <199502031802.MAA20515@pentagon.io.com>


<much snippage of press release naming commission members>
> 
> Attachment:
>      Biographic Information
> 
> 
> 
> 
> 
> 	      THE COMMISSION ON THE ROLES AND CAPABILITIES
> 	      OF THE UNITED STATES INTELLIGENCE COMMUNITY
>                             
<more snippage of bio information>

Anyone else notice all of the inside the beltway plus NYC area types 
on this list....anyone want to bet on how much "newly required" 
intelligence capabilities will come out of this commission...

Brett Turcotte
turcotte at io.com





From bdolan at use.usit.net  Fri Feb  3 10:24:21 1995
From: bdolan at use.usit.net (Brad Dolan)
Date: Fri, 3 Feb 95 10:24:21 PST
Subject: THROUGH THE LOOKING GLASS
In-Reply-To: <199502031709.JAA20821@netcom20.netcom.com>
Message-ID: <Pine.SOL.3.90.950203131758.22196B-100000@use.usit.net>


There really is a CP thread here.  

After you've had one of these experiences, you will not trust
authority any more.

I can't wait for the "good faith" exeception to the 4th amendment
to hit the streets.

bd


On Fri, 3 Feb 1995, Paul E. Baclace wrote:

> Recently a relative of mine was battered/assulted in a park.  The
> perp, after a personal item broke, called a friend at the police on 
> his cel phone and an officer charged my relative for assault! The 
> perp is also trying to sue for damages.  The relative is nearly at 
> retirement age and the perp had 3 large attack dogs at the time.
> This is a bad cop with a vindictive mentality and the court so far 
> believes the cop. (My relative should be suing for psychological damages
> after weeks of nightmares about being attacked and then betrayed
> by the police and fear of retribution for pursuing justice.  This
> is a very expensive process in money, time and emotions.)
> 
> A personal recording of what happened would make a lot of difference.
> 
> Paul E. Baclace
> peb at netcom.com
> 





From hfinney at shell.portal.com  Fri Feb  3 10:33:32 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 3 Feb 95 10:33:32 PST
Subject: to hfinney
Message-ID: <199502031832.KAA10617@jobe.shell.portal.com>


From: anonymous-remailer at shell.portal.com
> mr finney , do you know if that perl prog of yours to add stuff to .pgp
> files can be ported to messy dos ?
> many thanx

Perl does exist for ms-dos, and I think those scripts would probably work
OK there.  They don't do anything exotic, just some byte reads and
writes.  Maybe the random-number generation would need to be looked at;
as I said, that is the one weak part.  But probably they would work OK.
 
Hal





From sandfort at crl.com  Fri Feb  3 10:46:48 1995
From: sandfort at crl.com (Sandy Sandfort)
Date: Fri, 3 Feb 95 10:46:48 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
In-Reply-To: <199502030441.UAA17143@ix2.ix.netcom.com>
Message-ID: <Pine.SUN.3.91.950203103828.3246E-100000@crl.crl.com>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          SANDY SANDFORT
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C'punks,

On Thu, 2 Feb 1995, Dale Harrison wrote:

> . . .
> Actually, there is a germ of truth in this.  On older phones (don't know if 
> this works on newer electronic phones) when the handset is 'on-hook' a 
> switch opens and breaks the voice circuit.  This of course only works for 
> DC circuits.  If you drive that same circuit with an AC signal . . .

There's another angle I may have mentioned before.  Many 
electronic phones come with a ``feature'' that allows you to 
call home, produce an electronic tone and eavesdrop on your own
house.  When the tone is sounded, the ringing stops (or never
starts) and the phone goes into ``off hook'' mode (i.e., the
microphone in the mouthpiece is turned on).

Even if you did not buy this feature when you bought your phone,
it is still there, just waiting for that electronic tone.  You 
can't produce it, because you didn't buy the doohickey, but anyone
with such a doohickey can call your house and listen in. . .


 S a n d y

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






From tedwards at wam.umd.edu  Fri Feb  3 11:17:35 1995
From: tedwards at wam.umd.edu (Technoshaman Tom)
Date: Fri, 3 Feb 95 11:17:35 PST
Subject: Mugshot Identification Database announcement
Message-ID: <Pine.ULT.3.91.950203140756.10904D-100000@rac5.wam.umd.edu>


Heard elsewhere...

                 National Institute of Standards and Technology

                           announces the release of
                           NIST Special Database 18

                    Mugshot Identification Database (MID)

NIST Special Database 18 is being distributed for use in development and
testing of automated mugshot identification systems. The database consists
of three CD-ROMs, containing a total of 3248 images of variable size,
compressed with lossless compression. Each CD-ROM requires approximately
530 megabytes of storage compressed and 1.2 gigabytes uncompressed
(2.2 : 1 average compression ratio). There are images of 1573 individuals
(cases), 1495 male and 78 female. The database contains both front and
side (profile) views when available. Separating front views and profiles, 
there are 131 cases with two or more front views and 1418 with only one
front view. Profiles have 89 cases with two or more profiles and 1268 with
only one profile. Cases with both fronts and profiles have 89 cases with
two or more of both fronts and profiles, 27 with two or more fronts and
one profile, and 1217 with only one front and one profile. Decompression
software, which was written in C on a SUN workstation [1], is included
with the database.

NIST Special Database 18 has the following features:

	+  3248 segmented 8-bit gray scale mugshot images (varying sizes)
           of 1573 individuals
	+  1333 cases with both front and profile views (see statistics above)
	+  131 cases with two or more front views and 89 cases with two or
           more profiles
	+  images scanned at 19.7 pixels per mm
	+  image format documentation and example software is included

Suitable for automated mugshot identification research, the database can be used for:

	+  algorithm development
	+  system training and testing

The system requirements are a CD-ROM drive with software to read ISO-9660
format and the ability to compile the C source code written on a SUN
workstation [1].

Cost of the database: $750.00.

For ordering information contact:

                            Standard Reference Data
                National Institute of Standards and Technology
                            Building 221, Room A323
                            Gaithersburg, MD 20899
                             Voice: (301) 975-2208
                             FAX:   (301) 926-0416
                          email: srdata at enh.nist.gov

All other questions contact:
                            Craig Watson
		       craig at magi.ncsl.nist.gov
			    (301)975-4402


[1]  The SUN workstation is identified in order to adequately specify or
     describe the subject matter of this announcement. In no case does
     such identification imply recommendation or endorsement by the
     National Institute of Standards and Technology, nor does it imply
     that the equipment is necessarily the best available for the purpose.






From anonymous-remailer at shell.portal.com  Fri Feb  3 11:42:27 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Fri, 3 Feb 95 11:42:27 PST
Subject: re to hfinney
Message-ID: <199502031941.LAA18023@jobe.shell.portal.com>


hal sez:

: Perl does exist for ms-dos, and I think those scripts would probably work
: OK there.  They don't do anything exotic, just some byte reads and
: writes.  Maybe the random-number generation would need to be looked at;
: as I said, that is the one weak part. But probably they would work OK.

kool . could you please repost the scripts , i seem to have misplaced them.
also , where can i get perl for dos , any idea ? tia .





From jrochkin at cs.oberlin.edu  Fri Feb  3 11:42:44 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Fri, 3 Feb 95 11:42:44 PST
Subject: Compromising the first remailer
Message-ID: <ab58386301021004942b@[132.162.201.201]>


At 6:11 PM 02/03/95, rishab at dxm.ernet.in wrote:
>Actually any remailer, with NSA-modified operating software, can correlate the
>message it receives to the one it sends out, by keeping track of the message
>past any decryption until it's posted out. With rational use of garbage and
>chaining, all you do is stop the NSA from knowing your final destination from
>the first remailer, but they _would_ know the identity of the second remailer
>(assuming the first is compromised) and could try to attack the second, ad
>nauseum. Of course this was always known to be the problem, to which chaining
>and traffic analysis evasion are partial solutions.

Yes, but as long as _one_ remailer in your chain is not compromised by the
NSA, and if that one remailer has high enough traffic going through it and
does the proper things with reordering and latency and such (a big "if",
currently), you're still safe.

That turns out to be the whole purpose of chaining, since it has been shown
that it doesn't neccesarily make traffic analysis any harder.  The purpose
is to hope that at least one link on your chain is both honest and properly
working.  Yeah, if all the links on your chain are NSA-sponsored, your in
trouble.  Nothing that can be done about that.







From eric at remailer.net  Fri Feb  3 11:52:36 1995
From: eric at remailer.net (Eric Hughes)
Date: Fri, 3 Feb 95 11:52:36 PST
Subject: Remailer encryption module
In-Reply-To: <9502030123.AA02022@josquin.media.mit.edu>
Message-ID: <199502031942.LAA15031@largo.remailer.net>


   From: Derek Atkins <warlord at MIT.EDU>

   > I agree.  PGP just does not have the support for the encryption
   > required for mixing remailers.

   How
   is PGP deficient?  What do you need PGP to do in order to get it to
   work right with remailers?

Note that I said mixing remailers, not just regular remailers.

-- No support for random padding to a fixed length.  Yes, this can be
patched by script.  Hell, you could rewrite PGP with a script, so the
existence of a workaround is no defense.

-- Message size blowup for encrypted armor-within-armor.  Yes, I know
it compresses, but it would be a better thing to get PGP to unpack a
PGP encrypted message (the message to the next hop) to multipart form,
part regular text, part armored.

-- Inability to restrict PGP from accepting a non-encrypted message.
PGP run on an armored plaintext file will work just as if it were
encrypted.  This precludes being able to require encryption as a site
policy.  (Again this can probably be worked around; again, not an
excuse.)

In addition, there's a few really bad misfeatures for pseudonymity
(which is what everyone seems to want to do with remailers):

-- Identities for secret keys are in cleartext in the secret key ring.
Upon seizure of a secret key ring, presence of a pseudonym name can be
considered a presumption of possession of a corresponding secret key,
simply because people don't fill up their secret key rings with bogus
keys with other people's names.

-- Key ID of the recipient is always in the clear.

-- The RSA-encrypted session key does not have a flat representation
over its multiword container.  This yields a statistical traffic
analysis hole.  (This point is irrelevant without fixing 4.)  Hal and
I completely solved this problem last year.


This is all I can think of off the top of my head.  Not having
analyzed the problem recently, I can't say that I've got everything.

Eric





From jya at pipeline.com  Fri Feb  3 13:12:51 1995
From: jya at pipeline.com (John Young)
Date: Fri, 3 Feb 95 13:12:51 PST
Subject: NYT on Jihad
Message-ID: <199502032112.QAA08358@pipe4.pipeline.com>



   The New York Times
   February 3, 1995, p. A19


   [Column] On My Mind


   A. M. Rosenthal


   Jihad in America


   The Clinton Administration has come to two major
   conclusions about terrorism in America, and from America.


   The first is that the United States is becoming a
   national safe haven for terrorists from the Middle East:
   a combination bank, fund-raiser, militarist training
   ground, recruitment center, political academy and
   embarkation dock.


   Second conclusion: Do something. So one recent night,
   instructions from Washington went out to banks nationwide
   to freeze the funds of the various Hamas Hezbollah and
   Islamic Jihad units, and their clones, operating from the
   East Coast to Texas and California. Mr. Clinton did that
   by Presidential order.


   Now the Administration is asking Congress to pass new
   anti-terrorist legislation. It would enable the
   Government to trace funds to and from the
   terrorist-supporting groups, tighten the definition of
   terrorism, enlarge the powers of Federal attorneys to
   deal with it and make it illegal to plan or train for
   terrorism abroad as well as in the U.S.


   The draft legislation is called the Omnibus
   Counterterrorism Act of 1995. It was drawn up by the
   Department of Justice on Presidential order and will be
   introduced in Congress in a matter of days.


   For Americans who have been warning about terrorism
   operating in and out of America, the time to relax has
   hardly arrived. We will see how effective it is in ending
   the contribution to terrorism of American laws and
   American inattention.


   But the fact is that the Clinton Administration has begun
   to pay more attention to the growth of terrorist
   organizations here than its predecessors have. And in
   parts of the government intelligence machinery, the
   assessment of the danger of terrorism originating in
   America is strong enough to surprise even anti-terrorism
   alarm ringers like myself.


   In large part, the awakening can be credited to the
   terrorists themselves. Even for America, blowing up the
   World Trade Center was a little thick.


   But the next time you get all worked up about the
   dastardly press, do remember that in the matter of
   terrorism, as so many others, it was an American
   journalist whose skill, determination and risk-taking
   (physical and professional) helped shake government
   awake.


   On Nov. 21, 1994, PBS presented "Jihad in America." The
   documentary laid it all out on film -- the meetings in
   American cities where the cry of holy war went up against
   America, Christians, Jews and Muslims who would not
   surrender to fundamentalism; the training; the visits to
   American units by Middle Eastern leaders of Hamas and
   Islamic Jihad, and the fund-raising structure that
   supported terrorism.


   The executive producer was Steven Emerson, an
   investigator of terrorism who has turned out a strong
   body of work in film, books and print journalism. Among
   government officials I talked to, credit for Mr. Emerson
   was not only acknowledged but volunteered.


   Democracy often has a tough time defending itself because
   it has to operate step by step, inch by inch, under the
   law. Yes, of course, that is democracy's blessing and
   strength.


   But nothing says a democracy has to watch the bombers
   come racing in their trucks and pretend they are
   bicyclists out for a ride in the park. Laurie Mylroie,
   the U.S. expert on Iraq who wrote a fine best seller on
   Saddam Hussein with Judith Miller, has written another
   book, focusing on the question of an Iraqi role in the
   bombing. It deserves to be published wide and soon.


   The Emerson documentary brought protests from American
   Muslim groups. So will the new legislation. Immediately,
   non-Muslims nod sypathetically and think, well, it's
   understandable Muslims will be upset. I almost did
   myself. But why? Christians are not expected to complain
   about denunciation of Christian Fascists. Jews around the
   world led the protests of the massacre at the mosque in
   Hebron and Jews generally did not protest the President's
   freezing of funds of two extremist Jewish groups.


   The assumption that all Muslims must be angry at action
   against Muslim terrorists strengthens the killers. It
   demeans the intelligence of all Muslims. And, as for the
   hundreds of thousands of Muslim victims who died under
   Muslim state tyranny or Muslim state-supported terrorism,
   it spits on their graves.


   END






From turner at telecheck.com  Fri Feb  3 13:42:54 1995
From: turner at telecheck.com (Joe Turner)
Date: Fri, 3 Feb 95 13:42:54 PST
Subject: re to hfinney
In-Reply-To: <199502031941.LAA18023@jobe.shell.portal.com>
Message-ID: <9502032142.AA17527@TeleCheck.com>


> 
> hal sez:
> 
> : Perl does exist for ms-dos, and I think those scripts would probably work
> : OK there.  They don't do anything exotic, just some byte reads and
> : writes.  Maybe the random-number generation would need to be looked at;
> : as I said, that is the one weak part. But probably they would work OK.
> 
> kool . could you please repost the scripts , i seem to have misplaced them.
> also , where can i get perl for dos , any idea ? tia .
> 
> 

PERL can be obtained via anon FTP:

 ftp.uu.net			137.39.1.9
 archive.cis.ohio-state.edu  	128.146.8.52
 jpl-devvax.jpl.nasa.gov  	128.149.1.43

Get the source code and start compiling... :>

-- 
Joe N. Turner		Telecheck International
turner at telecheck.com    5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659
compu$erv: 73301,1654	(800) 888-4922  *   (713) 439-6597
Finger for PGP KEY.  MicroSoft SNA Server SUCKS.. buy it at your own risk.




From chen at intuit.com  Fri Feb  3 13:58:56 1995
From: chen at intuit.com (Mark Chen)
Date: Fri, 3 Feb 95 13:58:56 PST
Subject: Lucky primes & omlets on my face...
In-Reply-To: <199502020213.SAA17094@jobe.shell.portal.com>
Message-ID: <9502032157.AA04050@doom.intuit.com>



> > Recall:  x^p = x mod p therefore, x^(p-1) = 1 mod p. So what we need is:
> > (x^e)^d = x^ed = x^(p-1)*i+1 = x mod p.  
> 
> This would only be true for prime p, but with RSA we are dealing with
> composite moduli.  What we want is ed=1 mod phi(n), where
> phi(n)=(p-1)(q-1).  (Actually you want to use (p-1)(q-1)/gcd((p-1),(q-1)).
> I forget what that is called.)

"Least common multiple," or LAMBDA(n).


--
Mark Chen 
chen at intuit.com
415/329-6913
finger for PGP public key
D4 99 54 2A 98 B1 48 0C  CF 95 A5 B0 6E E0 1E 1D




From rrothenb at ic.sunysb.edu  Fri Feb  3 14:00:10 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Fri, 3 Feb 95 14:00:10 PST
Subject: The FIREWALL CHIP. U're phone always offhook?
In-Reply-To: <Pine.SUN.3.91.950203103828.3246E-100000@crl.crl.com>
Message-ID: <199502032159.QAA12943@libws4.ic.sunysb.edu>


>From a couple of folx....

> > Actually, there is a germ of truth in this.  On older phones (don't know if 
> > this works on newer electronic phones) when the handset is 'on-hook' a 
> > switch opens and breaks the voice circuit.  This of course only works for 
> > DC circuits.  If you drive that same circuit with an AC signal . . .
> 
> There's another angle I may have mentioned before.  Many 
> electronic phones come with a ``feature'' that allows you to 
> call home, produce an electronic tone and eavesdrop on your own
> house.  When the tone is sounded, the ringing stops (or never
> starts) and the phone goes into ``off hook'' mode (i.e., the
> microphone in the mouthpiece is turned on).
> 
[ Snip! ]

A simpler solution is to keep the phone in another room used mainly for
phonecalls, or even in a small office if you don't make an sounds there
worth evesdropping on. (The really paranoid can soundproof/tempest-proof
the room....)






From greg at ideath.goldenbear.com  Fri Feb  3 14:29:55 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Fri, 3 Feb 95 14:29:55 PST
Subject: Remailer Unreliability
Message-ID: <199502032132.AA09239@ideath.goldenbear.com>


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

>>  Well, *I* think it is a good idea.  But how does remailer1 know that
>>remailer2 is both a remailer and down?
>
>By attempting a connection to the SMTP port and using the alternate if
>it fails?

This depends on a significant change in remailer features - existing
remailers don't do message delivery, they pass remailed messages off 
to the local MTA (e.g, sendmail, Smail, whatever) and let it take
care of delivery. Expecting remailers to handle queueing and delivery
adds lots of code and complexity. (It also may piss off sysadmins who
aren't remailer operators. Bogus or not, some institutions frown on
attempting mail delivery manually or with non-standard programs.)

Also, it's difficult to say when delivery has failed. Not every failure
(where failure = not delivered in a reasonable time) results in a
bounce message; if the sending remailer can't determine success or
failure immediately, it will have to keep a database of the last few
(hundred, probably) primary/alternate address pairs, and then 
extract the failed message from the bounce message, then reprocess 
with the alternate address. Yuck. 

I think the easiest way to do this would be for remailers to have a
list of "unavailable remailers", and to process the primary/alternate
choice immediately upon receipt/resending - but if we have a good way
to provide the remailers with availability information, we've probably
found a good way to provide it to users, too.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzKgyH3YhjZY3fMNAQHlkwP7Bj5D5PbC1H+x3XXqP3gdUTTL6eLMjt2d
6cmj/kr0nv88XwXkIttj7r4wSDRXSe8K4mpU4utNQ1l+RlArDzZLkiY/qleuRhGX
yRplXo6eoNwSv24oBCIVwdu7r+gnlhVs4sU3tzkWD+deOQxVXffdPL0opZ1Cn8v6
qRmKmuOYFB8=
=i/8j
-----END PGP SIGNATURE-----




From eric at remailer.net  Fri Feb  3 15:14:54 1995
From: eric at remailer.net (Eric Hughes)
Date: Fri, 3 Feb 95 15:14:54 PST
Subject: MX'ing and jpunix.com
In-Reply-To: <199502022127.PAA14199@jpunix.com>
Message-ID: <199502032312.PAA15531@largo.remailer.net>


   From: "John A. Perry" <perry at jpunix.com>

	   Additional masking can be provided by having the MX record point
   to myriad.pc.cc.cmu.edu. What good does this do? I have an agreement with
   myriad.pc.cc.cmu.edu (Matt Ghio) where myriad will take the MX-pointed
   record and additionally alias it through the smail daemon on myriad. 

This is the beginning of private name service.  The machines behind
this MX record are not particularly visible to the outside.  Given the
existence of such machine, it makes sense to consider giving them
names which are also not too visible from the outside.

A group of remailer operators who had access to the DNS setups on
their machines could create their own personal top-level domain.  For
sake of discussion, let's call it ".cp".  Now random Unix boxes on the
Internet won't be able to gain access to .cp addresses, but the
remailer club would.  Outside parties would be able to be shown .cp
addresses but would not be able to resolve where the machines actually
were on the Internet, much less find them IRL.  (Access control on who
can pull .cp records will have to be added the the DNS software in
order to do this.)

Consider this in the light of Matt Ghio's MX service.  Matt MX's for
the alias.net addresses.  Inside alias.net, the individual remailers
could use .cp addresses to talk to each other.  In fact, those who
want zero contact with the outside world could advertise only .cp
addresses and mail only to other .cp addresses.

For sake of experimentation, I've set up a primary top-level
nameserver here on my machine for ".cp".  In order to access it,
you'll need to act as a secondary name server for the domain.  Hacking
alternate roots into BIND comes later.  Just add the following line to
your named.boot file:

    secondary       cp      204.94.187.1    db-secondary.cp

If you do this, you'll be able to ask for a second-level domain.
If you want a .cp domain, send mail to

    hostmaster at ndip.cp

Tell the kind hostmaster what name you want, what you want it for,
where you name servers are, etc.  This is an experimental service and
is not guaranteed to be reliable.  It might also serve as a test bed
for doing cryptographic name service trials.

Eric





From wcs at anchor.ho.att.com  Fri Feb  3 15:16:13 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Fri, 3 Feb 95 15:16:13 PST
Subject: VoicePGP cracked in 10 minutes?...
Message-ID: <9502032249.AA04577@anchor.ho.att.com>


> > I heard a rumor hear in Ctl. Tx. that the VoicePGP project was cracked in the
> > last couple of days in approx. 10 minutes. Anyone have any info on this other
> > than one of those wild rumors that occur?
> 
> Considering that VoicePGP hasn't even been released, this is
> fascinating news. Perhaps the same team could work next on cracking
> things that haven't even been invented yet.

Cracking VoicePGP is easy, since it's still a bones version without
the encryption installed yet - anybody who can figure out where
to get the software should be able to do it.  Might take more than
10 minutes to do that :-)

However, the rumor mostly sounded like a pro-active version of the
"NSA cracked PGP" version of the FBI Modem Tax on Religious Broadcasting
put out by Madeline Murray O'Shergold.





From wcs at anchor.ho.att.com  Fri Feb  3 15:24:04 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Fri, 3 Feb 95 15:24:04 PST
Subject: Is the remailer crisis over?
Message-ID: <9502032313.AA04793@anchor.ho.att.com>


> Well folks as of 11:30 on 1-30-94 there are 14 remailers with uptimes
> greater than 99%. What's the consensus...Is the remailer crisis over?

The "remailers are broken" crisis may be over, but until there
are a lot of remailers in service, and 14 isn't a lot,
with a lot of traffic on them, remailers won't be a very effective
security tool.  

If the Bad Guys wanted to watch all 14 remailers,
it'd probably not be hard to figure out which messages came from
which senders, just because there aren't enough for real tracking.
If the Bad Guys decided to confiscate 14 remailers, they could do it.
If your machine got busted or sued for sending an anonymous message somebody
didn't like, and you contended that you're a remailer and there was
no way to prove it originated on your machine, "they" could respond that
you're not one of the 14 well-known remailers and if you were "they"
would have been watching you because they watch every machine that
talks to the well-known remailers, and you're not one of them.

As the folks in the nuclear-war planning business say, fewer than
100 of anything isn't reliable.  

		Bill





From rchcnslt at epix.net  Fri Feb  3 16:11:52 1995
From: rchcnslt at epix.net (rchcnslt at epix.net)
Date: Fri, 3 Feb 95 16:11:52 PST
Subject: AIR Mosaic Feedback Mail
Message-ID: <199502040009.AA26622@relay.interserv.com>


Mail sent from AIR Mosaic (16-bit) version 3.07.04.02 

howdy..
Cyperpuk, life and all that..

Lemme in on the cool poop!

Rick R.





From hfinney at shell.portal.com  Fri Feb  3 18:45:45 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 3 Feb 95 18:45:45 PST
Subject: re to hfinney
Message-ID: <199502040245.SAA05320@jobe.shell.portal.com>


From: anonymous-remailer at shell.portal.com
> kool . could you please repost the scripts , i seem to have misplaced them.
> also , where can i get perl for dos , any idea ? tia .

Rather than re-post them, I put a copy of my message up for ftp at the
cypherpunks ftp site.  <URL:
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/incoming/pgppad.scr >





From wcs at anchor.ho.att.com  Fri Feb  3 19:58:31 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Fri, 3 Feb 95 19:58:31 PST
Subject: commercial authecation
Message-ID: <9502032329.AA04966@anchor.ho.att.com>


Keith Henson asked how to find the digital-time-stamp folks,
Surety Technologies Inc., started by Stuart Haber and Scott Stornetta 
as a spinoff of Bellcore.

They're now actively in business - there was an article in one of the 
trade rags that you can get their signature kit for PCs for
something like $50 with tokens for 50 notarizations.
Details on their web page.

email: info at surety.com  
www: http://surety.com  - with lots of little graphic icons :-(
ftp: surety.com 

			Bill





From werewolf at io.org  Fri Feb  3 21:09:35 1995
From: werewolf at io.org (Mark Terka)
Date: Fri, 3 Feb 95 21:09:35 PST
Subject: Wired Institutes PGP Usage For Subscriptions....
Message-ID: <8ajClOwscU-H077yn@io.org>


Got this message in my mailbox a week after I posted the query of magazine
subscriptions via encrypted cc #'s. I'll check it out tonight, as I want to
order a subscription for a friend.
===========================================================================






From weidai at eskimo.com  Fri Feb  3 21:59:13 1995
From: weidai at eskimo.com (Wei Dai)
Date: Fri, 3 Feb 95 21:59:13 PST
Subject: commercial authecation
Message-ID: <199502040558.AA15052@mail.eskimo.com>


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

> Keith Henson asked how to find the digital-time-stamp folks,
> Surety Technologies Inc., started by Stuart Haber and Scott Stornetta 
> as a spinoff of Bellcore.
> 
> They're now actively in business - there was an article in one of the 
> trade rags that you can get their signature kit for PCs for
> something like $50 with tokens for 50 notarizations.
> Details on their web page.

This technology is very clever and bound to be extremely important.  
But does anyone else think that the price is a little high?  I mean 
the marginal cost can't be more than a few seconds of CPU time for 
each time stamp...

This price tag will temporarily put the time stamp technology out of 
ubiquitous use, where every piece of e-mail, homework paper, Usenet 
post, etc., is automaticly time stamped in a cryptographically secure 
way so that authorship can be asserted and proved.  I think the 
need for proof of authorship is going to become increasingly important 
in an increasingly online world, where copying is so effortless, and 
reputations are based on digital identities.

Wei Dai

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzMXKDl0sXKgdnV5AQFA+gP/XcrjAncBMVqocpXYfAaBR7RJ2PDR4ZF/
TEgCPcPM7we4eoR5w++7V+jsBhtNRSng5OUCeKQWSCU8BDnkUXuQNpQ8+fNKciMS
RQWn1PBx4carczVOJoNyR1U8Rxu9tIH0Drh/NIZJ4324azpMOd8ysVFkJ4QODCPu
07Bf7pZ36c0=
=tAcu
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From tjb at acpub.duke.edu  Fri Feb  3 22:11:13 1995
From: tjb at acpub.duke.edu (Tom Bryce)
Date: Fri, 3 Feb 95 22:11:13 PST
Subject: IMPORTANT: BUG IN 68K IDEA ASSEMBLER DISTRIBUTED IN SECURE EDIT
Message-ID: <v01510102ab58c9039fd6@[152.3.113.8]>


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


IMPORTANT NOTE:

If you are going to use the IDEA 68k assembler distributed with Secure Edit
b0.5, please take note of the following bug:

You have to change

@Mulzero3:
        neg.w   d7 <---
        addq.w  #1,d5
        sub.w   -2(a1),d5
        bra.s   @Muldone3

to:

@Mulzero3:
        neg.w   d5 <---
        addq.w  #1,d5
        sub.w   -2(a1),d5
        bra.s   @Muldone3


I have not yet received any reports of data being fouled up by this, and
before tonight personally had encrypted and decrypted megabytes without
error, but note that I HAVE FOUND EXAMPLES OF IT FOULING UP A BLOCK OF
DATA. IT IS DANGEROUS TO USE THIS CODE IN ITS PRESENT FORM. Please make
note of this if you are going to use this 68k code.

Currently, I do not believe this code is being used anywhere except Secure
Edit b0.5, although it was certainly about to be used. I will immediately
upload a corrected version of Secure Edit and source.

Sorry about the screw up.

Tom



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzMbp1uwJA7oL8O9AQGk0wP/YF8VQ2jDtW63Wb7fteImBvYCfMi7NnTf
tXMBV6U5iIKf+iBoED34gnwJyLAdEplpMa6P1yJUIMjNXly1/I+SzQoMFGVXuuKV
m0h+idXI1mXTVG+gnmdpGMw9/6/u72DcaYCZRHveL8tuMesO5UdgQEDjvy+zX7+c
0cAvyXQaArg=
=ubXB
-----END PGP SIGNATURE-----







From tjb at acpub.duke.edu  Sat Feb  4 00:01:00 1995
From: tjb at acpub.duke.edu (Tom Bryce)
Date: Sat, 4 Feb 95 00:01:00 PST
Subject: FIXED SEC. EDIT, SEC. EDIT SOURCE, UPGRADE PATCH
Message-ID: <v0151010aab58e5d06317@[152.3.113.8]>



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


I have uploaded a fixed version of both secure edit and source code to
ripem.msu.edu in the directory pub/crypt/mac.

I have also uploaded a 35k patch that will update your b0.5 to b0.6.

There are also some other minor bugfixes rolled into this b0.6 update.

Again, sincere apologies for the bug (it was my fault), and I earnestly
hope no data was compromised by it.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzMx/1uwJA7oL8O9AQHHegP9FPCkO2fVO54Vm3kDTsJH+1SW5Iui3wTS
F4BvZ0CSzJTw8K15oYOVnVbYcqofoOe5DvmR4ex1kK7zPObicfwLeIQbcvnRbBuI
0xpk+ymOMgOzjd9ySusXNuTCuwomQHXD4jTuyEsU+QrT6FEkmUJjA+TtctAZu7JX
nbZGDtOD/18=
=xKnR
-----END PGP SIGNATURE-----







From nowhere at bsu-cs.bsu.edu  Sat Feb  4 02:22:46 1995
From: nowhere at bsu-cs.bsu.edu (Anonymous)
Date: Sat, 4 Feb 95 02:22:46 PST
Subject: <none specified>
Message-ID: <199502041019.FAA17058@bb.hks.net>


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

I wonder if 'Net-cash' is any good?  Try sending e-mail to
netbank-info at agents.com
with the words netbank-intro on the first line of body.

It says:

        The NetBank ...is based on "payment coupons" that may be traded
        via electronic mail ... NetCash is easily obtained by using the
        NetBank's "Check Cashing by FAX" service.  Customers may
        purchase NetCash by writing a personal check and faxing it to
        the NetCash Distribution Center.  Travelers on the Infobahn may
        carry NetCash and cash checks while online.

and lots more. Does not look too anymous, however, and there is no
mention of PGP in the documents I got.  But do check it out.

When you get the info, they give you 5 cents worth of NetCash, BTW.
They also have other stuff:

        For information on related topics, please send e-mail to
        "netbank-info at agents.com" with the following keyword(s) in the
        message:

    Keyword                         Topic

  netbank-faq         Answers to frequently asked questions
  buying-netcash      How to buy NetCash from the NetBank
  netbank-merchant    Opening a NetBank Merchant account
  shareware-info      Using the NetBank to collect shareware fees
  boardwatch-story    Reprint of NetCash story from Boardwatch Magazine
  story-update        Enhancements since the Boardwatch story was published

- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzNURyoZzwIn1bdtAQFwJwF+KeI9ErF2N04Y1+XwX4B6teBDlIudSuip
uNhn0k80uoru/vIWb//WMiMCBFHT+Bww
=39YD
-----END PGP SIGNATURE-----





From rrothenb at ic.sunysb.edu  Sat Feb  4 03:01:39 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Sat, 4 Feb 95 03:01:39 PST
Subject: Wired Institutes PGP Usage For Subscriptions....
In-Reply-To: <8ajClOwscU-H077yn@io.org>
Message-ID: <199502041101.GAA29832@libws4.ic.sunysb.edu>


> 
> Got this message in my mailbox a week after I posted the query of magazine
> subscriptions via encrypted cc #'s. I'll check it out tonight, as I want to
> order a subscription for a friend.

[ clip ]

> In article <v4cAlOwscUg6077yn at io.org>, werewolf at io.org (Mark Terka) wrote:
> 
> > .....if it is sooooooo hooked in the online culture have a PGP public key
> > that 'net users could use to send in their credit card numbers for
> > subscriptions?
> 
> 
> Here it is. We're just implementing it. Send us a message (send to
> talk2subs at wired.com)

[ clip ]

Neato. I'm tempted to send 'em a message saying "Where's the crime?!"...





From habs at panix.com  Sat Feb  4 05:59:04 1995
From: habs at panix.com (Harry S. Hawk)
Date: Sat, 4 Feb 95 05:59:04 PST
Subject: Forward: Teleco/Cabe REg. & Free speech
Message-ID: <199502041358.AA09885@panix.com>


TELECOM REFORM, REPUBLICAN-STYLE Sen. Larry Pressler (R-SD) has
proposed a telecommunications reform plan that would drop all cable TV
rate regulations; allow local phone and cable competition and
cross-ownership in one year; ease foreign ownership restrictions; and
allow local phone companies to compete in long distance in three
years. A formal counter proposal is expected from the Democrats
February 14, and it's expected that there will be objections to most
of the provisions outlined in Pressler's bill. (Investor's Business
Daily 2/2/95 A4)

(((cut here)))

For those that don't know I have my Master's in Interactive
Telecommunications, and have long looked at cable and teleco from
several angles including freemarket and cypherpunk viewpoints.

While there is a lack of detail here, I strongly endorse anything that
lets cable and phone companies compete. They have largely the same
customer base (although telco's have a larger % of the base), but the
cable companies are in a better opportunity to over PCS,
higher-bandwidth networking, and video on demand.

What we have to watch out for is FCC regulation. It is well excepted
that the FCC can censor commercial speech (cig. ads), and individual
speech (the 7 dirty words), in the "public" interest.

Cable and Teleco are FCC regulated. If they provide the network of
the future, as opposed to UUnet-Microsoft (for example), we might
have to be careful..

The "model" of interactivity most "thinking" people endorse is one
that is two way. The FCC does really monitor what you say on the phone
(although who knows about the NSA ;)... If you can in the brave new
Telco/Cable future send as well as receive.. and send in
broadcast-like mode... are you subject to content approval from the
FCC?

We should strongly endorse this move by. Sen. Pressler as it will
get us broadband to many homes in 5 to 7 years, but we have to
remain concerned about our freedom to speak not matter if that is
one on one, or to a large group!

/hawk


-- 
Harry S. Hawk  		   habs at panix.com
Product Marketing Manager
PowerMail, Inc. 	   Producers of MailWeir(tm) & PowerServ(tm)




From mjwohler at netcom.com  Sat Feb  4 06:26:35 1995
From: mjwohler at netcom.com (Marc Wohler)
Date: Sat, 4 Feb 95 06:26:35 PST
Subject: NYC CPUNKS MEET NEXT SAT
Message-ID: <199502041425.GAA29475@netcom15.netcom.com>


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

Attn.: New York City area Cypherpunks

NYC C'punks meeting:

Sat Feb 11, 3:00 P.M., at the home of Linn & Barbara  Stanton
315 West 106 Street  Apt 2A 
(Between West End Ave & Riverside Drive)
212-316-1958.

Once again the gracious Stanton's invite local area Cpunks to
their lovely home which is smoke free and feline friendly.

The agenda is still open and suggestions can be made to
mjwohler at netcom.com
or phone Marc Wohler @ 212-362-0690. Let me know if you plan to
attend.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLy+PL2eikzgqLB7pAQGHigP9HW1Py30O2fcZH/f1SAOToOBZYVZMiB9c
buGQrujaicGVJlvGb1Le/OjJ872JB69BQD1MMsemABSYi4swL15w9qj1rhoTAHIg
yTRDFJD16g1lqqLvEJZ0RijOh1dXLaUg8HNue0JoSAbARkQed8I3+mklP4C4saYn
qW2Fa/kDuZY=
=Rl9C
-----END PGP SIGNATURE-----




From rah at shipwright.com  Sat Feb  4 07:31:56 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Sat, 4 Feb 95 07:31:56 PST
Subject: <none specified>
Message-ID: <v01510100ab5909e219ad@[199.0.65.105]>


At 5:19 AM 2/4/95, Anonymous wrote:
>I wonder if 'Net-cash' is any good?

Probably the best discussion of the available transaction
processing/settlement mechanisms is by Jason Solinsky. It's called "An
Introduction to Electronic Commerce", and though he probably hasn't updated
it since he wrote it a few months ago, he discusses NetCash there...


http://nearnet.gnn.com/gnn/meta/finance/feat/sol.html

Take a bow, Jason.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From tjb at acpub.duke.edu  Sat Feb  4 09:05:15 1995
From: tjb at acpub.duke.edu (Tom Bryce)
Date: Sat, 4 Feb 95 09:05:15 PST
Subject: signature validation on secure edit messages
Message-ID: <v01510106ab5965a112c3@[152.3.113.8]>


Jeez. I really don't know why the heck this always happens to me, my
digsigs not validating.

You can finger me at tjbryce at amherst.edu to retrieve a message with a valid
signature.

I always write the message in eudora, copy it, sign it in MacPGP as TEXT
with attached signature, then go back and paste it over the old message.
Then I go back to MacPGP and check the signature on the clipboard to be
sure - no problems. But after getting mailed, it doesn't work.

Damn.

Tom







From hfinney at shell.portal.com  Sat Feb  4 10:11:09 1995
From: hfinney at shell.portal.com (Hal)
Date: Sat, 4 Feb 95 10:11:09 PST
Subject: There is another NetCash
Message-ID: <199502041810.KAA20164@jobe.shell.portal.com>


From: rah at shipwright.com (Robert Hettinga)
> At 5:19 AM 2/4/95, Anonymous wrote:
> >I wonder if 'Net-cash' is any good?
>
> Probably the best discussion of the available transaction
> processing/settlement mechanisms is by Jason Solinsky. It's called "An
> Introduction to Electronic Commerce", and though he probably hasn't updated
> it since he wrote it a few months ago, he discusses NetCash there...

People interested in NetCash should be aware of a potentially confusing
name re-use.  NetCash is also the name of a payment system designed by
people associated with the Information Sciences Institute (affiliated, I
think, with USC).  A reference is: <URL:
ftp://PROSPERO.ISI.EDU/pub/netcheque/information/netcash-cccs93.ps.Z >
 
Despite the names, neither one is cash in the cryptographic sense:
neither uses blinding.  If you didn't want the bank to be able to create
a database of every transaction you make, everything you spend and with
whom, you would need to have some anonymous connection with the bank and
exchange your netcash through that connection.  This would be cumbersome
IMO.  Some payment system is probably better than none, but I hate to see
the name "cash" expropriated by these non-cash systems.
 
Hal





From hfinney at shell.portal.com  Sat Feb  4 10:17:03 1995
From: hfinney at shell.portal.com (Hal)
Date: Sat, 4 Feb 95 10:17:03 PST
Subject: PGP padding scripts (again)
Message-ID: <199502041816.KAA20644@jobe.shell.portal.com>


Sorry for the bandwidth waste, but my anonymous correspondent was not
able to ftp these scripts.  I also got another request for the scripts.
So here again is my post with a pair of perl scripts which will insert
padding pretty much undetectably into a .pgp file.  The one limitation is
the quality of Perl's random number generator.



Here are a couple of perl scripts I wrote last year to add padding to PGP
encrypted files.  The usage would be:

perl pgppadt.pl filename bytestoadd

The output file is filename.pad.

It only works on binary ".pgp" public-key encrypted files (not ascii armored
files).  So there would be some work needed to make it a really useful tool.
It would also be better to use a strong source of random numbers.  I
think Carl Ellison recently posted some tools that could help with this.
The two files are pgppad.pl, which does the work, and pgppadt.pl, a very
simple test driver to show how to use it.  They are in a shar archive.

Hal

---------------cut here----------------
#!/bin/sh
# to extract, remove the header and type "sh filename"
if `test ! -s ./pgppad.pl`
then
echo "writing ./pgppad.pl"
cat > ./pgppad.pl << '\End\Of\Shar\'
# Perl module to allow padding and some other manipulation of PGP
# files.
#
# Include this with the statement:
# require 'pgppad.pl'
#
# 10/16/93
# Hal Finney


# Read a PGP Cipher Type Byte and the following length.
# One argument: file to read from
# Returns several things, in this order:
# CTB, with the length information removed, as a number.
# Length of following packet.
# Name of this kind of packet, made up, see list below.
# Packed CTB/length packet, suitable for writing out.
# Returns an empty string on error.
sub read_ctb {
    local($file) = @_;
    local($ctb, $length, $name, $rctb, $rlength, $lengthlength);

    if (read ($file, $rctb, 1) != 1) {		# Raw ctb
	return "";
    }
    $ctb = unpack ("C", $rctb);
    if ($ctb < 128) {
	return "";		# Must have high bit set
    }
    $lengthlength = $ctb % 4;
    $ctb -= $lengthlength;
    if ($lengthlength == 0) {
	$lengthlength = 1;
    } elsif ($lengthlength == 1) {
	$lengthlength = 2;
    } elsif ($lengthlength == 2) {
	$lengthlength = 4;
    } else {
	$lengthlength = 0;
	$length = -1;	# Unknown length
    }
    if (read ($file, $rlength, $lengthlength) != $lengthlength) {
	return "";
    }
    if ($lengthlength==1) {
	$length = unpack("C", $rlength);
    } elsif ($lengthlength==2) {
	$length = unpack("n", $rlength);
    } elsif ($lengthlength==4) {
	$length = unpack("N", $rlength);
    }
    $rctb = pack ("C a".$lengthlength, $rctb, $rlength);  # Packed data
    if ($ctb==0x84) {
	$name = "pubkey header";
    } elsif ($ctb==0x88) {
	$name = "signature";
    } elsif ($ctb==0x8c) {
	$name = "message digest";
    } elsif ($ctb==0x94) {
	$name = "secret key";
    } elsif ($ctb==0x98) {
	$name = "public key";
    } elsif ($ctb==0xa0) {
	$name = "compressed";
    } elsif ($ctb==0xa4) {
	$name = "conventional encrypted";
    } elsif ($ctb==0xa8) {
	$name = "plaintext";
    } elsif ($ctb==0xb0) {
	$name = "trust";
    } elsif ($ctb==0xb4) {
	$name = "user id";
    } elsif ($ctb==0xb8) {
	$name = "comment";
    } else {
	return "";
    }
    return ($ctb, $length, $name, $rctb);
}

# Write a CTB and length field out.
# 3 arguments: file handle, ctb value, and length in bytes.
# No return value.
# Length gets output as 1, 2, or 4 bytes, the smallest in which it
# will fit.
# If length is negative we output no length field, but an "indefinite
# length" code is added to ctb.
sub write_ctb {
    local($file, $ctb, $length) = @_;
    local($rctb);

    $ctb = $ctb - ($ctb % 4);	# Be sure 2 low bits are clear
    if ($length < 0) {
	$rctb = pack ("C", $ctb+3);		# Packed data
    } elsif ($length > 65535) {
	$rctb = pack ("C N", $ctb+2, $length);  # Packed data
    } elsif ($length > 255) {
	$rctb = pack ("C n", $ctb+1, $length);  # Packed data
    } else {
	$rctb = pack ("C C", $ctb+0, $length);  # Packed data
    }
    print $file $rctb;
}

# This entry point always outputs a 4-byte count.  Length must be > 0.
# Otherwise like write_ctb.
sub write_ctb_4 {
    local($file, $ctb, $length) = @_;
    local($rctb);

    $ctb = $ctb - ($ctb % 4);	# Be sure 2 low bits are clear
    if ($length < 0) {
	die ("write_ctb_4 called with negative length\n");
    }
    $rctb = pack ("C N", $ctb+2, $length);  # Packed data
    print $file $rctb;
}


# Pad a PGP public-key-encrypted file to the specified length.
# Arguments: input file handle; output file handle; new size.
# Returns negative value on error.  See the code for what the
# different values mean.
# Returns 0 on success.
sub pgppad {
    local($infile, $outfile, $size) = @_;
    local($ctb, $length, $name, $rctb, $insize, $buf);

    # Read ctb & length of pubkey header
    ($ctb, $len, $name, $rctb) = &read_ctb($infile);
    if ($ctb == 0) {
	return -1;	# Error
    }
    if ($name ne "pubkey header") {
	return -2;	# Error
    }
    if ($len < 0) {
	return -3;	# Error
    }

    $insize = length($rctb) + $len;

    # Read packet of pubkey header
    if (read ($infile, $data, $len) != $len) {
	return -3;
    }

    # Write out pubkey header, unchanged
    &write_ctb($outfile, $ctb, $len);
    print $outfile $data;

    # Read ctb and length of conventional packet
    ($ctb, $len, $name, $rctb) = &read_ctb($infile);
    if ($ctb == 0) {
	return -4;	# Error
    }
    if ($name ne "conventional encrypted") {
	return -5;	# Error
    }

    # Calculate size of outgoing conventional packet.
    # Assume rctb won't change size; it may grow by 1 or 2 in some
    # rather rare cases, in which case we'll be a byte or two too big.
    $size -= $insize + length($rctb);
    if ($size < $len) {
	return -6;	# Error
    }

    # Output CTB with new length
    &write_ctb_4($outfile, $ctb, $size);

    # Copy remainder of input file
    while (read ($infile, $buf, 32768)) {
	print $outfile $buf;
    }

    # Note that this random number generator is probably not
    # cryptographically strong.
    srand (time|$$);
    while ($len < $size) {
	print $outfile pack ("C", int(rand(256)));
	++$len;
    }

    return 0;		# Success
}

1;	# Non-zero return for 'require'
\End\Of\Shar\
else
  echo "will not over write ./pgppad.pl"
fi
if `test ! -s ./pgppadt.pl`
then
echo "writing ./pgppadt.pl"
cat > ./pgppadt.pl << '\End\Of\Shar\'
# Test program for pgppad.pl, showing how to use it.
require 'pgppad.pl';

open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n");
open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n");

$padding = $ARGV[1];

@stat = stat(IN);
$size = $stat[7];
print "Input file $ARGV[0] has size $size bytes\n";
print "Output file $ARGV[0].pad will have size ".$size+$padding." bytes\n";

if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) {
    die ("pgppad returns code $code\n");
}

close (IN);
close (OUT);
print ("Done\n");

\End\Of\Shar\
else
  echo "will not over write ./pgppadt.pl"
fi
echo "Finished archive 1 of 1"
exit






From skaplin at mirage.skypoint.com  Sat Feb  4 11:06:20 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Sat, 4 Feb 95 11:06:20 PST
Subject: PGP padding scripts (again)
In-Reply-To: <199502041816.KAA20644@jobe.shell.portal.com>
Message-ID: <Pine.SV4.3.91.950204130137.5569A-100000@mirage.skypoint.com>




On Sat, 4 Feb 1995, Hal wrote:

> Sorry for the bandwidth waste, but my anonymous correspondent was not
> able to ftp these scripts.  I also got another request for the scripts.
> So here again is my post with a pair of perl scripts which will insert
> padding pretty much undetectably into a .pgp file.  The one limitation is
> the quality of Perl's random number generator.

I've put em' up on my auto-responder. Send a message to: skaplin at c2.org
With the subject: SEND FILE pad

And you should get them within a couple of hours. 

Sam





From roy at cybrspc.mn.org  Sat Feb  4 11:19:53 1995
From: roy at cybrspc.mn.org (Roy M. Silvernail)
Date: Sat, 4 Feb 95 11:19:53 PST
Subject: re to hfinney
In-Reply-To: <9502032142.AA17527@TeleCheck.com>
Message-ID: <950204.123917.2m0.rusnews.w165w@cybrspc.mn.org>


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

In list.cypherpunks, turner at telecheck.com writes:

>> also , where can i get perl for dos , any idea ? tia .

> PERL can be obtained via anon FTP:
> 
>  ftp.uu.net                     137.39.1.9
>  archive.cis.ohio-state.edu     128.146.8.52
>  jpl-devvax.jpl.nasa.gov        128.149.1.43
> 
> Get the source code and start compiling... :>

Bring a lunch... you'll be at it a while.  :)

Perl is a non-trivial port to MS-DOS, but there are versions available.
Look on your favorite SimTel mirror site:

Directory SimTel/msdos/perl/
 Filename   Type Length   Date    Description
==============================================
bperl3s1.zip  B  505075  940412  32-bit Perl 4.0pl36 w/VM & Win supt. (src 1/3)
bperl3s2.zip  B  530821  940412  32-bit Perl 4.0pl36 w/VM & Win supt. (src 2/3)
bperl3s3.zip  B  522530  940412  32-bit Perl 4.0pl36 w/VM & Win supt. (src 3/3)
bperl3x.zip   B  482794  940412  32-bit Perl 4.0pl36 w/VM & Win 3.1 supt. (exe)
perl4019.zip  B  196446  920620  UNIX-based scripting lang. replaces sh/awk/sed
perl419x.zip  B  435591  920317  Len Reed's port of Unix Perl v4.19
ptch19.zip    B  116444  920317  Len Reed's patch set to make perl 4.19
 
- -- 
       Roy M. Silvernail         [ ]  roy at cybrspc.mn.org
                    PGP public key available by mail
     echo /get /pub/pubkey.asc | mail file-request at cybrspc.mn.org
         These are, of course, my opinions (and my machines)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLzPKuhvikii9febJAQH0QQP+I+gjmjrx4AFmwq71cxneTvo9xCqmckCj
nsZkNske/VQAmB3BJNgf/SgAahkHryq8xZ2aM0tWr8B0FLdObqxmUKYHfu801Jtm
6pCyhOSBKUffRfiI+dvFPbuhuCOGcl+poYH2lvdpxyL2ABs6+QNVXj+Q9AlrozzF
kpJXL4BjIlk=
=dM24
-----END PGP SIGNATURE-----





From rah at shipwright.com  Sat Feb  4 11:53:03 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Sat, 4 Feb 95 11:53:03 PST
Subject: There is another NetCash
Message-ID: <v01510102ab593f760d33@[199.0.65.105]>


At 10:09 AM 2/4/95, Hal wrote:

>Some payment system is probably better than none, but I hate to see
>the name "cash" expropriated by these non-cash systems.

Indeed. That was the point of the URL to Mr. Solinsky's excellent
introduction to the subject.

It is easy to see that the original NetCash isn't a digital cash system,
with its clearing of a single-use serial number transmitted unencrypted in
the clear, and with its "bank" settling the transaction through the telco
900-number system. Not having looked yet, I bet the "other" NetCash is
probably not Chaumian-equivalent digital cash either, or we'd have heard
more about it. It would be a pretty major accomplishment, especially if it
doesn't violate Chaum's patents.

As Eric has said here recently, we have to remember the difference between
transaction clearing (which First Virtual, for example, does well, at least
as a prima facie system) and transaction settlement (which FV does on the
back of the Visa/MC network), which is what a true cash-settlement system
would do in one stroke.

Someday, and not now, I would like to take up the cudgel and jumpstart the
old offline/online cash debate. I like offline cash because it doesn't
require a bank intervention at every transaction, double-spending cash and
"inside-job" private key theft notwithstanding...

Ah, well.

Someday.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From anonymous-remailer at shell.portal.com  Sat Feb  4 14:12:44 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Sat, 4 Feb 95 14:12:44 PST
Subject: finney's perl scripts
Message-ID: <199502042212.OAA09528@jobe.shell.portal.com>


hal , gotta question regarding your perl scripts .
 i ran em thru sh and d/l'd em , and here are the
results of my tests . first , i pgp'd a file in
 binary format , then ran " perl pgppadt.pl
test.pgp 10 " . the error i got was " Couldn't
 create test.pgp.pad " . so i renamed the file to
" test " and tried again with good results ! i got
 " Input file test has size 732 bytes 10 bytes 
pgppad returns code -3 " . then , iran " perl 
 pgppad.pl test 10 " and after the bit about perl
running under dos/4gw protected mode , i get dropped
 to my command prompt . i took a look at the file ,
and it's size wasn't any different , so i renamed the
 file to test.pgp and ran it again and got the same
results . so i guess i'm wonderin' if it added the
 padding , or what might be the problem ? for your
info , i'm using perl 4.0.





From sdw at lig.net  Sat Feb  4 14:31:31 1995
From: sdw at lig.net (Stephen D. Williams)
Date: Sat, 4 Feb 95 14:31:31 PST
Subject: How the cypherpunks nearly got me fired (long)
In-Reply-To: <9502011435.AA26645@snark.imsi.com>
Message-ID: <m0raoM0-0009tFC@sdwsys>


> 
> 
> Michael Sattler says:
> > At 22:10 1/31/95, David Mandl wrote:
> > 
> > [really horrid story about true life at a corporate dinosaur deleted]
...
> 
> I'm a consultant. However, I won't take on clients with sufficiently
> distasteful business practices. This is something I consider to be
> sufficiently distasteful.
> 
> Perry

Absolutely!

Good net access and good business practices are becoming requirements for
employment for many techies now.

It might be worthwhile to start keeping a list, a la 'The Great Piss List'
(whatever happened to it?), on business practices and net availability
at various companies.  Not to mention use and attitude toward privacy,
encryption, etc.  A name...  How about "Cyber-Work-Space Report".

I'll volunteer to start the list if people want to email me anything.
I can put it on my (slow but permanent) web site also.  Even if I
don't have much time, which is probable, I can make the messages available.

I can come up with details on at least 4.  The only issue I can think
of is being careful of not violating non-disclosures, but for the most
part I don't think it'll be a problem.  It's not much different from
asking: "How's the cafeteria", or "is the phone system nice".  I'll
also strip identity if requested.  You could always write a
description and ask for an OK from your manager to tell friends
because it would help them decide whether to work there.  (Which is
actually true.)

Since this is only partially tied into to cypherpunks, feel free to cross-
post and add attributes.

Initial attribute list:

Company:

Type of job:
(ie.: techies probably have more likelyhood of net access, etc.)

Plans:
(ie.: things promised or talked about seriously)

Privacy of email:

Routine scanning:

Encourage/discourage encryption:

Key management:
(ie.: Any planning for the 'Mack truck' scenario)

Net Access:
(email/Netnews/telnet/ftp(in/out)/irc/aol/various/Web server(public/internal),
 Business only/Educational-curiosity/Full use (a true fringe))

Justification:
(What was the argument used to get and/or maintain net access)

Platforms and software typically used:

Strategies used, good or bad, to limit 'addiction':

sdw
-- 
Stephen D. Williams    25Feb1965 VW,OH      sdw at lig.net http://www.lig.net/sdw
Senior Consultant    513-865-9599 FAX/LIG   513.496.5223 OH Page BA Aug94-Feb95
OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Firewall/WWW srvrs ICBM/GPS: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W wrk
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.28Jan95




From mikepb at freke.lerctr.org  Sat Feb  4 15:42:16 1995
From: mikepb at freke.lerctr.org (Michael P. Brininstool)
Date: Sat, 4 Feb 95 15:42:16 PST
Subject: Forward: Teleco/Cabe REg. & Free speech
In-Reply-To: <199502041358.AA09885@panix.com>
Message-ID: <1995Feb4.153121.29573@freke.lerctr.org>


In article <199502041358.AA09885 at panix.com> habs at panix.com (Harry S. Hawk) writes:
>TELECOM REFORM, REPUBLICAN-STYLE Sen. Larry Pressler (R-SD) has
>proposed a telecommunications reform plan that would drop all cable TV
>rate regulations; allow local phone and cable competition and
>cross-ownership in one year; ease foreign ownership restrictions; and
>allow local phone companies to compete in long distance in three
>years. A formal counter proposal is expected from the Democrats
>February 14, and it's expected that there will be objections to most
>of the provisions outlined in Pressler's bill. (Investor's Business
>Daily 2/2/95 A4)
>
>(((cut here)))
>
>For those that don't know I have my Master's in Interactive
>Telecommunications, and have long looked at cable and teleco from
>several angles including freemarket and cypherpunk viewpoints.

I have to agree.  When I first moved to Austin Texas, the rates for
cable were not too bad, we were in an area that had a choice between
two cable companies.  After a couple years, a third company, a wireless
company came into town.  I then moved to Plano Texas, outside of
Dallas, and was absolutely SHOCKED at the cable prices.  Of course, in
Plano, there was ONE cable company, and all the channels except
broadcast channels were scrambled, so you HAD to get the cable box.  In
Austin, I could use the VCR tuner.  The only scrambled channels were
the premium channels.  The service in Austin was better and about 2/3
the cost.  I definately feel that competition is a MUST!

---------------------------------------------------------|
| #include "std/disclaimer.h"     Michael P. Brininstool |
| mikepb at freke.lerctr.org      OR      mikepb at netcom.com |
|---------------------------------------------------------





From lwp at garnet.msen.com  Sat Feb  4 16:57:38 1995
From: lwp at garnet.msen.com (Lou Poppler)
Date: Sat, 4 Feb 95 16:57:38 PST
Subject: Vinge on PKE ?
Message-ID: <m0ravI7-0013GtC@garnet.msen.com>


Apologies if I repeat a question which has already been answered.
My only gateway onto the Net is very expensive, and I miss many
important postings.  Some time ago it was asked why Vernor Vinge
made passing reference to humans' naivete in trusting public key
encryption, and some posters were seeking to contact professor
Vinge for clarification.  Has any further explanation been 
discovered for his distrust of PKE?





From jim at acm.org  Sat Feb  4 17:52:44 1995
From: jim at acm.org (Jim Gillogly)
Date: Sat, 4 Feb 95 17:52:44 PST
Subject: Vinge on PKE ?
In-Reply-To: <m0ravI7-0013GtC@garnet.msen.com>
Message-ID: <199502050152.RAA07725@mycroft.rand.org>



> lwp at garnet.msen.com (Lou Poppler) writes:
> important postings.  Some time ago it was asked why Vernor Vinge
> made passing reference to humans' naivete in trusting public key
> encryption, and some posters were seeking to contact professor

I don't recall the conversation, but it could refer to his recent novel
"A Fire Upon the Deep."  Our galaxy is divided into a number of zones where
computation can be easier or harder than in the particular section where
the Earth hangs out.  The fastest zones have computational ability so far
beyond what's physically possible in our zone that we don't understand it.

In this situation you can't trust your security to merely computationally
difficult problems like factoring large numbers: the denizens of the faster
zones could crack them faster than slower communicators could enumerate them.

The protagonists spent a fair amount of time on a courier ship that was
carrying as its cargo 1/3 of a one-time-pad, which was intended to get
to the buyer and be XORed with the other two pieces.  This was a valuable
cargo.  After it became clear that this 1/3 was potentially compromised it
was used for some important but less provably reliable communications.

	Jim Gillogly
	Trewesday, 15 Solmath S.R. 1995, 01:49





From lwp at garnet.msen.com  Sat Feb  4 18:33:47 1995
From: lwp at garnet.msen.com (Lou Poppler)
Date: Sat, 4 Feb 95 18:33:47 PST
Subject: Vinge on PKE ?
In-Reply-To: <199502050152.RAA07725@mycroft.rand.org>
Message-ID: <Pine.BSI.3.91.950204211924.25224A-100000@garnet.msen.com>




On Sat, 4 Feb 1995, Jim Gillogly wrote:
> "A Fire Upon the Deep."  Our galaxy is divided into a number of zones where
> computation can be easier or harder than in the particular section where
/.../ 
> In this situation you can't trust your security to merely computationally
> difficult problems like factoring large numbers: the denizens of the faster
> zones could crack them faster than slower communicators could enumerate them.

Yes, and even in the here and now, we suspect the existence of Powers with 
computational resources far in excess of our own.  But do we know for 
sure that PKE *must* rely on computational obfuscation?  Is it 
demonstrable that access to a public key always yields the secret key, 
given sufficient computational power?  Or is this only a result of the 
clumsy way we construct our keypairs here in the slow zone?





From anonymous-remailer at shell.portal.com  Sat Feb  4 18:43:14 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Sat, 4 Feb 95 18:43:14 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <199502050242.SAA00239@jobe.shell.portal.com>


> Date: Sun, 29 Jan 1995 17:56:34 -0800
> From: Hal <hfinney at shell.portal.com>
> 
> Of course it was Chaum himself in his 1981 paper (which I think is
> available from the CP FTP site) who described the duplicate-message
> attack.  I don't see that inter-remailing encryption helps much,
> because the attacker can still notice that whenever they inject
> message A, _something_ goes to Bob.  The real solution, as Chaum
> pointed out, is that the remailer must reject duplicate messages,
> even when separated by days.  Doing this without keeping a database
> of all messages ever sent is left as an exercise.

  Perhaps the postage could integrally contain the request-remailing-
to field.  Supose the postage were <e-money, to-address> encrypted to
the remailer.  Then replayers would want to copy the to-address into a
new piece of postage.  But, we assume, they can't figgure out what it
is because they don't have the key for the remailer.  

  If the remailer issued it's own non-blinded stamps, the remailer
would have to keep a list of canceled stamps.  (For as long as that
series of stamps remains valid.)  If the remailer used Chaumiam e-cash
no logs would need to be kept at all.

> Another aspect worth mentioning is that message splitting can make
> the kinds of statistical correlations that Wei Dai was looking at
> more of a danger.  [...]  Ideally you'd want to dribble them out at
> some standard rate, a rate at which you always send a message
> whether you have something to send or not.  But this may introduce
> unacceptable latency.

  If everybody ran a second level remailer, and if they always
forwarded something (of very nearly the same size) when they recieved
an encrypted message, then without compromising the users machine it
would be imposible to say when a message was delivered.  Some of the
messages forwarded would need to be junk.  Is there a polite way to
send mail to a remailer, and ask it to junk the mail?  Some of the
messages forwarded would have to be 'part n of m' messages.

  Noyb





From habs at panix.com  Sat Feb  4 19:26:57 1995
From: habs at panix.com (Harry S. Hawk)
Date: Sat, 4 Feb 95 19:26:57 PST
Subject: Forward: Teleco/Cabe REg. & Free speech
In-Reply-To: <Pine.SUN.3.91.950204182755.14091B-100000@access.mbnet.mb.ca>
Message-ID: <199502050326.AA26218@panix.com>



> paid for by digital cash.  Such a means of exchanging print, audio, 
> video, or any software might be virtually impossible to censor.  Would it 
> be possible to build such a network using current cable systems?  

It is a reasonable bet that all data into the home will come on
cable systems which means they require encrytion anyway.. there
are bridged, not point-to-point...

And other traffic like mobile voice and data will use some RF
technology...  which also requires encryption...

Existing cable systems are now running 1 gigahertz of bandwidth and
I had presentations from TW staff indicating 2 gigahertz is easily
reachable.. 

Figure 2 gigahertz of bandwidth (split between analog and digital
services) in each neighborhood and a ATM switch pulling those signals
back to the "head-end/central office" via fiber, and you have the
cable system of the future.. (e.g, for the next 5 to 20 years)..

/hawk





From david.lloyd-jones at canrem.com  Sat Feb  4 23:00:50 1995
From: david.lloyd-jones at canrem.com (David Lloyd-Jones)
Date: Sat, 4 Feb 95 23:00:50 PST
Subject: Vinge on PKE ?
In-Reply-To: <m0ravI7-0013GtC@garnet.msen.com>
Message-ID: <60.19880.6525.0C1CDEB4@canrem.com>


LP+Apologies if I repeat a question which has already been answered.
  +My only gateway onto the Net is very expensive, and I miss many
  +important postings.  Some time ago it was asked why Vernor Vinge
  +made passing reference to humans' naivete in trusting public key
  +encryption, and some posters were seeking to contact professor
  +Vinge for clarification.  Has any further explanation been 
  +discovered for his distrust of PKE?

I once had a girlfriend who factored five digit numbers just by 
looking at them.  "29367?  No, that's not prime.  It's 117 times 
251..."  Good ol' Elizabeth.  That's what you get for an "IQ" of 
around 175.  Surely there might be higher "IQ's" someplace else in 
Universe?
 
Albert Szent-Georgi once told me his thought that an IQ difference of 
thirty points meant that one person solves by inspetion problems which 
no amount of explanation can make clear to the other.  He added that 
in a normal day we run into people spanning three such gulfs.
 
If an IQ of 100 routinely factors two digit decimal numbers, and you 
get another digit for every twenty or thirty points, then you're 
looking for beings with IQ's in the 1,000 range to factor 100 digits 
binary...
 
                       Cheers,
 
                               -dlj.

david.lloyd-jones at canrem.com

 * 1st 1.11 #3818 * "640k should be enough for anybody" - Bill Gates, 1981.





From erc at s116.slcslip.indirect.com  Sat Feb  4 23:17:28 1995
From: erc at s116.slcslip.indirect.com (Ed Carp [khijol Sysadmin])
Date: Sat, 4 Feb 95 23:17:28 PST
Subject: Vinge on PKE ?
In-Reply-To: <60.19880.6525.0C1CDEB4@canrem.com>
Message-ID: <m0rb1D8-0004IoC@s116.slcslip.indirect.com>


> LP+Apologies if I repeat a question which has already been answered.
>   +My only gateway onto the Net is very expensive, and I miss many
>   +important postings.  Some time ago it was asked why Vernor Vinge
>   +made passing reference to humans' naivete in trusting public key
>   +encryption, and some posters were seeking to contact professor
>   +Vinge for clarification.  Has any further explanation been 
>   +discovered for his distrust of PKE?
> 
> I once had a girlfriend who factored five digit numbers just by 
> looking at them.  "29367?  No, that's not prime.  It's 117 times 
> 251..."  Good ol' Elizabeth.  That's what you get for an "IQ" of 
> around 175.  Surely there might be higher "IQ's" someplace else in 
> Universe?
>  
> Albert Szent-Georgi once told me his thought that an IQ difference of 
> thirty points meant that one person solves by inspetion problems which 
> no amount of explanation can make clear to the other.  He added that 
> in a normal day we run into people spanning three such gulfs.
>  
> If an IQ of 100 routinely factors two digit decimal numbers, and you 
> get another digit for every twenty or thirty points, then you're 
> looking for beings with IQ's in the 1,000 range to factor 100 digits 
> binary...

There is a class of people called "idiot savants" who contain people who can also solve such
problems by inspection - their IQs are often much lower than 100, so that
blows Albert's theory.  These so-called "idiot savants" can easily factor
100 digit numbers.  The ability to solve such problems is not tied to IQ,
as there are many such people with IQs of 150+ who cannot solve them.
-- 
Ed Carp, N7EKG    			Ed.Carp at linux.org, ecarp at netcom.com
801/534-8857 voicemail			801/460-1883 digital pager
Finger ecarp at netcom.com for PGP 2.5 public key		an88744 at anon.penet.fi
                       ** PGP encrypted email preferred! **

Cop: "How many beers have you had tonight, bro?"
Suspect: "Seventy."  -- from the TV show "Cops"




From lcottrell at popmail.ucsd.edu  Sun Feb  5 00:22:00 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Sun, 5 Feb 95 00:22:00 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <ab5a3af601021004300d@[137.110.24.250]>


>  If the remailer issued it's own non-blinded stamps, the remailer
>would have to keep a list of canceled stamps.  (For as long as that
>series of stamps remains valid.)  If the remailer used Chaumiam e-cash
>no logs would need to be kept at all.

I was not under the impression that Chaum e-cash was free from the need to
keep a list of spent cash. Do you meant that it would be the bank, not the
remailer, that would keep the database?
>
>> Another aspect worth mentioning is that message splitting can make
>> the kinds of statistical correlations that Wei Dai was looking at
>> more of a danger.  [...]  Ideally you'd want to dribble them out at
>> some standard rate, a rate at which you always send a message
>> whether you have something to send or not.  But this may introduce
>> unacceptable latency.
>
>  If everybody ran a second level remailer, and if they always
>forwarded something (of very nearly the same size) when they recieved
>an encrypted message, then without compromising the users machine it
>would be imposible to say when a message was delivered.  Some of the
>messages forwarded would need to be junk.  Is there a polite way to
>send mail to a remailer, and ask it to junk the mail?  Some of the
>messages forwarded would have to be 'part n of m' messages.
>
>  Noyb

Messages are not identifiable as "part n of m" except at the last hop. If
you are a remailer, then they are only visible as such to you. In transit
they appear as any other message. Yes, there is a polite way to send to a
remailer's bit bucket with some remailers. Ghio remailers will trash any
message sent which requests remailing to "null". Remailer at nately is a Ghio
remailer. I can't remember if I implemented that in Mixmaster. If not, I
will.

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From lcottrell at popmail.ucsd.edu  Sun Feb  5 00:53:11 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Sun, 5 Feb 95 00:53:11 PST
Subject: Mixmaster client release
Message-ID: <ab5a41f403021004d49b@[137.110.24.250]>


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

I have put a SPARC executable for the Mixmaster client on my home page. It
is easy to install, just run one script. Please send me any comments.
-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzSSA1Vkk3dax7hlAQGhyAP8DkA2AetIpCHfFhnUDP8qiKdPJ3ish36V
ZFA/W3Gx+6Glzj+5ri7fnug6N3ENyLJ3eoUfWVWjJ6uK5yMczMQB6wX4m3Afhrwz
xUw9WCKwbP0cktnLnMvbufDxyLTsGxA6yvWaRdCRVcqP4eyAVN4SiHCftE8EbI6Y
Pg+3SYtjDf4=
=5lAa
-----END PGP SIGNATURE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From strick at yak.net  Sun Feb  5 02:03:31 1995
From: strick at yak.net (strick at The Yak)
Date: Sun, 5 Feb 95 02:03:31 PST
Subject: The SKRONK protocols (version 0.6)
Message-ID: <199502051002.CAA01090@nando.yak.net>


========================================================================
The SKRONK protocols                                         version 0.6
========================================================================
                                                        Henry Strickland 
                                                        <strick at yak.net>
                                                        Sun Feb  5  1995


                          This is a working document, subject to change. 
                                                   Please comment on it!


Skronk is a user-level C library that re-implements the usual "posix
i/o" (unix man 2) functions and "berkeley socket" functions with a set
of functions that can use enhanced or alternate ("skronked") protocols
for TCP connections.  (Typical enhancements could be authentication
and/or encryption of the connection.)  A simple negotiation protocol
allows the clients and servers to agree on what enhancements are
desired or required.

Skronk is designed so that your common unix network clients and servers
(telnet, sendmail, ftp, nntp, X11, etc.) can be merely relinked with the
skronk library (libskronk.a) without changing the source code for the
programs.

As a matter of configuration and policy, skronked clients and servers
may choose either to interoperate with normal (non-skronked) client and
servers or to forbid normal connections.  In order to not interfere
with non-skronked programs, skronked connections take place an
alternate TCP server port numbers.

/* "Skronk" is a musical term, for a new-york-ish free-jazz 
 *   massively saxaphonish kind of music, e.g. John Zorn  
 */


---- THE UDP PROTOCOL BEGINS HERE ----

THE SKRONK MAP DAEMON

A skronk map daemon is a UDP service that tells what skronked services are
available from a site, and what alternate TCP server port numbers they
use.

The skronk map daemon receives "skronk map request" packets and returns
"skronk map reply" packets that list pairs of port numbers, mapping
normal server port numbers to corresponding skronked port numbers.  The
skronk map reply packet is sent to the same IP address and host port
that the request was received from.

If there is no map reply in a certain time, after a couple of 
map request resends, the skronk map client should assume that 
skronked services are not currently available on that host.

SKRONK MAP REQUEST PACKET

See "struct skronk_map_request" below.  The comment will say
something like "finger skronk at yak.net for info", to explain what
is going on to network administrators who see these packets for
the first time probing their hosts.

SKRONK MAP REPLY PACKET

See "struct skronk_map_reply" below.  The "serial" field should
match the serial field of the map request packet.  Replies be cached,
using the "ttl" time-to-live field for a timeout.

If the request packet cannot be replied to (perhaps because the action
was not understood, or the version was wrong), a reply with action
SKRONK_MAP_NACK should be returned.  If the magic field of the request
is wrong, do not reply.  (The magic number should be changed if the
first five fields are changed; otherwise, version and opcode may be
changed to implement new protocols.)

Skronk map clients should also recognize as a reply the 
relevant ICMP packets indicating that there is no skronk map daemon.

Version numbers 128 through 255 will not be assigned and are
available for experimentation.  Action codes 128 through 255 will
not be assigned and are available for experimentation.

Initial prototypes use UDP port 333 for the skronk map service,
until a number is officially allocated.

--------------------------------

        /* unsigned long = 4 octets, "network" order */
        /* unsigned short = 2 octets, "network" order */
        /* char = 1 octet, ASCII encoding, NUL terminated */

        struct skronk_map_request {
                unsigned long   magic;          /* SKRONK_MAGIC */
                unsigned long   serial;
                unsigned short  version;        /* SKRONK_VERSION */
                unsigned short  action;         /* SKRONK_MAP_REQUEST */
                unsigned long   reserved;       /* (corresponds to ttl) */
                char            comment[1];  /* variable length, NTBS */
                /* after NUL, remained of packet ignored */
        };

        #define SKRONK_MAGIC    0x1F1206FB  /* tail(md5("SKRONK_MAGIC\n")) */
        #define SKRONK_VERSION  0x0101		/* major 1 minor 1 */

	#define SKRONK_MAP_REQUEST      63      /* '?' */
	#define SKRONK_MAP_RESPONSE     46      /* '.' */
	#define SKRONK_MAP_NACK         33      /* '!' */

        #define SKRONK_DEFAULT_TTL      3600    /* one hour */

        #define SKRONK_NUM_TRIES        3       /* try three packets */
        #define SKRONK_WAIT_TIME        3       /* wait three seconds */

        struct skronk_map_reply {
                unsigned long   magic;          /* SKRONK_MAGIC */
                unsigned long   serial;         /* matches map request serial */
                unsigned short  version;        /* SKRONK_VERSION */
                unsigned short  action;         /* SKRONK_MAP_REPLY or _NACK */
                unsigned long   ttl;            /* cache time to live, in seconds */
                unsigned short  map[1];         /* variable length, 0 terminate */
                /* after 0, remainder of packet ignored */
        };

--------------------------------


EXAMPLE SKRONK MAP REQUEST AND REPLY

Map Request Packet:

   ip header:
        UDP             protocol
        128.32.43.52    source_ip_address
        199.170.88.5    destination_ip_address
   udp header:
        1066            source_port
        skronk          destination_port (number not assigned yet)
   body:
        0x1F1206FB      skronk_magic
        2001            skronk_serial
        1               version
        '?'             action (SKRONK_MAP_REQUEST)
        "finger         comment (for paranoid net admins)
         skronk at yak.net
         for info"

Map Request Reply:

   ip header:
        UDP             protocol
        199.170.88.5    source_ip_address
        128.32.43.52    destination_ip_address
   udp header:
        skronk          source_port (number not assigned yet)
        1066            destination_port
   body:
        0x1F1206FB      skronk_magic
        2001            skronk_serial (copied from request)
        1               version
        '.'             action (SKRONK_MAP_REPLY)
        3600            ttl (one hour)
   map list:
        23, 423,        /* skronked TELNET on port 423 */
        25, 425,        /* skronked SMTP on port 425 */
        70, 470,        /* skronked GOPHER on port 470 */
        80, 480,        /* skronked HTTP on port 480 */
        514, 914,       /* skronked shell on port 914 */
        750, 350,       /* skronked shell on port 350 */
        6000, 6400,     /* skronked X11 on port 6400 */
        0               /* zero marks end of list */
                        /* ... assume other services 
                                cannot be skronked */

/* 
 * Notice the skronked ports on this host (199.170.88.5)
 * have been allocated by the system administrator
 * using a simple (but arbitrary) rule: 
 *
 *     add 400 to the normal number, unless this has
 *     problems (like it would bring a less-than-1024
 *     port number to be greater-than-1024), in which
 *     case subtract 400.
 *
 * I propose this rule as a default, since it does not seem
 * to collide with common port numbers, but because we 
 * have and always use the skronk map daemon, each site
 * could pick different numbers.
 */


---- THE UDP PROTOCOL ENDS HERE ----


SKRONK PER-CONNECTION NEGOTIATION

/* 
 * The current skronk prototype temporarily works on 
 * a simpler negotiation scheme, but below is the
 * intended scheme.
 */

/*
 * Good questions:  
 * 1.  Would telnet-style negotiations be better?
 *
 *      I conclude not:
 *      -- this offers options to be combined at once
 *      -- this does fewer passes from server to client
 *      -- this uses ASCII names rather than numbers
 *              for options, which allows liberal 
 *              experimentation with "x-" names.
 *
 * 2. Do we need some escape-character & character-stuffing 
 *    to re-open negotiations?
 *
 *      Maybe... but flow of control probably never returns 
 *      to the skronk layers with any such requests, so let's
 *      let some escape-octet (with escape-octet-stuffing) 
 *      option for return-to-negotiation be a negotiated
 *      option that can be added later.
 */

The skronk library does a negotiation at the beginning of each TCP
connection, after "connect()" and "accept()" rendezvous, before
returning flow of control to the application.  This negotiation is
transparent to the application, but may be configured with skronk
configuration files or environment variables.

These negotiations should not be confused with other negotiations
specific to the program, such as TELNET negotiations, which would occur
later, once control is returned to the application.


/*
 *  I should first define 'negotiation line', 'acceptance line', 
 *    and 'disconnect' to describe the following...
 */


When the connection is made, the server writes a line of 10 to 999
octets, composed of ASCII characters, terminating with CRLF, to the
client.  This line must begin with the eight characters

        'S'  'K'  'R'  SPACE  h  t  o  SPACE

where h, t, and o are three decimal digits '0'-'9' (hundreds, tens, and
ones places), with leading a zero in the hundreds place if required,
specifying the length of this line, counting the CRLF at the end.  Thus
the minimum length of the line is 10.  The reason for putting the
length of the line in the front is so that the client can first read 8
characters, and then read the rest of the line, but not try to read any
characters beyond that size.

After the "SKR hto " follow zero or more words of the regexp form

        [A-Za-z0-9+][A-Za-z0-9/.+-]*

separated by one or more SPACE characters.  Case matters.  These words
specify protocols, and should registered with strick at yak.net, or begin
with "x-" for experimental protocols.

By sending this line, the server volunteers to server this protocol
skronked with any of the listed protocols.  The server should list the
protocols in order of preference, its favored protocols first.

The client reads this line, chooses one (or more) protocols, and
responds with a similar line, listing only the protocol(s) that it
chooses to use, in a specific "stacking" order, from the first protocol
applied to the last.  For instance, if it chooses "gzip" compression
followed by "des" encryption, it should list them in the order "gzip
des".  Some protocols choices may not be compatible, and some protocol
choices may not have stacking order; this will have to be described
when the protocols are defined.

If the client does not like any of the choices offered, it may hang up
the connection, instead of replying with a line.

If the server accepts the protocol the client chose, it responds with 8
characters

        'S'  'K'  'R'  SPACE  'O'  'K'  CR  LF

If not, it may either disconnect the connection, or it may send another
initial negotiation line, which should be different from the initial
line offered (probably with fewer options for the client to choose).


If the negotiation is accepted, what happens next depends on the
accepted protocols, and on the actions of the rest of the program.
Typically a selected protocol may have to do some more negotiation or
trading of data before control is returned to the application.  And
later reads and writes from the application to the skronked socket may
be intercepted and frobbed.


PRIMORDIAL PROTOCOLS

For stream encryption:

	/* needs work */

	A simple initial protocol named "dh/idea.1".

	Use Diffee-Hellman key exchange from RSAREF 2.0.
	Let the server declare the R_DH_PARAMS, and the size of things.
	Use IDEA encryption in CFB mode from PGP 2.6.
	No authentication -- susceptible to man-in-the-middle 
	attacks at connection time.


For authentication:

	/* needs lots of work */

	A simple initial protocol named "auth-pgp.1"

	Use PGP public keys and certificates to create
	a web of trust and thereby authenticate hosts.

	Can be combined with "dh/idea.1" or used separately. 

	(This probably requires having secret key pass phrases
	on multiuser machines, so it's one small step forward.)



--------------------------------

END $Header: /x/nepal/x/yak/strick/work/skronk-write/RCS/skronk.proto,v 1.3 95/02/05 01:18:49 strick Exp Locker: strick $





From jya at pipeline.com  Sun Feb  5 07:05:34 1995
From: jya at pipeline.com (John Young)
Date: Sun, 5 Feb 95 07:05:34 PST
Subject: NYT on Tera and UUNet
Message-ID: <199502051504.KAA09875@pipe3.pipeline.com>


John Markoff writes today on Tera Computer's supercomputer 
prayers.


For email copy (13k) send blank message to <jya at pipeline.com> 
with subject:  TER_nup


And, Laurie Flynn writes on UUNet's tender tap by Microsoft.


For copy (13k), same, with subject:  UUN_zzz





From jcorgan at aeinet.com  Sun Feb  5 08:50:30 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Sun, 5 Feb 95 08:50:30 PST
Subject: Here we go again...
Message-ID: <Chameleon.4.01.950205084831.jcorgan@comet.aeinet.com>



+---------------------------------------------------------+
 ##### #     #     #          #     #     ##### ####  #####
 #     ##   ##    # #        # #    #     #     #   #   #
 ###   # # # #   #   #      #   #   #     ###   ####    #
 #     #  #  #  #######    #######  #     #     #  #    #
 ##### #     # #       #  #       # ##### ##### #   #   #
+---------------------------------------------------------+
                       -> EMA ALERT <-
            News For and About the Members of the
               ELECTRONIC MESSAGING ASSOCIATION
============================================================
                February 3, 1995 -- Number 18
<---------------------------------------------------------->
                  ***** SPECIAL ALERT *****
 - Congress to consider making all system operators liable
   for messaging content.  Bill would force employers to
   monitor message content.              ACTION NEEDED NOW!
<---------------------------------------------------------->

UNREASONABLE NETWORK POLICING PROPOSED
   Yesterday, Senator Jim Exon (D-NE) introduced S.314, the
Communications Decency Act of 1995, in the United States
Senate.  In an effort to stamp out digital pornography, it
makes all telecommunications providers doing business in the
United States (from the telephone companies all the way down
to offices that use LANs) liable for the content of anything
sent over their networks.  To avoid the possibility of tens
of thousands of dollars in fines and up to two years in
jail, business owners would be forced to police their
networks and monitor in advance all messages sent over them.

WITHOUT ACTION - COULD BE LAW IN MONTHS
   This bill is substantially the same as the one he put
forward last year.  He will offer it as an amendment to the
pending telecommunications deregulation legislation in the
U.S. Senate, which is expected to be enacted by July.  Last
year, his amendment was adopted even though many thought it
hastily drafted and poorly thought out.  Fortunately, the
telecommunications deregulation legislation died.  This
year, a more conservative U.S. Congress may be even more
reluctant to challenge a "morality" amendment; and its
legislative vehicle, the telecommunications deregulation
legislation, stands a much better chance of passage this
year.

ACTION NEEDED NOW
   Action by the business community is needed now.  Please
notify your corporate government affairs office and/or your
legal counsel.  This measure could be adopted as an
amendment to the telecommunications bill IN A MATTER OF
WEEKS (or potentially added to any legislation pending on
the U.S. Senate floor), if business does not mobilize
against it.  S.314 will not stop digital pornography, but it
could devastate the messaging business.  If you are
interested in further information or are able to participate
in lobbying efforts over the next few weeks, contact Sarah
Reardon at EMA (see below).

------------------------------------------------------------
EMA ALERT is published and copyrighted (1995) by the
Electronic Messaging Association.  Permission to reproduce
and/or redistribute with attribution is hereby given to all
EMA members.  For more information about anything in EMA
ALERT, contact EMA via e-mail - use either X.400 (S=info;
O=ema; A=mci; C=us) or Internet (info at ema.org) address,
facsimile (1-703-524-5558), or telephone (1-703-524-5550).
Any EMA staff member can be addressed directly via e-mail by
using, for X.400, G=<firstname>; S=<lastname>; O=ema; A=mci;
C=us, and, for Internet, <firstinitial><lastname>@ema.org.
EMA's postal address is 1655 N. Fort Myer Dr. #850,
Arlington, VA 22209 USA.


==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov







From yusuf921 at uidaho.edu  Sun Feb  5 09:55:12 1995
From: yusuf921 at uidaho.edu (Syed Yusuf)
Date: Sun, 5 Feb 95 09:55:12 PST
Subject: No Subject
Message-ID: <Pine.HPP.3.91.950205095632.27089A-100000@goshawk.csrv.uidaho.edu>



Does anyone have a an list of a current remailers?


/sy/





From nobody at tower.techwood.org  Sun Feb  5 10:02:38 1995
From: nobody at tower.techwood.org (Anonymous)
Date: Sun, 5 Feb 95 10:02:38 PST
Subject: BROKEN REMAILERS
Message-ID: <199502051758.MAA02142@bb.hks.net>


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

I have tested remailers and their PGP keys over some time now and this is
what I have found:	

MIXMASTER is a great, fast and reliable remailer but you can't PGP with it.

REMAILER at NATELY.UCSD.EDU is just as fast and reliable (same guy) and you 
can use PGP, but a few weeks ago it started acting really funny: It will
forward any ATTACHED files, but it will only read the first commandline
of a PGP block that has been pgp'ed with Nately's public key.  In other
words, if you wrap layers of chained remailers inside each other, you 
will now have to have NATELY as the *last* link in your chain as it will
otherwise discard the rest of the block. Alternatively you can have the
chain as a series of attached files.

USURA is really quick too and has lately been reliable. But it has always
suffered from the same problem as Nately, namely that it will truncate all
of the remaining lines in a PGP message encrypted with its own public key,
this making it impossible to chain effectively.  It will read the first 
command only.  It DOES forward all attached files, however (by which I 
mean text that have been tagged on OUTSIDE of the pgp block encrypted
to Usura).

EXTROPIA and VOX suffer from the exact *opposite* problem.  They forward
the entire inner remains of a pgp block untouched after having only read
the first commands to them.  But they both ignore and discard all text
outside that first initial pgp block encrypted with their public keys.
This means that you cannot send a message with multiple pgp's through
either of them: because any attached parts get thrown away.  
As a practical application, it means that you can't use either of these
two as part of your nym at alpha.c2.org setup, sadly...
BTW, with VOX you will have to add the ::Encrypted: PGP bit whereas you
don't have to do that with Extropia (or with alias at alpha.c2.org for that
matter).

REBMA is ideal in that it does not touch your message: You can use *both*
attached files and "wheels within wheels" where you have layers of pgp'ed
remailer instructions hidden inside one another. The main problem with 
REBMA is that she has been down a bit lately and even when she is not down,
you have to wait ages: 1 or 2 days, sometimes even more.

The best remailer, IMO, is HAL at ALUMNI.CALTECH.EDU which operates in tandem 
with HFINNEY at SHELL.PORTAL.COM: Both are fast and very reliable.  Moreover,
neither will throw away attached messages (like Vox and Extropia do) nor
throw away the other loops of an inner-encrypted pgp reply block (like
Usura and now, lately, unfortunately, also Nately do). Very versatile!

I used to like JPUNIX too.  Now it seems HOMER at RAHUL.NET is a winner,
I don't know if he will stay reliable, but he sure is fast.  In terms
of PGP, he is just as good as HAL/HFINNEY.  Likewise, TOWER: Both work!

The DESERT remailer is sometimes fast, sometimes slow. I have a feel it waits
until it can send out stuff in batches. So sometimes you have to wait a day
or so.  It works with Anon-To: last I checked, if I recall correctly.

That's the extent of my playing around. I would appreciate corrections
and help, especially information with some of the remailers I have not 
mentioned here.  I have not played with Q or with FLAME, for instance. 

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

.Signature field left blank
(or it wouldn't be anonymous, would it?)

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzUR0CoZzwIn1bdtAQGoHQF/ep/uxpNHaCX4JUoETqULLax8Q0vu6VrY
Jh1P/ey2QrWi1TKWky3/SJ967S+xoqg0
=gEZ3
-----END PGP SIGNATURE-----





From Nobody at eniac.ac.siue.edu  Sun Feb  5 10:03:55 1995
From: Nobody at eniac.ac.siue.edu (Anonymous)
Date: Sun, 5 Feb 95 10:03:55 PST
Subject: BROKEN REMAILERS
Message-ID: <199502051800.NAA02153@bb.hks.net>


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

Here's a bug report on some remailers that won't work in a nested chain
when it is encrypted.
First, a look at how a chain is supposed to work.  Three good ones, chained
like:
1) Tower->Alumni->Homer. OK
2) Homer->Tower->Alumni. OK
3) Homer->Alumni->Tower. OK

This was in a test of the new Tower remailer. In other words, 
it doesn't matter if Tower is at the beginning, middle or end of a chain.
The message will reach its intended destination. (In fact, quite fast).

But some other remailers fuck up when they become part of a nested, encrypted
chain.  One of those? The Syrinx remailer.  Here are the test results:
1) Syrinx->alumni->Homer. NO
2) Homer->syrinx->alumni. NO
3) Homer->alumni->syrinx. OK

The third one came back to be in under an hour. No reply from number 1 and 2.
I don't know why it doesn't work but it doesn't! Maybe one explanation is
that as Syrinx gets a messages it sees the :: Encrypted: PGP and then
decodes it using its key (as it should), but then in the decrypted message
it sees another :: Encrypted: PGP and attempts to decode it again using its
key (again), fails (of course) and aborts. This to me is the only explanation
as to this strange behaviour. It is a serious problem and I do think that
it should be brought to the attention of everybody. Now I haven't tested
all of the remailers so I don't really know which one also will fail the
test. In that test I choose Homer and Alumni because I know that these 2
are reliable and don't care in what order they are in a chain, I also always
send the same test message it reads:

This is a test
line1
line2
line3
line4
Sent <TIME and DATE>
to #1->#2->#3

So its easy to do. And when I get a reply I know which one (1, 2 or 3)
worked, since the path is in the message. Now I know that syrinx doesn't
work. So I add it to my list of those remailers that failed the test.

Also on this list are:
* Nately
and 
* Usura
as they both share the same properties as Syrinx: The chained message gets
home ONLY is Syrinx / Usura / Nately is the _last_ link of the chain.
(Nately *used* to be as good as Homer, Tower, Hal and Portal, but not
anymore. Around Christmas, it changed its performance. Maybe the operator
tinkered - don't what what he did, but he made it worse.)

Two other remailers failing our tests, but for other reasons, are:
* Extropia
and 
* Vox.
Neither forwards attached files. In other words, anything outside of the 
original encrypted block gets sent on.  This makes both of them useless
for reply blocks, for instance.


- --
anon
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzUSGCoZzwIn1bdtAQH3IgF9FIUMOTd6rsihkaXUCKn4w14qTtOEfjcD
sXFPB/62K6NQZCuHTUPBDa30jh2c8sJY
=6tBU
-----END PGP SIGNATURE-----





From sdw at lig.net  Sun Feb  5 11:02:38 1995
From: sdw at lig.net (Stephen D. Williams)
Date: Sun, 5 Feb 95 11:02:38 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <199502051002.CAA01090@nando.yak.net>
Message-ID: <m0rb7Za-0009tFC@sdwsys>


...
> /* "Skronk" is a musical term, for a new-york-ish free-jazz 
>  *   massively saxaphonish kind of music, e.g. John Zorn  
>  */
> 
> 
> ---- THE UDP PROTOCOL BEGINS HERE ----
> 
> THE SKRONK MAP DAEMON
> 
> A skronk map daemon is a UDP service that tells what skronked services are
> available from a site, and what alternate TCP server port numbers they
> use.

UDP won't get through most firewalls.

Build in support for non-transparent firewalls (ie: telnet gatekeeper,
c sys port).

Handle getting access to skronked protocols by using the standard telnet
port and logging in as 'skronk' to get access to a service multiplexer.

Just some suggestions to deal with realities of availability.

...

sdw
-- 
Stephen D. Williams    25Feb1965 VW,OH      sdw at lig.net http://www.lig.net/sdw
Senior Consultant    513-865-9599 FAX/LIG   513.496.5223 OH Page BA Aug94-Feb95
OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Firewall/WWW srvrs ICBM/GPS: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W wrk
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.28Jan95




From adam at bwh.harvard.edu  Sun Feb  5 12:25:05 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Sun, 5 Feb 95 12:25:05 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <m0rb7Za-0009tFC@sdwsys>
Message-ID: <199502052024.PAA21302@bwh.harvard.edu>


Stephen D Williams wrote:

| > THE SKRONK MAP DAEMON
| > 
| > A skronk map daemon is a UDP service that tells what skronked services are
| > available from a site, and what alternate TCP server port numbers they
| > use.
| 
| UDP won't get through most firewalls.
| 
| Build in support for non-transparent firewalls (ie: telnet gatekeeper,
| c sys port).
| 
| Handle getting access to skronked protocols by using the standard telnet
| port and logging in as 'skronk' to get access to a service multiplexer.
| 
| Just some suggestions to deal with realities of availability.

	I was going to say some similar things about firewalls, but
then decided that Strick is doing the right thing.  If the firewall
wants to offer skronk'd services, it can respond to the UDP packet,
and offer up services, presumably through relays.

	The relay/proxy programs for these protocols already exist.
So you can reuse them to carry encrypted traffic through your
firewall.  Why build a new set of proxies that have to be checked for
correctness?

	Of course, letting encrypted traffic through your firewall
will upset those people who thought they can virus/porn scan at the
firewall.  Such scanners are almost always broken anyway.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From sdw at lig.net  Sun Feb  5 12:33:21 1995
From: sdw at lig.net (Stephen D. Williams)
Date: Sun, 5 Feb 95 12:33:21 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <199502052024.PAA21302@bwh.harvard.edu>
Message-ID: <m0rb8zF-0009tFC@sdwsys>


> 
> Stephen D Williams wrote:
> 
> | > THE SKRONK MAP DAEMON
...
> 	I was going to say some similar things about firewalls, but
> then decided that Strick is doing the right thing.  If the firewall
> wants to offer skronk'd services, it can respond to the UDP packet,
> and offer up services, presumably through relays.
> 
> 	The relay/proxy programs for these protocols already exist.
> So you can reuse them to carry encrypted traffic through your
> firewall.  Why build a new set of proxies that have to be checked for
> correctness?

I wasn't talking about replacing the proxy's, but 'playing' them instead
of assuming you could connect directly between the skronked program and
it's server.

In otherwords: Since it looks like we're stuck with visible proxy
firewalls for the forseeable future, we need to start codifying
proxy-relay semantics into new protocol preambles.  This gets us back
to more or less transparent network services.  This is especially true
of non-mainstream methods of access.

> 	Of course, letting encrypted traffic through your firewall
> will upset those people who thought they can virus/porn scan at the
> firewall.  Such scanners are almost always broken anyway.
> 
> Adam
> 
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 						       -Hume
> 


-- 
Stephen D. Williams    25Feb1965 VW,OH      sdw at lig.net http://www.lig.net/sdw
Senior Consultant    513-865-9599 FAX/LIG   513.496.5223 OH Page BA Aug94-Feb95
OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Firewall/WWW srvrs ICBM/GPS: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W wrk
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.28Jan95




From tcmay at netcom.com  Sun Feb  5 13:00:32 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 5 Feb 95 13:00:32 PST
Subject: Zimmermann charges dropped?
Message-ID: <199502052059.MAA08492@netcom8.netcom.com>



Apologies if this has been discussed and I somehow missed it. I just
got back from Monte Carlo last night and have briefly scanned the 500+
accumulated messages, not seeing this item mentioned.

Drew Taubman (sp?), the new Executive Director of the EFF, told me
that in recent days the grand jury meeting in the PRZ case did in fact
decide to go forward with the indictment.

However, says Drew, the judge in the case dismissed the charges after
looking at them, apparently in about an hour or so. He cited the
absence of relevant law in the case (as I understand it, the argument
being that there is no law against what PRZ did, i.e., "make code
available" in such a way that _others_ might then access it and
perhaps then illegally export it (assuming such export might be later
proved to be illegal).

Drew went on to tell me that the judge said there would need to be a
relevant law on this, and that Senator Leahy and his staff (recall
their involvement in the Digital Telephony Bill) are already at work
drafting such legislation.

I haven't seen mention of this, so I thought I'd mention it here. I
could of course try to get confirmation first from Phil, but he is
notoriously hard to reach in e-mail, ironically, and this seems
sufficiently important to mention to the list.

And if you can't trust the EFF, who _can_ you trust? (Don't answer
that.)

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From rfb at lehman.com  Sun Feb  5 13:16:45 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Sun, 5 Feb 95 13:16:45 PST
Subject: How the cypherpunks nearly got me fired (long)
In-Reply-To: <m0raoM0-0009tFC@sdwsys>
Message-ID: <9502052116.AA01421@cfdevx1.lehman.com>


    From: "Stephen D. Williams" <sdw at lig.net>
    Date: Sat, 4 Feb 1995 17:32:59 +0000 (GMT)
    
    'The Great Piss List' (whatever happened to it?)

As far as I know, Colin is still maintaining it although I haven't
corresponded with him recently.  You might try direct mail to 
Colin Owen Rafferty <colin at rafferty.com>

			Rick





From perry at imsi.com  Sun Feb  5 13:17:47 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 5 Feb 95 13:17:47 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <199502052024.PAA21302@bwh.harvard.edu>
Message-ID: <9502052117.AA02893@snark.imsi.com>



Adam Shostack says:
> 	I was going to say some similar things about firewalls, but
> then decided that Strick is doing the right thing.  If the firewall
> wants to offer skronk'd services, it can respond to the UDP packet,
> and offer up services, presumably through relays.

I was going to mention something about not putting excess thought into
the fifth or sixth "encrypt tcp connections" hack I'm aware of, but...

Perry





From perry at imsi.com  Sun Feb  5 13:19:33 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 5 Feb 95 13:19:33 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <m0rb8zF-0009tFC@sdwsys>
Message-ID: <9502052119.AA02901@snark.imsi.com>



Stephen D. Williams says:
> In otherwords: Since it looks like we're stuck with visible proxy
> firewalls for the forseeable future, we need to start codifying
> proxy-relay semantics into new protocol preambles.

Or simply codify the firewall techniques, a la the IETF AFT group...

.pm





From mg5n+ at andrew.cmu.edu  Sun Feb  5 15:10:45 1995
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Sun, 5 Feb 95 15:10:45 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <m0rb7Za-0009tFC@sdwsys>
Message-ID: <YjBJeLe00bkR9JllAy@andrew.cmu.edu>


sdw at lig.net (Stephen D. Williams) wrote:

> UDP won't get through most firewalls.

I'm working on a program that gets around this.  It creates a IP tunnel
by setting up a SLIP interface on a encrypted TCP stream and routes
packets through that.  It's not completely finished but it does work. 
Send me mail if you want it.





From msattler at jungle.com  Sun Feb  5 15:52:39 1995
From: msattler at jungle.com (Michael Sattler)
Date: Sun, 5 Feb 95 15:52:39 PST
Subject: Zimmermann charges dropped?
Message-ID: <v03001308ab5b146037be@[140.174.229.221]>


At 12:59 2/5/95, Timothy C. May wrote:

>I could of course try to get confirmation first from Phil, but he is
>notoriously hard to reach in e-mail...

Especially when he (and presumably his attorney Phil Dubois) are on the
road, as he is this week.  I'm trying to reach PRZ at his hotel to confirm
this.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
And so these men of Indostan/ disputed long and loud/ each in his own  |
opinion/ exceeding stiff and strong/ though each was partly right/ and |
all were in the wrong! - John Godfrey Saxe                             |







From perry at imsi.com  Sun Feb  5 16:08:37 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 5 Feb 95 16:08:37 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <YjBJeLe00bkR9JllAy@andrew.cmu.edu>
Message-ID: <9502060008.AA03105@snark.imsi.com>



Matthew J Ghio says:
> sdw at lig.net (Stephen D. Williams) wrote:
> 
> > UDP won't get through most firewalls.
> 
> I'm working on a program that gets around this.  It creates a IP tunnel
> by setting up a SLIP interface on a encrypted TCP stream and routes
> packets through that.  It's not completely finished but it does work. 
> Send me mail if you want it.

Pardon but... why? Whats the reason for wanting to do this?

If a firewall has been set up to stop UDP, then it should stop UDP. If
the firewall has not been set up to stop UDP, or has a mechanism like
the experimental versions of "socks" currently being played with that
relay UDP, then there is no reason to want to do the above. I don't
really understand what the idea is here.

Perry






From david.lloyd-jones at canrem.com  Sun Feb  5 16:16:10 1995
From: david.lloyd-jones at canrem.com (David Lloyd-Jones)
Date: Sun, 5 Feb 95 16:16:10 PST
Subject: VINGE ON PKE ?
In-Reply-To: <m0rb1D8-0004IoC@s116.slcslip.indirect.com>
Message-ID: <60.19899.6525.0C1CE099@canrem.com>


Ed Carp writes:


EC+There is a class of people called "idiot savants" who contain people who can
  +also solve such
  +problems by inspection - their IQs are often much lower than 100, so that
  +blows Albert's theory.  These so-called "idiot savants" can easily factor
  +100 digit numbers.  The ability to solve such problems is not tied to IQ,
  +as there are many such people with IQs of 150+ who cannot solve them.

 
Many idiot savants can multiply extremely large numbers, though I have 
not read of numbers with a hundred digits being involved.  Factoring 
large numbers is an extremely different kettle of fish, and I know of 
no writing about idiot savants doing difficult factoring.  If you have 
references to any such performances, I'd like to read them.
 
Szent Georgi's remark was addressed to general intelligenc in everyday 
life, not to bravura arithmetic.  My scepticism about all things IQish 
was supposed to be indicated by my use of quotation marks on "IQ".
 
                           Cheers,
 
                                -dlj.

david.lloyd-jones at canrem.com

 * 1st 1.11 #3818 * A piano is a piano is a piano. -- Gertrude Steinway.





From usura at replay.com  Sun Feb  5 16:28:47 1995
From: usura at replay.com (Alex de Joode)
Date: Sun, 5 Feb 95 16:28:47 PST
Subject: BROKEN REMAILERS
Message-ID: <199502060028.AA09342@xs1.xs4all.nl>


In article <199502051758.MAA02142 at bb.hks.net> nobody stated:

: I have tested remailers and their PGP keys over some time now and this is
: what I have found:	

: USURA is really quick too and has lately been reliable. But it has always
: suffered from the same problem as Nately, namely that it will truncate all
: of the remaining lines in a PGP message encrypted with its own public key,
: this making it impossible to chain effectively.  It will read the first 
: command only.  It DOES forward all attached files, however (by which I 
: mean text that have been tagged on OUTSIDE of the pgp block encrypted
: to Usura).

I did some testing myself and the format below did work for me:
(I encrypt using " pgp -eat ")

->

To: remailer at xs4all.nl

::
Encypted: PGP

----BEGIN PGP MESSAGE----
::
Anon-To: usura at replay.com

::
Encrypted: PGP

----BEGIN PGP MESSAGE----
::
Anon-To: usura at dds.nl

test of chained message
----END PGP MESSAGE----
----END PGP MESSAGE----

THIS IS OUTSIDE THE PGP MESSAGE

<-

This drops a message in my dds.nl mailbox stating:

->

test of chained message
THIS IS OUTSIDE THE PGP MESSAGE

<-


Hope this helps,
--
Alex de Joode					    
usura at replay.com	                            
http://www.xs4all.nl/~usura                PARTIE PIEPEL MOEF JOR FIET !!!







From mg5n+ at andrew.cmu.edu  Sun Feb  5 16:29:28 1995
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Sun, 5 Feb 95 16:29:28 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <9502060008.AA03105@snark.imsi.com>
Message-ID: <sjBKpHm00bkP0bX0Yx@andrew.cmu.edu>


"Perry E. Metzger" <perry at imsi.com> writes:

> Pardon but... why? Whats the reason for wanting to do this?
> 
> If a firewall has been set up to stop UDP, then it should stop UDP. If
> the firewall has not been set up to stop UDP, or has a mechanism like
> the experimental versions of "socks" currently being played with that
> relay UDP, then there is no reason to want to do the above. I don't
> really understand what the idea is here.

Presumably you would only let trusted people tunnel through your firewall.





From lcottrell at popmail.ucsd.edu  Sun Feb  5 16:31:18 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Sun, 5 Feb 95 16:31:18 PST
Subject: BROKEN REMAILERS
Message-ID: <ab5b1a2a020210049a0d@[137.110.24.250]>


>I have tested remailers and their PGP keys over some time now and this is
>what I have found:
>
>MIXMASTER is a great, fast and reliable remailer but you can't PGP with it.
>
>REMAILER at NATELY.UCSD.EDU is just as fast and reliable (same guy) and you
>can use PGP, but a few weeks ago it started acting really funny: It will
>forward any ATTACHED files, but it will only read the first commandline
>of a PGP block that has been pgp'ed with Nately's public key.  In other
>words, if you wrap layers of chained remailers inside each other, you
>will now have to have NATELY as the *last* link in your chain as it will
>otherwise discard the rest of the block. Alternatively you can have the
>chain as a series of attached files.
>

I am not sure what is going on with remailer at nately. I just tested it,
sending a PGP encrypted message chained through it 3 times, I also sent a
message chained through nately to c2. They both worked fine. Are you using
a program to build the chain, like "Chain"? If so, which?


Mixmaster now has a PGP key (it has had one for a long time for testing
purposes, this is a new one). The front end for using mixmaster remailer
type 2 messages is on my WWW page. Right now it only runs on Suns.

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

mQCNAy8y6PAAAAEEAJF05HUUQM4n9G5wHOZ+bHZbF6yFmeX5wBGElssHqUnbb4PQ
S/f8jWvJyfiZkjlOkzOEJ47fZ++x+yYWgzKGUKp2ejIKu2MvnzgLfIkwKfxioPXq
xgBpLcFaDrbM52Mi4MEpEYW4DJqxk9TrAnHZBwXmxpOZQ57UcgbmF1BLzawNAAUR
tC5NaXhtYXN0ZXIgUmVtYWlsZXIgPG1peG1hc3RlckBuYXRlbHkudWNzZC5lZHU+
iQCVAwUQLzLpflVkk3dax7hlAQH2GQP9FGBU7uGako4YghrUNzyb3tcdwZwsGkBx
Gy9MGojOSwWgXQ0CRLD9+IWgkZnRY902pU65C3IZhFB7erXBk5eyGOXhbahHv07o
mhHRiE2v4Z9hNapWVHHeDo0F2AoL7B8kkiFjXI2fVYzofB6gmXd7X8Wzh/9AEQsz
63U8X9cbajyJAJUDBRAvMulXBuYXUEvNrA0BAQOkA/9QfgNGLp6MX1Qwk55uLiHG
ajeT+Rtgruaj9DPOoZFVj9w0pImBkCQNw5eA6iZTgiAqkbSG7RaR9yKMU27Gf/O+
yz3cWAx4slFmCpVDlEl5qSa1Bd+2LuneN4EvnxfeI7TLUIFKlPcIOnx9zsu5Ny0I
SCtHVHBaGw43OT1OYmLjgA==
=Zr4D
-----END PGP PUBLIC KEY BLOCK-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From mab at crypto.com  Sun Feb  5 16:45:30 1995
From: mab at crypto.com (Matt Blaze)
Date: Sun, 5 Feb 95 16:45:30 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <9502060008.AA03105@snark.imsi.com>
Message-ID: <199502060048.TAA19441@crypto.com>



>
>Matthew J Ghio says:
>> sdw at lig.net (Stephen D. Williams) wrote:
>> 
>> > UDP won't get through most firewalls.
>> 
>> I'm working on a program that gets around this.  It creates a IP tunnel
>> by setting up a SLIP interface on a encrypted TCP stream and routes
>> packets through that.  It's not completely finished but it does work. 
>> Send me mail if you want it.
>
>Pardon but... why? Whats the reason for wanting to do this?
>
>If a firewall has been set up to stop UDP, then it should stop UDP. If
>the firewall has not been set up to stop UDP, or has a mechanism like
>the experimental versions of "socks" currently being played with that
>relay UDP, then there is no reason to want to do the above. I don't
>really understand what the idea is here.
>
>Perry
>

Actually, tunneling through a telnet connection on an application-level
firewall does have its place, especially when the firewall's
granularity of authentication is designed only to bind authorized
people to telnet connections.   This way, the firewall need only
enforce a very simple access control model (which is easier to
verify is working correctly) and need make very few authentication
decisions on a per-packet basis.

The down side (which is why I don't do this myself) is that you
have to be careful that the external end of the tunnel does not
forward IP packets from the rest of the net and is otherwise
reasonably secure, or one such connection is enough to eliminate
any security benefits the firewall might otherwise have offered.
It's not clear there's much a telnet firewall can do to prevent
tunnels, however, so we might as well at least make them secure as
we can.

-matt





From perry at imsi.com  Sun Feb  5 16:48:44 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 5 Feb 95 16:48:44 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <sjBKpHm00bkP0bX0Yx@andrew.cmu.edu>
Message-ID: <9502060048.AA03181@snark.imsi.com>



Matthew J Ghio says:
> "Perry E. Metzger" <perry at imsi.com> writes:
> 
> > Pardon but... why? Whats the reason for wanting to do this?
> > 
> > If a firewall has been set up to stop UDP, then it should stop UDP. If
> > the firewall has not been set up to stop UDP, or has a mechanism like
> > the experimental versions of "socks" currently being played with that
> > relay UDP, then there is no reason to want to do the above. I don't
> > really understand what the idea is here.
> 
> Presumably you would only let trusted people tunnel through your firewall.

Fine -- then packet filter on your firewall. Of course, you can't
really trust the IP addresses anyway -- you need something IPSP-like
if you actually want to trust outside hosts (swIPe does nicely as a
stopgap). And even if one wanted to move packets through a firewall
over TCP, why use SLIP encapsulation? It was designed for unreliable
links -- on a reliable link, you can save lots of grief by just
sending the packet -- total length of an IP datagram is included
inside the datagram, thus rendering further encapsulation unnecessary.


Perry





From strick at yak.net  Sun Feb  5 17:06:28 1995
From: strick at yak.net (strick at The Yak)
Date: Sun, 5 Feb 95 17:06:28 PST
Subject: "encrypt tcp connections" hacks
Message-ID: <199502060105.RAA07673@nando.yak.net>


Perry, could you enumerate them?  I take your opinions more
seriously than perhaps I should, so I want to understand
what you're saying.

I'm not doing this to re-invent the wheel.  I'm doing it because
I need it, and nothing else is working very well for me.

I'm doing it because I don't see anything that's easy-to-use in wide
use today.  I don't just want one or two encrypted applications -- like
the Kerberos telnet and rcp -- but something to transparently provide
privacy for all TCP sockets -- like SMTP sockets between (re)mailers,
NNTP, X11, FTP, MUDs, etc.

Let me name the ones I can think of.

  1.  	Matt Blaze just announced one.  As always, he has the best
	crypto.  But his world interface seems to be a hacked up
	script.c.  If I lift his crypto, and make it a standard
	module in Skronk, I can reuse 90% of his good work.

  2.	Kerberos4.  I use Kerberos4 between home and work all the time.
	However the only command I have that actually encrypts the
	session is the "rlogin" replacement.  (But I sure use it, even 
	if it's just DES.)

	Also Kerberos administration is a nightmare.  I'm a fairly
	knowledgeable crypto hacker and unix system administrator but
	honestly I don't understand what I did.  If it weren't for
	the Cygnus installation manuals giveing line-by-line
	instructions, I wouldn't have made it.  I've taken the 
	reference manuals to bed with me several times, but still
	haven't gotten a grasp of how to fully use it.

	And the reason big providers like The Well and Netcom won't
	run kerberos (or at least not the last time I asked) is that
	they would have to hire another person just to do the
	password management etc.  Skronk should be "just plug it in
	and it works".  There should be no reason why big providers
	can't offer it as an option.

  3.	Kerberos5.  I've been unable to build Kerberos5 on my 
	sun3.  Honestly.  To build it, I have to have ISODE, which seems 
	to be some enormous ISO thing that I haven't been able to build.

	Again, not too encouraging for your average unix sys admin.

  4.	The new telnet program with Telnet Options for authentication
	and encrytion.  Well it won't do encryption unless you
	can get the authentication done, and so you're back to 
	problems 2 and 3 above.  I couldn't get it to work in 
	an evening, and decided the world needed something better.
	Also even if it did work, it's only Telnet.  None of the other
	apps I named above can use it.

  5.	Standards for IPng.  Vapor, as far as I know.  Is there any
	usable code, that works in IP this generation?


I think it comes down to the fact that, of these, only Skronk and 
Blaze's software use a Diffee-Hellman -like Key Exchange so that
administration stuff doesn't have to be done by humans and footnet.

The real value I'm adding is not the crypto.  It's the packaging.
When I'm done it should be possible to skronk all your current 
clients and servers by just overriding the shared library libc.so,
running a skronk map UDP daemon, and customizing a configuration
file to tell the daemon what to say.


=================

As for the UDP service:

> UDP won't get through most firewalls.
> 
> Build in support for non-transparent firewalls (ie: telnet gatekeeper,
> c sys port).

UDP packets are for automatic configuration of skronk maps.  
Skronk maps could be announced other ways too -- including via
manual configuration, where you put skronk maps in your SKRONK_CONF
environment variable.

I may have to spend more effort on this than I wanted to.   I have
a SKRONK_CONF variable, and an option to say "dont ask the UDP 
skronk map daemon" about this port, just skronk it -- but right now 
it's only dependant on port number, not on the IP address too.
This can be fixed.

> UDP Port 333 - does this imply you need to be root to use it,
> at least as a server, or are only TCP ports typically root-limited
> for low-number ports?
>                 Bill

You need to be root to install it properly on your system, for the
skronked services to become bona fide system services.  Users should
not be able to hijack SMTP and TELNET connections to a site unless
they're root.

For people who run their own web server on a nonstandard port on a 
machine that someone else administers -- we're back to the manual
configuration method.  Maybe we can build a PGP service with 
signed certificates to collect nonstandard skronked services.  
But really I think these services will be marginal.



I had thought about using DNS TXT records.  But I decided against that
because a *lot* of people have autonomy over their workstation on
the net, but not over their DNS records.   Linux boxen in dorm rooms
come to mind.  Or anyone who puts a new machine on someone else's
ethernet, grabbing an IP address via ARP.


================= 

Thanks to everyone for your comments.

The discussion question is -- if we have so many hacks already -- 
howcome they're not in use.  I hope I found the reasons and addressed
them.  The firewalls issue bugs me a bit.  Would using a well-known
TCP port instead of the UDP port fix the problem?  I don't think 
so.  Firewalls will block my new TCP port as well.  Matt Ghio's
project to tunnel through the telnet port sounds good.  Of course,
that defeats the purpose of the firewall, which is not my aim.
My aim is to work with the internet and within its policies, so it
can get widespread use.

How much of skronk works today?  I'm nearing alpha of a version that's
hardwired to do DH exchange (using RSAREF2.0) and IDEA CBF (stolen from
PGP sources) for the symmetric encryption.  But I broke it recently
when I added hacks for servers to fake select() listening on both
skronked and normal ports, when the program only thinks it's only
listening on normal ports.


I gotta go ...     strick


==================


p.s.	need some wizard-level help here.

	I use syscall(2) when I reimplement read() write() connect()
	accept() etc. on SunOS. 

	On LINUX I borrowed code from the libc sources.

	On HPUX and Solaris and AIX I'm having difficulty finding
	a way to do what system calls do, without using the
	manufacture's packaging.  

	any help would be appreciated.







From joelm at eskimo.com  Sun Feb  5 17:28:35 1995
From: joelm at eskimo.com (Joel McNamara)
Date: Sun, 5 Feb 95 17:28:35 PST
Subject: signature validation on secure edit messages
Message-ID: <199502060128.AA07417@mail.eskimo.com>


Try turning Word Wrap off in Eudora.  I was encountering the same thing in the Windows version of Eudora.  With Word Wrap on, it seems to add CRs (or CR/LFs on a PC) to the end of each line upon sending.  This obviously causes a message not to match the signature, since all of those CRs weren't there when you composed it.  With Word Wrap off, your text still wraps on the screen when you're composing, but those unwanted CRs in the sent mail don't get added.

Joel McNamara
joelm at eskimo.com - finger for PGP key
    
>Jeez. I really don't know why the heck this always happens to me, my
>digsigs not validating.
>
>You can finger me at tjbryce at amherst.edu to retrieve a message with a valid
>signature.
>
>I always write the message in eudora, copy it, sign it in MacPGP as TEXT
>with attached signature, then go back and paste it over the old message.
>Then I go back to MacPGP and check the signature on the clipboard to be
>sure - no problems. But after getting mailed, it doesn't work.
>
>Damn.
>
>Tom
>






From anonymous-remailer at shell.portal.com  Sun Feb  5 17:48:11 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Sun, 5 Feb 95 17:48:11 PST
Subject: Judge not...
Message-ID: <199502060147.RAA25515@jobe.shell.portal.com>


Here's something I though would probably be of interest to more than a
few here that read Usenet news.  First article is the "Cancel FAQ" put out
by the "Judges List", which many may have seen on the new.admin.*
groups.  Following it is the "Judges List" FAQ.  

I doubt this is a major threat, but is a good example of the sort of
thing that needs to be nipped in the bud.

If the "Cancel FAQ" doesn't trip any alarms, be sure to read the
following "Judges List" FAQ.  

Please pardon the length.

Articles follow:

Article xxxxx of news.admin.misc:
From: judges[tm]@arch.ping.dk (NetNews Judges[TM] List)
Newsgroups: news.admin.policy,comp.admin.policy,comp.security.misc,misc.legal.computing,news.admin.misc,news.groups.questions,news.groups,news.newusers.questions,alt.censorship,alt.comp.acad-freedom.talk,alt.current-events.net-abuse
Subject: Cancel Messages:  Frequently Asked Questions (FAQ)
Date: Sat, 4 Feb 95 16:29:13 +0100 (CET)
Organization: NetNews Judges[TM] List
Message-ID: <01050105.limupb at arch.ping.dk>
Reply-To: judges[tm]@arch.ping.dk (NetNews Judges[TM] List)
X-Mailer: uAccess - Macintosh Release: 1.6v2
Lines: 382


Cancel Messages:  Frequently Asked Questions (FAQ). Ver. 2.0


---------------------------------------------------------

Summary:

You can protect your reputation as a information source by 
cancelling articles posted under your name as soon as you 
discover that they are erroneous.

Cancelling other's articles, however, can expose you, 
your site, and the Net as a whole, to serious threats. The 
sender should be notified when articles need to be cancelled. 

Disputes or doubtful cases can be directed to the Judges' 
List for resolution.

---------------------------------------------------------

       List of Frequently Asked Questions


*** Purpose of this document

1) What are cancel messages?

2) How have cancel messages been used?

3) When should I issue a cancel message?

4) When should I not issue a cancel message?

5) What should I do when in doubt about whether a 
cancel is appropriate?

6) What should I do if I receive a request to 
cancel one of my own messages?

7) How can I request that a message be cancelled 
when I can not do so myself?

8) What should I do if I suspect one of my 
posts has been improperly cancelled?

9) Why should I follow these guidelines?

*** Cancellation request form

*** Contributors to this FAQ

---------------------------------------------------------



***     Purpose of this document

This FAQ list serves as an introduction to cancel messages. 
More advanced information is presented in the document 
"Administration of Cancel Messages", which is directed to 
News system administrators. The objectives and operational 
procedures of Judges' List are specified and explained in the 
Judges-L FAQ, also available as the Welcome message for new 
subscribers to the List.


1)     What are cancel messages?

Cancel messages are special USENET messages from a class 
known as "Control" messages.  Control messages don't result 
in postings for people to read. Instead, they give 
instructions to the USENET server software at each site that 
gets the message.  A Cancel message is a control message that 
indicates that a particular message (named through its unique 
Message-ID) should be deleted.



2)     How have cancel messages been used?

Most commonly they are used when a person posts something 
they want to delete, correct, or retract.  One can cancel an 
old message and optionally issue a new one.  (There is a
better way to cancel and re-issue called Superseding, but 
most user programs do not support it.) 

Cancels are sometimes used by moderators of moderated 
newsgroups to delete messages that should not have been 
posted. 



3)     When should I issue a cancel message?

You should issue a cancel message if it becomes necessary to 
delete, correct, or retract one of your own posts.

You can issue a cancel message to delete a forgery: A message 
posted by someone else, that appears to be from you. A 
forgery can often be cancelled by you as if it were your own 
article. Such cancels should be reported to the Judges' List 
(see below).

Some victims of forgeries don't cancel them, but consider it 
sufficient to post disclaimers to the affected newsgroups 
alerting everyone to the forgery. This is wise, in any case, 
since the forged message is likely to be seen by many people, 
even if it is cancelled.

The newsreaders rn, nn, and trn use "C" as the cancel 
command. In Rusnews type ":cancel" while reading the message 
to be deleted.




4)     When should I not issue a cancel message?

It is not appropriate to cancel an article posted by someone 
else. However, a forgery is an exception. 

A low-tech form of "forgery" is to insert fabricated quotes 
in an article. Such posts should be followed-up with a 
correction and the poster notified. 

Misattribution of quotations, as opposed to fabrication, is 
often a result of inferior news-reading software. Such posts 
can be followed-up with a correction and the poster should be 
notified. 

It is inappropriate to cancel someone else's writing simply 
because you find the opinions expressed offensive. You can, 
however, ask the author to cancel the offensive post. Your 
news-reading software should permit you to enter the names of 
offensive posters in a "kill" file. Then, you will not see 
articles from that person in the future. Ask your 
administrator to upgrade your software if your news-reading 
software does not have this capability.

The poster should be asked to cancel a chain letter or a 
libelous article, or any other post, such as an advertisement 
or pyramid scheme, that has inappropriate content.  A copy of 
the request should be directed to the postmaster at the 
originating site, if the content is unlawful.



5)      What should I do when in doubt about whether a cancel 
is appropriate?

Unless you are certain the poster is acting in bad faith, you 
should explain to the poster why you object to the post and 
ask that it be deleted. State that you are considering 
submitting a complaint to the Judges' List and explain how 
one can participate in the dispute-resolution process (see 
below). You may explain how the offending post, or a post 
that accomplishes the same objective, can be broadcast.  One 
source of information is a list of Frequently Asked 
Questions, "How to find the right place to post (FAQ)" in the 
newsgroup "news.newusers.questions".

If the post comes from your site, contact your postmaster or 
News administrator for an opinion about whether the article 
violates the site's usage agreement.

Doubtful cases can be submitted to the Judges' List, for an 
opinion.

A complaint to the Judges' List must include a:

     :complete copy of the offending post.

     :complete copy of your letter to the poster, requesting 
that the post be cancelled.

     : complete copy of any reply from the poster or a News 
administrator (only if permission to forward is not refused).

The complaint must have a subject line that starts with the 
characters "COMPLAINT: ", followed by the subject of the 
offending post.

If you receive additional information after submitting a 
complaint or wish to withdraw the complaint, the same subject 
line should be used.

Mail the complaint to JUDGES-L at UBVM.cc.buffalo.edu or 
JUDGES-L at UBVM.BITNET.

If you wish to participate in the discussion of the 
complaint, email to LISTSERV at UBVM.cc.buffalo.edu or 
LISTSERV at UBVM.BITNET with only the command:
SUB JUDGES-L <your-name-here>
in the message body. Replace the <your-name-here>, with your 
first and last name, in the above command.

Before making comments on the List, please wait for someone 
to respond to your complaint. If there is no response within 
a week, it is most likely that you did not file a 
satisfactory complaint (see above). If you find no error in 
your complaint and the problem still has not been resolved, 
send an additional message asking for help.



6)     What should I do if I receive a request to cancel one 
of my own messages?

If you do not agree that the request is valid, reply to the 
request with your reasons for not cancelling. If the request 
does not mention the Judges' List, refer to this FAQ and ask 
that you be notified if a complaint is submitted.



7)     How can I request that a message be cancelled when I 
can not do so myself?

If your software does not permit cancellation, or you are not 
confident in using it, ask your administrator to issue a 
cancel message for you.



8)     What should I do if I suspect one of my posts has been 
improperly cancelled?

If you suspect that your post has been improperly cancelled, 
contact your News administrator to rule out the possibility 
of a technical failure. If there has been an improper cancel, 
complete documentation should be directed to the Judges' 
List. Follow the procedures for submitting a complaint, but 
replace the characters "COMPLAINT: " with "CANCEL: ".



9)     Why should I follow these guidelines?

If you do not cancel erroneous articles that you have posted, 
you waste readers' time and damage your own reputation as a 
reliable source. Consider an article posted to a typical 
newsgroup with 36,000 readers, a post that takes an average 
of 1 second for each reader to deal with (i. e., examining 
the subject line) uses a total of ten man-hours  (36,000 
seconds / 3,600 seconds/hour = 10 hours). If the article uses 
up an average of four seconds, then the total time 
expenditure is 40 hours, the equivalent of a work-week. This 
is probably the minimum time expenditure on any article that 
is even selected for scanning. Thus, a few minutes spent 
cancelling an article can save a lot of time for readers. 
Groups with a lot of erroneous articles tend to lose readers, 
and articles posted to those groups reach a limited audience. 
By cancelling erroneous posts, you also reduce the risk that 
your name will be entered in numerous kill files, thus 
limiting the audience you can reach with your posts. Posting 
of apologies for faulty articles, such as those with an empty 
body, is to be avoided, since this wastes even more time of 
the reader, without supplying useful information.

If you abuse the cancel facility, by cancelling other's 
articles, you force people to take defensive actions. Many 
administrators have disabled cancels, because they have been 
abused. The disabling of cancels means that you will not be 
able to delete all copies of your own posts. Therefore, if 
you cancel an erroneous article and then post a corrected 
one, readers at certain sites will first see the erroneous 
one and then the corrected one. They may think that the 
corrected one is a duplicate and not read it. This situation 
is obviously of no benefit to posters or readers. If your 
site's administrator has disabled cancels, it is wise for you 
to notify your administrator when you issue a cancel, so at 
least it can be deleted at your site. 

Disabling of cancels does not prevent a cancel from working 
at all, since the cancel message can delete the cancelled 
article before it gets to a site where cancels are disabled. 
Therefore, a cancel will be most effective if it is issued 
immediately after the target article is posted. In some 
cases, robot posters have been used to immediately repost 
articles that have been cancelled. This can rapidly lead to a 
newsgroup being overloaded at a site where the cancel 
facility has been disabled. This type of conflict situation 
should be avoided, since it makes the newsgroup unusable for 
most readers. Cancel messages must be used with extreme care.

If you cancel articles based upon their content, you expose 
your site to a legal risk, since it can then be argued that 
you are taking responsibility for all articles' content, some 
of which may violate copyright or pornography laws, for 
example. Originating sites already are exposed to this risk, 
therefore, they should be allowed to cancel such posts. They 
should also have a user agreement that permits them to 
discipline a user, thus ensuring that repeated postings of 
this type do not occur, and thereby reducing the legal risk 
at all News sites. 

This is not a hypothetical risk. Many sites have been closed 
down, had their equipment seized, and their operators 
prosecuted, and in some cases jailed. The effectiveness of a 
common-carrier or "bookstore" type of defense has yet to be 
established (But see Mike Godwin <mnemonic at eff.org>. INTERNET 
LIBEL: IS THE PROVIDER RESPONSIBLE? Internet World, Nov./Dec. 
1993) [URL: ftp://ftp.eff.org/pub/CAF/lawlibel_1.IW]. The use 
of non-originating site cancels, to control content of 
articles, reduces the chances that such a defense can ever be 
established. This could make the risk of operating a News 
site unacceptable. Some sites have already been prohibited 
from operating moderated newsgroups or mailing lists by their 
legal counsel, because of the legal risk associated with 
assuming responsibility for content of distributed messages. 
The damage to USENET caused by the most extreme case of 
abusive posting was much less than that caused by external 
threats, even when those threats did not directly result in 
disruption of a News site. Therefore, in doubtful cases, 
cancel messages should not be issued. Notification of 
authorities external to the Net should be avoided. Contacts 
to the Press should be left to those who have been trained in 
public relations or have equivalent experience.

In order to minimize legal liability, you should in, first 
instance, try to stop abusive posting at the source. By 
objecting directly to a poster of offensive material and 
making the person aware of this FAQ, you reduce the chances 
of repeated abuse.

In the case, that a poster refuses to comply with a request 
to cancel an article and you refer the matter to the Judges' 
List, the conflict can be resolved in a way which benefits 
the Net in the long term, and reduces the risk that you will 
be subject to retaliation, for example, by having your posts 
improperly cancelled. Complaints to the Judges' List also 
permits a database of repeat abusers to be built up, with 
much more effective resolution of such cases then becoming 
possible.



***     Cancellation request form

Sample reply to a poster requesting cancellation or 
explanation (not usable in cases where only the opinions 
expressed are offensive):

---------------------------------------------------------------
I object to your post, because ....

Please cancel this post and notify me that you have done so, 
or explain why you will not delete the post. Please note that 
any reply may be forwarded to the JUDGES-L list, unless 
explicit objection is given.

If I get no response, I will submit a complaint to the 
Judges' List. 

If you wish to participate in the discussion of the complaint 
on that List, email to LISTSERV at UBVM.cc.buffalo.edu or 
LISTSERV at UBVM.BITNET with only the command:
SUB JUDGES-L <your-name-here>
in the message body. Replace the <your-name-here>, with your 
first and last name, in the above command.
---------------------------------------------------------------



***     Contributors to this FAQ include:

Bob MacDowell <bobmacd at NETCOM.COM>
Tim Pierce <twpierce at midway.uchicago.edu>
David Stodolsky <david at arch.ping.dk>
Dimitri Vulis <dlv at dm.com>


================================================
Posted on behalf of the NetNews Judges(TM) List.
Judges-L Registrar,
dss


David S. Stodolsky, PhD  * Social *   Internet: david at arch.ping.dk
Tornskadestien 2, st. th.   * Research *    Tel.: + 45 38 33 03 30
DK-2400 Copenhagen NV, Denmark  * Methods *  Fax: + 45 38 33 88 80


And now, the "Judges List" FAQ:






From perry at imsi.com  Sun Feb  5 18:03:00 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 5 Feb 95 18:03:00 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <199502060105.RAA07673@nando.yak.net>
Message-ID: <9502060202.AA03281@snark.imsi.com>



strick at The Yak says:
> I take your opinions more seriously than perhaps I should,

I don't want to scare people into not doing things -- but I do want to
inform. Persons taking my opinion, or that of any authority, on face
value without doing their own reasoning, get what they deserve.

> I'm not doing this to re-invent the wheel.  I'm doing it because
> I need it, and nothing else is working very well for me.

Then do it...

> I'm doing it because I don't see anything that's easy-to-use in wide
> use today.  I don't just want one or two encrypted applications -- like
> the Kerberos telnet and rcp -- but something to transparently provide
> privacy for all TCP sockets -- like SMTP sockets between (re)mailers,
> NNTP, X11, FTP, MUDs, etc.

Well, in the long term, my hope is that people use IPSP for this. It
will mean that the kernels on their machines simply deal with all this
stuff and that userland applications get to ignore it 90% of the time.

> Let me name the ones I can think of.
> 
>   1.  	Matt Blaze just announced one.

>   2.	Kerberos4.  I use Kerberos4 between home and work all the time.
> 	However the only command I have that actually encrypts the
> 	session is the "rlogin" replacement.

And the telnet; however, it has a library to let you do whatever you want.

>       (But I sure use it, even if it's just DES.)

In v5 there is more general support, I believe.

> 	Also Kerberos administration is a nightmare.

Thats really an interface issue, I think -- they have a lot of the
fundamental stuff down. If thats one's only complaint with Kerberos (I
have others) the "right thing" is to build a simplified administration
system. 

> 	And the reason big providers like The Well and Netcom won't
> 	run kerberos (or at least not the last time I asked) is that
> 	they would have to hire another person just to do the
> 	password management etc.

Thats quite untrue -- passwords in kerberos are set by the users, not
by the administrators!


>   3.	Kerberos5.  I've been unable to build Kerberos5 on my 
> 	sun3.  Honestly.  To build it, I have to have ISODE, which seems 
> 	to be some enormous ISO thing that I haven't been able to build.
> 
> 	Again, not too encouraging for your average unix sys admin.

You only need ISODE for the ASN.1 compiler; you don't have to build
the whole thing.

>   5.	Standards for IPng.  Vapor, as far as I know.  Is there any
> 	usable code, that works in IP this generation?

There is swIPe, and the derived TIS product. Its a bit primitive since
it doesn't handle per-socket keying. There is stuff that I'm hacking
on between flames -- its going to be called swIPe II. It will conform
to my RFC drafts and should run out of the box on any 4.4BSD
system. I'm hoping people will back-port it to SunOS and the like.

There is also SSL, which is what the Netscape people are pushing --
stands for Secure Sockets Layer.

There is also the thing this guy Andy Heffernan did a draft on in
which you do this at the TCP layer; he uses a TCP option to pass IVs
and MACs.

There is also the method proposed by the AFT working group at the
IETF, a.k.a. the "socks" working group, for encrypting sockets.

There is also the thing that Miron Cuperman wrote for YTalk. It did
diffie-hellman key exchange followed by an encrypted session.

There are about three or four more that I can't bring to mind at the
moment but I'm damn sure I've seen them.

> I think it comes down to the fact that, of these, only Skronk and 
> Blaze's software use a Diffee-Hellman -like Key Exchange so that
> administration stuff doesn't have to be done by humans and footnet.

Diffie-Hellman doesn't give you real security without some sort of way
to authenticate the exchange. Man in the middle gets you. You are then
down to either using signed exchanges or some sort of challenge or
conventionally keyed way of authenticating.

BTW, Kerberos most emphatically does not require active
administration. I've run it in an environment with thousands of hosts
with narry a person paying it any attention.

> The real value I'm adding is not the crypto.  It's the packaging.
> When I'm done it should be possible to skronk all your current 
> clients and servers by just overriding the shared library libc.so,
> running a skronk map UDP daemon, and customizing a configuration
> file to tell the daemon what to say.

Well, this is an admirable goal. Of course, the Netscape people want
to do the same thing with SSL, and others have proposed to do it, too.

Ultimately, the thing that is going to fix the net is IP layer
encryption -- anything at a higher layer can't really fix all the
problems reliably. (As an example, consider RST attacks against TCP
connections.) It also can't fix them pleasantly.

Meanwhile, of course, it is going to be a while before that stuff is
universally deployed. My reference implementation isn't going to be
here before April. It will be freely available, but it will only run
on some architectures, and it is unlikely to be idiot friendly or
perfect out of the box day one.

Understand, also, that as one of the few people here who writes code I
don't want to discourage you from continuing by any means!

However, I'd say that this isn't going to be a permanently deployed
thing on the net -- that much we can be pretty sure of.

> The discussion question is -- if we have so many hacks already -- 
> howcome they're not in use.

Probably people aren't that enthusiastic about them. Encrypted
sessions are in wide use for telnet and the like -- I do that sort of
thing regularly, and now that session stealing has become a fact of
the net I suspect that S/Key is going to vanish and be replaced by
various encrypted telnets. SMTP it doesn't make much sense to protect
because what you really want to protect is the contents -- i.e. via
PEM, MIME security multiparts, or some similar method (I favor PGP'ed
secure multiparts myself.)

> p.s.	need some wizard-level help here.
> 
> 	I use syscall(2) when I reimplement read() write() connect()
> 	accept() etc. on SunOS. 

Why? Why not just do the original calls? If you are trying to overlay
shared libraries, just rename the calls in the symbol tables or
relink the library or something similar...

Perry





From dmandl at panix.com  Sun Feb  5 19:02:57 1995
From: dmandl at panix.com (David Mandl)
Date: Sun, 5 Feb 95 19:02:57 PST
Subject: signature validation on secure edit messages
Message-ID: <v01510104ab5b3e946aac@[166.84.250.21]>


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

Good point.  But if you turn word wrap off, your message will go out as one long line, or one long line for each paragraph.  Most smart mail programs will handle this cleanly, but I assume there are still many that won't.  Have all the people who are using PGP with Eudora been sending mail without line breaks?  Is this not a problem for 99.99% of the mail-reading software out there?

   --Dave.


At 5:28 PM 2/5/95, Joel McNamara wrote:
>Try turning Word Wrap off in Eudora.  I was encountering the same thing in the Windows version of Eudora.  With Word Wrap on, it seems to add CRs (or CR/LFs on a PC) to the end of each line upon sending.  This obviously causes a message not to match the signature, since all of those CRs weren't there when you composed it.  With Word Wrap off, your text still wraps on the screen when you're composing, but those unwanted CRs in the sent mail don't get added.
>
>Joel McNamara
>joelm at eskimo.com - finger for PGP key
>    
>>Jeez. I really don't know why the heck this always happens to me, my
>>digsigs not validating.
>>
>>You can finger me at tjbryce at amherst.edu to retrieve a message with a valid
>>signature.
>>
>>I always write the message in eudora, copy it, sign it in MacPGP as TEXT
>>with attached signature, then go back and paste it over the old message.
>>Then I go back to MacPGP and check the signature on the clipboard to be
>>sure - no problems. But after getting mailed, it doesn't work.
>>
>>Damn.
>>
>>Tom
>>

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzWQLZeBqjXzSLLFAQHBbwP+OwhP/d7Yim3/GTY0sI3s17QY4ve+dH6K
UoxUboys/VuPFD60gYMdM8LrlxwQksRQm7JWxgp204crKucPZuyOO3ZpZyqiwAmx
23NMf5qtEmxJV5fCPQ8mh61vVeGXOuG7VUA1S+Q3yd7AmZw/PKOllF41VtfmPZvK
weRwnYmb7Ho=
=q+U5
-----END PGP SIGNATURE-----

--
Dave Mandl
dmandl at panix.com







From dave at esi.COM.AU  Sun Feb  5 19:18:28 1995
From: dave at esi.COM.AU (Dave Horsfall)
Date: Sun, 5 Feb 95 19:18:28 PST
Subject: Judge not...
In-Reply-To: <199502060147.RAA25515@jobe.shell.portal.com>
Message-ID: <Pine.SUN.3.91.950206141712.8260C-100000@eram.esi.com.au>


On Sun, 5 Feb 1995 anonymous-remailer at shell.portal.com wrote:

[ I wonder why he/she/it wishes to remain anonymous? ]

> Here's something I though would probably be of interest to more than a
> few here that read Usenet news.  First article is the "Cancel FAQ" put out
> by the "Judges List", which many may have seen on the new.admin.*
> groups.  Following it is the "Judges List" FAQ.  

Thanks - I hardly read the news.* hierarchy these days.

> I doubt this is a major threat, but is a good example of the sort of
> thing that needs to be nipped in the bud.

Why?

> If the "Cancel FAQ" doesn't trip any alarms, be sure to read the
> following "Judges List" FAQ.  

I did - I don't have a problem with it.  Do you?

-- 
Dave Horsfall (VK2KFU) | dave at esi.com.au | VK2KFU @ VK2AAB.NSW.AUS.OC | PGP 2.6
Opinions expressed are mine. | E7 FE 97 88 E5 02 3C AE  9C 8C 54 5B 9A D4 A0 CD






From lrh at PrimeNet.Com  Sun Feb  5 19:34:50 1995
From: lrh at PrimeNet.Com (Dr. Lyman Hazelton)
Date: Sun, 5 Feb 95 19:34:50 PST
Subject: "encrypt tcp connections" hacks
Message-ID: <199502060334.UAA09244@news.primenet.com>


I realize this may be heresy, but have you considered a hardware solution?
Cisco is currently offering a version of their popular routers with a builtin
Zylink crypto box... uses either DES or a "proprietary single bit CFB mode"
system (maybe RC4?) which is exportable.  The boxes are relatively
inexpensive.  Zylink offers just the crypto box for even less.  Both boxes
offer DH key management.

                                                                        Lyman

To obtain my PGP key, finger lrh at primenet.com or see
my Web page at http://www.primenet.com/~lrh/index.html






From hfinney at shell.portal.com  Sun Feb  5 20:23:55 1995
From: hfinney at shell.portal.com (Hal)
Date: Sun, 5 Feb 95 20:23:55 PST
Subject: Excerpts of signed messages
Message-ID: <199502060423.UAA18043@jobe.shell.portal.com>


(I forget if this was posted here last year, it sounds familiar.)

Suppose I get a PGP-signed flaming message, full of insults, and at the
end it says, sarcastically, "For a stupid moron, you've made some very
nice postings."  I could choose to excerpt this last part, "...you've made
some very nice postings", and exhibit it in signed form.  What I would do
is to run the MD5 hash calculation on the first part of the message, saving
the internal state of that calculation.  I then publish just that MD5 state
along with the rest of the message.  Someone can check the signature by
initializing their MD5 to that state, then running the algorithm on the
part of the message I publish.  This will end up with the signed MD5
value from the signature.

The checker would know he was dealing with an excerpt, and that it came
from the end of the message, but he would have know way of knowing what
was in the part that was removed.

Presently of course PGP has no mechanism to check such signature
excerpts, but that could be added.  Under some circumstances this might
be a desirable feature.  But people would have to be aware of the
limitation that the excerptable portion would have to be the tail end of
the message.

Hal





From harmon at tenet.edu  Sun Feb  5 20:30:56 1995
From: harmon at tenet.edu (Dan Harmon)
Date: Sun, 5 Feb 95 20:30:56 PST
Subject: dna ink
Message-ID: <Pine.3.89.9502052222.B22385-0100000@Joyce-Perkins.tenet.edu>



I just saw an item on CNN about a company in LA called Art Guard.  It 
sells an ink that is created using your dna as a protection against 
forged signatures.

Interesting.

Dan






From eric at remailer.net  Sun Feb  5 20:32:42 1995
From: eric at remailer.net (Eric Hughes)
Date: Sun, 5 Feb 95 20:32:42 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <9502060202.AA03281@snark.imsi.com>
Message-ID: <199502060431.UAA18798@largo.remailer.net>


Perry advocates IPSP as an almost-panacea for Internet security.  I
disagree.  I'll quote only the most relevant bits:

   From: "Perry E. Metzger" <perry at imsi.com>

   > I don't just want one or two encrypted applications -- like
   > the Kerberos telnet and rcp -- but something to transparently provide
   > privacy for all TCP sockets -- like SMTP sockets between (re)mailers,
   > NNTP, X11, FTP, MUDs, etc.

   Well, in the long term, my hope is that people use IPSP for this. It
   will mean that the kernels on their machines simply deal with all this
   stuff and that userland applications get to ignore it 90% of the time.

   [...]

   However, I'd say that this isn't going to be a permanently deployed
   thing on the net -- that much we can be pretty sure of.

The basic problem with assuming IPSP as a universal encryption
solution is that it answers an incomplete threat model.  IPSP works
where you trust the endpoints but not the intermediates.  When you
don't trust the endpoints for silence, but do trust them for routing,
IPSP doesn't work.  Let me make this concrete:

TIA on netcom.

Suppose I'm running extruded netcom ports on winsock clients using TIA
to multiplex the serial line.  (Some of you may be doing this right
now.)  My Netscape connection is passing from my MS Windows machine
through netcom over the internet to my web server of the moment.  IPSP
doesn't provide end-to-end security in this case, because the endpoint
for the IP packet (netcom) doesn't coincide with the endpoint of the
actual connection (the home machine).  A maxim:

Trust boundaries are not the same as machine boundaries.

It's fallacious to argue simply that everyone's going to be _on_ the
Internet soon enough anyway, and that this problem will go away.
Absolutely not.  If anything, this kind of proxying for Internet
connectivity is going to be come _more_ common, and that as a result
of cypherpunk projects for realtime proxy services, such as web and
ftp proxies.

You don't want to trust the proxy in an anonymization service to do
your crypto for you, just like (if you're smart) you won't trust your
secrets to netcom even for processes, much less for filesystems.  And
you can't say that all proxies are going to be IP-to-IP proxies,
either.  Some of them are going to be proxying the whole protocol,
some will participate partially, some not at all.  What this does
indicate, however, is that the need for peer-to-peer encryption will
be necessary at _each_ level of abstraction, and pretty much forever.

It will be an interesting and practical exercise in trust modeling to
figure out how to pass one layers policy requirement for a secure
channel to a service offering at a lower layer.  The problems involved
here are going to be extremely difficult to make work for anything
approaching generality.

Eric





From tcmay at netcom.com  Sun Feb  5 21:06:23 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 5 Feb 95 21:06:23 PST
Subject: Zimmermann charges NOT dropped
In-Reply-To: <199502052059.MAA08492@netcom8.netcom.com>
Message-ID: <199502060504.VAA19605@netcom14.netcom.com>



Charges against Phil Zimmermann have apparently NOT been dropped, and
Zimmermann's legal team is still in high gear.

Proving once more that things said or asked on this list often--even
usually--find their way to the persons mentioned, Phil called me today
to ask further about what I'd heard from Drew Taubman and to explain
that as of Friday, when Phil Dubois, Phil's lawyer, spoke to the
prosecutor in the case, the case had not been dropped. Or if it was,
the lead attorney and his client were not told.

(My discussion with Drew was at 10 p.m., Wednesday, Monte Carlo time.)

So, it appears that my source was either incorrect, or wires got
crossed in some way. (Or that EFF has access of a kind that seems
farfetched.)

Phil speculated that Drew was speaking about the LaMacchia case, of
several weeks back. This is unlikely, as the LaM. case was a separate
discussion we had, specific mention was made that the news was very
recent, happening within a few days of our conversation, and that
Senator Leahy would be incorporating changes based on the PRZ case
situation into legislation on telephony and expert being planned.

In any case, it seemingly is just not the case that charges have been
dropped (or that plans to file them have been dropped).

Anyway, my apologies. I sometimes think I am talking to the 20-30 of
you who post regularly, and can thus feel free to ask about a report
I've heard. But, as Hal Finney and others have also discovered, this
is not the case...boundaries are changing in cyberspace.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From skaplin at mirage.skypoint.com  Sun Feb  5 21:07:50 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Sun, 5 Feb 95 21:07:50 PST
Subject: Here we go again...
In-Reply-To: <Chameleon.4.01.950205084831.jcorgan@comet.aeinet.com>
Message-ID: <Pine.SV4.3.91.950205230508.28613A-100000@mirage.skypoint.com>




On Sun, 5 Feb 1995, Johnathan Corgan wrote:

>                   ***** SPECIAL ALERT *****
>  - Congress to consider making all system operators liable
>    for messaging content.  Bill would force employers to
>    monitor message content.              ACTION NEEDED NOW!
> <---------------------------------------------------------->

Anyone got the text of this bill? Good old thomas.log.gov wasn't too much 
help. It seemed to only list proposed changes to the bill.

Sam





From hfinney at shell.portal.com  Sun Feb  5 21:35:07 1995
From: hfinney at shell.portal.com (Hal)
Date: Sun, 5 Feb 95 21:35:07 PST
Subject: Remailer encryption module
Message-ID: <199502060534.VAA26941@jobe.shell.portal.com>


From: eric at remailer.net (Eric Hughes)
> -- The RSA-encrypted session key does not have a flat representation
> over its multiword container.  This yields a statistical traffic
> analysis hole.  (This point is irrelevant without fixing 4.)  Hal and
> I completely solved this problem last year.

For reference, here is that old message with an algorithm that produces an
encrypted session key with a flat distribution over a specified number of
bytes, along with a proof that it works.  The purpose of this is you
could strip off the PGP header stuff and have a file which looked for all
intents and purposes like totally random bytes, but if you knew the
secret key then you could decrypt it just fine.

(I recently took my CP archives and indexed them using Mark Zimmermann's
(no relation to Phil, apparently) FreeText browser which lets me do
keyword searches.  Pretty nice.)

> Date: Mon, 7 Mar 94 08:34:04 -0800
> From: hughes at ah.com (Eric Hughes)
> Message-Id: <9403071634.AA10351 at ah.com>
> To: cypherpunks at toad.com
> In-Reply-To: Hal's message of Sun, 6 Mar 1994 11:22:17 -0800 <199403061922.LAA26901 at jobe.shell.portal.com>
> Subject: Truly Stealthy PGP (algorithm)
> Sender: owner-cypherpunks at toad.com
> Precedence: bulk
> Status: RO
> 
> >If I understand Eric's general idea, we would keep trying session keys
> >under a set of rules which would lead to the desired statistical
> >distribution of the encrypted key.  
>  
> I actually said nothing about how to get the particular distribution
> of keys specified, since that was another issue.  I was more concerned
> with just getting the one result across.
>  
> >Here is an algorithm which would work.
>  
> It does work, and I'll put down a proof sketch below.
>  
> Notation alert:
> >Let L be the next power of 256 above the modulus n.  Let t be the integer
> >part of L/n, so that L = n*t + s with s in [0,n).  Call the PGP IDEA session
> >key SK, and the encrypted version of that m = SK^e.  Now do these steps:
> 
> >1) Pick a random SK in [0,n).
> 
> This random number in [0,n) is the wrong distribution, but that's OK,
> since we'll be throwing some numbers away.
>  
> >2) RSA-encrypt it to form m = SK^e mod n.
>  
> RSA encryption is a bijection (an 1-1 map).  If it were not, there
> would be two or more possible decryptions for a given ciphertext.
> Therefore RSA encryption is a permutation, and a permutation of
> probabilities preserves expected values of functions of the
> probability, such as entropy.  Since we assume the entropy of the SK
> is maximal (probabilistic entropy), therefore the entropy of the m's
> is maximal.  So the m's have a flat distribution.
>  
> (As always, the above statements about bijection hold only if SK is
> multiple of one of the divisors of the modulus.  But then if you do
> find one of those, you've also factored the modulus and thus broken
> the key.  We assume this doesn't happen, since if it does little of
> this matters anyway.)
> 
> >3) Choose a random k in [0,t].
> >4) Calculate the "stegged" encrypted key as M = m + k*n.  
>  
> Hal now observes that M is uniformly distributed.  This is correct,
> and happens because m is in [0,n) and we are adding a multiple of n to
> m.  This means that each M has a unique represenative as some pair
> <m,k>.  Since both m and k are independently random (max entropy, flat
> distribution), so is M.
> 
> >5) if M is not in [0,L) (i.e. if M >= L) then go back to step 1.
> >The idea is that once we get M uniform in [0,(t+1)*n) we can make it
> >uniform in [0,L) simply by rejecting those candidates which were too high.
>  
> What we have here is a Markov chain.  We have accepting states and
> rejecting/retrying states.  Since the probabilities in the chain are
> independent of each other and are also time-invariant, the
> distribution of final probabilities is the same as the distribution of
> normalized accepting probabilities.
> 
> In simple terms, you can just retry until you get it right.  Since the
> probabilities are all the same before, they will all be the same
> after, only larger to account for the fact that some possibilities
> didn't work.
>  
> [re: rejection and retry]
> >This will only happen if k=t and m>=s.
> 
> That's right, and that means that for m < s you have valid k in
> [0,t+1) and for m >= s only for [0,t).  If you go back an look at the
> entropy expression, you'll see exactly this difference in relative
> probability for the two parts of [0,n).
>  
> >Now, it seems to me that the worst case for rejection is when n=L-1, in
> >which case t=1, s=1, and almost one-half of all initial SK choices will
> >be rejected.  
> 
> Right, but the worst case for rejection is not the same as the worst
> case for entropy loss, which occurs at n=L/2+1 and s=t-1, i.e. at the
> other end of the spectrum entirely.
>  
> >Following Eric's reasoning, this would be an effective loss
> >of one bit of key length, from say 1024 to 1023, which is tolerable.
> 
> Actually not.  The loss of effective key length happens based on the
> posterior distribution of the session keys, not on the number of
> rejections that happen in the process.
>  
> >Using this algorithm with the current Stealth PGP would produce a
> >"truly stealthy" version which I think would be indistinguishable from
> >random bytes without access to the receiver's private key.
> 
> Indeed.  Observe, though, that as far as deployment went, this would
> require modification to PGP itself for it to be anything like
> widespread.
>  
> Eric





From hfinney at shell.portal.com  Sun Feb  5 22:04:34 1995
From: hfinney at shell.portal.com (Hal)
Date: Sun, 5 Feb 95 22:04:34 PST
Subject: finney's perl scripts
Message-ID: <199502060603.WAA00621@jobe.shell.portal.com>


From: anonymous-remailer at shell.portal.com
> hal , gotta question regarding your perl scripts .
>  i ran em thru sh and d/l'd em , and here are the
> results of my tests . first , i pgp'd a file in
>  binary format , then ran " perl pgppadt.pl
> test.pgp 10 " . the error i got was " Couldn't
>  create test.pgp.pad " . so i renamed the file to
> " test " and tried again with good results ! i got
>  " Input file test has size 732 bytes 10 bytes 
> pgppad returns code -3 " . then , iran " perl 
>  pgppad.pl test 10 " and after the bit about perl
> running under dos/4gw protected mode , i get dropped
>  to my command prompt . i took a look at the file ,
> and it's size wasn't any different , so i renamed the
>  file to test.pgp and ran it again and got the same
> results . so i guess i'm wonderin' if it added the
>  padding , or what might be the problem ? for your
> info , i'm using perl 4.0.

Unfortunately, my PC's disk died several months ago so I don't have one
right now.

pgppadt.pl sets the output file name with:
open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n");

This doesn't work on DOS since it appends .pad to the input file name so
it doesn't fit the 8.3 character format.

The other errors you are getting are probably due to the difference
between binary and ascii I/O mode on DOS.  I forgot about that
in my test script.  Try this revision of pgppadt.pl, and let me know if
it works on DOS:

----------------------cut here------------------------------
# Test program for pgppad.pl, showing how to use it.
# Revised 2/5/95 for DOS legality
# Usage: perl pgppadt.pl infile <bytes-to-add>
# Output file is infile, stripped of extensions, with .pad appended.

require 'pgppad.pl';
 
open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n");
$outfile = $ARGV[0];
$outfile =~ s/\..*//;
open (OUT, ">$outfile.pad") || die ("Couldn't create $outfile.pad\n");
binmode IN;
binmode OUT;

$padding = $ARGV[1];
 
@stat = stat(IN);
$size = $stat[7];
print "Input file $ARGV[0] has size $size bytes\n";
print "Output file $outfile.pad will have size ",$size+$padding," bytes\n";
 
if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) {
    die ("pgppad returns code $code\n");
}
 
close (IN);
close (OUT);
print ("Done\n");
----------------------cut here------------------------------





From MIKEINGLE at delphi.com  Sun Feb  5 22:17:10 1995
From: MIKEINGLE at delphi.com (Mike Ingle)
Date: Sun, 5 Feb 95 22:17:10 PST
Subject: New directions in anonymity (needed)
Message-ID: <01HMPLWWZOXU90B2L7@delphi.com>


There has been a lot of talk about anonymity and the best ways of providing
it recently. Anonymity now is about where cryptography was before Diffie and
Hellman's paper, or untraceable transactions before Chaum. To use it, you
have to trust someone, or at least a group of people.

All of our anonymous systems boil down to only two techniques: indirection
and broadcast. Indirection is sending a message through one or more
intermediate nodes to conceal its point of origin. Broadcast is sending a
message to multiple recipients to conceal the intended recipient.

Indirection is somewhat secure for anonymous-to-known messaging. Properly
done, all intermediate nodes must be compromised to reveal the anonymous
sender. It is entirely broken for allowing replies to an anonymous person.
To allow a reply, a traceable path must exist back to the anonymous person.
Having obtained whatever piece of data is used to send a reply, the attacker
can trace this back one node at a time. Kludge all you want, but there is no
good solution to this. You can make the path disappear when it is used, but
if the attacker gets it first, there is nothing you can do.

Broadcast is exactly as secure as it is nonscalable. If you broadcast to 100
people, an attacker's uncertainty is one in 100. The security grows linearly
with the overall bandwidth. For cryptographic-level security, it would need
to grow exponentially with bandwidth.

Anonymity needs something fundamentally new, something comparable to public
key for cryptography or blind signatures for digital cash. Suppose a server
has a large file. A message comes in and is combined into this file. Another
message comes in with a key to retrieve data. The server processes the
retrieval key against this large file and comes up with an output, which it
returns to the person doing the retrieving. This output contains the input
message, transformed in such a way that even the server cannot match it
to the input that produced it. This is what we need.

It would require three keys: an encryption key, a selection key, and a
decryption key. The sender uses the recipient's encryption key to encrypt
the message, then sends it to the server. The server mixes the message into
its file, but cannot identify the encrypted file as destined for a
particular recipient. The recipient's selecting key extracts the data, but
the data extracted does not resemble the data the sender sent. The
decryption key, kept private by the recipient, is necessary to return the
data to its original form. The server must be unable to link the data from
the sender to the data sent to the recipient, and this is the hard part.

A method like this would permit anonymity without trust, much as public key
allows secrecy without trust and digicash allows transaction privacy without
trust. Is there any way to do it? There are functions like the Fourier
transform that can distribute data over a large file, but the inverse
function gives you back the same data. We need the not-so-inverse function
to give back a different piece of data, but one that can be converted, by a
private key, into the original, which the server never sees.

						Mike

P.S. Have any of the "beta testers" actually tested RSAREF for Perl?
RSA gave me permission to call the random number and DES routines, so I am
ready to add that in and release the code.





From jamesd at netcom.com  Sun Feb  5 22:58:47 1995
From: jamesd at netcom.com (James A. Donald)
Date: Sun, 5 Feb 95 22:58:47 PST
Subject: Judge not...
In-Reply-To: <199502060147.RAA25515@jobe.shell.portal.com>
Message-ID: <Pine.3.89.9502052211.A8714-0100000@netcom9>


> [...]
> 
> Notification of 
> authorities external to the Net should be avoided. Contacts 
> to the Press should be left to those who have been trained in 
> public relations or have equivalent experience.

Seems thoroughly sane.
 
> How does the Judges' List work?
> 
> The List distributes messages to a panel of Judges who cancel 
> multiple posts to NetNews immediately. The List is used to 
> help Judges organize themselves, finalize policy, and set 
> procedures to enforce rules. It is primarily directed to 
> those who issue cancels.

In other words, it is a list for net vigilantes.

Sounds reasonable to me.  We need net vigilantes and we need
them to talk to each other.

Why should anyone object to this?

Enforcers are self appointed:  How else should anarchy work?
 

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From anonymous-remailer at shell.portal.com  Sun Feb  5 23:01:37 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Sun, 5 Feb 95 23:01:37 PST
Subject: re finney's perl scripts
Message-ID: <199502060700.XAA06256@jobe.shell.portal.com>


hal sez ,

: The other errors you are getting are probably due to the difference
: between binary and ascii I/O mode on DOS.  I forgot about that
: in my test script.  Try this revision of pgppadt.pl, and let me know if
: it works on DOS:

works like a charm , thanks !





















From wcs at anchor.ho.att.com  Sun Feb  5 23:44:10 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Sun, 5 Feb 95 23:44:10 PST
Subject: Creating commercial acceptability for remailers?
Message-ID: <9502060742.AA01282@anchor.ho.att.com>


How can we convince _lots_ of people to run remailers,
assuming it can be made technically painless?
How can we spread remailer-operations beyond the cypherpunks and
fellow travellers and the privacy/paranoia businesses like
tax reduction and pharmaceutical retailers?

Suppose you were in the "Get Connected To The Net" consulting business,
and you wanted to include a remailer in the outside-the-firewall
part of the mail handler - how would you get companies to accept it?

What kinds of other businesses could benefit from providing anonymous service?

Some ideas for non-mundane businesses -
- Shrinks-r-us or other on-line recovery groups, beyond the current
	use in a.s.a.r.?
- Tax advice - one-shot anonymous returns so you can ask questions
	from the IRS or whatever without much risk of audit?
- Anonymous tips (the D.A.R.E. hotline?)  Arrrgh.	
- Whistleblowers.com?  (Who'd trust whistleblowers.gov?)
- For one-way anonymity, perhaps MTV could run an "email from Beavis" server,
	letting you send rude comments to your friends.
	Digitally signed, with optional MIME noises!
	Sending mail through it might put your address in an
	email junk-mail marketing list, but without tying it
	to the outgoing message?
	
But what about mundane businesses?  I've seen suggestion boxes
operated with minimalist anonymization for internal use
(no attempt to obscure the time or prevent logging, just header-zapping.)
University ombudsman's offices could be a good approach,
and might help get around the occasional reactive sysadmins.
But that's inside the firewall, though I suppose you could
use them for outgoing mail as well. 

Another use for inside-to-outside remailers is to preserve the privacy of
internal addresses, though that's more likely to need a service which 
replaces the originating headers with the real user's name, using some 
authentication to prevent forged email from the company president, etc.

Any suggestions on getting companies to accept outside-to-outside-capable
remailers on their gateways, or outside-to-inside?


		Anonymity is cool, heh,heh..
			Beavis





From shamrock at netcom.com  Sun Feb  5 23:50:18 1995
From: shamrock at netcom.com (Lucky Green)
Date: Sun, 5 Feb 95 23:50:18 PST
Subject: Zimmermann charges NOT dropped
Message-ID: <v01510107ab5b7ff342ba@[192.0.2.1]>


At 9:04 PM 2/5/95, Timothy C. May wrote:

>Anyway, my apologies. I sometimes think I am talking to the 20-30 of
>you who post regularly, and can thus feel free to ask about a report
>I've heard. But, as Hal Finney and others have also discovered, this
>is not the case...boundaries are changing in cyberspace.

Very true. I tend to forget that this list isn't just composed of the few
co-conspirators I sometimes tend to believe to know so well from their
postings.

 How was Monte Carlo? I used to live in Nice for some years and made it to
Monte Carlo once in a while. <Hmm, haven't been in Europe for years, London
is really nice in April. All the lawns are covered in daphodyls. Got to get
some tickets tomorrow.>


-- Lucky Green <shamrock at netcom.com>
   PGP encrypted mail preferred.







From lcottrell at popmail.ucsd.edu  Sun Feb  5 23:53:08 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Sun, 5 Feb 95 23:53:08 PST
Subject: Mixmaster supports PGP
Message-ID: <ab5b846d020210042dbd@[137.110.24.250]>


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

Just wanted to officially announce the Mixmaster supports pgp encrypted
messages. I also want to plug using it as a second generation remailer
(that is why I wrote it). If you use a sun (that means you netcom folks),
get the front end from my home page.

Raph, please change the "mix" entry in your list to reflect pgp support.

Here is the Key:

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

mQCNAy8y6PAAAAEEAJF05HUUQM4n9G5wHOZ+bHZbF6yFmeX5wBGElssHqUnbb4PQ
S/f8jWvJyfiZkjlOkzOEJ47fZ++x+yYWgzKGUKp2ejIKu2MvnzgLfIkwKfxioPXq
xgBpLcFaDrbM52Mi4MEpEYW4DJqxk9TrAnHZBwXmxpOZQ57UcgbmF1BLzawNAAUR
tC5NaXhtYXN0ZXIgUmVtYWlsZXIgPG1peG1hc3RlckBuYXRlbHkudWNzZC5lZHU+
iQCVAwUQLzLpflVkk3dax7hlAQH2GQP9FGBU7uGako4YghrUNzyb3tcdwZwsGkBx
Gy9MGojOSwWgXQ0CRLD9+IWgkZnRY902pU65C3IZhFB7erXBk5eyGOXhbahHv07o
mhHRiE2v4Z9hNapWVHHeDo0F2AoL7B8kkiFjXI2fVYzofB6gmXd7X8Wzh/9AEQsz
63U8X9cbajyJAJUDBRAvMulXBuYXUEvNrA0BAQOkA/9QfgNGLp6MX1Qwk55uLiHG
ajeT+Rtgruaj9DPOoZFVj9w0pImBkCQNw5eA6iZTgiAqkbSG7RaR9yKMU27Gf/O+
yz3cWAx4slFmCpVDlEl5qSa1Bd+2LuneN4EvnxfeI7TLUIFKlPcIOnx9zsu5Ny0I
SCtHVHBaGw43OT1OYmLjgA==
=Zr4D
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzXU7lVkk3dax7hlAQHsrgP9G0NyW4RDvWOXa5BiWnr9gk6+Yq0bW0v8
gXZcn3tyzy3VAarmk09JLZOCnIADP9/zZXVEhJsXGDH/2O2j8IzBCCewCv9DnFcq
VnGtzwTHUdeLROSiOZYgwvhdtUgLdhB76c0akJhlNcVv7xMVEPRMqGtSMC/BPbTd
d9xUaQz/ibk=
=/0EA
-----END PGP SIGNATURE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From tcmay at netcom.com  Mon Feb  6 00:00:52 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 6 Feb 95 00:00:52 PST
Subject: New directions in anonymity (needed)
In-Reply-To: <01HMPLWWZOXU90B2L7@delphi.com>
Message-ID: <199502060743.XAA01417@netcom14.netcom.com>


Mike Ingle wrote:
> 
> There has been a lot of talk about anonymity and the best ways of providing
> it recently. Anonymity now is about where cryptography was before Diffie and
> Hellman's paper, or untraceable transactions before Chaum. To use it, you
> have to trust someone, or at least a group of people.
> 
> All of our anonymous systems boil down to only two techniques: indirection
> and broadcast. Indirection is sending a message through one or more
> intermediate nodes to conceal its point of origin. Broadcast is sending a
> message to multiple recipients to conceal the intended recipient.

First, I think it important to clearly distinguish between "sender
anonymity," where the physical identity or sending site is hidden, and
"receiver anonymity," where the same is true of the receiving site.

Chaumian digital mixes--what you Americans call "remailers"--mainly
solves the sender anonymity problem. Message pools, or broadcast to a
group or site that includes the receiver, mainly deals with receiver
anonymity. The combination of the two deals with both.

Both are solved elegantly with the Dining Cryptographer's Protocol,
about which much is written on this list every few months. Messages
are "sent" in an Ouija-board fashion and received by the person who
can successfully decrypt a public message sent over the system.

The process can be made information-theoretically secure, with
one-time pads used instead of ciphers. But, as Mike Ingle points out
here, the process can be compromised if _enough collusion_ exists. Ah,
but so can all known systems!

Digital money is not untraceable if you're the only person in the
universe (or in _your_ uhiverse...same difference) who is using it, or
if the banks, shops, and other customers are in collusion, leaving you
as the one and only user. (Proof: The banks and shops are not actually
using digital cash, leaving the "mark"--pun intended--as the only
person merrily spending digital cash. Ergo, all purchases made with
digital cash are traceable to this mark. I can imagine contrived
situations in the early days of digital cash when this kind of set-up
occurs.) 

My intuition is that any cryptographic situation in which an
individual/entity can be "isolated" so that all other individuals and
entities, and all connections, can be compromised (added to the set of
colluders) will be "broken." How else could it be?

Anyway, I think DC Nets are every bit as secure as e-cash is.
Obviously the security depends on a bunch of things, but the concept
of anonymous communication is not weaker in any fundamental way than
is digital cash. Full collusion by everyone who is not "you" causes
big problems with any cryptographic system that I know of.

(Stuff about reply blocks elided. I agree that more work is needed to
understand attacks on reply block methods. However, I'm not at all
convinced that "tracking back" is any different from the conventional
approach of demanding input-output mappings at each level, by
subpoenaing the remailer's records, etc. But I'll think about this
some more and maybe comment at another times.)

> Broadcast is exactly as secure as it is nonscalable. If you broadcast to 100
> people, an attacker's uncertainty is one in 100. The security grows linearly
> with the overall bandwidth. For cryptographic-level security, it would need
> to grow exponentially with bandwidth.

This gets to the important point of _proving_ vs. _suspecting_. To
make this concrete, consider that 10,000 people may download the
entire contents of, say, "alt.anonymous," a message pool newsgroup
created largely for the publication of anonymous messages.

The Internetpol may _suspect_ that one of these 10,000 readers is the
person to whom the messatge is intended, but cannot _prove_ it. Even
if the list of readers is down around 100, I know of no legal systems
that would accept this as proof. (There are many issues here, and many
more detailed scenarios. For example, over the course of time, as
readership changes but some readers remain readers, patterns may
emerge from the noise. And there are issues of bandwidth. I am not too
worried about running out of bandwith soon, since an awful lot of text
messages can fit into just a single one of the MPEG or JPEG images
that flood the *.pictures newsgroups...and these *.picutures
newsgroups are sent to and locally stored on tens of thousands of
machines....) 

> Anonymity needs something fundamentally new, something comparable to public
> key for cryptography or blind signatures for digital cash. Suppose a server

I think you ought to carefully look at Chaum's work on Dining
Cryptographers. It does all this. (It ain't perfect, and it ain't been
implemented in practical terms, a la a "Pretty Good Dining
Cryptographers," but it's at least as basic a concept as the other
things are....some might say that all are variations on the same theme.)

> has a large file. A message comes in and is combined into this file. Another
> message comes in with a key to retrieve data. The server processes the
> retrieval key against this large file and comes up with an output, which it
> returns to the person doing the retrieving. This output contains the input
> message, transformed in such a way that even the server cannot match it
> to the input that produced it. This is what we need.

But how is this any less "suspcious" in terms of pointing to the
receiver than is the more general and easier process of simply
retrieving the file from the server? Why would doing some sort of
computation on the distant server make the act of access any less
incriminating.? If 100 people all retrieve the file, they're the
"suspects," despite nothing being provable. And if those 100 people
first tell the server to do some particulary transformation, they're
still equally suspect. (Unless they tell the server to use a chain of
remailers to do the retransmission to them, which is different from my
understanding here, and is in fact the "anonymous anonymous ftp" we've
long talked of.) And if fewer than the 100 people actually send the
message, then of course the list of suspect is even smaller. (The
advantages of passive, do-nothing broadcast are lost, a net lose.)

> It would require three keys: an encryption key, a selection key, and a
> decryption key. The sender uses the recipient's encryption key to encrypt
[stuff elided]

Be careful also not to assume the server is trustable, as I gather it
is presumed to be here. (Doing the transformations, and all.)

> A method like this would permit anonymity without trust, much as public key
> allows secrecy without trust and digicash allows transaction privacy without
> trust. Is there any way to do it? There are functions like the Fourier
> transform that can distribute data over a large file, but the inverse
> function gives you back the same data. We need the not-so-inverse function
> to give back a different piece of data, but one that can be converted, by a
> private key, into the original, which the server never sees.

I expect broadcast models, or anonymous anonymous ftp models, to be
more sophisticated than simple "publish everything in alt.anonymous"
strategies. That is, multiple routes, multiple places, hierarchies,
etc. All involve trade-offs in time, space, security, cost,
convenience.

Some methods may involve splitting files into multiple pieces for
independent retrieval. However, I am not really convinced that the
alleged problems are solved this way.

The point about "which the server never sees" is confusing to me.
Surely the server _could_ see the transformed data if he wanted to, as
he was the one who did the remote transformation (as I understand
Mike's scheme). (If the scheme involves a server which can do
transformations but not see the output, then this is a much harder
problem, dealing with models of computation, secure hardware, etc.)

(The idea of a sealed box which executes a model in which no records
are kept, etc., is of course Chaum's original 1981 concept of a
digital mix. No "key" need be sent by the recipient if in fact the box
executes the proper mix function, keeps no records, is not
compromised, etc. If Mike is suggesting that his "server" behave more
like a true digital mix and thus not be as dependent as on human
trust, then of course this is a good idea. We need more mix-like
boxes, for our remailings. This has nothing to with the broadcast
model per se, dealing as it does with the general mix issue.)

In any case, what difference does it make if the server sees the data
or file? He surely can track his internal CPU processes and know which
incoming file was sent out, and to which address! (Just the remailer
in-out mapping problem again, which has always been unconcerned with
the internal contents of files.)

Sorry for the length here.

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay




















From strick at versant.com  Mon Feb  6 00:04:41 1995
From: strick at versant.com (strick -- henry strickland)
Date: Mon, 6 Feb 95 00:04:41 PST
Subject: The SKRONK protocols (version 0.6)
In-Reply-To: <01HMPOWDUA1M91MP0I@delphi.com>
Message-ID: <9502060806.AA07087@versant.com>


THUS SPAKE Network Security Observations <NSO at delphi.com>:
# Henry,
# I would like to publish the working doc. in the next available issue 

Go ahead; I place the document in the public domain.

# of Internet Security Monthly. Obviously with a request to respond.

It would be kind if you sent me a copy of the issues that discuss it.
I'm not familiar with the journal.  If it's on paper, ask for my USPS address.

# Do you have any further material that you prefer to go along with it ?

Nope, that says what I have to say right now.  

The followup discussion on Cypherpunks has been helpful to me;
the punks mostly made good points and correct observations.  


		best regards, strick






From lmccarth at ducie.cs.umass.edu  Mon Feb  6 00:08:52 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Mon, 6 Feb 95 00:08:52 PST
Subject: New directions in anonymity (needed)
In-Reply-To: <01HMPLWWZOXU90B2L7@delphi.com>
Message-ID: <199502060810.DAA27099@ducie.cs.umass.edu>


Mike Ingle writes:
[...]
> Anonymity needs something fundamentally new, something comparable to public
> key for cryptography or blind signatures for digital cash. Suppose a server
> has a large file. A message comes in and is combined into this file. Another
> message comes in with a key to retrieve data. The server processes the
> retrieval key against this large file and comes up with an output, which it
> returns to the person doing the retrieving. This output contains the input
> message, transformed in such a way that even the server cannot match it
> to the input that produced it. This is what we need.
[...]

In a naive model, the sender could encrypt the message with two distinct 
public keys belonging to the intended recipient. The server shuffles the
result randomly with all its other messages. The recipient sends the private
key associated with the outer layer of encryption to the server, which in
turn finds something to decrypt with that key. Finally the recipient receives
the singly-encrypted message, and uses her other private key to decipher the
message. This still places full trust in the server, though.

It's trivial for the server to log each incoming message separately, noting 
the sender, in addition to combining it with the melange of all received 
traffic as expected. Thus the protocol above fails, since the server can
simply test-decrypt each distinct original file with the private key supplied
by the intended recipient, thereby linking the ends of the communication. 

So the function computed on the melange file and the recipient-supplied key 
must not do anything extraordinary when applied to the original message and 
the recipient key. Actually, it's much worse than that. The server could 
create a mock melange file, combine each original message with it, then apply
the extraction function to each resulting melange and the recipient key. Since
the recipient has no control over the previous state of the melange file, prior
to the arrival of the message for her, the extraction function can't depend in
any detailed way upon the contents of the melange. Therefore, I believe it's
impossible to specify an extraction function immune to melange spoofing by the
server.

-L. Futplex McCarthy, seeking summer employment in computer science; background
 mainly in theoretical CS, but open to many alternatives [private email please]




From greg at ideath.goldenbear.com  Mon Feb  6 00:23:33 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Mon, 6 Feb 95 00:23:33 PST
Subject: Remailer msgs ideath -> rebma don't work.
Message-ID: <199502060821.AA08985@ideath.goldenbear.com>


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


Remailer messages sent via remailer at ideath.goldenbear.com to 
remailer at rebma.mn.org are failing; the system which handles my
mail upstream can't seem to connect to rebma. I'm going to try
to get things ironed out, but until then the ideath -> rebma path
should be avoided.

Sorry for any inconvenience; the bounced messages have been
discarded.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzXb4X3YhjZY3fMNAQErKgP+ND8r1sqXs3PXv87rL8IGTJ8j7FB4gmXI
YwDC3jNWHdOimVoK0zJS8utCAk9VlUDW7azXjBuXs+1qpMiygG9Nr7Up8iGaejM4
sV8906vU/+Hq+Dvd/fZn1tkfL7dB8qKUMpi7aNFz0YbadCvE79MYzLBuzUVKCJTm
j17jVq6tpX4=
=C3mW
-----END PGP SIGNATURE-----




From lmccarth at ducie.cs.umass.edu  Mon Feb  6 00:47:19 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Mon, 6 Feb 95 00:47:19 PST
Subject: Legal implications of one-of-a-group guilt
In-Reply-To: <199502060743.XAA01417@netcom14.netcom.com>
Message-ID: <199502060849.DAA27258@ducie.cs.umass.edu>


Tim May writes:		[welcome back, Tim]
> The Internetpol may _suspect_ that one of these 10,000 readers is the
> person to whom the messatge is intended, but cannot _prove_ it. Even
> if the list of readers is down around 100, I know of no legal systems
> that would accept this as proof.

Well, I'm not so sure. DNA fingerprinting has soared in popularity for
criminal cases over the last decade or so. From the figures I vaguely recall
being quoted, such evidence of a DNA match narrows down a list of
suspects to a mere few hundred thousand people, and is commonly admitted into
evidence. This situation is reminiscent of that phenomenon, IMHO.

I imagine that the looser standard of evidence in civil cases would make such
information quite significant in determining "the preponderance of evidence".

It would be interesting to hear from some folks with legal training on this 
issue, if only to correct my mistakes. IANAL.

 -L. Futplex McCarthy; PGP key by finger or server   "The objective is for us 
  to get those conversations whether they're by an alligator clip or ones and 
  zeroes. Wherever they are, whatever they are, I need them." -FBI Dir. Freeh




From an448 at freenet.carleton.ca  Mon Feb  6 01:33:14 1995
From: an448 at freenet.carleton.ca (Yves Bellefeuille)
Date: Mon, 6 Feb 95 01:33:14 PST
Subject: Legal implications of one-of-a-group guilt
Message-ID: <199502060933.EAA16328@freenet2.carleton.ca>


>Well, I'm not so sure. DNA fingerprinting has soared in popularity for
>criminal cases over the last decade or so. From the figures I vaguely recall
>being quoted, such evidence of a DNA match narrows down a list of
>suspects to a mere few hundred thousand people, and is commonly admitted into
>evidence. This situation is reminiscent of that phenomenon, IMHO.
>
>I imagine that the looser standard of evidence in civil cases would make such
>information quite significant in determining "the preponderance of evidence".
>
>It would be interesting to hear from some folks with legal training on this 
>issue, if only to correct my mistakes. IANAL.

Well, I missed the beginning of this, but here's the general principle.
Any evidence is admissible which makes it more likely that whatever you're
trying to prove is true rather than untrue.

For example, I want to prove that you stole my watch. I can prove that the
thief is a man: since you are a man, this makes it more likely than before
that you are the thief. It doesn't prove that you did it, but it goes in
that direction -- it narrows it down. Okay? 

Now, here's the important corollary. If the jury is likely to give undue
weight to the evidence, it can be inadmissible even though it would be
admissible under the general principle. Lie detector tests are a good
example of this, at least in Canada: they're not admissible, and the
reason they're not admissible isn't because they don't prove with 100 %
certainty, but because the jury is likely to think they're much more
reliable than they actually are. 

Since I have no idea what the original topic was, I leave it to you to
apply these general rules to your specific concern as an exercise. :-)

Disclaimer: Since I'm in Canada, obviously I can't give any advice
regarding US law.

Regards,

--
Yves Bellefeuille, Ottawa, Canada
an448 at freenet.carleton.ca (finger here for PGP key)
ua294 at fim.uni-erlangen.de





From rrothenb at ic.sunysb.edu  Mon Feb  6 02:00:36 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 6 Feb 95 02:00:36 PST
Subject: Excerpts of signed messages
In-Reply-To: <199502060423.UAA18043@jobe.shell.portal.com>
Message-ID: <199502061000.FAA01701@libws4.ic.sunysb.edu>


> (I forget if this was posted here last year, it sounds familiar.)

Some of us are relatively new to the list...
> 
> Suppose I get a PGP-signed flaming message, full of insults, and at the
> end it says, sarcastically, "For a stupid moron, you've made some very
> nice postings."  I could choose to excerpt this last part, "...you've made
> some very nice postings", and exhibit it in signed form.  What I would do

In other words, you'd like to retain an excerpt from the message with the
signature still intact?

Problem with that is how do you prevent one from creating a clerverly made
excerpt that distorts what one is saying (but has a valid signature)? It
seems your example does this very thing.

Better to quote the unsigned portion but retainthe original signed message
as evidence that the excerpt is Ok.

[ Snip! ]

> The checker would know he was dealing with an excerpt, and that it came
> from the end of the message, but he would have know way of knowing what
> was in the part that was removed.

That's the problem, of course.

> 
> Hal
> 





From rrothenb at ic.sunysb.edu  Mon Feb  6 02:03:53 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 6 Feb 95 02:03:53 PST
Subject: dna ink
In-Reply-To: <Pine.3.89.9502052222.B22385-0100000@Joyce-Perkins.tenet.edu>
Message-ID: <199502061003.FAA01784@libws4.ic.sunysb.edu>



> I just saw an item on CNN about a company in LA called Art Guard.  It 
> sells an ink that is created using your dna as a protection against 
> forged signatures.
> 
> Interesting.

Yes, I've seen that too. They insisted it will always be secure, especially
if one keeps changing the ink...

...probably will be until DNA cloning becomes cheap and accessible...

BTW, I think that company also had other ideas to use cheap cloning technology
such as distributing icons of famous people (Jerry Garcia was an example) that
had bits of their DNA in them... 

> 
> Dan
> 
> 
Rob





From perry at imsi.com  Mon Feb  6 02:26:23 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 6 Feb 95 02:26:23 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <199502060431.UAA18798@largo.remailer.net>
Message-ID: <9502061025.AA03724@snark.imsi.com>



Eric Hughes says:
> Perry advocates IPSP as an almost-panacea for Internet security.  I
> disagree.

Well, no; it doesn't fix things like mail for which the data needs to
be protected but not the link. However, I think I can answer some of
your other objections...

> TIA on netcom.

TIA is sort of a short term hack people are using to get around having
to have their administrators manage SLIP or PPP properly; I suspect
this difficulty will vanish with time.

> It's fallacious to argue simply that everyone's going to be _on_ the
> Internet soon enough anyway,

Well, IBM of all firms is trying very hard to make sure you are, and
Microsoft is even investing in UUNet to try to make sure of it, too.

Remember, by the way, that PPP is far cheaper per customer than shell
accounts, even though moronic providers right now don't make it look
that way.

IP is ultimately designed to be a proxy protocol that will work over
anything -- stuff like TIA simply gets around temporary mental
difficulties among providers in seeing things that way...<

Perry





From nzook at bga.com  Mon Feb  6 03:30:23 1995
From: nzook at bga.com (Nathan Zook)
Date: Mon, 6 Feb 95 03:30:23 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <Pine.3.89.9502060510.C19655-0100000@ivy.bga.com>


 
kevin at elvis.wicat.com:
 
>Be gentle, though - it's my first time.
 
Here?  You jest.  ;)
 
>It seems to me that the current remailer web suffers a fundamental flaw.
>It is simply too static. When a remailer disappears, service is
>disrupted and messages are lost. Humans have to statically route their
>messages through the web either by hand or using relatively primitive
>tools such as the chain script (not to belittle the useful work that has
>been done, but it is by no means idiot proof yet). Basically, the
>current web of mailers shows nothing of the dynamic nature that has kept
>the internet alive and has offered us a decent chance at truly anonymous
>communications, nor is it easy to use to its full potential.
>
>Consider a more dynamic web of remailers. I envision remailers that
>actively advertise their presence on the web so that all active
>remailers are aware of all other active remailers. This advertising is
>to have very low latency so that a new mailer can be known to the web
>within minutes (I will address the implementation of this later). Thus,
>remailers can constantly be appearing and disappearing without impact on
>the web as a whole (I refer to this dynamic web of remailers as a
>"froth"). Imagine also that remailers are allowed to dynamically perform
>the routing functions that are currently done statically offline (for
>reasons I will discuss shortly).
>
 
Some version of this discussion came up a few months ago, and I passed on
it then, but I think I've heard enough to comment now:
 
The remailers are based on an inherently different model than the InterNet.
Some of these differences, in fact, are crucial.
 
1) The InterNet is based on mutual cooperation/mutual trust.  Cypherpunks
   trust no one that they don't have to.
 
This is not just a result of our twisted psyche.  If we could trust
everyone, we wouldn't _need_ remailers.  Since we don't even know who is
whom out there, we avoid extending trust.
 
2) The InterNet is concerned first about reliability, and not at all about
   privacy.  The remailers are concerned first about privacy, and can leave
   reliability to the users, if need be.
 
There is nothing to prevent Alice and Bob agreeing to send each other ACK
statements, and retransmitting messages if they don't get the ACK.  There
has been some mention of remailers doing the same with each other, in an
attempt to improve net-wide reliability.  BTW, with T1, sending ACKs is not
unreasonable between remailers.
 
3)  From 1) and 2).  The remailers are heading towards mandatory PGP,
    possibly nested.  All InterNet messages are world-readable--although
    this may be changing as the model breaks down.
 
Again, this has to do with the intrinsic diffences.
 
>The use of such transient routers implies allowing dynamic routing. If
>any given remailer may go down or move at any point, it is impractical
>to expect users to keep track of which are up at the moment and create
>static routes in the current manner. The only reasonable solution I have
>come up with is to allow the remailers themselves to choose routing,
>given that they have full knowledge of the current state of the froth.
 
Here we have the real head of the problem, as Hal so asutely points out:
in your model, if the first remailer is bad, the message is compromised.
If user encrypt to all remailers, they might as well encrypt directly to
mole at snakeoil.nsa.gov.  If they don't, they severly limit who can pick out
their messages.  In particular, they bypass transient remailers.
 
But that isn't all.  If the remailers pick the route, they are in a no
better state than the users.  Since the flushing attack requires remailers
to operate on ticks, with carryover, an hour delay per remailer is almost
minimal, untill traffic really picks up.  So if some message routes through
four remailers, a minimum of four hour delay results.  In your case, this
could easily move between in/out of service modes.
 
 
>                 Think about the proposed extension to MixMaster to
>allow separate parts of a multi-part message to be routed separately,
>and consider whether you really want to have to do this by hand. I
>strongly suspect that most messages are currently routed via boilerplate
>scripts, which has to make the job of traffic analysis much easier for
>our good friend Eve.
 
Stupid is as stupid does.
 
 
>By the way, a brief rant on a related topic; people speak of not
>trusting remailers any further than necessary, while I am clearly
>suggesting granting more authority and trust to the remailers. This
>notion of not assigning trust is simply nonsense. When you send a piece
>of mail to a remailer, encrypted or not, you are assigning complete
>trust in that remailer to keep you anonymous and not to forward your
>mail to the NSA immediately.
 
NOT TRUE.  With proper use of encryption, you are trusting your first
remailer only to not reveal that you sent a message, and not to correlate
that message to the one it sends out.  With rational use of garbage running
two deep, you can even suffer this loss without significant harm.
 
 
>This does lead to a related problem, however; if we allow remailers to
>pop up at random and join in the froth, how do we know that Deitweiller
>won't set up a number of black hole remailers that take your mail and
>throw it away, disrupting the froth, or forward it to nphard at nsa.gov?
 
How indee  The reason we chain is buse we _don't_ really trust our
first remailer--or any other.
 
>Fortunately, we already have the PGP web of trust model in place and can
>use it to good effect in this case. Remailers should simply not route
>mail through any remailer whose public key is not trusted unless
>explicitly ordered otherwise. This requires remailer operators to
>cooperate to some extent to validate one another's remailer keys, but
>does confer the great advantage of portable remailers as mentioned
>above; if I run a trusted remailer on one machine, I can move it to
>another machine, and as soon as I advertise the new address and the PGP
>public key, it is a trusted and useful part of the froth.
 
Actually, there may be something here.  I don't know about you all, but my
PGP isn't very happy about all these new remailer keys.  We could agree to
the following standard:  Signing a remailers' key means that you believe
the remailer to be secure.  Trusting a remailer key means trusting the
remailer operator to validate other remailer's security.  This adds a whole
new meaning to the phrase, "key compromise certificate".
 
 
>While we are advertising a PGP key and internet address, we might as
>well incorporate other useful information. For instance, remailers could
>advertise their maximum latency. 
 
While I agree that it is useful to post the operating characteristics of
the remailers, the maximum latency must theoretically be infinite in the
standard model to prevent flushing attacks.
 
>    Kevin
 
 
 
Hal <hfinney at shell.portal.com>:
 
 
>I do like Kevin's ideas about a dynamic remailer net, but I think
>another approach would put more smarts into the client program used by
>the originator.  
 
Hear ye, hear ye!  And along those lines...
 
I'm scetchy (at best) by what is meant by "pinging" a remailer.  Would it
not be possible for live-on-the-net remailers to accept a (socket?) quick
check to see if they are online?  If so, then the ping would only work if
the remailer was active when tried.  Furthermore, client software could
startup by sending out these pings, and presenting only responding
remailers to the user--with an exception list for those not "live".
 
Nathan






From nzook at bga.com  Mon Feb  6 03:31:24 1995
From: nzook at bga.com (Nathan Zook)
Date: Mon, 6 Feb 95 03:31:24 PST
Subject: Cooperation
Message-ID: <Pine.3.89.9502060545.E19655-0100000@ivy.bga.com>


Hal:
   I agree that it is to our advantage to minimize the cooperation between
remailers, for the following reasons:
 
1)  The existance of a cabal dominating such a function admits the
posibility of the abuse of power, for whatever reason.
 
2)  The requirement of cooperation between remailers limits the size of the
remailer net to the number of operators that can effectively cooperate with
each other.  (Yes, we can extend via overlapping groups, but this
introduces chokepoints--another weakness.)
 
3)  The requirement of cooperation between remailers raises the cost (in
time and legal vulnerabilities) to enter the remailer net.
 
4)  Failing all of these, there is a real chance (happening even now) that
users will trust the operators too much.
 
 
But there is a major difference between active cooperation and agreeing to
a standard.  Active cooperation is just that--something which cannot be
automated, or which involves automated judgement decisions.  I claim that
my ideas are merely standards.  A standard which might even be extendable
into the dominions of a hostile government.
 
Nathan
 






From tcmay at netcom.com  Mon Feb  6 03:55:41 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 6 Feb 95 03:55:41 PST
Subject: Cooperation
In-Reply-To: <Pine.3.89.9502060545.E19655-0100000@ivy.bga.com>
Message-ID: <199502061154.DAA11069@netcom15.netcom.com>


Nathan Zook wrote:

> But there is a major difference between active cooperation and agreeing to
> a standard.  Active cooperation is just that--something which cannot be
> automated, or which involves automated judgement decisions.  I claim that
> my ideas are merely standards.  A standard which might even be extendable
> into the dominions of a hostile government.

Yes! Standards are not collusion. In fact, standards can lessen the
amount of ad hoc contact needed between remailer operators, and thus
reduce somewhat the prospects for compromise and collusion.

Robust standards are also helpful for building "hands-off" remailers,
in which remailer account owners take a hands-off approach, possibly
even to the point of creating the accounts and then never checking
again.

The proposals I've made, sometimes called a "Remailer's Guild," were
not for a cabal, but for a market standard that would tend to reward
those who follow certain standards and punish (all in a market sense)
those who flout standards just for the sake of being different.

(The real idea was to get some progress on deciding on some features
and terminology, to the point that a "Release" version could be
produced, like PGP 2.6, for example.)

It may be that such convergence on standards can be done without any
contact at all, just through market forces and things like pinging
scripts. The remailer analog of a self-healing network, rerouting
around brain-damaged sites.

--Tim May, posting at 3:55 a.m. because this is my jet lag rebound
period, in which I can't go to sleep because I slept for 11 hours upon
my arrival at home


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From skaplin at mirage.skypoint.com  Mon Feb  6 06:27:43 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Mon, 6 Feb 95 06:27:43 PST
Subject: Change to the congressional contact list
Message-ID: <Pine.SV4.3.91.950206082059.3359A-100000@mirage.skypoint.com>


The congressional fax/phone list that I recently posted has at least one 
error in it. Senator Rod Grams' fax number is (202) 228-0956. The amended 
list will be available on the auto-responder in about 15 minutes. To get 
a copy:

Send a message to: skaplin at c2.org
With the subject: SEND FILE congresscritter.104

You should get it within two hours.

Sam





From raph at CS.Berkeley.EDU  Mon Feb  6 06:49:53 1995
From: raph at CS.Berkeley.EDU (Raph Levien)
Date: Mon, 6 Feb 95 06:49:53 PST
Subject: List of reliable remailers
Message-ID: <199502061450.GAA28746@kiwi.CS.Berkeley.EDU>


   I operate a remailer pinging service which collects detailed
information about remailer features and reliability.

   To use it, just finger remailer-list at kiwi.cs.berkeley.edu

   There is also a Web version of the same information, at:
http://www.cs.berkeley.edu/~raph/remailer-list.html

   This information is used by premail, a remailer chaining and PGP
encrypting client for outgoing mail, which is available at:
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.30.tar.gz

   For the PGP public keys of the remailers, as well as some help on
how to use them, finger remailer.help.all at 204.95.228.28

This is the current info:

                                 REMAILER LIST

   This is an automatically generated listing of remailers. The first
   part of the listing shows the remailers along with configuration
   options and special features for each of the remailers. The second
   part shows the 12-day history, and average latency and uptime for each
   remailer. You can also get this list by fingering
   remailer-list at kiwi.cs.berkeley.edu.

$remailer{"vox"} = "<remail at vox.xs4all.nl> cpunk pgp. post";
$remailer{"avox"} = "<anon at vox.hacktic.nl> cpunk pgp post";
$remailer{"extropia"} = "<remail at extropia.wimsey.com> cpunk pgp special";
$remailer{"portal"} = "<hfinney at shell.portal.com> cpunk pgp hash";
$remailer{"alumni"} = "<hal at alumni.caltech.edu> cpunk pgp hash";
$remailer{"bsu-cs"} = "<nowhere at bsu-cs.bsu.edu> cpunk hash ksub";
$remailer{"rebma"} = "<remailer at rebma.mn.org> cpunk pgp hash";
$remailer{"c2"} = "<remail at c2.org> eric pgp hash";
$remailer{"soda"} = "<remailer at csua.berkeley.edu> eric post";
$remailer{"penet"} = "<anon at anon.penet.fi> penet post";
$remailer{"ideath"} = "<remailer at ideath.goldenbear.com> cpunk hash ksub";
$remailer{"usura"} = "<usura at replay.com> cpunk pgp. hash latent cut post";
$remailer{"desert"} = "<remail at desert.xs4all.nl> cpunk pgp. post";
$remailer{"nately"} = "<remailer at nately.ucsd.edu> cpunk pgp hash latent cut";
$remailer{"myriad"} = "<remailer at myriad.pc.cc.cmu.edu> cpunk pgp hash latent cut ek";
$remailer{"xs4all"} = "<remailer at xs4all.nl> cpunk pgp hash latent cut post ek";
$remailer{"flame"} = "<tomaz at flame.sinet.org> cpunk pgp hash latent cut post ek";
$remailer{"rahul"} = "<homer at rahul.net> cpunk pgp hash";
$remailer{"mix"} = "<mixmaster at nately.ucsd.edu> cpunk hash latent cut ek";
$remailer{"q"} = "<q at c2.org> cpunk pgp hash latent cut ek";
$remailer{"syrinx"} = "<syrinx at c2.org> cpunk pgp";
$remailer{"tower"} = "<remailer at tower.techwood.org> cpunk pgp";
$remailer{"eniac"} = "<vanklava at eniac.ac.siue.edu> cpunk pgp hash latent cut";
$remailer{"charon"} = "<charon at styx.jpunix.com> cpunk hash latent cut ek";
$remailer{"bonafide"} = "<remailer at bonafide.jpunix.com> cpunk hash latent cut ek";
$remailer{"ford"} = "<ford at prefect.jpunix.com> cpunk hash latent cut ek";
$remailer{"aegis"} = "<aegis at athena.jpunix.com> cpunk";
catalyst at netcom.com is _not_ a remailer.
lmccarth at ducie.cs.umass.edu is _not_ a remailer.

JPUNIX.COM offers a domain hiding service for remailers. Send email to 
perry at jpunix.com for more information. NOTE: JPUNIX.COM itself does not 
run a remailer. All subdomains of jpunix.com on this list are remailers 
that are not physically located on jpunix.com

Use "premail -getkeys remailer.help.all at 204.95.228.28" as a stopgap to
get PGP keys for the remailer, at least until Matt Ghio gets his
machine situation straightened out. Fingering this address works too.

Last ping: Mon 6 Feb 95 6:00:01 PST
remailer  email address                        history  latency  uptime
-----------------------------------------------------------------------
rahul    homer at rahul.net                  -*+****#-*+#    19:19  99.88%
alumni   hal at alumni.caltech.edu           +****-*##* #     9:02  99.87%
eniac    vanklava at eniac.ac.siue.edu         #***+#***#     6:06  99.88%
penet    anon at anon.penet.fi               *+**+*+++-+*  1:40:22  99.99%
tower    remailer at tower.techwood.org        *********#     7:38  99.88%
mix      mixmaster at nately.ucsd.edu        --*-++++++++    43:06  99.85%
nately   remailer at nately.ucsd.edu         --++++++++++    41:00  99.85%
portal   hfinney at shell.portal.com         +***#-*##* #     6:53  99.85%
xs4all   remailer at xs4all.nl               **-*+++**+**    16:46  99.75%
charon   charon at styx.jpunix.com               #-++-*      26:06  99.78%
bonafide remailer at bonafide.jpunix.com           ##****     6:39  99.68%
ford     ford at prefect.jpunix.com                ++-+++    27:13  99.67%
soda     remailer at csua.berkeley.edu       .--.._.....   9:02:42  99.56%
myriad   remailer at myriad.pc.cc.cmu.edu     +***-******    37:47  99.37%
vox      remail at vox.xs4all.nl             ...---..--   22:10:50  99.51%
usura    usura at replay.com                 *+-****+ ***    15:05  98.98%
aegis    aegis at athena.jpunix.com                          15:55  99.07%
c2       remail at c2.org                    +++ - ++-+++  1:44:28  97.95%
syrinx   syrinx at c2.org                    ***  +++-*      30:09  97.85%
q        q at c2.org                         --+--+++-++   1:13:16  97.75%
flame    tomaz at flame.sinet.org             +***-******    59:14  97.51%
bsu-cs   nowhere at bsu-cs.bsu.edu           ***+ *--**-*  1:38:08  96.72%
ideath   remailer at ideath.goldenbear.com   --------- --  2:04:17  95.12%
desert   remail at desert.xs4all.nl          .-___.-_.-   48:16:44  68.02%
rebma    remailer at rebma.mn.org            _.-_---      21:10:27  41.53%
extropia remail at extropia.wimsey.com                     5:04:09   6.34%

For more info: http://www.cs.berkeley.edu/~raph/remailer-list.html

   History key
     * # response in less than 5 minutes.
     * * response in less than 1 hour.
     * + response in less than 4 hours.
     * - response in less than 24 hours.
     * . response in more than 1 day.
     * _ response came back too late (more than 2 days).

   Options and features

   cpunk
          A major class of remailers. Supports Request-Remailing-To:
          field.

   eric
          A variant of the cpunk style. Uses Anon-Send-To: instead.

   penet
          The third class of remailers (at least for right now). Uses
          X-Anon-To: in the header.

   pgp
          Remailer supports encryption with PGP. A period after the
          keyword means that the short name, rather than the full email
          address, should be used as the encryption key ID.

   oldpgp
          Remailer does not like messages encoded with MIT PGP 2.6. Other
          versions of PGP, including 2.3a and 2.6ui, work fine.

   hash
          Supports ## pasting, so anything can be put into the headers of
          outgoing messages.

   ksub
          Remailer always kills subject header, even in non-pgp mode.

   nsub
          Remailer always preserves subject header, even in pgp mode.

   latent
          Supports Matt Ghio's Latent-Time: option.

   cut
          Supports Matt Ghio's Cutmarks: option.

   post
          Post to Usenet using Post-To: or Anon-Post-To: header.
          
   special
          Accepts only pgp encrypted messages.

   ek
          Encrypt responses in relpy blocks using Encrypt-Key:
          header.


Raph Levien





From corbet at stout.atd.ucar.edu  Mon Feb  6 07:37:21 1995
From: corbet at stout.atd.ucar.edu (Jonathan Corbet)
Date: Mon, 6 Feb 95 07:37:21 PST
Subject: Vinge on PKE ? (really idiot savants)
Message-ID: <199502061537.IAA20779@atd.atd.ucar.EDU>


> These so-called "idiot savants" can easily factor
> 100 digit numbers.  The ability to solve such problems is not tied to IQ,
> as there are many such people with IQs of 150+ who cannot solve them.

Gee...such a person could do a pretty thorough job on a 512-bit RSA key.
How many of them do you suppose the NSA employs?

:-)

jon





From an158409 at anon.penet.fi  Mon Feb  6 07:45:16 1995
From: an158409 at anon.penet.fi (beacher)
Date: Mon, 6 Feb 95 07:45:16 PST
Subject: Camden New Jersey
Message-ID: <9502061348.AA14911@anon.penet.fi>



I thought nothing but armed robberies happened in Camden New Jersey.

Teenage Pirate To Pay $25,000, Loses BBS Equipment
CAMDEN, NEW JERSEY, U.S.A., 1995 FEB 3 (NB) -- A teenage computer operator
charged with illegally distributing hundreds of copyrighted commercial
software programs has reached a settlement with Novell Inc., (NASDAQ: NOVL)
and Microsoft Corp., (NASDAQ: MSFT).

The settlement requires the operator of the now-defunct Deadbeat Bulletin
Board to pay $25,000 to Novell and Microsoft and forfeit the equipment he
used to run the board to the two software makers.

The agreement apparently closes the book on an investigation of the New
Jersey computer BBS (bulletin board service), which authorities said
contained several hundred commercial software products. The equipment was
seized in an August raid of the board.

This was just one of the cases investigated under an aggressive joint
campaign by Novell and Microsoft to locate and prosecute pirate system
operators. The project was mounted last summer and has already resulted in
the closing of two bulletin boards. The two companies said they expect more
seizures in the near future.

Pirate bulletin boards let users download commercial products, paying for
them in money or in barter by uploading programs the BBS doesn't have.
According to Novell the Deadbeat Bulletin Board also contained several beta
files, software which is still in the testing stage. Beta programs are often
incomplete or contain problems, and are distributed to a limited number of
users so those problems can be worked out before the final product comes to
market.

Novell and Microsoft investigators said they first got wind of the illegal
software in late July, and eventually discovered more than 60 Novell and
Microsoft products on the board. A court ordered seizure of the equipment and
the raid was carried out in August. The court records have been sealed until
now.

The agreement also prohibits Microsoft and Novell from any further action
against the 17-year old boy and from releasing his name.

(Jim Mallory/19950203/Press contact: Jessica Jersey, Novell, 408-577-8739;
Public contact: 800-785-3448 or 800-747-2837 to report suspected software
piracy)


-------------------------------------------------------------------------
To find out more about the anon service, send mail to help at anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin at anon.penet.fi.





From perry at imsi.com  Mon Feb  6 08:09:47 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 6 Feb 95 08:09:47 PST
Subject: Camden New Jersey
In-Reply-To: <9502061348.AA14911@anon.penet.fi>
Message-ID: <9502061609.AA04485@snark.imsi.com>



What does this have to do with cryptography per se?

.pm

beacher says:
> 
> I thought nothing but armed robberies happened in Camden New Jersey.
> 
> Teenage Pirate To Pay $25,000, Loses BBS Equipment
> CAMDEN, NEW JERSEY, U.S.A., 1995 FEB 3 (NB) -- A teenage computer operator
> charged with illegally distributing hundreds of copyrighted commercial
> software programs has reached a settlement with Novell Inc., (NASDAQ: NOVL)
> and Microsoft Corp., (NASDAQ: MSFT).





From MFROOMKI at umiami.ir.miami.edu  Mon Feb  6 08:48:13 1995
From: MFROOMKI at umiami.ir.miami.edu (Michael Froomkin)
Date: Mon, 6 Feb 95 08:48:13 PST
Subject: CFP'95 Program/Registration Information (fwd)
Message-ID: <Pine.3.89.9502061157.A589326734-0100000@umiami.ir.miami.edu>


---------- Forwarded message ----------
Date: Sun, 05 Feb 1995 12:43:36 -0500 
From: Carey Heckman <ceh at leland.Stanford.EDU>
To: Multiple recipients of list <cyberia-l at birds.wm.edu>
Subject: CFP'95 Program/Registration Information 

The Fifth Conference on Computers, Freedom and Privacy

Sponsored by:          * ACM SIGCOMM, SIGCAS, SIGSAC, and
                       * Stanford Law School

28 - 31 March 1995
San Francisco Airport Marriott Hotel
Burlingame, California

CONNECT WITH OTHERS WHO ARE DETERMINING HOW COMPUTERS AND TELECOMMUNICATIONS
WILL AFFECT YOUR FREEDOM AND PRIVACY... 

JOIN US AT CFP'95.

We have reached the crossroads of the Information Age.

No longer is the electronic frontier inhabited solely by a small band of 
technical pioneers sharing a common code of conduct. Computer and 
telecommunications technologies have become part of mainstream living, 
conversation, and politics. These changes compel us to reexamine the 
definition of our rights and the processes by which those rights are being 
defined. 

The Fifth 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 explore and better understand the
definition of our rights at this crossroads.

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.

Featured speakers include:

John P. Morgridge, Chairman, Cisco Systems
Esther Dyson, Release 1.0/EDVenture Holdings, Inc.
Roger W. Wilkins, Professor of History and American Culture at George 
	Mason University and commentator, National Public Radio
Margaret Jane Radin, Professor of Law, Stanford University
Willis H. Ware, RAND 

Some of the topics in the CFP'95 program include:

FREEDOM AND RESPONSIBILITY OF ELECTRONIC SPEECH -- Exploring recent
controversies in online free speech, including a Socratic forum
that will ask whether the Constitution can indeed be viewed through a
technologically transparent lens.

HIS MASTER'S VOICE... -- Probing the future for "net propaganda" from
governments, government officials, and politicians, and who will pay 
so whose message will get to whom.

STUDENT DATABASES: FOR EDUCATION AND FOR LIFE? -- Looking at how gaining the
benefits of nationwide information about K-12 students could also spell
serious privacy problems.

CAN THE NET SURVIVE COPYRIGHT? CAN COPYRIGHT SURVIVE THE NET? -- Delving
into the controversies surrounding copyright protection that throttles 
freedoms and copyright protection that protects just rewards for creativity.

INTELLIGENT TRANSPORTATION SYSTEMS: PAVING OVER PRIVACY -- Examining the
privacy implications of tracking and surveillance technologies now being
planned for vehicles and roadways nationwide.

"IT OUGHTA BE A CRIME..." -- Debating with law enforcement representatives
about who should set the rules for governing the net and when should bad 
manners become a crime.

WHEN DO THEY NEED TO KNOW 'WHODUNNIT'? -- Discussing the right time and
places for identified, anonymous, and pseudonymous transactions.

TRANSACTION RECORDS IN INTERACTIVE SERVICES: WHO WATCHES THE SERVERS? --
Looking at the issues raised by the collection of personal information
as part of the new interactive home entertainment, telecommunications,
and online services.

DEFINING ACCESS PARADIGMS: LIBRARIES, RURAL AREAS, AND INTERNATIONAL 
ASPECTS -- Evaluating the differing models of "open access" to Internet and
computer-mediated communications in the library, rural, and lesser-developed
country contexts.

THE CASE AGAINST COMPUTERS: A SYSTEMIC CRITIQUE -- Daring to discuss whether
computers may be doing our world more harm than good.

A NET FOR ALL: WHERE ARE THE MINORITIES? -- Examining how and to what degree
minority groups participate on the net and asking whether social class is
relevant to net participation or non-participation.

WHO OWNS THE LAW? -- Reviewing the debate over legal citation form and online
databases, and what it means to all of us.

CAN WE TALK LONG-DISTANCE? REMOVING IMPEDIMENTS TO SECURE INTERNATIONAL
COMMUNICATIONS -- Covering export and import controls, outright prohibitions,
and other technical and policy obstacles to secure international
communications.

The Fifth Conference on Computers, Freedom, and Privacy will also offer a 
number of in-depth tutorials on subjects including:

   *	Inside Washington: The New Congress and Secrets of Advocacy
   *	National ID Card Initiatives
   *	The Law of Fundamental Rights for Non-Lawyers 
   *	Everything You Need to Know to Argue About Cryptography
   *	Digital Activism
   *	Inside the World of Law Enforcement
   *	Intellectual Property for the Information Age 

FOR MORE INFORMATION ABOUT CFP'95:

Web:	http://www-techlaw.stanford.edu/CFP95.html
Gopher:	gopher://www-techlaw.stanford.edu/CFP95
FTP:	ftp://www-techlaw.stanford.edu/CFP95
Email:	Info.CFP95 at forsythe.stanford.edu
Fax: 	(415) 548-0840
Call: 	(415) 548-9673


                                REGISTRATION


Please register for the conference by returning the conference
registration form along with the appropriate payment by any
method listed below. The registration fee includes conference
materials, three luncheons (Wednesday, Thursday, and Friday), two
banquets (Wednesday and Thursday) and evening receptions
(Tuesday, Wednesday, and Thursday).

Registration Fees are:

If mailed by:     February 24    March 14    after 14 March

Conference Fees      $335          $395          $445
Tutorial Fees:       $155          $185          $220

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'95 Registration                    Send Registration Form
P.O. Box 6657                              (415) 548-0840
San Mateo, CA 94403                     Available 24 hours

By Phone:                            By Email (at your own risk*):
(with Credit Card only)                (with Credit Card only)
(415) 548-0840                  Register.CFP95 at forsythe.stanford.edu
9 am to 5 pm Pacific Time

   *	Information for sending a PGP-encrypted registration available at
	http://www-techlaw.stanford.edu/CFP95.html and
	ftp://www-techlaw.stanford.edu/CFP95.

CFP'95 Scholarships:
The Fifth Conference on Computers, Freedom and Privacy 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'95 Student Paper and Scholarship Chair, Gary Marx at: 
Gary.Marx at colorado.edu or call (303) 492-1697.

Hotel Accommodations:
The Fifth 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 February 17,1995, so we urge you to make your reservations *
* as early as possible.                                                 *
*************************************************************************

After February 17 but before March 15, the special conference rate will be
$110/night, single or multiple occupancy. 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 or fax (415) 692-8016.

Official Airlines:
Special convention airfare discounts have been arranged on American and United 
Airlines. Bungey Travel, (800) 286-4391 or (415) 325-5686 or fax (415) 321-
5309, will be happy to assist you in any manner. Please identify yourself as 
attending the Computers, Freedom, and Privacy Conference and you will 
automatically receive a 5% discount off nonrefundable discounted US tickets or 
10% off of all unrestricted US coach fares.






From hfinney at shell.portal.com  Mon Feb  6 08:51:56 1995
From: hfinney at shell.portal.com (Hal)
Date: Mon, 6 Feb 95 08:51:56 PST
Subject: Cooperation
Message-ID: <199502061651.IAA02758@jobe.shell.portal.com>


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

From: Nathan Zook <nzook at bga.com>
>    I agree that it is to our advantage to minimize the cooperation between
> remailers, for the following reasons:
> [...]
> But there is a major difference between active cooperation and agreeing to
> a standard.  Active cooperation is just that--something which cannot be
> automated, or which involves automated judgement decisions.  I claim that
> my ideas are merely standards.  A standard which might even be extendable
> into the dominions of a hostile government.

I see your point.  I tend to have something of a knee-jerk reaction
against proposals which put more responsibility into the hands of the
remailer operators, but as you say the mere promulgation of a standard
does not in itself require cooperation.  We have de-facto standards
right now, which is what makes chaining possible.

And from the technical point of view, the idea of remailers encrypting
between themselves seems to do no harm and could possibly make the
attacker's job potentially more difficult by reducing the amount of
information he has available.

One problem is that one remailer may not know about all of the others.
So to the extent that your proposal requires a registry of remailers, a
centralized service which keeps track of all remailers, I still have a
problem.  This is where my vision departs from those who see the
"remailer net" as an entity, and for whom the notion that remailers would
treat messages to each other specially is a natural assumption.  If you
would suggest that at each stage the message included not only the
address of the next remailer, along with the "payload" which was already
encrypted (by the sender) for that remailer, but in addition a key for
that remailer and a request to encrypt under that key, then I would feel
much better about it.  This way there is no need for the remailer to know
anything about whom it is sending to.

Likewise if we wanted to specify in the standard that messages could be
signed, that also would not imply collusion.  However to specify that
signatures must be checked would have some implications about acquiring
the necessary public keys through some means, and I don't think that
should be done.

I do like the idea of standards.  In fact I wonder if the current "mark
1" remailer command set shouldn't be documented as an Internet RFC.  It
has been in use for a couple of years now, evolving somewhat over that
time, and some twenty or thirty remailers have operated for some part of
that time following that spec.  It would also give a certain amount of
(undeserved, perhaps) respectability to remailer operators if there were
an actual numbered RFC which they were following.  And it does seem to me
that this kind of thing is exactly what the RFC's are for.  Certainly
there are a great many "minor" RFC's which are less followed than our
remailer standards.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzZTfBnMLJtOy9MBAQFsRwIA4A5EzFZwJdEmSvcfMmnu+RCAEGYK56dg
y2LBawLdYn5FNcnvH6YkfCMHIcWURm1b6emEsw32FVH2m6ScAAH/iQ==
=F2+s
-----END PGP SIGNATURE-----





From rogaski at phobos.lib.iup.edu  Mon Feb  6 09:56:05 1995
From: rogaski at phobos.lib.iup.edu (Mark Rogaski)
Date: Mon, 6 Feb 95 09:56:05 PST
Subject: dna ink
In-Reply-To: <Pine.3.89.9502052222.B22385-0100000@Joyce-Perkins.tenet.edu>
Message-ID: <199502061755.MAA14493@phobos.lib.iup.edu>


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

- From the node of Dan Harmon:
: 
: 
: I just saw an item on CNN about a company in LA called Art Guard.  It 
: sells an ink that is created using your dna as a protection against 
: forged signatures.
: 
: Interesting.
: 
: Dan
: 
: 

Faustus ... Faustus ... Why do you delay?

- -----
Doc					      doc at phobos.lib.iup.edu
aka Mark Rogaski			      http://www.lib.iup.edu/~rogaski/

Disclaimer:  You would probably be hard-pressed to find ANYONE who agrees
             	with me, much less my university or employer...

   [finger fllevta at oak.grove.iup.edu for PGP Public Key and Geek Code v2.1]


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzZicx0c4/pqJauBAQGgqQQAqOgSZNxJsR3UdEqASFUQ39divPhvbHnk
AIzG+Jut+CHm0DE+CvMb9ZHzPI6JTQt5gYSuN9OSqHkZ82uxv5gPJOvxHq3PXYoD
iaKkxnXPilWImuVHOUHVBpaCibfzdM4ZxYsj0bJSA8juB5G29LDI/3JeUvo8eJFX
A+wWkjbawIc=
=bpge
-----END PGP SIGNATURE-----




From cdbunch at bansai.ucs.uoknor.edu  Mon Feb  6 09:58:33 1995
From: cdbunch at bansai.ucs.uoknor.edu (Trool the Red Adept)
Date: Mon, 6 Feb 95 09:58:33 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <9502060202.AA03281@snark.imsi.com>
Message-ID: <9502061152.ZM18057@bansai.ucs.uoknor.edu>



On Feb 5,  9:02pm, Perry E. Metzger wrote:

> There is also SSL, which is what the Netscape people are pushing --
> stands for Secure Sockets Layer.
>
>
>-- End of excerpt from Perry E. Metzger

  Of course SSL is not really a solution.  First it requires that the server
have a well-known RSA public key.  It is also not an optional service so it
requires new well-known ports for the secure services (such as https ).  Also
for some strange reason it uses two session keys (both generated at the client
end) one for client->server and another for server->client.  Not to mention I
distrust any protocol with provisions for sending bits of my key in the clear.
	Clinton


-- 





From tedwards at src.umd.edu  Mon Feb  6 10:09:51 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Mon, 6 Feb 95 10:09:51 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <9502061025.AA03724@snark.imsi.com>
Message-ID: <Pine.SUN.3.91.950206130709.20818A-100000@thrash.src.umd.edu>


On Mon, 6 Feb 1995, Perry E. Metzger wrote:

> Remember, by the way, that PPP is far cheaper per customer than shell
> accounts, even though moronic providers right now don't make it look
> that way.

PPP/SLIP is currently not cheaper per customer - if you figure in the 
time your help desk staff put in over the first couple of weeks of a new 
customer coming on line.  Many people who have barely ever used a BBS are 
deciding they "need their internet connection" and going SLIP/PPP even 
where a shell account would do most of what they want.

-Thomas






From tedwards at src.umd.edu  Mon Feb  6 10:14:00 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Mon, 6 Feb 95 10:14:00 PST
Subject: Cooperation
In-Reply-To: <199502061154.DAA11069@netcom15.netcom.com>
Message-ID: <Pine.SUN.3.91.950206131048.20818B-100000@thrash.src.umd.edu>


On Mon, 6 Feb 1995, Timothy C. May wrote:

> Yes! Standards are not collusion. In fact, standards can lessen the
> amount of ad hoc contact needed between remailer operators, and thus
> reduce somewhat the prospects for compromise and collusion.

If someone adds the secure coin-flip exchange between chain neighbors to
my Dining Cryptographers IRC client, all remailer operators can go on IRC 
and anonymously discuss the standards so that no cabals can form ;)

-Thomas






From perry at imsi.com  Mon Feb  6 10:30:41 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 6 Feb 95 10:30:41 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <Pine.SUN.3.91.950206130709.20818A-100000@thrash.src.umd.edu>
Message-ID: <9502061830.AA04828@snark.imsi.com>



Thomas Grant Edwards says:
> On Mon, 6 Feb 1995, Perry E. Metzger wrote:
> 
> > Remember, by the way, that PPP is far cheaper per customer than shell
> > accounts, even though moronic providers right now don't make it look
> > that way.
> 
> PPP/SLIP is currently not cheaper per customer - if you figure in the 
> time your help desk staff put in over the first couple of weeks of a new 
> customer coming on line.

Thats because the providers never package things up cleanly. If they
sent a client on a disk, a la AOL, and they set things up to
autoconfigure, they'd never need to speak to the clients.

Perry





From philip at cs.brandeis.edu  Mon Feb  6 10:59:56 1995
From: philip at cs.brandeis.edu (Philip Trauring)
Date: Mon, 6 Feb 95 10:59:56 PST
Subject: MD5 coding
Message-ID: <ab5c1c670202100461ba@[129.64.123.61]>


I am looking to put together an MD5 message digest program and have
extracted the MD5.c and MD5.h files from PGP(excerpt of the MD5.h file
below) but I'm not sure how it all works. Can someone who is familiar with
the functions and the data structure please e-mail me with a bit of
guidance as to what each one does and how to implement it. If anyone can
lead me to a good description of the processes involved I would appreciate
that too. Thanks.

----====----
struct MD5Context {
        uint32 buf[4];
        uint32 bits[2];
        unsigned char in[64];
};

void MD5Init(struct MD5Context *context);
void MD5Update(struct MD5Context *context, unsigned char const *buf,
unsigned len);
void MD5Final(unsigned char digest[16], struct MD5Context *context);
void MD5Transform(uint32 buf[4], uint32 const in[16]);
----====----

        Philip Trauring

--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--
    Philip Trauring                     Brandeis University MB1001
    philip at cs.brandeis.edu              P.O. Box 9110
    (617) 736-5282 ['94/95]             Waltham, Ma  02254-9110
--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--







From jltocher at CCGATE.HAC.COM  Mon Feb  6 11:17:09 1995
From: jltocher at CCGATE.HAC.COM (jltocher at CCGATE.HAC.COM)
Date: Mon, 6 Feb 95 11:17:09 PST
Subject: To Bundle Or Not To Bundle?
Message-ID: <9501067920.AA792098085@CCGATE.HAC.COM>


     From Edupage:
     
     TO BUNDLE OR NOT TO BUNDLE? THAT IS THE MICROSOFT QUESTION 
     One of the fears Microsoft rivals have is that Microsoft will build 
     directly into the Windows operating system various applications 
     software packages (such as encryption for financial processing over 
     the Internet), because customers would be reluctant to pay for 
     products that do more-or-less the same thing as an installed product 
     that they get "for free." Although it's unlikely that the government 
     would consider breaking Microsoft up into separate companies, it is 
     conceivable that it could force Microsoft to limit what it includes 
     with its operating systems. (The Economist 1/28-2/3/95 p.61)
     
John L. Tocher                THE CITY-a bounded infinity.   A labyrinth where 
JLTocher at earthlink.net        you are never lost. Your private map where every 
PGP:  CE 72 1A 11 07 47 35    block bears exactly the same number. Even if you 
35 9A C1 DE EA 64 21 BC 94    lose your way, you cannot go wrong.   --Kobo Abe
     
     






From adam at bwh.harvard.edu  Mon Feb  6 11:43:50 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Mon, 6 Feb 95 11:43:50 PST
Subject: MD5 coding
In-Reply-To: <ab5c1c670202100461ba@[129.64.123.61]>
Message-ID: <199502061946.OAA00186@hermes.bwh.harvard.edu>



| I am looking to put together an MD5 message digest program and have
| extracted the MD5.c and MD5.h files from PGP(excerpt of the MD5.h file
| below) but I'm not sure how it all works. Can someone who is familiar with
| the functions and the data structure please e-mail me with a bit of
| guidance as to what each one does and how to implement it. If anyone can
| lead me to a good description of the processes involved I would appreciate
| that too. Thanks.

	I seem to recall that md5 is explained pretty well in
Schneier.  You may be doing this to learn, which is great, but you
might be pleased to know that there are several md5 programs already
available.  Tripwire includes one, and there was one included in a
CERT/CIAC advisory last year.


Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From eric at remailer.net  Mon Feb  6 12:13:17 1995
From: eric at remailer.net (Eric Hughes)
Date: Mon, 6 Feb 95 12:13:17 PST
Subject: Cooperation
In-Reply-To: <199502061651.IAA02758@jobe.shell.portal.com>
Message-ID: <199502062011.MAA19947@largo.remailer.net>


   From: Hal <hfinney at shell.portal.com>

   I do like the idea of standards.  In fact I wonder if the current "mark
   1" remailer command set shouldn't be documented as an Internet RFC.  

If an RFC is issued, I personally would like to clean up the syntax
and get the remailer operators to upgrade accordingly.

In particular, I chose Request-Remailing-To: as a purposefully obtuse
experimental name.  It deserves to die.

My preferences are for the following:

Anon-Send-To: for anonymized email
Send-To: for normal forwarded email
Anon-Post-To: for anonymized Usenet posting
Post-To: for a regular mail-to-Usenet gateway

I want to capture the distinction between Usenet and email as well as
to support plain forwarding of text for people with connectivity
problems.

Eric





From philip at cs.brandeis.edu  Mon Feb  6 12:15:03 1995
From: philip at cs.brandeis.edu (Philip Trauring)
Date: Mon, 6 Feb 95 12:15:03 PST
Subject: MD5 coding
Message-ID: <ab5c33b100021004dc51@[129.64.123.61]>


>        I seem to recall that md5 is explained pretty well in
>Schneier.  You may be doing this to learn, which is great, but you
>might be pleased to know that there are several md5 programs already
>available.  Tripwire includes one, and there was one included in a
>CERT/CIAC advisory last year.
>
>
>Adam

I need a version that will run on a Mac also which is the version I am
putting together now. I know there are versions for DOS and other platforms
but I specifically need to be able to run it on a Mac since the server I am
producing is Mac-based.

        Philip Trauring


--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--
    Philip Trauring                     Brandeis University MB1001
    philip at cs.brandeis.edu              P.O. Box 9110
    (617) 736-5282 ['94/95]             Waltham, Ma  02254-9110
--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--=====--=--







From eric at remailer.net  Mon Feb  6 12:25:10 1995
From: eric at remailer.net (Eric Hughes)
Date: Mon, 6 Feb 95 12:25:10 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <9502061025.AA03724@snark.imsi.com>
Message-ID: <199502062023.MAA19967@largo.remailer.net>


   From: "Perry E. Metzger" <perry at imsi.com>

   Eric Hughes says:
   > Perry advocates IPSP as an almost-panacea for Internet security.  I
   > disagree.

   Well, no; it doesn't fix things like mail for which the data needs to
   be protected but not the link. 
   
In the case of email, there's the same discrepancy I pointed out
earlier -- the machine or filesystem boundary is not the same as the
trust boundary.  This will happen for email as well as more live and
online communications needs.

   TIA is sort of a short term hack people are using to get around having
   to have their administrators manage SLIP or PPP properly; I suspect
   this difficulty will vanish with time.

I agree with you that this particular example may be short lived, but
you appear to have ignored the more fundamental point I was making.
Namely, the existence of communications proxies which _change_ the
level of abstraction will be with us forever.  The TIA unix end
switches from TCP-to-the-world to IP-to-the-PC.  That's a level
switch.

   IP is ultimately designed to be a proxy protocol that will work over
   anything -- stuff like TIA simply gets around temporary mental
   difficulties among providers in seeing things that way...<

I'm not saying that IP proxies won't exist.  What I am saying is that
other forms of proxying will also exist.  Not all policies will be
able to be enforced at the IP level.  As soon as you want security
policy to apply to non-IP abstractions, IPSP is no longer primary,
even if it's still involved.

Firewall policies are a prime example of security policy enforced at
the TCP and UDP levels, with access control by port number.  External
firewalls, a class that includes packet laundries, web proxies, and
IRC anonymizers, will not for the most part operate at the IP level.

It's certain that IP security will greatly increase the overall
security of the Internet.  I'm not advocating its removal but rather
the acknowledgement that higher (and lower) level abstractions will
require their own cryptography.

Eric





From talon57 at well.sf.ca.us  Mon Feb  6 12:29:02 1995
From: talon57 at well.sf.ca.us (Brian D Williams)
Date: Mon, 6 Feb 95 12:29:02 PST
Subject: Firewall chips
Message-ID: <199502062028.MAA25818@well.sf.ca.us>




>> Actually, there is a germ of truth in this.  On older phones
>>(don't know if  this works on newer electronic phones) when the
>>handset is 'on-hook' a  switch opens and breaks the voice
>>circuit. This of course only works for DC circuits.  If you drive
>>that same circuit with an AC signal . . .

>There's another angle I may have mentioned before.  Many 
>electronic phones come with a ``feature'' that allows you to 
>call home, produce an electronic tone and eavesdrop on your own
>house.  When the tone is sounded, the ringing stops (or never
>starts) and the phone goes into ``off hook'' mode (i.e., the
>microphone in the mouthpiece is turned on).

>Even if you did not buy this feature when you bought your phone,
>it is still there, just waiting for that electronic tone.  You 
>can't produce it, because you didn't buy the doohickey, but anyone
>with such a doohickey can call your house and listen in. . .


> S a n d y

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Devices of this type are known generically as "infinity
transmitters." They will not function anywhere the phone network is
run by a digital (4ESS or better) switch.

 In a modern switch, the ringing you hear is being generated by the
switch, the switch is simultaneously ringing the number you dialed,
however the two are not physically connected. The actual connection
is not made untill the far end answers, this was implemented to
stop various types of fraud, and unauthorized eavesdropping.


Brian D Williams
Cypherpatriot

 
 






From perry at imsi.com  Mon Feb  6 12:44:12 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 6 Feb 95 12:44:12 PST
Subject: Cooperation
In-Reply-To: <199502062011.MAA19947@largo.remailer.net>
Message-ID: <9502062043.AA05429@snark.imsi.com>



Eric says:
> If an RFC is issued, I personally would like to clean up the syntax
> and get the remailer operators to upgrade accordingly.
> 
> In particular, I chose Request-Remailing-To: as a purposefully obtuse
> experimental name.  It deserves to die.

I'd say that it would work far better if things were changed to MIME
formats. You would send a message by recursively encapsulating your
message to be remailed inside a MIME message. Simple and clean...

Perry





From shamrock at netcom.com  Mon Feb  6 12:48:48 1995
From: shamrock at netcom.com (Lucky Green)
Date: Mon, 6 Feb 95 12:48:48 PST
Subject: dna ink
Message-ID: <v0151010eab5c172d0d6e@[192.0.2.1]>


At 10:30 PM 2/5/95, Dan Harmon wrote:
>I just saw an item on CNN about a company in LA called Art Guard.  It
>sells an ink that is created using your dna as a protection against
>forged signatures.

Why not just sign in blood?


-- Lucky Green <shamrock at netcom.com>
   PGP encrypted mail preferred.







From eric at remailer.net  Mon Feb  6 13:15:06 1995
From: eric at remailer.net (Eric Hughes)
Date: Mon, 6 Feb 95 13:15:06 PST
Subject: Cooperation
In-Reply-To: <9502062043.AA05429@snark.imsi.com>
Message-ID: <199502062113.NAA20075@largo.remailer.net>


   Eric says:
   > In particular, I chose Request-Remailing-To: as a purposefully obtuse
   > experimental name.  It deserves to die.

   From: "Perry E. Metzger" <perry at imsi.com>

   I'd say that it would work far better if things were changed to MIME
   formats. You would send a message by recursively encapsulating your
   message to be remailed inside a MIME message. Simple and clean...

That's fine.  I like MIME, but the issue is cleaning up the existing
remailers, none of which use MIME, and the chaining scripts, none of
which do either.

Getting everybody to support Anon-Send-To: in addition to
Request-Remailing-To: is a very simple and straightforward fix for an
acknowledged syntactic inanity.

Eric





From perry at imsi.com  Mon Feb  6 13:31:30 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 6 Feb 95 13:31:30 PST
Subject: dna ink
In-Reply-To: <v0151010eab5c172d0d6e@[192.0.2.1]>
Message-ID: <9502062129.AA05503@snark.imsi.com>



Lucky Green says:
> At 10:30 PM 2/5/95, Dan Harmon wrote:
> >I just saw an item on CNN about a company in LA called Art Guard.  It
> >sells an ink that is created using your dna as a protection against
> >forged signatures.
> 
> Why not just sign in blood?

The same occured to me.

Perry





From rishab at dxm.ernet.in  Mon Feb  6 14:01:26 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Mon, 6 Feb 95 14:01:26 PST
Subject: Selection key crypto protocol trial balloon
Message-ID: <gate.wJ85Zc1w165w@dxm.ernet.in>



Before replying to Tim's comments on Mike Ingle's new directions for anonymity
which, I think, are based on a misunderstanding of what Mike was essentially
positing, here's my (slightly lengthy) take on the Selection Key Crypto 
protocol. Please read it before criticising, as I've already done that...

Mp is the plaintext message. Alice encrypts it with Bob's public key:
Mc = E.kpub (M)                                 [1]

She sends Mc to Hermes, the Hoarder of Messages. Hermes also receives 
Alice's identity string (Ia) which will probably be anonymous, but let's 
assume it's not. Now's the tricky bit. Hermes adds Mc to its message store, S:
S' = G (S, Mc)                                  [2]

The key here is G, the Digest function, which has to spread M over S (with a 
variation of the Fourier function, perhaps), and not just append it, so that
the _only_ way it can be extracted is with Bob's selection key, which Bob
transmits to Hermes along with an involuntary identity string (Ib) to get:
Mx = H.ksel (S')                                [3]

where H.ksel is the Regurgitate function applied with Bob's selection key,
and Mx is _not_ the original encrypted message, Mc, nor the plaintext Mp.

Finally Bob decrypts Ms with his _private_ key (or possibly a variation, which
we'll call v(kpri)), to get the plaintext:
Mp = D.v(kpri) (Ms)                                [4]

So the possible crypto operations are:
Mp = D.kpri (E.kpub(Mp))
Mp = D.v(kpri) (Mx)  where v(x) may be = x
Mx = H.ksel (S')
And the Digest function, S' = G (S, E.kpub(Mp))
Note that only the private key kpri, and its variation v(kpri) are private. 
The other two are public.

Now for the obvious criticisms:
1. after [1] Hermes can store Alice's identity (Ia) in a dark grey dossier,
   and match it to Bob's identity (Ib) and the extracted message (Mx). Nope.
   The premise of this scheme is that Mx doesn't look like Mc at all, and that
   G (in [2]) dissolves the original message into a sludge, from which Mx
   somehow emerges, NOT that it chops Mc into bits with Ia on a little nametag
2. after [1] Hermes can store Ia along with the message and feed [Mc, Ia]
   to [2] in the hope that it will reappear in [3] as [Mx, Ia']. Well, the
   digest function has prevent this, possibly by making the regurgitated
   thing so different from the input that matching Ia to Ia' will be 
   impossible. Of course, Bob probably won't grok [Mx, Ia'] in [4]
3. Hermes gets Bob's identity string (Ib) in [3]. Et alors? As that is 
   incidental, not required to extract the message (unlike in a remailer, where
   that identity string - e-mail address, return block, whatever is _precisely_
   what is required for a message to reach), it's irrelevant. The _real_
   identity is the selection key, which does not correlate to any cyberspatial
   location. See further on traffic analysis.
4. ksel, Bob's selection key, is obviously not private, at least not to Hermes,
   and may as well be public. So anyone can extract the message intended for
   Bob (which reinforces my previous point that Ib is irrelevant). But what
   they extract is Mx, which is not the plaintext. To get the plaintext you
   need not the selection key but Bob's private key, which only Bob has.
5. The Digest function [2-3] has to be robust, i.e. it shouldn't puke if
   it's got lots of messages, and should be able to extract the right one
   in any state. Well, yes, that's tough.

Traffic analysis
The difference between the SKC model and remailers
  Alice --> (Raven, the remailer net) --> Bob   .... multiplied ad infinitum
  Alice --> (Hermes) --> Bob
                     --> Carol, David, the whole world as the 
                         selection key is public
The remailer net is essentially one-to-one, making traffic analysis easier
and limiting Bob's deniability - if the last remailer says it's gone to Bob,
it was _for_ Bob.

The broadcast model essentially increases deniability - they all got it,
any of them could have seen it if they had the key, and you'll only know that
I had the private key with thumb-screws. But they all _get_ it, so bandwidth
is huge.

The SKC model is a compromise. It increases deniability - anyone could have
got it, they all have the selection key, they could only have seen it with the
private key etc. It cuts bandwidth. But it's not a data haven, at least not
as earlier discussed.

The data haven in its latest guise has the same deniability as SKC, and the
same prerequisites that aid recipient protection (anon anon ftp etc). But it
doesn't protect the sender. If the haven is in collusion with remailers that
Alice used to post, it can link her to the message and possibly to Bob. With
SKC, even with the collusion of remailers the link gets lost in digestion.
Also, Bob (or anyone) can frequently extract stuff with the selection key,
perhaps garbage if Hermes is misbehaving or without messages for Bob.

Of course when (and how) Hermes is to expire messages is part of the problem
of the various functions involved.

Comments?


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From jrochkin at cs.oberlin.edu  Mon Feb  6 14:08:37 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Mon, 6 Feb 95 14:08:37 PST
Subject: Cooperation
Message-ID: <ab5c4d2f0902100430ee@[132.162.201.201]>


At 3:43 PM 02/06/95, Perry E. Metzger wrote:
>I'd say that it would work far better if things were changed to MIME
>formats. You would send a message by recursively encapsulating your
>message to be remailed inside a MIME message. Simple and clean...

Well... perhaps for a future remailer standard.  I think the purpose of an
RFC at this point is to clearly outline how it is that present remailers
work, and standardize the working somewhat, and provide a document for
people writing new remailers to look at to make sure their remailers work
like everyone elses (or are a superset of the "Standard Type 1 Remailer"
functions, a superset which certainly could include MIME or anything else).
The point is to accurately describe how most remailers work now, rather
then propose a major change in the way most remailers work.  The latter has
a place, but the former seems more pressing, as well as easier to do, and
perhaps a first step to the latter.

Changing "Request-Remailing-To:" to "Anon-Send-To:" is trivial, in that it
would be an incredibly minor code change, and in that some remailers
already implement "Anon-Send-To:".  But changing everything to MIME would
not be so trivial, and if we published a "standard" that said to do it with
MIME, we'd end up with a standard that in fact no one follows, that doesn't
accurately describe the way things are.  The remailers are definitely
evolving,  and it's been mentioned that it might be a good idea to have a
Type 1 Remailer standards document, and a Type 2 Remailer standards
document, etc.  But it seems of primary importance to first publish a
standard of how the remailers _are_ (Type 1 remailer), instead of how we
might wish they could be.   (Type 1 remailer with MIME, Type 2 remailer,
whatever).

As for the idea of using MIME headers in itself, I'm a bit concerned that
it might make it overly complicated to put together a to-be-remailed
message by hand.  I'm not entirely familiar with MIME and recursive
encapsulation of MIME, so my concern might be ungrounded.  But I think it
might be a Good Thing that it's easy to remail a message by hand by adding
a simple "::\nAnon-Send-To:" at the top, and it would be a mistake to make
it more complicated or dificult to do this by hand, unless it's really
neccesary for some reason.







From jcorgan at aeinet.com  Mon Feb  6 14:09:54 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Mon, 6 Feb 95 14:09:54 PST
Subject: "encrypt tcp connections" hacks
Message-ID: <Chameleon.4.01.950206140937.jcorgan@comet.aeinet.com>


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

>It's certain that IP security will greatly increase the overall
>security of the Internet.  I'm not advocating its removal but rather
>the acknowledgement that higher (and lower) level abstractions will
>require their own cryptography.

This resolves to a layered quality-of-service issue.  Encryption and
authentication at the network layer provides an excellent base for
improving security, and in and of itself solves a lot of problems like
packet payload sniffing, session stealing, etc.

But as you so aptly point out, trust boundaries do not coincide with
network boundaries.  Applications that "ride" on top of TCP and UDP may
have their own, very different, threat models.  And sniffing the
physical layer provides most of what you need for traffic analysis
unless some sort of sophisticated packet laundering is used.

You pointed this out to me at the last cpunks meeting--each layer in the
network model needs to be able to ask for and use security facilities in
the lower layer, as well as advertise its security features to the next
layer up. 

Of course, it is perfectly reasonable for me to expect to write an
email, encrypt it with PGP and send it via an encrypted SMTP protocol to
my mail gateway.  On its way, it will ride on top of an encrypted TCP
session to port 25, with the physical T1 link between my site and the
internet encrypted as well.  This is an example of security features
present at most of the layers between 1 and 7 of the OSI model.  These
should remain independent.

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov
WWW:                    http://ftp.netcom.com/pub/jc/jcorgan/home.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzad6E1Diok8GKihAQExdAP+LZvM2rbJWf6WwIs2oHPjfWRCyXAQTnYm
gpMld86xiJeM5AKudlH2YW+b12lv+9wdH71Fo38FNOdLDX7xDkXQzmkz2creV7sQ
GCfrJOAObLro8vwpZ5LVwin0qvmZzH4PO7to2Th3iYGbrXh4zoOdr5GNLU8j+wTd
HcV9N6nELxg=
=iNH8
-----END PGP SIGNATURE-----








From talon57 at well.sf.ca.us  Mon Feb  6 14:13:47 1995
From: talon57 at well.sf.ca.us (Brian D Williams)
Date: Mon, 6 Feb 95 14:13:47 PST
Subject: DNA ink
Message-ID: <199502062213.OAA11162@well.sf.ca.us>



>>Lucky Green says:
>> At 10:30 PM 2/5/95, Dan Harmon wrote:
>>I just saw an item on CNN about a company in LA called Art Guard. 
>>It sells an ink that is created using your dna as a protection
>>against forged signatures.
>> 
>> Why not just sign in blood?

>The same occured to me.

>Perry

 Yes, this would work even better! If the ink just contained your
DNA, someone could use PCR to duplicate it! If you actually signed
in blood, they would have to match the type and if a white blood
cell was there they would have to "forge" the mitochondria since
they have different DNA! This is not to mention other blood
factors.

 There is prime material here for Klaus! on the the difficulties of
running "blood remailers" "anonymous bloodletting," etc.....


Brian D Williams
Cypherpatriot


"Prime material here"  heh heh!





From ktk at anemone.corp.sgi.com  Mon Feb  6 16:02:37 1995
From: ktk at anemone.corp.sgi.com (Katy Kislitzin)
Date: Mon, 6 Feb 95 16:02:37 PST
Subject: preliminary cypherpunks announcement
Message-ID: <199502070002.QAA28857@anemone.corp.sgi.com>


hi!  we're going to try again to broadcast this saturday's sf bay area
cypherpunks meeting.  Scheduled time is Feb 11, 1pm - 6pm.
Crypto-anarchy will be the order of the day, as usual; will post a
real announcement with speakers and topics shortly.  Please let me
know asap if there are conflicts...

--kt
Katy Kislitzin
Silicon Graphics
I/S Network Software
ktk at corp.sgi.com





From weidai at eskimo.com  Mon Feb  6 17:23:00 1995
From: weidai at eskimo.com (Wei Dai)
Date: Mon, 6 Feb 95 17:23:00 PST
Subject: a simple explanation of DC-Net
Message-ID: <199502070122.AA01568@mail.eskimo.com>


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

The DC-Net is not very easy to understand.  I'll try to explain the most
important parts of the concept as simply as I can.

Let's say there are a number of participants in a DC-Net.  Each
participant shares a different one-time pad with each of several other
participants.

At most one participant can send one bit through the DC-Net per "round".
How does this work?  For each round i, a participant takes the i-th bit
of all the one-time pads that he has and XORs them together.  If he
doesn't want to send a bit, he just broadcasts the resulting bit to
every other participant.  If he DOES want to send a bit, then he
broadcasts the XOR of that resulting bit and the bit he wants to send.
When everyone has done this, each participant takes all of the bits that
has been broadcasted, and XORs them together.  This last action produces
the output of the DC-Net for the i-th round.

Suppose for the first round nobody wants to send a bit.  Since each one-
time pad is known by 2 participants, the first bit of each pad has been
XORed into the final output twice.  Since anything XORed by anything
twice equals itself, these two XORs cancel each other out.  And since
nothing else has been XORed into the output, the output must equal 0.

If one participant wanted to send a bit, however, then something else
HAS been XORed into the output.  Since all the bits from the one-time
pads cancel out, the output equals the bit he wanted to send.

Wei Dai

P.S.  I realize someone has probably written something like this
already, but I hope this explanation helps someone who is still
puzzled.  If nothing else, it serves as a sanity check on my own
understanding.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzbKfTl0sXKgdnV5AQGTpwQAtGe5zl91MgA/ayzBGo/DLXh7NyTDSw00
h/qZZxh2U9HoNFLHMMiHV64PYE8poJlCH8kLDY+XZlv1phoiBtMnc2AehN5XVJmr
YCQ77rH9vp6yk6SZ5F7HV/UNIIQj6TkW806OZP7LlgUrXWPZdCSYGPh7n60J4TkD
RaspzTgFcUk=
=ml6y
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From flatline at u.washington.edu  Mon Feb  6 19:13:47 1995
From: flatline at u.washington.edu (Christopher E Stefan)
Date: Mon, 6 Feb 95 19:13:47 PST
Subject: alt.religion.your.operating.system.sucks
In-Reply-To: <Pine.ULT.3.91.950130063546.13138C-100000@selway.umt.edu>
Message-ID: <Pine.A32.3.91c.950206190403.47399A-100000@mead2.u.washington.edu>


On Mon, 30 Jan 1995, Name Withheld By Request wrote:

> Does this stupid OS flamewar have *anything* to do with cypher? No.
> 
> Could it *PLEASE* be taken somewhere else?

Yea, like the UNIX-HATERS mailing list, or the appropriate 
comp.*.advocacy group.

I read this list to hear about *cypherpunks*, and while it is true that a 
good cypherpunk will write code, he/she should do so under the OS of 
his/her choice and not engage in OS holy wars.  There need to be good 
cypherpunk tools for *ALL* operating systems/enviroments, flaming people 
over their operating system is not a good way to accomplish this.

-- 
Christopher E Stefan  *  flatline at u.washington.edu  *  PGP 2.6ui key by request






From grendel at netaxs.com  Mon Feb  6 19:17:40 1995
From: grendel at netaxs.com (Michael Handler)
Date: Mon, 6 Feb 95 19:17:40 PST
Subject: Remailer RFC
Message-ID: <Pine.SUN.3.91.950206221438.28091A-100000@unix3.netaxs.com>


[ I shouldn't be posting -- I'm legally not supposed to be on the net. 
But hell... ]

I've been compiling and editing a remailer standards document, following 
the format of the Internet RFCs [mainly because I think it's elegant]. 
I'd be glad to make it a `formal' RFC, registered with the IETF... But I 
have no idea how it's done. If anyone out there wants to tell me how...

Michael
--
Michael Handler                                         <grendel at netaxs.com>
Civil Liberty Through Complex Mathematics                   Philadelphia, PA
"Toi qui fais au proscrit ce regard calme et haut" -- Baudelaire * Skotoseme
PGP Key ID FC031321  Print: 9B DB 9A B0 1B 0D 56 DA  61 6A 57 AD B2 4C 7B AF






From root at einstein.ssz.com  Mon Feb  6 19:27:53 1995
From: root at einstein.ssz.com (root)
Date: Mon, 6 Feb 95 19:27:53 PST
Subject: dna ink
In-Reply-To: <9502062129.AA05503@snark.imsi.com>
Message-ID: <199502062339.RAA00978@einstein.ssz.com>


> 
> Lucky Green says:
> > At 10:30 PM 2/5/95, Dan Harmon wrote:
> > >I just saw an item on CNN about a company in LA called Art Guard.  It
> > >sells an ink that is created using your dna as a protection against
> > >forged signatures.
> > 
> > Why not just sign in blood?
> 
> The same occured to me.
> 
> Perry
> 
The blood is water soluble and many of the componants breakdown over time. By
injecting DNA (which has lifetimes measured in millions of years) in some kind
of matrix (ie epoxy or cyanoacetates) it becomes possible to create a modern
'seal' similar to the wax seals of yesteryear. In the case of the old seals it
was not the wax which provided the protection but rather the symobigy that was
embedded in it (ie DNA).

And you thought that T Rex forward from the dinosaur mailing list about DNA
from dinosaur bones was unrelated to crypto......bwahahahahaha


                                                      Ravage
                                                       Black
                                                        Leather
                                                         Monster

ps You really should go take a look at the mathematics used to 'bridge' gaps
   in the DNA strands.






From weidai at eskimo.com  Mon Feb  6 19:28:34 1995
From: weidai at eskimo.com (Wei Dai)
Date: Mon, 6 Feb 95 19:28:34 PST
Subject: (dis)advantages of DC-Net vs remailers
Message-ID: <199502070328.AA11135@mail.eskimo.com>


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

tcmay at netcom.com wrote:

> Chaumian digital mixes--what you Americans call "remailers"--mainly
> solves the sender anonymity problem. Message pools, or broadcast to a
> group or site that includes the receiver, mainly deals with receiver
> anonymity. The combination of the two deals with both.
> 
> Both are solved elegantly with the Dining Cryptographer's Protocol,
> about which much is written on this list every few months. Messages
> are "sent" in an Ouija-board fashion and received by the person who
> can successfully decrypt a public message sent over the system.

I tend to favor remailers + broadcasting + anonymous-return-addresss
over the DC-Net protocol.  Let me list some of their relative 
advantages and disadvantages.  Please add to these if you can think
of more...

Advantages of DC-Net over remailers

	- more flexible trust relationships - you can add your buddies to 
		the set of people who have to be compromised to trace you
	- lower latency - don't have to wait for remailers to collect enough 
		mail for batches
	- untracibility need not depend on assumptions about the enemy's
		computational power

Disadvantages of DC-Net

	- complexity - explaining the core concepts of a remailer takes only 
		a couple of lines, as opposed to a couple of screens for a DC-Net
		Implementation of a DC-Net seems to be an order of magnitude
		harder as well.
	- more vulnerable to denial of service attacks
	- MUCH higher bandwidth costs

I think over the long run the last factor will be most important.  In 
a DC-Net, for each bit one participant wants to send to another, EVERY
OTHER participant must broadcast a bit to ALL participants.  I can 
imagine a remailer-net with one million users, but I don't see any 
possibility that a DC-Net can be scaled to that size.

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzboXjl0sXKgdnV5AQEqqAP+JU2sgiESnFZm+CCgNNboXnL3uKg0GP4Z
y6NV+U56yGvPKzsi9suUiOpbuzwsYVaMnWIuqRCOaxic75SFsDi0NvjE1K4JgyXz
aoyVs1i+xlFKnfmZr1+7EAheUq7wlfSWdp0cnAhbNWSrC3cSuDiNGYciJQLW8GGv
3YUvmW+Xoj0=
=Aa+t
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From entropy at IntNet.net  Mon Feb  6 19:58:14 1995
From: entropy at IntNet.net (Jonathan Cooper)
Date: Mon, 6 Feb 95 19:58:14 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <9502061830.AA04828@snark.imsi.com>
Message-ID: <Pine.SV4.3.91.950206191208.28669C-100000@xcalibur>


> Thats because the providers never package things up cleanly. If they
> sent a client on a disk, a la AOL, and they set things up to
> autoconfigure, they'd never need to speak to the clients.

    You've obviously never attempted to get a Windows product working for 
someone whose previous experience with a computer is limited to "Solitaire".

    I've done work with this ISP, and I can tell you it's nearly the most 
frustrating experience I've had in my life -- Windows has bizzare 
conflicts with software eating other software, ports getting set up 
wrong, and just general nastiness.  Even the slickest software needs 
helpline time - for whatever reason.

-jo

( --------[ Jonathan D. Cooper ]--------[ entropy at intnet.net ]-------- )
( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4  5B 12 A0 35 E0 9B C0 01 )
( home page: http://taz.hyperreal.com/~entropy/ ]---[ Key-ID: 4082CCB5 )






From tedwards at src.umd.edu  Mon Feb  6 20:02:51 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Mon, 6 Feb 95 20:02:51 PST
Subject: a simple explanation of DC-Net
In-Reply-To: <199502070122.AA01568@mail.eskimo.com>
Message-ID: <Pine.SUN.3.91.950206224622.21262B-100000@thrash.src.umd.edu>


On Mon, 6 Feb 1995, Wei Dai wrote:

> P.S.  I realize someone has probably written something like this
> already, but I hope this explanation helps someone who is still
> puzzled.

I've written a test-bed IRC client which uses DC Nets to allow multiple 
people to talk on an IRC channel anonymously.  It operates in a ring, 
with every participant showing his/her random bit stream with the 
neighbor to the "left."  Participants compare their bit stream with the 
one their neighbor shares with them, and broadcasts the differences 
(with lies indicating xmitted "1" bite) to all participants.  The 
difference bits for each round are totalled together modulo 2 by each 
participant, and any anonymous broadcasts can be determined from those 
totals.

My implementation was a quick project for a class and lacks some really 
important features:

1)  used built-in PRNG
2)  does not encrypt private messages for bit stream sharing between 
neighbors
3)  no ALOHA or similar protocol for dealing with message collisions
4)  ring could be expanded to more complex graph to increase number of
    colluding participants needed to break anonymity.

BTW - There have been a few other papers on DC-Nets since Chaum including 
detections of DC-Net disrupters, and protection against a group of active 
attacks.  I include a report with my code now available at 
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/applications/dc-irc.alpha.tar.gz
which goes into more details on these matters and has references.

-Thomas






From jrochkin at cs.oberlin.edu  Mon Feb  6 20:08:28 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Mon, 6 Feb 95 20:08:28 PST
Subject: dna ink
Message-ID: <ab5ca280040210043eb1@[132.162.201.201]>


At 6:39 PM 02/06/95, root wrote:
>The blood is water soluble and many of the componants breakdown over time. By
>injecting DNA (which has lifetimes measured in millions of years) in some kind
>of matrix (ie epoxy or cyanoacetates) it becomes possible to create a modern
>'seal' similar to the wax seals of yesteryear. In the case of the old seals it
>was not the wax which provided the protection but rather the symobigy that was
>embedded in it (ie DNA).
>
>And you thought that T Rex forward from the dinosaur mailing list about DNA
>from dinosaur bones was unrelated to crypto......bwahahahahaha

Something I've been is: Why can't one of your enemies just get a piece of
your hair or fingernails or something, and make their own DNA ink our of
your DNA?  They could probably even send it to this DNA ink company, and
they'd make your enemy ink out of your own DNA without even noticing.
Doesn't seem very secure to me.

[Yeah, it's not crypto related, but I've been wondering about this since
the topic was first brought up, and am somewhat surprised that of the few
messages there were making fun of the DNA ink,  none mentioned this fact.
Is that because it's too obvious to mention, or is there something I'm not
thinking about which makes DNA ink useful after all?]







From anonymous-remailer at shell.portal.com  Mon Feb  6 20:18:10 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Mon, 6 Feb 95 20:18:10 PST
Subject: New directions in anonymity (needed)
In-Reply-To: <199502060743.XAA01417@netcom14.netcom.com>
Message-ID: <199502070417.UAA18418@jobe.shell.portal.com>


> From: tcmay at netcom.com (Timothy C. May)
> Date: Sun, 5 Feb 1995 23:43:39 -0800 (PST)
> 
> Mike Ingle wrote:
> > All of our anonymous systems boil down to only two techniques: indirection
> > and broadcast. Indirection is sending a message through one or more
> > intermediate nodes to conceal its point of origin. Broadcast is sending a
> > message to multiple recipients to conceal the intended recipient.
> 
> First, I think it important to clearly distinguish between "sender
> anonymity," where the physical identity or sending site is hidden, and
> "receiver anonymity," where the same is true of the receiving site.

  I agree and will call them s anonymity, and r anonymity cause I am
too lazy to type much.

> Chaumian digital mixes--what you Americans call "remailers"--mainly
> solves the sender anonymity problem. Message pools, or broadcast to a
> group or site that includes the receiver, mainly deals with receiver
> anonymity. The combination of the two deals with both.

  I'll call the combo of "sender -> remail network -> pool ->
reciever" by the term "repool" in this message.

> Both are solved elegantly with the Dining Cryptographer's Protocol,
> about which much is written on this list every few months. Messages
> are "sent" in an Ouija-board fashion and received by the person who
> can successfully decrypt a public message sent over the system.

  Not so.  Though Chaum's DC protocol does give s/r anonymity, it does
so at a large cost.  Much larger than the repool protocol.

> > Broadcast is exactly as secure as it is nonscalable. If you
> > broadcast to 100 people, an attacker's uncertainty is one in
> > 100. The security grows linearly with the overall bandwidth. For
> > cryptographic-level security, it would need to grow exponentially
> > with bandwidth.

  I think this is exactly the right aproach.  So, lets look at the
cost of ataining anonymity.  For U people to communicate M bits (total
-- 2 people each sending 2 bits is M==4) s/r anonymously takes O(U*M)
bits multicast bandwidth for Chaum's DC protocol, but the repool
protocol uses only O(h*M) bits narowcast bandwidth plus O(M) bits
multicast bandwidth (Where h is the average number of remailer hops,
expected to be a constant wrt U and M, smaller than U, and much smaller
than M).

  Chaum's DC protocol also assumes an _interactive_ speed multicast
network.  Ouch!  The multicast internet protocol does help addresses
this problem, but it isn't widely available.  IRC is perhaps a bit
more expensize, more widely available, but lower bandwidth than
multicast IP packets.

> [...]
> > Anonymity needs something fundamentally new, something comparable to public
> > key for cryptography or blind signatures for digital cash. Suppose a server
> 
> I think you ought to carefully look at Chaum's work on Dining
> Cryptographers. It does all this. (It ain't perfect, and it ain't been
> implemented in practical terms, a la a "Pretty Good Dining
> Cryptographers," but it's at least as basic a concept as the other
> things are....some might say that all are variations on the same theme.)

  Chaum's DC protocol achieves U way s/r anonymity for U times the
work of sending a message.  Chaum's DC protocol provides s anonymity
as conditional as the cryptosystem achieves privacy (i.e.
uncomditional for one time pads, and dependant on 'strong
cryptosystems' assumption for the 'conventional' DC net).  Like the
repool protocol, it provides unconditional r anonymity.

  The repool protocol achieves U way s/r anonymity for no more than h
times the work of sending a message.  The repool protcol (by use of a
pool) provides unconditional (U-way) r anonymity, but (due to using
remailers) only provide conditional (U-way) s anonymity (conditional
on there existing at least one trusted remailer in the chain, and on
the existance of strong cryptosystems).  The repool protocol also
suffers from TA attacks like those sugested by Wei (at least as
currently implemented).

  What we would like is for the work to scale sub-linearly (ideally
exp(-U)) with the number of users U.  Said another way, we would like
U to scale faster than linearly as a function of the work (ideally
exp(W)).  If the effort of a protocol scales linearly (or worse) with
U, I don't think it will become widely employed.  Even better would be
a system which provided s/r anonymity without using multicast
bandwidths at all.  Btw, what is the cost of multicast v.s. narowcast
(say SMTP bassed) today on the net?

  Noyb





From root at einstein.ssz.com  Mon Feb  6 20:23:16 1995
From: root at einstein.ssz.com (root)
Date: Mon, 6 Feb 95 20:23:16 PST
Subject: dna ink
In-Reply-To: <ab5ca280040210043eb1@[132.162.201.201]>
Message-ID: <199502070417.WAA01434@einstein.ssz.com>


> 
> Something I've been is: Why can't one of your enemies just get a piece of
> your hair or fingernails or something, and make their own DNA ink our of
> your DNA?  They could probably even send it to this DNA ink company, and
> they'd make your enemy ink out of your own DNA without even noticing.
> Doesn't seem very secure to me.
> 
> [Yeah, it's not crypto related, but I've been wondering about this since
> the topic was first brought up, and am somewhat surprised that of the few
> messages there were making fun of the DNA ink,  none mentioned this fact.
> Is that because it's too obvious to mention, or is there something I'm not
> thinking about which makes DNA ink useful after all?]
> 
> 
This is the same problem that arose with the original idea of seals once
the skills of metalworking became commen enough. By the 1500's it was
nearly impossible to keep a seal confidential more than a few weeks until
somebody got a impression and built a copy.






From root at einstein.ssz.com  Mon Feb  6 20:26:25 1995
From: root at einstein.ssz.com (root)
Date: Mon, 6 Feb 95 20:26:25 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <Pine.SV4.3.91.950206191208.28669C-100000@xcalibur>
Message-ID: <199502070420.WAA01441@einstein.ssz.com>


> 
>     You've obviously never attempted to get a Windows product working for 
> someone whose previous experience with a computer is limited to "Solitaire".
> 
>     I've done work with this ISP, and I can tell you it's nearly the most 
> frustrating experience I've had in my life -- Windows has bizzare 
> conflicts with software eating other software, ports getting set up 
> wrong, and just general nastiness.  Even the slickest software needs 
> helpline time - for whatever reason.
> 
I have been doing help desk related work for nearly 10 years and in my 
experience 'user friendly' is something you see on ads and never in the
software.

I have yet to see a piece of software that is useful and actually solves
a problem or does a job that doesn't also require an investment by the
help desk.

It simply ain't that easy.






From jamesd at netcom.com  Mon Feb  6 20:46:27 1995
From: jamesd at netcom.com (James A. Donald)
Date: Mon, 6 Feb 95 20:46:27 PST
Subject: (dis)advantages of DC-Net vs remailers
In-Reply-To: <199502070328.AA11135@mail.eskimo.com>
Message-ID: <Pine.3.89.9502062012.A1613-0100000@netcom13>


On Mon, 6 Feb 1995, Wei Dai wrote:
 
> I think over the long run the last factor will be most important.  In 
> a DC-Net, for each bit one participant wants to send to another, EVERY
> OTHER participant must broadcast a bit to ALL participants.  I can 
> imagine a remailer-net with one million users, but I don't see any 
> possibility that a DC-Net can be scaled to that size.

Not so -- you merely have to broadcast to enough people.  
But then the topology, and hence the complexity, gets worse.

This however merely reduces the bandwidth waste from n^2 to n*lg(n)


A further wrinkle -- forming DC nets of DC nets, can reduce the
bandwidth waste to lg(n)^2, which should scale adequately to cover
the cosmos, but then the complexity gets really scary.

And when you try to figure how to deal with denial of service
attacks in a big DC net that tries to use bandwidth with
tolerable efficiency -- I don't know if anyone has figured out
what would be involved -- I certainly have not.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From usenet at agate.berkeley.edu  Mon Feb  6 20:49:57 1995
From: usenet at agate.berkeley.edu (Usenet Administration)
Date: Mon, 6 Feb 95 20:49:57 PST
Subject: Automatic Echo of Test Posting
Message-ID: <199502070449.UAA23007@agate.berkeley.edu>


This is an automatic echo of your posting to *.test.

Your header as received by this site follows.

If you don't want to get this message, please put the words "No Reply", 
or "Ignore" in the header of your posting.

        NNTP service with a :-)

rob robertson                agate!usenet             usenet at agate.berkeley.edu
-------------------------------------------------------------------------------

    Path: agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
    Subject: lwall
    Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
    NNTP-Posting-Host: ack.berkeley.edu
    Organization: cypherpunks
    Lines: 2
    From: cypherpunks at toad.com
    Distribution: world
    Newsgroups: alt.test
    Date: 6 Feb 1995 19:34:19 GMT







From usenet at mathworks.com  Mon Feb  6 20:50:18 1995
From: usenet at mathworks.com (MathWorks Autoresponder)
Date: Mon, 6 Feb 95 20:50:18 PST
Subject: lwall
Message-ID: <199502070450.XAA05997@turing.mathworks.com>


Your Usenet test article was received on Mon Feb  6 23:50:01 EST 1995 here at 
The MathWorks, Inc. in Natick, MA.  Natick, MA is about 20 miles 
west of Boston, MA.

You are receiving this message because you posted a test message to one of
the *.test newsgroups.

The MathWorks' news admin can be reached via e-mail at usenet at mathworks.com.
Please note that we do not offer news access to sites outside of our
organization.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

All headers plus at most 10 lines of user text from your original article are
reproduced below for your perusal:

Path: news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT





From jamesd at netcom.com  Mon Feb  6 20:55:55 1995
From: jamesd at netcom.com (James A. Donald)
Date: Mon, 6 Feb 95 20:55:55 PST
Subject: "encrypt tcp connections" hacks
In-Reply-To: <Pine.SV4.3.91.950206191208.28669C-100000@xcalibur>
Message-ID: <Pine.3.89.9502062024.A1613-0100000@netcom13>


On Mon, 6 Feb 1995, Jonathan Cooper wrote:
>     You've obviously never attempted to get a Windows product working for 
> someone whose previous experience with a computer is limited to "Solitaire".
> 
>     I've done work with this ISP, and I can tell you it's nearly the most 
> frustrating experience I've had in my life -- Windows has bizzare 
> conflicts with software eating other software, ports getting set up 
> wrong, and just general nastiness.  Even the slickest software needs 
> helpline time - for whatever reason.

Some software needs more than others.

Central Points desktop for windows -- a very complex and powerful 
product, had quite low help line costs.

On the other hand the messy and confused windows internet utilities,
produced by diverse people, often crudely ported from Unix by 
shareware operators who could not afford the time and effort 
for a proper setup program, or crudely ported by people who may 
have been Unix experts but most obviously were not windows
experts, (example: ftp softwares terminal emulator) are a total 
disaster, and this is why the help cost for SLIP lines is so 
high.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From sdw at lig.net  Mon Feb  6 21:01:19 1995
From: sdw at lig.net (Stephen D. Williams)
Date: Mon, 6 Feb 95 21:01:19 PST
Subject: dna ink
In-Reply-To: <ab5ca280040210043eb1@[132.162.201.201]>
Message-ID: <m0rbdOC-0009tFC@sdwsys>


...
> your DNA?  They could probably even send it to this DNA ink company, and
> they'd make your enemy ink out of your own DNA without even noticing.
> Doesn't seem very secure to me.
> 
> [Yeah, it's not crypto related, but I've been wondering about this since
> the topic was first brought up, and am somewhat surprised that of the few
> messages there were making fun of the DNA ink,  none mentioned this fact.
> Is that because it's too obvious to mention, or is there something I'm not
> thinking about which makes DNA ink useful after all?]
> 

A much more interesting spin on this would be a variety of ways to encode
throughout a substance in an inert but permanent way a public key.

Whether it's an easily identifiable molecule or some type of deep etching,
you could do things like mark all the parts of a car or all the paint,
fabric, plastic, etc. of a work of art.

DNA isn't very good really since it's mostly the same and based a lot
on probabilities.

sdw
-- 
Stephen D. Williams    25Feb1965 VW,OH      sdw at lig.net http://www.lig.net/sdw
Senior Consultant    513-865-9599 FAX/LIG   513.496.5223 OH Page BA Aug94-Feb95
OO R&D AI:NN/ES crypto     By Buggy: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Firewall/WWW srvrs ICBM/GPS: 39 38 34N 84 17 12W home, 37 58 41N 122 01 48W wrk
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.28Jan95




From hfinney at shell.portal.com  Mon Feb  6 21:37:24 1995
From: hfinney at shell.portal.com (Hal)
Date: Mon, 6 Feb 95 21:37:24 PST
Subject: New directions in anonymity (needed)
Message-ID: <199502070522.VAA27293@jobe.shell.portal.com>


From: Noyb, anonymous-remailer at shell.portal.com
>   So, lets look at the
> cost of ataining anonymity.  For U people to communicate M bits (total
> -- 2 people each sending 2 bits is M==4) s/r anonymously takes O(U*M)
> bits multicast bandwidth for Chaum's DC protocol, but the repool
> protocol uses only O(h*M) bits narowcast bandwidth plus O(M) bits
> multicast bandwidth (Where h is the average number of remailer hops,
> expected to be a constant wrt U and M, smaller than U, and much smaller
> than M).

The repool could actually be somewhat worse than this.  Wei has
shown that if you don't send every tick then statistical information
builds up surprisingly quickly to link senders and probable receivers,
especially if there is a pair communicating frequently over a long period
of time, arguably one of the main forms of usage of these nets.  So
everyone has to send all the time at the rate of the maximum per-user
rate accepted by the remailers (say, one packet per tick).  If this rate
is considerably above the actual average communication rate of a given
user then this will be much higher than O(h*M) (although granted it will
not scale directly with U, increasing U will increase the desired packet
rate that would satisfy, say, 90% of users).

Hal





From tcmay at netcom.com  Mon Feb  6 22:22:38 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 6 Feb 95 22:22:38 PST
Subject: a simple explanation of DC-Net
In-Reply-To: <199502070122.AA01568@mail.eskimo.com>
Message-ID: <199502070620.WAA29156@netcom4.netcom.com>


Wei Dai wrote:

> The DC-Net is not very easy to understand.  I'll try to explain the most
> important parts of the concept as simply as I can.
...nice explanation elided...

> P.S.  I realize someone has probably written something like this
> already, but I hope this explanation helps someone who is still
> puzzled.  If nothing else, it serves as a sanity check on my own
> understanding.

Yes, I wrote up a similar explanation for the Extropians list, in
mid-1992, before our list existed. (It's been redistributed here a
couple of times, and is in some of the CP archives an/or URLs reported
here.)

Eric Hughes and I did a anthropomorphic demo of DC-Nets a couple of
years ago, at the first CP meeting. That is, we got up in front of
folks and literally acted-out a simple transmission (and even this
took some minutes, to make clear the protocols, etc.).

My estimate is that the averagely bright Cypherpunk (which is to say,
_very_ bright person) can get the key ideas of DC-Nets in a few hours
of careful thinking and diagramming of the ideas in the paper, which
is of course archived at the Cypherpunks site (and probably readily
accessible in several URLs). By "key ideas" I mean the first 3-4
pages of the paper, whjere the ideas are laid out.

Issues of collusion and disruption are what Chaum spends most of his
1988 paper on, and start after the first introductory pages. Sub-nets,
to reduce collusion, for example. Later papers, such as those by the
Pfitzmanns and by Jurgen Bos, deal in much more detail with
disruption.

(By the way, I mentioned to Chaum, in Monte Carlo last week, our
continuing fascination with DC-Nets, despite the difficulties in fully
implementing/using them. Chaum was aware of the efforts by the Austin
group, and was pleased to hear that several parallel are continuing. I
got the impression that we are the only people in the world still
looking at this stuff, which is not as bad as it sounds. You see,
those writing papers have moved on to other things, whereas
Cypherpunks is a list devoted to practical implementations and
demonstrations, and few others are, so we have a continuing interest.
Chaum was very complimentary about the Cypherpunks.)

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From autoreply at xpat.postech.ac.kr  Mon Feb  6 22:24:32 1995
From: autoreply at xpat.postech.ac.kr (Xpat Autoresponder)
Date: Mon, 6 Feb 95 22:24:32 PST
Subject: lwall
Message-ID: <199502070619.PAA12524@xpat.postech.ac.kr>


DO NOT PANIC!  REMAIN CALM!  READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET!

Your Usenet test article was received here at the news gateway machine for
the Pohang University of Science and Technology in Pohang, South Korea.
The Xpat newsadmins can be reached via e-mail at usenet at xpat.postech.ac.kr.
Any reply to this message will be dropped into the bit bucket, and never be
seen by a human.  Please note that we do not offer news access to sites
outside of our organization.

If you're a newsadmin and you'd like to run your own autoresponder, this one
is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

There are typically 5 possible reasons why you were sent this e-mail message:

1) You intentionally posted a Usenet news article to a *.test newsgroup.  
These newsgroups exist so you can verify that your articles are being 
propagated correctly.  When your article arrives here, we send you this message
as confirmation.  We will only send you ONE e-mail reply for each of your test
articles that we see.

2) You unintentionally posted a Usenet news article to a *.test newsgroup.  
This is a bit of net.childishness caused by a Followup-To: header directing all
replies into a *.test newsgroup.  This is done by somebody upset with the
content of a discussion thread who wants to "punish" anybody who replies to his
message.  Your reply will be sent to *.test instead of the original newsgroup,
and you will start receiving autoresponder messages similar to this one that
you didn't ask for.  To avoid this in the future, look for a Followup-To:
header and make sure it's appropriate before replying to any articles.

3) You were a victim of a Reply-To: header directing your e-mail into a *.test
newsgroup via a mail->news gateway.  Similar to 2) above.

4) Somebody has forged a posting in your name to one of the *.test newsgroups.
To avoid this in the future, use better net.etiquette and you will make fewer
net.enemies.  If you want to try and identify the forger, use the following
procedure.  Make a legitimate posting to the same *.test newsgroup that the
forger used.  We will send you an e-mail reply.  Compare the Path: header from
this legitimate reply with the Path: header from the forgery.  The front
part of the two headers will be the same or topologically similar path to
your site.  Where the forged header becomes substantially different can
provide clues to where the forger lives.  Note that if you receive multiple
newsfeeds you may need to repeat this process several times so you can discover
all legitimate paths between our site and yours.  Once you think you've
identified the forger's site, try sending POLITE e-mail to the newsadmin/
sysadmin/postmaster explaining the situation.

5) You issued a cancel control message to a *.test newsgroup.  Some users
dislike autoresponses for cancel messages, but the newsadmins here think it
can be a valuable diagnostic tool for verifying cancel propagation.  If you
don't like it, use the "delete" key in your mail client!

All headers plus at most 10 lines of user text from your original article are
reproduced below for your perusal:

Path: xpat.postech.ac.kr!news.kreonet.re.kr!insosf1.infonet.net!solaris.cc.vt.edu!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT

test
test





From rrothenb at ic.sunysb.edu  Mon Feb  6 22:37:39 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 6 Feb 95 22:37:39 PST
Subject: MD5 coding
In-Reply-To: <ab5c1c670202100461ba@[129.64.123.61]>
Message-ID: <199502070637.BAA17973@libws4.ic.sunysb.edu>



> I am looking to put together an MD5 message digest program and have
> extracted the MD5.c and MD5.h files from PGP(excerpt of the MD5.h file
> below) but I'm not sure how it all works. Can someone who is familiar with
> the functions and the data structure please e-mail me with a bit of
> guidance as to what each one does and how to implement it. If anyone can
> lead me to a good description of the processes involved I would appreciate
> that too. Thanks.

Better than looking at sources, look for the file rsa.doc avail. from a lot
of crypto/security ftp-sites... specifically something called the MD5-A RFC
...? It explains the algorithm pretty well, and is what I used to write my
own assembler implementation with... better to work from an explanation of
the algorithm than from sources which you may or may not understand what is
going on.






From stig at hackvan.com  Tue Feb  7 01:25:16 1995
From: stig at hackvan.com (Stig)
Date: Tue, 7 Feb 95 01:25:16 PST
Subject: The Rise of "Worse is Better"...
Message-ID: <m0rbm8e-0006DaC@hackvan.com>



A while ago, I mentioned appendix C to the _Unix-Haters Handbook_ and someone
(Jason?) was interested in it.  I couldn't come up with the text of the
chapter until now because I didn't have it until now.

Look through the Lisp-specific jargon to see what RPG (the author) has to
say about the differrent priorities in getting a job done...  One school of
engineering follows "The Right Thing" approach, while the other uses the
"Worse is Better" (quick-and-dirty) approach.

    Stig
    
I have the .tex file for the article, and it's available on the WWW as
    http://www.ai.mit.edu/articles/good-news/good-news.html

-----------------------------------------------------------------------------
[Image]  [Image] [Image]  Previous: Lisp's Apparent Failures Up: Lisp's
Apparent Failures Next: Good Lisp Programming is Hard

The Rise of ``Worse is Better''

I and just about every designer of Common Lisp and CLOS has had extreme
exposure to the MIT/Stanford style of design. The essence of this style can be
captured by the phrase ``the right thing.'' To such a designer it is important
to get all of the following characteristics right:

      Simplicity-the design must be simple, both in implementation and
     interface. It is more important for the interface to be simple than the
     implementation.

      Correctness-the design must be correct in all observable aspects.
     Incorrectness is simply not allowed.

      Consistency-the design must not be inconsistent. A design is allowed to
     be slightly less simple and less complete to avoid inconsistency.
     Consistency is as important as correctness.

      Completeness-the design must cover as many important situations as is
     practical. All reasonably expected cases must be covered. Simplicity is
     not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will
call the use of this philosophy of design the ``MIT approach.'' Common Lisp
(with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

      Simplicity-the design must be simple, both in implementation and
     interface. It is more important for the implementation to be simple than
     the interface. Simplicity is the most important consideration in a design.

      Correctness-the design must be correct in all observable aspects. It is
     slightly better to be simple than correct.

      Consistency-the design must not be overly inconsistent. Consistency can
     be sacrificed for simplicity in some cases, but it is better to drop those
     parts of the design that deal with less common circumstances than to
     introduce either implementational complexity or inconsistency.

      Completeness-the design must cover as many important situations as is
     practical. All reasonably expected cases should be covered. Completeness
     can be sacrificed in favor of any other quality. In fact, completeness
     must sacrificed whenever implementation simplicity is jeopardized.
     Consistency can be sacrificed to achieve completeness if simplicity is
     retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will
call the use of this design strategy the ``New Jersey approach.'' I have
intentionally caricatured the worse-is-better philosophy to convince you that
it is obviously a bad philosophy and that the New Jersey approach is a bad
approach.

However, I believe that worse-is-better, even in its strawman form, has better
survival characteristics than the-right-thing, and that the New Jersey approach
when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey
distinction is valid and that proponents of each philosophy actually believe
their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on Unix)
once met to discuss operating system issues. The person from MIT was
knowledgeable about ITS (the MIT AI Lab operating system) and had been reading
the Unix sources. He was interested in how Unix solved the PC loser-ing
problem. The PC loser-ing problem occurs when a user program invokes a system
routine to perform a lengthy operation that might have significant state, such
as IO buffers. If an interrupt occurs during the operation, the state of the
user program must be saved. Because the invocation of the system routine is
usually a single instruction, the PC of the user program does not adequately
capture the state of the process. The system routine must either back out or
press forward. The right thing is to back out and restore the user program PC
to the instruction that invoked the system routine so that resumption of the
user program after the interrupt, for example, re-enters the system routine. It
is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,''
where ``loser'' is the affectionate name for ``user'' at MIT.

The MIT guy did not see any code that handled this case and asked the New
Jersey guy how the problem was handled. The New Jersey guy said that the Unix
folks were aware of the problem, but the solution was for the system routine to
always finish, but sometimes an error code would be returned that signaled that
the system routine had failed to complete its action. A correct user program,
then, had to check the error code to determine whether to simply try the system
routine again. The MIT guy did not like this solution because it was not the
right thing.

The New Jersey guy said that the Unix solution was right because the design
philosophy of Unix was simplicity and that the right thing was too complex.
Besides, programmers could easily insert this extra test and loop. The MIT guy
pointed out that the implementation was simple but the interface to the
functionality was complex. The New Jersey guy said that the right tradeoff has
been selected in Unix-namely, implementation simplicity was more important than
interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender
chicken, but the New Jersey guy didn't understand (I'm not sure I do either).

Now I want to argue that worse-is-better is better. C is a programming language
designed for writing Unix, and it was designed using the New Jersey approach. C
is therefore a language for which it is easy to write a decent compiler, and it
requires the programmer to write text that is easy for the compiler to
interpret. Some have called C a fancy assembly language. Both early Unix and C
compilers had simple structures, are easy to port, require few machine
resources to run, and provide about 50%--80% of what you want from an operating
system and programming language.

Half the computers that exist at any point are worse than median (smaller or
slower). Unix and C work fine on them. The worse-is-better philosophy means
that implementation simplicity has highest priority, which means Unix and C are
easy to port on such machines. Therefore, one expects that if the 50%
functionality Unix and C support is satisfactory, they will start to appear
everywhere. And they have, haven't they?

Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle to get good
performance and modest resource use. Programs written using the New Jersey
approach will work well both in small machines and large ones, and the code
will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If
so, the viral spread is assured as long as it is portable. Once the virus has
spread, there will be pressure to improve it, possibly by increasing its
functionality closer to 90%, but users have already been conditioned to accept
worse than the right thing. Therefore, the worse-is-better software first will
gain acceptance, second will condition its users to expect less, and third will
be improved to a point that is almost the right thing. In concrete terms, even
though Lisp compilers in 1987 were about as good as C compilers, there are many
more compiler experts who want to make C compilers better than want to make
Lisp compilers better.

The good news is that in 1995 we will have a good operating system and
programming language; the bad news is that they will be Unix and C++.

There is a final benefit to worse-is-better. Because a New Jersey language and
system are not really powerful enough to build complex monolithic software,
large systems must be designed to reuse components. Therefore, a tradition of
integration springs up.

How does the right thing stack up? There are two basic scenarios: the ``big
complex system scenario'' and the ``diamond-like jewel'' scenario.

The ``big complex system'' scenario goes like this:

First, the right thing needs to be designed. Then its implementation needs to
be designed. Finally it is implemented. Because it is the right thing, it has
nearly 100% of desired functionality, and implementation simplicity was never a
concern so it takes a long time to implement. It is large and complex. It
requires complex tools to use properly. The last 20% takes 80% of the effort,
and so the right thing takes a long time to get out, and it only runs
satisfactorily on the most sophisticated hardware.

The ``diamond-like jewel'' scenario goes like this:

The right thing takes forever to design, but it is quite small at every point
along the way. To implement it to run fast is either impossible or beyond the
capabilities of most implementors.

The two scenarios correspond to Common Lisp and Scheme.

The first scenario is also the scenario for classic artificial intelligence
software.

The right thing is frequently a monolithic piece of software, but for no reason
other than that the right thing is often designed monolithically. That is, this
characteristic is a happenstance.

The lesson to be learned from this is that it is often undesirable to go for
the right thing first. It is better to get half of the right thing available so
that it spreads like a virus. Once people are hooked on it, take the time to
improve it to 90% of the right thing.

A wrong lesson is to take the parable literally and to conclude that C is the
right vehicle for AI software. The 50% solution has to be basically right, and
in this case it isn't.

But, one can conclude only that the Lisp community needs to seriously rethink
its position on Lisp design. I will say more about this later.

rpg at lucid.com





From tcmay at netcom.com  Tue Feb  7 02:07:17 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 02:07:17 PST
Subject: Corporate Fascism, Rand, Greens, Oh My!
In-Reply-To: <199501302310.PAA13622@mail.igc.apc.org>
Message-ID: <199502071005.CAA25848@netcom9.netcom.com>


I just saw this older message as I waded through the 700 messsages
which accumulated during my absence (and since my return, too). IO
know there will be some who see no crypto relevance in this, but
that's just too bad. I've seen endless OS flame war posts, endless
flames about "can't we get back to crypto?" (often from the OS
flamers, ironically), so my foray into anarcho-capitalism is at least
as related to Cypherpunks issues. 

Besides, I want to respond to my old friend Rich.

Richard F. Dutcher wrote:

> Do you assume privacy and protection from arbitrary power are solely 
> libertarian concerns?  If so, educate yourself and check out the ACLU 
> and Amnesty International ...
> 
> I even know lots of cyrpto-anarcho-libbers [or whatever Tim May is 
> calling them nowadays ;-] who are willing to concede, under pressure, 
> that unfettered corporations can be as dangerous to freedom as any 
> government.

It doesn't even take any pressure for me to concede this, although
there are some subtleties about what "unfettered" means, and what
options corporations have to stifle competitors by using State power.

The Randian ideal (well, "ideal" for many of us who cut our teeth on
"Atlas Shrugged" while future commie wimp-simps were studying
"Johnathan Livingston Seagull" :-}) is seldom met. Even in Rand and
Heinlein we find plenty of allegedly free-market corporations who cozy
up to the State, buy elections, impose bureaucratic laws they
know will stifle new competitors, etc. We saw them in Rand, with the
"Anti Dog-eat-Dog Law," and the various slacker companies, and we
certainly see it in the real world. Corporations that hire the police
to break strikes by breaking heads (and I mean strikers who are merely
not working, or who are walking a line); there's strike violence on
both sides, of course. Or corporations who pay bribes to bypass laws
(even "reasonable" laws that any libertarian would support, such as
law involving the dumping of toxic waste into streams). Or
corporations that use the legal and patent system to suppress
upstarts. (I could name a company I happen to know quite well, which
basically stole its starting seed products from the company it sprung
from, then later used the legal system and government laws to cleverly
stop some others from doing the same thing.)

As Mussollini so cogently put it, "corporatism is fascism." A State
that blesses Fiat and suppresses competitors, or that blesses Lockheed
through bailouts and exemptions from laws, is basically fascist.
(Fascist is a term with a socioeconomic meaning, not merely an epithet
or adjective.)

(As many of you may imagine, much of the hype about the Information
Superduperhighway--more suitably called the Infobahn--is explicity
totatalitarian, with large corporations slavering to get a piece of
the action! I have no problems with Cyberdyne Systems, for example,
installing new T2 links to where customers want more bandwidth. But
the I-way is a large boondoggle, with sociocrats and "cybercrats"
(apparently a new term from Mark Stahlman, which I like) trying to
plan the optimal society and with corporation pleding to "make the
packets run on time." Ughh!)

Make no mistake about it, strong crypto, what I call crypto anarchy,
will have as great an effect on corporate sizes, structures, and
behaviors as it will have on governments. Maybe more of an effect.

I'm glad to see Rich Dutcher on our list, as we need more folks of
that persuasion. (I can happily coexist with thoughtful leftists who
have some appreciation of the issues--Dave Mandl also comes to mind.
The ones I can't abide are the ignoramuses who blithely speak of
redistributing income and have grade school understandings of markets
and economics. They have no idea of the corporate fascism that comes
from state-run economies. But then the same applies to libertarians
with a lack of understanding.)

> So encrypt away, guys, and I'll keep telling *my* compatriots that no, 
> "the modem in Washington" didn't rig all the vote-counting computers 
> in the last election.  I'm relying on you-all to keep it that way, 
> while others try to make/keep voting meaningful.  It's called 
> division of labor ...

> Rich Dutcher, San Francisco Greens

> "That's libertarians for you - anarchists who want police protection from their slaves."
>                           Kim Stanley Robinson, "Green Mars"

That's a good one! I loved "The Gold Coast" by him, so maybe I'll have
to read this one (though I've skipped the recent crop of "Mars" books).


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From tcmay at netcom.com  Tue Feb  7 02:16:44 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 02:16:44 PST
Subject: Is the remailer crisis over?
In-Reply-To: <CeSBlKjqRGfK078yn@mirage.skypoint.com>
Message-ID: <199502071015.CAA26435@netcom9.netcom.com>


Samuel Kaplin wrote:
> 
> Well folks as of 11:30 on 1-30-94 there are 14 remailers with uptimes
> greater than 99%. What's the consensus...Is the remailer crisis over?
> 

It's great that it's on the upswing again, as it was dipping
pretty low a few weeks back. 

I don't think the "crisis" will be over until there are at least 50
remailers, spread over at least five countries. Each supporting the
usual features, and with some reasonable traffic.

With luck, and with "remailer accounts," this could happen by this
summer.

But it's a good sign.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From stig at hackvan.com  Tue Feb  7 02:43:21 1995
From: stig at hackvan.com (Stig)
Date: Tue, 7 Feb 95 02:43:21 PST
Subject: The Rise of "Worse is Better"...
In-Reply-To: <m0rbm8e-0006DaC@hackvan.com>
Message-ID: <m0rbnN3-0006DaC@hackvan.com>


L. McCarthy wrote:
> 
> Why did you send this to cypherpunks ?  I don't see any crypto/privacy
> relevance.

No crypto/privacy relevance.  Software methodology relevance.  It makes
points about why it's better to get 50% out the door immediately than to be
overly stuck on doing everything "The Right Way"...

That the "Worse is Better" approach has better survival characteristics than
"The Right Way" approach is applicable to the mission(s) of the cypherpunks
is it not?  Of course, in the case of the cypherpunks, it may be preaching
to the converted and if that is the case, then I apologize...

> Perhaps you're hoping to revive the latest pointless James Donald flame
> war ?

I only subscribe to cp-lite, so I don't have to read all the rehashed
flames.  I suppose that I should be glad that I missed it...

    Stig





From tcmay at netcom.com  Tue Feb  7 02:44:11 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 02:44:11 PST
Subject: Remailer Scripting Languages
In-Reply-To: <ab54891b070210044757@[132.162.201.201]>
Message-ID: <199502071042.CAA27653@netcom9.netcom.com>


Jonathan Rochkind wrote:

> At 6:55 PM 01/31/95, Robert Rothenberg wrote:
> >Without quoting the entire message, I think I better solution, in terms of
> >ease to implement as well as conserving bandwidth would be to have a
> >sophisticated remailer script-language.
> 
> Yeah, this is really an excellent idea, that I don't see happening any time
> soon. Although of course if anyone wants to write code for such a beast,
> that would be really excellent.  If someone gets around to writing it,
> it'll happen, but it would be a fairly big project, so I wouldn't hold my
> break.  Safe TCL, anyone?

I certainly support this kind of idea, and have for a long time.
Crypto is well-suited for the "small languages" point of view (and the
competing points of view for object-oriented systems, production
systems, etc.).

Anything to abstract away the grungy details and hide them. TCL and
Perl are steps, and Strick (Henry Strickland) has of course been
working on his Skronk system, which does some of this.

Python is another possibility.

Some of the graphical-oriented languages like Prograph might be
useful. And I still think Smalltalk has promise, as many financial
institutions are using it to model and automate financial
transactions, which have obvious similarities to our crypto projects. 

The real obstacles are time and money. Corporations and banks doing
this work can put several people on these projects for several years,
while most Cypherpunks projects have to be fit in between "Data
Structures 202" and "Ren and Stimpy."

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From perry at imsi.com  Tue Feb  7 04:46:44 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Tue, 7 Feb 95 04:46:44 PST
Subject: dna ink
In-Reply-To: <199502070417.WAA01434@einstein.ssz.com>
Message-ID: <9502071246.AA06847@snark.imsi.com>



root says:
> This is the same problem that arose with the original idea of seals once
> the skills of metalworking became commen enough. By the 1500's it was
> nearly impossible to keep a seal confidential more than a few weeks until
> somebody got a impression and built a copy.

Seals were duplicatable from the start. You just needed clay and a
seal made with the oritinal if you wanted to forge them -- fairly
common stuff. Signatures have been duplicatable from the start, too.

Signatures and seals are NOT truly authenticating technologies. They
are just a legal mechanism for an entity to demonstrate that it has
read and agreed to the terms on a document. It was always assumed that
someone might forge a signature, which is why if you had a document
where you cared that people might disclaim their signature, you got
people who could testify to the signature to witness the signing.

Digital "signatures" are the first real unforgeable authentication
technology mankind has developed.

Perry





From usenet at netnet2.netnet.net  Tue Feb  7 05:13:54 1995
From: usenet at netnet2.netnet.net (Usenet Autoresponder)
Date: Tue, 7 Feb 95 05:13:54 PST
Subject: lwall
Message-ID: <199502071312.HAA26488@netnet2.netnet.net>


DO NOT PANIC!  REMAIN CALM!  READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET!

Your Usenet test article was received here at the news gateway machine for
NetNet, Inc. in Green Bay Wisconsin.  We provide wholesale internet services
for all kinds of services for internet providers and end-users.  From WWW 
pages, newsfeeds, telnet accounts, ppp services, to fully maintained POP's
in your area. 

For sales info please address sales at netnet.net.  Technical and news support to
shane at netnet.net

For an auto-reply of gereral services and prices email info at netnet.net

If you're a newsadmin and you'd like to run your own autoresponder, this one
is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

There are typically 5 possible reasons why you were sent this e-mail message:

1) You intentionally posted a Usenet news article to a *.test newsgroup.  
These newsgroups exist so you can verify that your articles are being 
propagated correctly.  When your article arrives here, we send you this message
as confirmation.  We will only send you ONE e-mail reply for each of your test
articles that we see.

2) You unintentionally posted a Usenet news article to a *.test newsgroup.  
This is a bit of net.childishness caused by a Followup-To: header directing all
replies into a *.test newsgroup.  This is done by somebody upset with the
content of a discussion thread who wants to "punish" anybody who replies to his
message.  Your reply will be sent to *.test instead of the original newsgroup,
and you will start receiving autoresponder messages similar to this one that
you didn't ask for.  To avoid this in the future, look for a Followup-To:
header and make sure it's appropriate before replying to any articles.

3) You were a victim of a Reply-To: header directing your e-mail into a *.test
newsgroup via a mail->news gateway.  Similar to 2) above.

4) Somebody has forged a posting in your name to one of the *.test newsgroups.
To avoid this in the future, use better net.etiquette and you will make fewer
net.enemies.  If you want to try and identify the forger, use the following
procedure.  Make a legitimate posting to the same *.test newsgroup that the
forger used.  We will send you an e-mail reply.  Compare the Path: header from
this legitimate reply with the Path: header from the forgery.  The front
part of the two headers will be the same or topologically similar path to
your site.  Where the forged header becomes substantially different can
provide clues to where the forger lives.  Note that if you receive multiple
newsfeeds you may need to repeat this process several times so you can discover
all legitimate paths between our site and yours.  Once you think you've
identified the forger's site, try sending POLITE e-mail to the newsadmin/
sysadmin/postmaster explaining the situation.

5) You issued a cancel control message to a *.test newsgroup.  Some users
dislike autoresponses for cancel messages, but the newsadmins here think it
can be a valuable diagnostic tool for verifying cancel propagation.  If you
don't like it, use the "delete" key in your mail client!

All headers plus at most 10 lines of user text from your original article are
reproduced below for your perusal:

questions to shane at netnet.net
complaints to /dev/null

------------------------------- your post follows ----------------------------
Path: netnet2.netnet.net!news.sprintlink.net!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT

test
test





From rfb at lehman.com  Tue Feb  7 05:22:55 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Tue, 7 Feb 95 05:22:55 PST
Subject: Cooperation
In-Reply-To: <9502062043.AA05429@snark.imsi.com>
Message-ID: <9502071321.AA19736@cfdevx1.lehman.com>


    Date: Mon, 06 Feb 1995 15:43:46 -0500
    From: "Perry E. Metzger" <perry at imsi.com>

    I'd say that it would work far better if things were changed to MIME
    formats. You would send a message by recursively encapsulating your
    message to be remailed inside a MIME message. Simple and clean...

Personally, I vastly prefer that things that can be handled with
header lines be handled that way.

MIME may be general and handle messages with mixed data, but the
Big-Ugly-Block style that everything seems to be moving to is, well,
overly big and overly ugly.

When the data in a message is of a single type, adding all of this
ugly MIME bulk is neither simple nor clean.  It's artificial
complexity and needless blecherousness.

Recursive encapsulation needn't affect how any particular level looks.

			Rick





From rparratt at london.micrognosis.com  Tue Feb  7 05:32:28 1995
From: rparratt at london.micrognosis.com (Richard Parratt)
Date: Tue, 7 Feb 95 05:32:28 PST
Subject: lwall
Message-ID: <9502071330.AA03045@pero>


Someone at Berkeley's been a reet tit,
haven't they..

--
Richard

> ------------------------------- your post follows ----------------------------
> Path: netnet2.netnet.net!news.sprintlink.net!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
> Subject: lwall
> Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
> NNTP-Posting-Host: ack.berkeley.edu
> Organization: cypherpunks
> Lines: 2
> From: cypherpunks at toad.com
> Distribution: world
> Newsgroups: alt.test
> Date: 6 Feb 1995 19:34:19 GMT
> 
> test
> test
> 





From lce at wwa.com  Tue Feb  7 06:34:09 1995
From: lce at wwa.com (Larry E)
Date: Tue, 7 Feb 95 06:34:09 PST
Subject: Source code for Applied Cryptography
Message-ID: <sGuDlG9s1Si8075yn@wwa.com>


I think it's been mentioned that the source code for Bruce
Schneier's "Applied Cryptography" was available via ftp.  

Would someone be so kind as to post some locations where it can be
obtained?

Thanks for the help.






From jcorgan at aeinet.com  Tue Feb  7 06:50:23 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Tue, 7 Feb 95 06:50:23 PST
Subject: Source code for Applied Cryptography
Message-ID: <Chameleon.4.01.950207065030.jcorgan@comet.aeinet.com>


>I think it's been mentioned that the source code for Bruce
>Schneier's "Applied Cryptography" was available via ftp.  
>
>Would someone be so kind as to post some locations where it can be
>obtained?

This web page isn't the complete set, but points to most of it anyway:

http://www.openmarket.com/info/cryptography/applied_cryptography.html

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov
WWW:                     ftp://ftp.netcom.com/pub/jc/jcorgan/home.html






From jcooper at acs.ucalgary.ca  Tue Feb  7 07:45:14 1995
From: jcooper at acs.ucalgary.ca (jason cooper)
Date: Tue, 7 Feb 95 07:45:14 PST
Subject: The Rise of "Worse is Better"...
In-Reply-To: <m0rbm8e-0006DaC@hackvan.com>
Message-ID: <Pine.3.89.9502070839.B31143-0100000@acs6.acs.ucalgary.ca>


I like.  I guess I'm basically in with the New Jersey crowd.  Anybody 
else?

-----------------------------------------------------------------
  "The meek shall inherit the earth...   Fortunately, the rest of
us will upgrade to the new version, which is supposed to come out
later this year."
 
Jason Cooper                              jcooper at acs.ucalgary.ca







From hfinney at shell.portal.com  Tue Feb  7 08:37:19 1995
From: hfinney at shell.portal.com (Hal)
Date: Tue, 7 Feb 95 08:37:19 PST
Subject: MIME based remailing commands
Message-ID: <199502071636.IAA15674@jobe.shell.portal.com>


From: "Perry E. Metzger" <perry at imsi.com>
> 
>     I'd say that it would work far better if things were changed to MIME
>     formats. You would send a message by recursively encapsulating your
>     message to be remailed inside a MIME message. Simple and clean...

Here is an example of how such a mesage might look.  I created it using
the safe-tcl scripting language.  Interestingly, safe-tcl can to a
considerable extent be considered a tcl extension to let you work easily
with mime messages.  It makes it easy to create and parse them.

The whole message could be encrypted and marked with the "Encrypted: PGP"
header as we do now, or when the new PGP/MIME standard is finalized then
that could be followed.

I made up two new content types for this, one to hold the composite
multipart message, and one to hold the remailer commands themselves.
Although these types are not implemented, I think it would be very easy
to make a remailer that would use this structure, built out of safe-tcl.
(The batching and latency would not be trivial, but the basic remailing
would be easy.)

Hal

> To: hfinney at shell.portal.com
> Subject: No subject
> Mime-Version: 1.0
> Content-Type: multipart/remail; boundary="----- =_792174086"
> Content-ID: <1471.792173861.3 at cryo>
>  
> ------- =_792174086
> Content-Type: application/remail-commands
> Content-ID: <1471.792173861.1 at cryo>
> 
> Latency: 2 hours
> Minimum-Batch-Size: 5 messages
> Anon-Send-To: cypherpunks at toad.com
> Subject: Example of remailed message
>  
> ------- =_792174086
> Content-Type: text/plain
> Content-ID: <1471.792173861.2 at cryo>
>  
> This is a message which is being sent to the mailing list.
> It is being remailed via a MIME-based structure where two new content types
> are defined: multipart/remail and application/remail-commands.  The
> multipart/remail type is supposed to be composed of two parts, the
> application/remail-commands part which has remailer commands, and the
> other part which is the "payload" to be remailed.
>  
> ------- =_792174086--





From perry at imsi.com  Tue Feb  7 08:49:48 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Tue, 7 Feb 95 08:49:48 PST
Subject: MIME based remailing commands
In-Reply-To: <199502071636.IAA15674@jobe.shell.portal.com>
Message-ID: <9502071649.AA08393@snark.imsi.com>



I was actually contemplating going a bit further, and making the core
message not a "text/plain" but a Message/Rfc822, but without a "From",
or perhaps with a "From: somethingfictitious". I also wouldn't declare
the contents to be a multipart -- rather I'd have them be a security
multiparts container that in turn contained a multipart containing a
remail commands section and another security multipart...

Hal says:
> From: "Perry E. Metzger" <perry at imsi.com>
> > 
> >     I'd say that it would work far better if things were changed to MIME
> >     formats. You would send a message by recursively encapsulating your
> >     message to be remailed inside a MIME message. Simple and clean...
> 
> Here is an example of how such a mesage might look.  I created it using
> the safe-tcl scripting language.  Interestingly, safe-tcl can to a
> considerable extent be considered a tcl extension to let you work easily
> with mime messages.  It makes it easy to create and parse them.
> 
> The whole message could be encrypted and marked with the "Encrypted: PGP"
> header as we do now, or when the new PGP/MIME standard is finalized then
> that could be followed.
> 
> I made up two new content types for this, one to hold the composite
> multipart message, and one to hold the remailer commands themselves.
> Although these types are not implemented, I think it would be very easy
> to make a remailer that would use this structure, built out of safe-tcl.
> (The batching and latency would not be trivial, but the basic remailing
> would be easy.)
> 
> Hal
> 
> > To: hfinney at shell.portal.com
> > Subject: No subject
> > Mime-Version: 1.0
> > Content-Type: multipart/remail; boundary="----- =_792174086"
> > Content-ID: <1471.792173861.3 at cryo>
> >  
> > ------- =_792174086
> > Content-Type: application/remail-commands
> > Content-ID: <1471.792173861.1 at cryo>
> > 
> > Latency: 2 hours
> > Minimum-Batch-Size: 5 messages
> > Anon-Send-To: cypherpunks at toad.com
> > Subject: Example of remailed message
> >  
> > ------- =_792174086
> > Content-Type: text/plain
> > Content-ID: <1471.792173861.2 at cryo>
> >  
> > This is a message which is being sent to the mailing list.
> > It is being remailed via a MIME-based structure where two new content types
> > are defined: multipart/remail and application/remail-commands.  The
> > multipart/remail type is supposed to be composed of two parts, the
> > application/remail-commands part which has remailer commands, and the
> > other part which is the "payload" to be remailed.
> >  
> > ------- =_792174086--





From nobody at tower.techwood.org  Tue Feb  7 09:09:02 1995
From: nobody at tower.techwood.org (Anonymous)
Date: Tue, 7 Feb 95 09:09:02 PST
Subject: Is the remailer crisis over?
In-Reply-To: <199502071015.CAA26435@netcom9.netcom.com>
Message-ID: <199502071708.JAA17106@tower.techwood.org>


tcmay at netcom.com (Timothy C. May) wrote:

> I don't think the "crisis" will be over until there are at least 50
> remailers, spread over at least five countries. Each supporting the
> usual features, and with some reasonable traffic.
> 
> With luck, and with "remailer accounts," this could happen by this
> summer.

I think the increase in remailers is partly due to better
protection/privacy/anonymnity for remailer operators, which is a good
thing, but I worry about puting all our eggs in one basket.  Nearly 40%
of the remailers now are either on c2.org or through John Perry's and
Matt Ghio's MXing thing.  I don't know much about the latter, but
Sameer's net connection is not very reliable and disconnects frequently.
 It seems these two points of failure could cause serious problems for
the remailer network as a whole.  Not to mention that these two systems
would be prime targets for anyone who wants to do traffic analysis...

The remailer crisis is far from over.





From andrew_loewenstern at il.us.swissbank.com  Tue Feb  7 09:37:02 1995
From: andrew_loewenstern at il.us.swissbank.com (Andrew Lowenstern)
Date: Tue, 7 Feb 95 09:37:02 PST
Subject: (dis)advantages of DC-Net vs remailers
Message-ID: <9502071736.AA00821@ch1d157nwk>


>  And when you try to figure how to deal with denial of service
>  attacks in a big DC net that tries to use bandwidth with tolerable
>  efficiency -- I don't know if anyone has figured out what would be
>  involved -- I certainly have not.

The bandwidth is the easy part.  Building clients that do a DC protocol with  
real-world reliability and resistance to denial of service is the hard part.   
And doing all this in a package that would be easy to get people to use is  
probably the hardest part.

The only way I know of to deal with denial of service is for everyone to  
reveal their flips and kick the attackers out of the net.  However, if  
someone is legitimately transmitting that round they loose their  
untraceability.  So pretty much the only way to do it is ensure that only one  
participant has permission to transmit and that the participant with  
permission gets to decide if everyone shows their hands.

A way to do this would be to have a separate reservation phase of the  
protocol.  In the reservation phase all of the participants 'bid' on a token.  
 Whoever gets the token has permission to transmit during that round.  If  
collisions have been occurring, the participant holding the token can demand  
that everyone reveal their flips.  I think there is a paper describing a  
protocol for this, but I don't have access to a library with crypto material.

The protocol for distributing the token would be somewhere between an  
All-Or-Nothing-Disclosure-Of-Secrets and a poker card dealing protocol.  Only  
one person should be able to get the token and nobody should know who got it.  
 To make it more complicated, for people to be able to transmit in a timely  
fashion, you should be able to specifically request the token when you want  
it (so you would have a 1/n chance of getting it with n being the total  
number of participants wanting to transmit that round), and not have any  
chance of getting it when you don't want to transmit.  In addition the  
generation of the token(s) should be secure so that none of the participants  
have to trust anyone that only one participant can get a valid transmit  
token.

I can think of a way to do this with a mental poker protocol.  The only  
problem is there is always a 1/n chance of getting the transmit token (where  
n is the total number of participants), whether you want it or not.  I  
believe it also requires some trust in the 'dealer'...  Anyway, the deck  
would consist of 1 transmit token and n-1 blank tokens.  Immediately after  
the transmit phase the participant holding the token can optionally demand  
that everyone reveal their flips.  To do that the participant would reveal  
their valid transmit token.  At that point everyone else would reveal their  
blank transmit tokens (to make sure there are no duplicates).  If anyone  
refuses to reveal their blank token, they are removed from the net.  Once  
it's been determined that there is only one valid transmit token, everyone  
reveals their flips.

In theory all of this stuff would work, but implementing it is a different  
story.  For a DC net to be practical, it would have to run completely without  
human intervention.  Maybe a client could be placed in your .login or shell  
rc file and would run in the background whenever you were logged in.  It  
could keep running after you logged out if you had a message in your queue to  
be sent out.  Clients must be smart enough to synchronize rounds and remove  
participants who aren't responding fast within time-outs, etc...   
automatically attempt to 'lay a trap' when collisions have been occurring,  
figure out who is disrupting or not following protocol and remove them or  
alternately have the client drop out of the DC-Net when protocol hasn't been  
followed to satisfaction (duplicate tokens in one round, etc...), etc...

Quite a tall order, and for how much more untraceability than the current  
remailer system?  Even if it is implemented you still have to get people to  
use it.  The current remailer system can be used with no software  
whatsoever...

Still, it's an interesting prospect, as it offers real sender and receiver  
untraceability within the group of participants.  But is it worth it?


(apologies for the length...)
andrew





From keith at filoli.com  Tue Feb  7 09:53:15 1995
From: keith at filoli.com (Keith Henson)
Date: Tue, 7 Feb 95 09:53:15 PST
Subject: dna ink
Message-ID: <199502071740.JAA26640@mentat.filoli.com>


Re signin in blood, I heard last year that the Army is requiring
a drop of blood on enlistment papers.  It is no some kind of pack
with the devil :-) but if all they ever find of you is a wrist 
bone, they want to be able to match DNA.  Keith






From jya at pipeline.com  Tue Feb  7 09:58:40 1995
From: jya at pipeline.com (John Young)
Date: Tue, 7 Feb 95 09:58:40 PST
Subject: CIAC Bulletin F-10:  HP-UX Remote Watch
Message-ID: <199502071758.MAA14611@pipe3.pipeline.com>


   [Reformated for mailing by <jya at pipeline.com>.]


   Sender: ciac-bulletin at cheetah.llnl.gov
   Subject: CIAC Bulletin F-10: HP-UX Remote Watch


       _____________________________________________________
                   The U.S. Department of Energy
               Computer Incident Advisory Capability
                     ___  __ __    _     ___
                    /       |     /_\   /
                    \___  __|__  /   \  \___
       _____________________________________________________

                       INFORMATION BULLETIN

                        HP-UX Remote Watch


   February 6, 1995 1200 PST                     Number F-10
   _________________________________________________________

   PROBLEM:       Security vulnerabilities in HP-UX Remote
                  Watch can be used to increase access
                  privileges of users.

   PLATFORMS:     HP 9000 series 300/400s and 700/800s, for
                  HP-UX versions 8.x and 9.x

   DAMAGE:        User can increase their access privileges.

   SOLUTION:      Apply appropriate vendor patch as described
                  below.
   _________________________________________________________

   VULNERABILITY
   ASSESSMENT:    The security vulnerability in HP-UX Remote
                  Watch can be used to increase a user's
                  access privileges which may result in
                  system compromise.  CIAC urges affected
                  sites to install install the appropriate
                  secuirty patch as soon as possible.
   _________________________________________________________

        Critical Information about HP-UX Remote Watch

   CIAC has obtained information from Hewlett Packard
   regarding a new security vulnerability in Remote Watch
   contained in the WATCH-RUN fileset for releases of HP-UX. 
   Appendix I provides detailed patch information for the HP
   Remote Watch vulnerability.


   The document /pub/ciac/bulletin/f-fy95/hppatchs.txt has
   been updated to reflect this bulletin.  The hppatchs.txt
   document contains the entire list of all HP Bulletins and
   patches and is available on our FTP server ciac.llnl.gov.


   HP has an automatic server to allow patches and other
   security information to be retrieved over the Internet.  To
   utilize this server, send an e-mail message to
   support at support.mayfield.hp.com.  The subject line of the
   message is ignored and the body (text) of the message
   should contain the words


   send XXXX


   where XXXX is the identifier for the information you want
   retrieved.  For example, to retrieve the patch PHSS_4834,
   the message would be "send PHSS_4834".


   Other information that can be retrieved include the HP
   SupportLine mail service user's guide (send guide.txt), the
   readme file for a patch and the original HP bulletin (send
   doc HPSBUX9501-020).


   HP also has a World Wide Web server to browse and retrieve
   bulletins and patches.  To utilize this server, use a WWW
   client and connect to http://support.mayfield.hp.com.


   IMPORTANT NOTE: Hewlett Packard updates patches
   periodically.  These updates are not reflected in the text
   of each HP bulletin.  The overview presented here contains
   current information on the patches available at the time of
   the release of this CIAC bulletin.  If you request an
   updated patch, when you try to retrieve the patch you will
   receive a message stating that the patch is obsolete and
   the name of the patch which supersedes it.


   Hewlett Packard has made sum and MD5 checksums available
   for their patches and for their security bulletins.  See
   the detailed explanation for HPSBUX9408-016 in CIAC
   bulletin F-02 for information on how to access and utilize
   these checksums.

   _________________________________________________________

   CIAC wishes to thank Hewlett Packard for the information
   contained in this bulletin.
   _________________________________________________________

   CIAC is the computer security incident response team for
   the U.S. Department of Energy.  Services are available free
   of charge to DOE and DOE contractors.


   DOE and DOE contractor sites can contact CIAC at:

        Voice:   510-422-8193
        FAX:     510-423-8002
        STU-III: 510-423-2604
        E-mail:  ciac at llnl.gov


   Previous CIAC notices, anti-virus software, and other
   information are available on the Internet via anonymous FTP
   from ciac.llnl.gov (IP address 128.115.19.53).


   CIAC has several self-subscribing mailing lists for
   electronic publications:

   1.   CIAC-BULLETIN for Advisories, highest priority - time
        critical information, and Bulletins, important
        computer security information;

   2.   CIAC-NOTES for Notes, a collection of computer
        security articles;

   3.   SPI-ANNOUNCE for official news about Security Profile
        Inspector (SPI) software updates, new features,
        distribution and availability;

   4.   SPI-NOTES, for discussion of problems and solutions
        regarding the use of SPI products.


   Our mailing lists are managed by a public domain software
   package called ListProcessor, which ignores E-mail header
   subject lines. To subscribe (add yourself) to one of our
   mailing lists, send requests of the following form:


   subscribe list-name LastName, FirstName PhoneNumber


   as the E-mail message body, substituting CIAC-BULLETIN,
   CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for "list-name" and
   valid information for "LastName" "FirstName" and
   "PhoneNumber."  Send to: ciac-listproc at llnl.gov not to:
   ciac at llnl.gov


   e.g.,

   subscribe ciac-notes O'Hara, Scarlett 404-555-1212 x36

   subscribe ciac-bulletin O'Hara, Scarlett 404-555-1212 x36


   You will receive an acknowledgment containing address and
   initial PIN, and information on how to change either of
   them, cancel your subscription, or get help.
   _________________________________________________________

   PLEASE NOTE: Many users outside of the DOE and ESnet
   computing communities receive CIAC bulletins. If you are
   not part of these communities, please contact your agency's
   response team to report incidents. Your agency's team will
   coordinate with CIAC. The Forum of Incident Response and
   Security Teams (FIRST) is a world-wide organization. A list
   of FIRST member organizations and their constituencies can
   be obtained by sending E-mail to first-request at first.org
   with an empty subject line and a message body containing
   the line: send first-contacts.


   This document was prepared as an account of work sponsored
   by an agency of the United States Government. Neither the
   United States Government nor the University of California
   nor any of their employees, makes any warranty, expressed
   or implied, or assumes any legal liability or
   responsibility for the accuracy, completeness, or
   usefulness of any information, product, or process
   disclosed, or represents that its use would not infringe
   privately owned rights. Reference herein to any specific
   commercial products, process, or service by trade name,
   trademark manufacturer, or otherwise, does not necessarily
   constitute or imply its endorsement, recommendation, or
   favoring by the United States Government or the University
   of California. The views and opinions of authors expressed
   herein do not necessarily state or reflect those of the
   United States Government nor the University of California,
   and shall not be used for advertising or product
   endorsement purposes.

   _________________________________________________________

        Appendix I:  Details of HP-UX Remote Watch Bulletin


   HPSBUX9510-020: HP-UX Remote Watch dated January 31, 1995


   This vulnerability can allow users to increase their access
   privileges which may result in system compromise.  All HP
   300/400 and 700/800 series machines running HP-UX 8.x or
   9.x which have Remote Watch installed are affected.


   The patch to install depends on which operating system
   version and machine series you are currently using.  Use
   the following table to determine which patch to retrieve
   and install:


   Operating System      Series    Apply patch

   HP-UX 8.x             800       PHSS_5185
   HP-UX 9.x             800       PHSS_5136
   HP-UX 8.x             700       PHSS_5180
   HP-UX 9.x             700       PHSS_5107
   HP-UX 8.x             300/400   PHSS_5168
   HP-UX 9.x             300/400   PHSS_5120


   Obtain necessary patches, and install per the installation
   instructions included with the patches.


   After the patch is installed, be sure to examine
   /tmp/update.log for any relevant WARNINGs or ERRORs.  This
   can be done by typing "tail -60 /tmp/update.log | more",
   then paging through the screens via the space bar, looking
   for WARNING or ERROR messages.


   [END]







From tjb at acpub.duke.edu  Tue Feb  7 10:14:44 1995
From: tjb at acpub.duke.edu (Tom Bryce)
Date: Tue, 7 Feb 95 10:14:44 PST
Subject: testing the waters re: new crypto FTP site
Message-ID: <v01510101ab5d68bca64c@[152.3.113.8]>


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


I'm considering setting up a new FTP site dedicated to cryptography
and security software, code, and information, with particular emphasis
on personal microcomputer (even more particular emphasis on macintosh :)
) security.

I'm sending this message to test the waters regarding how useful such
a new site would be. I considered setting up a new PGP keyserver
earlier, but the consensus of net.opinion when I asked about it seemed
to be that there were plenty of keyservers that worked fine already, so
I abandoned the idea. :-) Does anyone have an opinion they could send me
regarding whether such a new site would be useful / would not be too
useful? I'm looking to do something that would actually be useful to the
net.community.

For example, I'd like to scavenge the various crypto archives as well
as public archives for programs to password-protect hard drives, encrypt
files and volumes, monitor AppleShare access, do stegnanography, and so
on. Of course, there are the old standbys as well: PGP, cryptanalysis,
dictionaries, password crackers, interesting documentation and clippings
from EMAIL and net.posts from people who know their stuff, and so on.

The crypto stuff, folks would have to send me email establishing legal
eligibility, whereupon I'd create for them a non-anonymous account. The
non-crypto stuff would be in directories accessible to anonymous FTP
login.

This sounds like a lot of fun and I'd enjoy running it. However, if,
like my keyserver idea, I wouldn't be doing anything really new or
useful, it might just be a way for me to spend lots of time not getting
much useful stuff done. :-)

In particular, mail saying "Yeah, that sounds cool, I'd use it" would
mean potential users. No mail to this effect would mean folk already
have sufficient FTP resources. Any opinions appreciated.

Tom
tjb at acpub.duke.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLze6FluwJA7oL8O9AQGtGAQAxAXt1Fhw5IykRe7W4Ls09NvKePwL5l4t
43uwnEunDNUNWYpdPqVOAErb1RG4217RC2bXRkzwPiorPzxNP8X1IYdS81fQ1NZo
288OO3IJC0xvT3+YxglKerAfkHY5sfrihGKOysT/BZfxNSY6LM/8N38T2hyRyw/4
ZGE0o2KP4TQ=
=XY/5
-----END PGP SIGNATURE-----







From ktk at anemone.corp.sgi.com  Tue Feb  7 10:32:33 1995
From: ktk at anemone.corp.sgi.com (Katy Kislitzin)
Date: Tue, 7 Feb 95 10:32:33 PST
Subject: preliminary cypherpunks announcement
In-Reply-To: <199502070311.WAA03160@bwh.harvard.edu>
Message-ID: <199502071830.KAA29964@anemone.corp.sgi.com>


> From: Adam Shostack <adam at bwh.harvard.edu>
 > Is the march meeting scheduled yet?  I'm trying to plan to be out for
 > both CFP & the cypherpunks meeting, but have paid no attention to when
 > they're held, since I live on the wrong coast to attend most of them.
 > 
 > Adam
 > 
 > -- 
 > "It is seldom that liberty of any kind is lost all at once."
 > 						       -Hume

 We have the usual 2nd Saturday (March 12) meeting planned, but I
 *definitely* think cpunks should do something around the cfp
 conference.  last year we did an informal in-the-hotel-halls meeting,
 but since this cfp is in the bay area....  I propose keeping the
regular March and April mtgs, and adding a cpunks dinner &&|| BOF at
cfp.  other ideas?

--kt
 ps CFP is March 28-31, at the sf airport marriot in burlingame ca.






From adam at bwh.harvard.edu  Tue Feb  7 10:41:14 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Tue, 7 Feb 95 10:41:14 PST
Subject: CIAC Bulletin F-10:  HP-UX Remote Watch
In-Reply-To: <199502071758.MAA14611@pipe3.pipeline.com>
Message-ID: <199502071840.NAA05395@freud.bwh.harvard.edu>


Since CERT & CIAC have public lists for this stuff, and since everyone
who wants to get these advisories already does, please post at most a
pointer to the things.

Adam




From frissell at panix.com  Tue Feb  7 11:13:35 1995
From: frissell at panix.com (Duncan Frissell)
Date: Tue, 7 Feb 95 11:13:35 PST
Subject: Corporate Fascism, Rand, Greens, Oh My!
Message-ID: <199502071907.AA08674@panix.com>


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

Tim May writes:

>Make no mistake about it, strong crypto, what I call crypto anarchy,
>will have as great an effect on corporate sizes, structures, and
>behaviors as it will have on governments. Maybe more of an effect.

For those of you who want a solid discussion of just *how* computer
technology (let alone crypto) downsizes companies see the Economist article
"The Incredible Shrinking Company" thoughtfully HTMLized by yours truely:

http://www.ios.com/~lroth/clips/bussiz.html

DCF

- --
If it's on your hard drive (and of interest to others) it should be on the
WEB.  Post something on your WEB page every day.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzeNoYVO4r4sgSPhAQH8bQP/TuNsPuq3oz1aeXpGqXSomwou10ThucmE
MeEahsf6lg2RwSBiHzuykhprNHuYHpgnFjePxFRC2Wxl6rB0l5ySto/B9KOTXm47
LvAhwmpD1xmyomOkNqttlBLSopuXb1o4FewS/m7awV9N1+KK5IqLcYdJZxeaOK9H
i5u/Zw8oONE=
=XARh
-----END PGP SIGNATURE-----






From asgaard at sos.sll.se  Tue Feb  7 11:14:35 1995
From: asgaard at sos.sll.se (Mats Bergstrom)
Date: Tue, 7 Feb 95 11:14:35 PST
Subject: Is the remailer crisis over?
In-Reply-To: <199502071708.JAA17106@tower.techwood.org>
Message-ID: <Pine.HPP.3.91.950207184635.26403A@cor.sos.sll.se>



Anonymous wrote:

> The remailer crisis is far from over.

And the other kind of remailer - Julf style - might possibly be
in a crisis too. One of the Horsemen (Pedo) hit Sweden in a
heavier way than ever before, yesterday. Top front page article
in a leding newspaper followed up in the evening news on a main
national TV channel. Another newspaper article today but still
beginning on the front page ('Intermediary admits to computer porno'). 
Guess who is the intermediary. Both newspaper (with big picture)
and TV interviews with Johan Helsingius (Julf), who belongs to the
minority in Finland having Swedish as their mother's tounge.
The story starts with some joker at Stockholm University, dep of
Computer Science, who has made a study of alt.binary.pictures.erotica
and have found that one percent of the material is 'nude pictures of
girls and boys 8-10 years of age' and that 'most of the child-pictures
have bounced through Johan Helsingius' computer in Helsingfors'. 
Mr Helsingius says that he is very concerned and (picture subtitle:) 
'lies awake at night'. The big fat hedline on top of his picture 
says: 'This is where the kiddie porn is spreading from'. I guess
this is big "news" in Finland also, there are close media connections
between our countries. 'I don't want to reveal their addresses, only
that it concerns people in Germany and a multi-national organization
in the US' says Mr Helsingius about who are responsible for the kiddie
porn. But then he also gets a chance to talk about the benefits (abused,
political dissidents - the usual). Todays article also mention cypherpunks
remailers (although not by name).

I don't know - this just might be yesterdays news tomorrow. Kiddie porn
per se whistle-blowing is slowly getting out of fashion here, it's only
the net connection that makes it headline news. But there is a chance
some politician will try to score on this story and, as mentioned above,
the ties on that level between Helsingfors and Stockholm are strong.
We have to wait and see.

I'm getting to think that SAFE anonymous posting will need IP spoofing,
or worse (things that I know nothing about, please correct me if I'm
totally out in the blue here).

Mats

 





From eric at remailer.net  Tue Feb  7 11:28:01 1995
From: eric at remailer.net (Eric Hughes)
Date: Tue, 7 Feb 95 11:28:01 PST
Subject: dna ink
In-Reply-To: <9502071246.AA06847@snark.imsi.com>
Message-ID: <199502071926.LAA21751@largo.remailer.net>


   From: "Perry E. Metzger" <perry at imsi.com>

   Digital "signatures" are the first real unforgeable authentication
   technology mankind has developed.

Impossibility is a pretty strong concept, and here, as elsewhere, it's
an exaggeration.  Digital signatures are not unforgeable.  If you
steal the private key, you can forge signatures.  The unforgeability
is exactly as great as the strength of the container where the private
key lies.  The issue of incarnation, if you will, is perhaps the
single most important issue for actual deployment.

It's a matter of economics.  The cryptographic barrier is
insurmountable, but it's not the only barrier.  So don't try to breach
the cryptography; try to breach one of the other elements of the
system.

[Perry, I promise it's not personal; it just _seems_ like I'm
nit-picking on everything you write this week.]

A remark on the meaning of forgery.  Let me rewrite what Perry said:

   Digital "signatures" are the first authentication technology
   mankind has developed where forgery is impossible to detect.
   
An indistinguishable signature can still be a forged signature.  A
forged signature is one that is made by the wrong person.  If the
wrong person gets the private key, signatures made by that person are
forgeries, even though nobody can tell them apart.

This point is not merely pedantic.  The concept of forgery adheres to
the person committing the act, not the act itself.  A piece of data
which presents itself as a signature, but which does not pass the
verification process, is not a forged signature but an invalid one.

The external inability to distinguish proper digital signatures from
forged ones has profound effect on the legal interpretations of the
physical signing device (hardware+software).  I wish only to point
this out and leave discussion to another thread.

Eric





From eb at comsec.com  Tue Feb  7 11:57:38 1995
From: eb at comsec.com (Eric Blossom)
Date: Tue, 7 Feb 95 11:57:38 PST
Subject: dna ink
In-Reply-To: <199502061003.FAA01784@libws4.ic.sunysb.edu>
Message-ID: <199502071902.LAA27173@comsec.com>


Robert Rothenburg Walking-Owl <rrothenb at ic.sunysb.edu> writes:

> ...probably will be until DNA cloning becomes cheap and accessible...

Can you say "Polymerase Chain Reaction"?






From perry at imsi.com  Tue Feb  7 12:27:55 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Tue, 7 Feb 95 12:27:55 PST
Subject: dna ink
In-Reply-To: <199502071926.LAA21751@largo.remailer.net>
Message-ID: <9502072020.AA08784@snark.imsi.com>



Eric Hughes says:
>    From: "Perry E. Metzger" <perry at imsi.com>
> 
>    Digital "signatures" are the first real unforgeable authentication
>    technology mankind has developed.
> 
> Impossibility is a pretty strong concept, and here, as elsewhere, it's
> an exaggeration.

Naturally -- but the other methods were complete jokes -- forging a
signature requires nothing more than a pen and slight practice.

> The concept of forgery adheres to
> the person committing the act, not the act itself.

Indeed -- which is why witnesses used to be the primary verification
technology, and not graphologists...

Perry





From tcmay at netcom.com  Tue Feb  7 12:27:56 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 12:27:56 PST
Subject: Seals and Sealing Waxes
Message-ID: <ab5d0f8b040210047448@DialupEudora>


Perry says:

>root says:
>> This is the same problem that arose with the original idea of seals once
>> the skills of metalworking became commen enough. By the 1500's it was
>> nearly impossible to keep a seal confidential more than a few weeks until
>> somebody got a impression and built a copy.
>
>Seals were duplicatable from the start. You just needed clay and a
>seal made with the oritinal if you wanted to forge them -- fairly
>common stuff. Signatures have been duplicatable from the start, too.

"All crypto is economics," and this is what made seals and sealing wax so
useful for so long. Saying "seals were duplicatable from the start" does
not mean this feat was easy, even if technically possible.

In fact, the fine details produced by a good seal are hard to exactly
emulate with a copy. Even on a two-dimensional surface. And with the advent
of three-dimensional surfaces, which sealing wax made possible, the fine
detail of a good seal was in fact very hard to forge.

Not impossible, but very costly with the technology of the day. Or even the
technology of _today_. After all, paper currency is largely based on seal
technology, with various embossing, printing, etc. methods used (on special
paper) that remain fairly hard to duplicate.

(Not impossible, and counterfeiting flourishes. It's all about economics,
and I'm only disputing the claims of easiness. As an added note,
transactions in the Far East are still often "sealed" with "chop marks,"
carved stamps that are uniquely associated with persons or groups.)

>Signatures and seals are NOT truly authenticating technologies. They
>are just a legal mechanism for an entity to demonstrate that it has
>read and agreed to the terms on a document. It was always assumed that
>someone might forge a signature, which is why if you had a document
>where you cared that people might disclaim their signature, you got
>people who could testify to the signature to witness the signing.

I think this understates the importance of signatures and seals in these
earlier times.

--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^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."









From tcmay at netcom.com  Tue Feb  7 13:28:59 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 13:28:59 PST
Subject: CFP, Cypherpunks, and Crypto
In-Reply-To: <199502071830.KAA29964@anemone.corp.sgi.com>
Message-ID: <199502072127.NAA28248@netcom14.netcom.com>


Katy Kislitzin wrote:

> > From: Adam Shostack <adam at bwh.harvard.edu>
>  > Is the march meeting scheduled yet?  I'm trying to plan to be out for
>  > both CFP & the cypherpunks meeting, but have paid no attention to when
>  > they're held, since I live on the wrong coast to attend most of them.
...
>  We have the usual 2nd Saturday (March 12) meeting planned, but I
>  *definitely* think cpunks should do something around the cfp
>  conference.  last year we did an informal in-the-hotel-halls meeting,
>  but since this cfp is in the bay area....  I propose keeping the
> regular March and April mtgs, and adding a cpunks dinner &&|| BOF at
> cfp.  other ideas?

The Computers, Freedom, and Privacy Conference is to be held 29-31
March 1995, at the Marriott in Burlingame, CA (SF Airport). Details
have been distributed recently to most of the usual places.

I'll be on Michael Froomkin's "Crypto" panel on Friday, 31 March.
Along with Stewart Baker (ex-NSA, famous for "Clipper opponents just
getting revenge for missing Woodstock"), Steve Walker (TIS), Phil
Karn, a Microsoft guy, and maybe others. Details should be available.

So I'm all for a Cypherpunks BOF ("birds of a feather," in case this
term is new to you....basically, a special interest group gathering)
or dinner. Maybe more than one?

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From samman at CS.YALE.EDU  Tue Feb  7 13:40:58 1995
From: samman at CS.YALE.EDU (Ben)
Date: Tue, 7 Feb 95 13:40:58 PST
Subject: Child Porno
Message-ID: <Pine.SUN.3.91.950207163815.7583A-100000@jaguar.zoo.cs.yale.edu>


Just heard on the radio "How child pornographers are using the 'Net to 
turn your home computer into their playground and why you can't do 
anything because of lax and permissive legislation."

All this over some very discordany chords to make it seeem more ominous.  
Gotta love the evening news here in CT.

>From the same people that had a feature of 'MArtial arts weapons as 
weapons of mass destruction and how easy they are to get.'  I wonder if 
the producer is a closet facist or a ratings freak.

Ben.






From mab at research.att.com  Tue Feb  7 14:16:43 1995
From: mab at research.att.com (Matt Blaze)
Date: Tue, 7 Feb 95 14:16:43 PST
Subject: CFP, Cypherpunks, and Crypto
Message-ID: <9502072215.AA20605@merckx.info.att.com>


Tim May says:
...
>The Computers, Freedom, and Privacy Conference is to be held 29-31
>March 1995, at the Marriott in Burlingame, CA (SF Airport). Details
>have been distributed recently to most of the usual places.
>
>I'll be on Michael Froomkin's "Crypto" panel on Friday, 31 March.
>Along with Stewart Baker (ex-NSA, famous for "Clipper opponents just
>getting revenge for missing Woodstock"), Steve Walker (TIS), Phil
>Karn, a Microsoft guy, and maybe others. Details should be available.
>

While we're at it, let me put in a plug for my tutorial, "Everything
you need to know to argue about cryptography", to be held Tuesday
afternoon (March 28) as part of the pre-conference tutorial track.
Spread the word...

-matt





From kipp at warp.mcom.com  Tue Feb  7 14:44:29 1995
From: kipp at warp.mcom.com (Kipp E.B. Hickman)
Date: Tue, 7 Feb 95 14:44:29 PST
Subject: ssl-talk@netscape.com
Message-ID: <9502071444.ZM25840@warp.mcom.com>


There is now a new mailing list, called "ssl-talk at netscape.com" for people
wishing to discuss SSL and its implementations.

It uses the "smartlist" stuff, so send your (un)subscription request in the
message subject line.


-- 
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp at netscape.com          http://home.mcom.com/people/kipp/index.html






From slowdog at wookie.net  Tue Feb  7 06:58:36 1995
From: slowdog at wookie.net (slowdog)
Date: 7 Feb 1995 14:58:36 GMT
Subject: URGENT - What S.314 Would Do
Message-ID: <3h81qs$ee0@dockmaster.phantom.com>


[ Article crossposted from comp.org.cpsr.talk,comp.org.cpsr.talk,misc.legal.comp ]
[ Author was slowdog (slowdog at wookie.net) ]
[ Posted on 7 Feb 1995 14:56:15 GMT ]

The following is what Senator Exon's bill (S.314) would do to the 
Communicatons Act of 1934. The text in [brackets] is what is being 
deleted or changed. What exists as plain text outside those brackets is 
how the new law will look.

Read carefully. There are indeed implications for Internet service 
providers in terms of their responsibility under the law for the content 
of their systems and services.


-------------------------------------------------------------------

   47 USC Sec. 223
   
   TITLE 47
   CHAPTER 5
   SUBCHAPTER II
   
   
   Sec. 223. [Obscene or harassing telephone calls in the District of
   Columbia or in interstate or foreign communications] Obscene or
   harassing utilization of telecommunications devices and facilities
   in the District of Columbia or in interstate or foreign
   communications
   
   
   (a) Prohibited acts generally
   
   Whoever -
   
   (1) in the District of Columbia or in interstate or foreign
   communication by means of [telephone] telecommunications
   device -
   
   (A) [makes any comment, request, suggestion or proposal] 
   makes, transmits, or otherwise makes available any comment,
   request, suggestions, proposal, image, or other communication]
   which is obscene, lewd, lascivious, filthy, or indecent;

   (B) [makes a telephone call, whether or not conversation
   ensues, without disclosing his identity and with intent to
   annoy, abuse, threaten, or harass any person at the called
   number] makes a telephone call or utilizes a telecommunications
   device, whether or not conversation or communications ensues,
   without disclosing his identity with intent to annoy, abuse,
   threaten, or harass any person at the called number or who
   receives the communication;
   
   (C) makes or causes the telephone of another repeatedly or   
   continuously to ring, with intent to harass any person at the
   called number; or
   
   (D) [makes repeated telephone calls, during which conversation
   ensues, solely to harass any person at the called number; or]
   makes repeated telephone calls or repeatedly initiates
   communication with a telecommunications device, during which
   comversation or communication ensues, solely to harass any
   person at the called number of who receives the communication;
   or
   
   (2) knowingly permits any [telephone] telecommunications facility
   under his control to be used for any purpose prohibited by this
   section, shall be fined not more than [$50,000] $100,000 or
   imprisoned not more than [six months] 2 years, or both.
   
   (b) Prohibited acts for commercial purposes; defense to prosecution
   
   (1) Whoever knowingly -
   
   (A) within the United States, by means of [telephone], 
   telecommunications device makes (directly or by recording device)
   any obscene communication for commercial purposes to any person, 
   regardless of whether the maker of such communication [placed the
   call] placed the call or initiated the conversation; or
   
   (B) permits any [telephone] telecommunications facility under such 
   person's control to be used for an activity prohibited by
   subparagraph (A), shall be fined in accordance with title 18 or 
   imprisoned not more than two years, or both.
   
   (2) Whoever knowingly -
   
   (A) within the United States, [by means of telephone, makes]
   by means of telecommunications device, makes, knowingly
   transmits, or knowingly makes available (directly or by recording 
   device) any indecent communication for commercial purposes which is 
   available to any person under 18 years of age or to any other person 
   without that person's consent, regardless of whether the maker of
   such communication [placed the call] placed the call or
   initiated the communication; or
   
   (B) permits any [telephone] telecommunications facility under such 
   person's control to be used for an activity prohibited by subparagraph 
   (A), shall be fined not more than [$50,000] $100,000 or imprisoned not 
   more than [six months] 2 years, or both.
   
   (3) It is a defense to prosecution under paragraph (2) of this
   subsection that the defendant restrict access to the prohibited
   communication to persons 18 years of age or older in accordance
   with subsection (c) of this section and with such procedures as the
   Commission may prescribe by regulation.
   
   (4) In addition to the penalties under paragraph (1), whoever,
   within the United States, intentionally violates paragraph (1) or
   
   (2) shall be subject to a fine of not more than [$50,000]
   $100,000 for each violation. For purposes of this paragraph, each
   day of violation shall constitute a separate violation.
   
   (5)(A) In addition to the penalties under paragraphs (1), (2),
   and (5), whoever, within the United States, violates paragraph (1)
   or (2) shall be subject to a civil fine of not more than [$50,000]
   $100,000 for each violation. For purposes of this paragraph, each
   day of violation shall constitute a separate violation.
   
   (B) A fine under this paragraph may be assessed either -
   
   (i) by a court, pursuant to civil action by the Commission or
   any attorney employed by the Commission who is designated by the
   Commission for such purposes, or
   
   (ii) by the Commission after appropriate administrative
   proceedings.
   
   (6) The Attorney General may bring a suit in the appropriate
   district court of the United States to enjoin any act or practice
   which violates paragraph (1) or (2). An injunction may be granted
   in accordance with the Federal Rules of Civil Procedure.
   
   (c) Restriction on access to subscribers by common carriers;
   judicial remedies respecting restrictions
   
   (1) A common carrier within the District of Columbia or within
   any State, or in interstate or foreign commerce, shall not, to the
   extent technically feasible, provide access to a communication
   specified in subsection (b) of this section from the [telephone]
   telecommunications device of any subscriber who has not previously 
   requested in writing the carrier to provide access to such 
   communication if the carrier collects from subscribers an identifiable 
   charge for such communication that the carrier remits, in whole or in 
   part, to the provider of such communication.
   
   (2) Except as provided in paragraph (3), no cause of action may
   be brought in any court or administrative agency against any common
   carrier, or any of its affiliates, including their officers,
   directors, employees, agents, or authorized representatives on
   account of -
   
   (A) any action which the carrier demonstrates was taken in good
   faith to restrict access pursuant to paragraph (1) of this
   subsection; or
   
   (B) any access permitted -
   
   (i) in good faith reliance upon the lack of any
   representation by a provider of communications that
   communications provided by that provider are communications
   specified in subsection (b) of this section, or
   
   (ii) because a specific representation by the provider did
   not allow the carrier, acting in good faith, a sufficient
   period to restrict access to restrict access to communications
   described in subsection (b) of this section.
   
   (3) Notwithstanding paragraph (2) of this subsection, a provider
   of communications services to which subscribers are denied access
   pursuant to paragraph (1) of this subsection may bring an action
   for a declaratory judgment or similar action in a court. Any such
   action shall be limited to the question of whether the
   communications which the provider seeks to provide fall within the
   category of communications to which the carrier will provide access
   only to subscribers who have previously requested such access.






From dubois at csn.org  Tue Feb  7 15:00:31 1995
From: dubois at csn.org (Philip L. Dubois)
Date: Tue, 7 Feb 95 15:00:31 PST
Subject: Zimmermann
Message-ID: <199502072300.AA20868@teal.csn.org>


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

Many of you know that members of Philip Zimmermanns
defense team traveled recently to San Jose to meet with
the Assistant U.S. Attorney (AUSA) assigned to the
Zimmermann investigation.  This was done for the purpose of
persuading the AUSA not to indict.  In the hope of avoiding
speculation and misinformation, I write now to report that the
meeting was cordial, that the AUSA listened carefully and
agreed to consider our arguments, and that we dont know when
a decision will be made.

The defense effort continues and remains in need of
financial support.  Before the trip to San Jose, one
generous person donated a plane ticket from his own
frequent-flyer miles.  This contribution was timely and
much appreciated and shows a way for people to
contribute without digging into their pocketbooks.
More travel will be necessary during the next month or
two, and if there is an indictment, a great deal of
travel will be necessary.  Any new contributions,
including plane tickets, will be received with gratitude.

It may seem odd, given the nature of the case, that the
defense effort does not have its own Web page, ftp
site, or other electronically-accessible source of
information.  Keep in mind that youre dealing with a
lawyer who tends not to do things without considerable
deliberation.  The investigation has only been going on
for two years.  Im working on it.

Government investigators may seek to interview people.
It would be helpful to us to hear from such people.
The government is not required to, and will not, tell
us what its up to.  Our only source of information is
people whove been questioned.  There is nothing wrong
with such folks telling us about their interviews, and
it helps us a great deal.  I therefore ask that anyone who has
been approached and/or interviewed by any federal investigator
about Mr. Zimmermann contact me.  My email is dubois at csn.org,
my phone is 303-444-3885, and my mail address is 2305
Broadway, Boulder, CO, 80304-4132.

Ill close by offering thanks.  Mr. Zimmermann and I
very much appreciate the warm reception we were
accorded by the Cypherpunks while we were in
California.  And we are deeply grateful for all your
generous contributions of financial and other support.
Your appreciation of the importance of Mr. Zimmermanns
case to the wider causes of privacy and individual
liberty is encouraging.

Philip L. Dubois
Lawyer for Philip Zimmermann

-----BEGIN PGP SIGNATURE-----
Version: 2.7

iQCVAwUBLze+ebZ7C+AHeDONAQGJbgP9EMCSSQa0nEx2Tyb15IRei4JT3snpui1p
nwrfmeXHLMawsXeUqCbsrZPgo6CJMHryiy/2dAMc+jc4KwUSuNudWZ9wbPGWALUg
PNKlfpGi/3i7Fa+sE/RcR32PQ3vXixk6vYNHMV/mx/ZpjV4pLb31UgHhnjgDuKjv
73t8Klg8D6I=
=lQdU
-----END PGP SIGNATURE-----


From jackr at dblues.engr.sgi.com  Tue Feb  7 15:26:47 1995
From: jackr at dblues.engr.sgi.com (Jack Repenning)
Date: Tue, 7 Feb 95 15:26:47 PST
Subject: Zimmermann
In-Reply-To: <199502072300.AA20868@teal.csn.org>
Message-ID: <27154.792199642@dblues.engr.sgi.com>


Has anyone yet discovered the secret reformatting necessary to
make Phil Dubois' signature check on that message?  The usual
trick of pulling all the paragraphs up onto one line wasn't
enough.





From strick at techwood.org  Tue Feb  7 15:54:09 1995
From: strick at techwood.org (strick at techwood.org)
Date: Tue, 7 Feb 95 15:54:09 PST
Subject: noiz-0.5: simple noise-emitting package
Message-ID: <199502072350.PAA17765@gwarn.versant.com>


NAME

        noiz -- a simple package for accumulating and dispensing
                cryptographically-strong noise, using MD5 as
                a stirring function

	See "noiz.doc" for more information.

I'm interested in someone pointing out serious errors in my
algorithm or the implementation.  See particularly the ALGORITHM 
section at the end of "noiz.doc".

I believe this will meet Tim May's standards for practical entropy,
but probably not Matt Blaze's high standards.

It allows users to decide how much true entropy they require, and lets
them share entropy with each other if they want.  Crunching with MD5
obscures where the randomness came from.  The "noizout" command
produces 128 high-entropy bits in a split second, and can be repeated
for more, although it is theoretically better to add entropy to the pool
every time you take some out.  But I personally use a crontab that adds
a few bits every minute, and rely on the crunching to hide correlations.

			strick

p.s.  	I will be in chicago this weekend,
	so I'll mess the MVCPPM :(

----------------

MAKE A DIRECTORY NAMED "noiz-0.5" and unshar it there.

This works on SunOS and probably on almost any unix platform
with minor tweaks to the Makefile.


#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  README Makefile md5.c md5.h mkshar noiz.doc noiz.h
#   noizinit.c noizout.c noizspin.c noizstir.c patchlevel version
# Wrapped by strick at gwarn on Tue Feb  7 15:38:49 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'README' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'README'\"
else
echo shar: Extracting \"'README'\" \(694 characters\)
sed "s/^X//" >'README' <<'END_OF_FILE'
XNAME
X
X	noiz -- a simple package for accumulating and dispensing
X		cryptographically-strong noise, using MD5 as 
X		a stirring function
X
XANTICOPYRIGHT
X
X	Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X	This package is placed this package in the public domain.
X
X	Because this package is free, there is no warranty 
X	for it whatsoever.  Caveat hacker.
X
X	This is alpha-quality software.  It seemed to work for
X	me, but it may not do what I say it does.
X
X	The MD5 implementation is by Colin Plumb (1993), 
X	and is also in the public domain.
X
X
XSee "noiz.doc" for more information.
X
X
XEND $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/README,v 1.1 95/02/07 14:55:59 strick Exp Locker: strick $
END_OF_FILE
if test 694 -ne `wc -c <'README'`; then
    echo shar: \"'README'\" unpacked with wrong size!
fi
# end of 'README'
fi
if test -f 'Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(1904 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
X#####  noiz/Makefile
X#
X#       Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X#
X#       This package is placed this package in the public domain.
X#
X#       Because this package is free, there is no warranty
X#       for it whatsoever.  Caveat hacker.
X#
X#
X#       This file Makefile is dedicated to the ascii	TAB	character.
X#
X
XBIN=/usr/local/bin
XNOIZ=/etc/noiz
X
XOWNER=root
XGROUP=kmem
X
XCC= gcc
XCFLAGS= -O -D'NOIZ_FILE="$(NOIZ)"'
X
X
Xall : noizinit noizstir noizout noizspin
X
Xnoizstir : noizstir.o md5.o 
X	$(CC) -o noizstir $(CFLAGS) noizstir.o md5.o
X
Xnoizout : noizout.o md5.o 
X	$(CC) -o noizout $(CFLAGS) noizout.o md5.o
X
Xclean:
X	rm -f *.o
X	rm -f noizinit noizstir noizout noizspin
X	rm -f a.out core
X
Xinstall: all
X	test -d $(BIN) || mkdir $(BIN)
X	strip noizinit noizout noizstir noizspin
X	install -o $(OWNER) -g $(GROUP) -m  550 noizinit $(BIN)
X	install -o $(OWNER) -g $(GROUP) -m 2555 noizstir $(BIN)
X	install -o $(OWNER) -g $(GROUP) -m 2555 noizout $(BIN)
X	install -o $(OWNER) -g $(GROUP) -m  555 noizspin $(BIN)
X	$(BIN)/noizinit
X	chown $(OWNER) $(NOIZ)
X	chgrp $(GROUP) $(NOIZ)
X	chmod 660 $(NOIZ)
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	ls -li / /var/adm/ | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	netstat -s | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	$(BIN)/noizspin | $(BIN)/noizstir
X	:
X	:
X	: Suggestion for your crontab:
X	:   "* * * * * $(BIN)/noizspin | $(BIN)/noizstir"
X	:
X
X# END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/Makefile,v 1.6 95/02/07 15:35:36 strick Exp Locker: strick $
END_OF_FILE
if test 1904 -ne `wc -c <'Makefile'`; then
    echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'md5.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'md5.c'\"
else
echo shar: Extracting \"'md5.c'\" \(7656 characters\)
sed "s/^X//" >'md5.c' <<'END_OF_FILE'
X/*
X * This code implements the MD5 message-digest algorithm.
X * The algorithm is due to Ron Rivest.  This code was
X * written by Colin Plumb in 1993, no copyright is claimed.
X * This code is in the public domain; do with it what you wish.
X *
X * Equivalent code is available from RSA Data Security, Inc.
X * This code has been tested against that, and is equivalent,
X * except that you don't need to include two pages of legalese
X * with every copy.
X *
X * To compute the message digest of a chunk of bytes, declare an
X * MD5Context structure, pass it to MD5Init, call MD5Update as
X * needed on buffers full of bytes, and then call MD5Final, which
X * will fill a supplied 16-byte array with the digest.
X */
X#include <string.h>	/* for memcpy() */
X#include "md5.h"
X
X#ifndef HIGHFIRST
X#define byteReverse(buf, len)	/* Nothing */
X#else
Xvoid byteReverse(unsigned char *buf, unsigned longs);
X
X#ifndef ASM_MD5
X/*
X * Note: this code is harmless on little-endian machines.
X */
Xvoid byteReverse(unsigned char *buf, unsigned longs)
X{
X	uint32 t;
X	do {
X		t = (uint32)((unsigned)buf[3]<<8 | buf[2]) << 16 |
X		            ((unsigned)buf[1]<<8 | buf[0]);
X		*(uint32 *)buf = t;
X		buf += 4;
X	} while (--longs);
X}
X#endif
X#endif
X
X/*
X * Start MD5 accumulation.  Set bit count to 0 and buffer to mysterious
X * initialization constants.
X */
Xvoid
XMD5Init(struct MD5Context *ctx)
X{
X	ctx->buf[0] = 0x67452301;
X	ctx->buf[1] = 0xefcdab89;
X	ctx->buf[2] = 0x98badcfe;
X	ctx->buf[3] = 0x10325476;
X
X	ctx->bits[0] = 0;
X	ctx->bits[1] = 0;
X}
X
X/*
X * Update context to reflect the concatenation of another buffer full
X * of bytes.
X */
Xvoid
XMD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
X{
X	uint32 t;
X
X	/* Update bitcount */
X
X	t = ctx->bits[0];
X	if ((ctx->bits[0] = t + ((uint32)len << 3)) < t)
X		ctx->bits[1]++;	/* Carry from low to high */
X	ctx->bits[1] += len >> 29;
X
X	t = (t >> 3) & 0x3f;	/* Bytes already in shsInfo->data */
X
X	/* Handle any leading odd-sized chunks */
X
X	if ( t ) {
X		unsigned char *p = (unsigned char *)ctx->in + t;
X
X		t = 64-t;
X		if (len < t) {
X			memcpy(p, buf, len);
X			return;
X		}
X		memcpy(p, buf, t);
X		byteReverse(ctx->in, 16);
X		MD5Transform(ctx->buf, (uint32 *)ctx->in);
X		buf += t;
X		len -= t;
X	}
X
X	/* Process data in 64-byte chunks */
X
X	while (len >= 64) {
X		memcpy(ctx->in, buf, 64);
X		byteReverse(ctx->in, 16);
X		MD5Transform(ctx->buf, (uint32 *)ctx->in);
X		buf += 64;
X		len -= 64;
X	}
X
X	/* Handle any remaining bytes of data. */
X
X	memcpy(ctx->in, buf, len);
X}
X
X/*
X * Final wrapup - pad to 64-byte boundary with the bit pattern 
X * 1 0* (64-bit count of bits processed, MSB-first)
X */
Xvoid
XMD5Final(unsigned char digest[16], struct MD5Context *ctx)
X{
X	unsigned count;
X	unsigned char *p;
X
X	/* Compute number of bytes mod 64 */
X	count = (ctx->bits[0] >> 3) & 0x3F;
X
X	/* Set the first char of padding to 0x80.  This is safe since there is
X	   always at least one byte free */
X	p = ctx->in + count;
X	*p++ = 0x80;
X
X	/* Bytes of padding needed to make 64 bytes */
X	count = 64 - 1 - count;
X
X	/* Pad out to 56 mod 64 */
X	if (count < 8) {
X		/* Two lots of padding:  Pad the first block to 64 bytes */
X		memset(p, 0, count);
X		byteReverse(ctx->in, 16);
X		MD5Transform(ctx->buf, (uint32 *)ctx->in);
X
X		/* Now fill the next block with 56 bytes */
X		memset(ctx->in, 0, 56);
X	} else {
X		/* Pad block to 56 bytes */
X		memset(p, 0, count-8);
X	}
X	byteReverse(ctx->in, 14);
X
X	/* Append length in bits and transform */
X	((uint32 *)ctx->in)[ 14 ] = ctx->bits[0];
X	((uint32 *)ctx->in)[ 15 ] = ctx->bits[1];
X
X	MD5Transform(ctx->buf, (uint32 *)ctx->in);
X	byteReverse((unsigned char *)ctx->buf, 4);
X	memcpy(digest, ctx->buf, 16);
X	memset(ctx, 0, sizeof(ctx));	/* In case it's sensitive */
X}
X
X#ifndef ASM_MD5
X
X/* The four core functions - F1 is optimized somewhat */
X
X/* #define F1(x, y, z) (x & y | ~x & z) */
X#define F1(x, y, z) (z ^ (x & (y ^ z)))
X#define F2(x, y, z) F1(z, x, y)
X#define F3(x, y, z) (x ^ y ^ z)
X#define F4(x, y, z) (y ^ (x | ~z))
X
X/* This is the central step in the MD5 algorithm. */
X#define MD5STEP(f, w, x, y, z, data, s) \
X	( w += f(x, y, z) + data,  w = w<<s | w>>(32-s),  w += x )
X
X/*
X * The core of the MD5 algorithm, this alters an existing MD5 hash to
X * reflect the addition of 16 longwords of new data.  MD5Update blocks
X * the data and converts bytes into longwords for this routine.
X */
Xvoid
XMD5Transform(uint32 buf[4], uint32 const in[16])
X{
X	register uint32 a, b, c, d;
X
X	a = buf[0];
X	b = buf[1];
X	c = buf[2];
X	d = buf[3];
X
X	MD5STEP(F1, a, b, c, d, in[ 0]+0xd76aa478,  7);
X	MD5STEP(F1, d, a, b, c, in[ 1]+0xe8c7b756, 12);
X	MD5STEP(F1, c, d, a, b, in[ 2]+0x242070db, 17);
X	MD5STEP(F1, b, c, d, a, in[ 3]+0xc1bdceee, 22);
X	MD5STEP(F1, a, b, c, d, in[ 4]+0xf57c0faf,  7);
X	MD5STEP(F1, d, a, b, c, in[ 5]+0x4787c62a, 12);
X	MD5STEP(F1, c, d, a, b, in[ 6]+0xa8304613, 17);
X	MD5STEP(F1, b, c, d, a, in[ 7]+0xfd469501, 22);
X	MD5STEP(F1, a, b, c, d, in[ 8]+0x698098d8,  7);
X	MD5STEP(F1, d, a, b, c, in[ 9]+0x8b44f7af, 12);
X	MD5STEP(F1, c, d, a, b, in[10]+0xffff5bb1, 17);
X	MD5STEP(F1, b, c, d, a, in[11]+0x895cd7be, 22);
X	MD5STEP(F1, a, b, c, d, in[12]+0x6b901122,  7);
X	MD5STEP(F1, d, a, b, c, in[13]+0xfd987193, 12);
X	MD5STEP(F1, c, d, a, b, in[14]+0xa679438e, 17);
X	MD5STEP(F1, b, c, d, a, in[15]+0x49b40821, 22);
X
X	MD5STEP(F2, a, b, c, d, in[ 1]+0xf61e2562,  5);
X	MD5STEP(F2, d, a, b, c, in[ 6]+0xc040b340,  9);
X	MD5STEP(F2, c, d, a, b, in[11]+0x265e5a51, 14);
X	MD5STEP(F2, b, c, d, a, in[ 0]+0xe9b6c7aa, 20);
X	MD5STEP(F2, a, b, c, d, in[ 5]+0xd62f105d,  5);
X	MD5STEP(F2, d, a, b, c, in[10]+0x02441453,  9);
X	MD5STEP(F2, c, d, a, b, in[15]+0xd8a1e681, 14);
X	MD5STEP(F2, b, c, d, a, in[ 4]+0xe7d3fbc8, 20);
X	MD5STEP(F2, a, b, c, d, in[ 9]+0x21e1cde6,  5);
X	MD5STEP(F2, d, a, b, c, in[14]+0xc33707d6,  9);
X	MD5STEP(F2, c, d, a, b, in[ 3]+0xf4d50d87, 14);
X	MD5STEP(F2, b, c, d, a, in[ 8]+0x455a14ed, 20);
X	MD5STEP(F2, a, b, c, d, in[13]+0xa9e3e905,  5);
X	MD5STEP(F2, d, a, b, c, in[ 2]+0xfcefa3f8,  9);
X	MD5STEP(F2, c, d, a, b, in[ 7]+0x676f02d9, 14);
X	MD5STEP(F2, b, c, d, a, in[12]+0x8d2a4c8a, 20);
X
X	MD5STEP(F3, a, b, c, d, in[ 5]+0xfffa3942,  4);
X	MD5STEP(F3, d, a, b, c, in[ 8]+0x8771f681, 11);
X	MD5STEP(F3, c, d, a, b, in[11]+0x6d9d6122, 16);
X	MD5STEP(F3, b, c, d, a, in[14]+0xfde5380c, 23);
X	MD5STEP(F3, a, b, c, d, in[ 1]+0xa4beea44,  4);
X	MD5STEP(F3, d, a, b, c, in[ 4]+0x4bdecfa9, 11);
X	MD5STEP(F3, c, d, a, b, in[ 7]+0xf6bb4b60, 16);
X	MD5STEP(F3, b, c, d, a, in[10]+0xbebfbc70, 23);
X	MD5STEP(F3, a, b, c, d, in[13]+0x289b7ec6,  4);
X	MD5STEP(F3, d, a, b, c, in[ 0]+0xeaa127fa, 11);
X	MD5STEP(F3, c, d, a, b, in[ 3]+0xd4ef3085, 16);
X	MD5STEP(F3, b, c, d, a, in[ 6]+0x04881d05, 23);
X	MD5STEP(F3, a, b, c, d, in[ 9]+0xd9d4d039,  4);
X	MD5STEP(F3, d, a, b, c, in[12]+0xe6db99e5, 11);
X	MD5STEP(F3, c, d, a, b, in[15]+0x1fa27cf8, 16);
X	MD5STEP(F3, b, c, d, a, in[ 2]+0xc4ac5665, 23);
X
X	MD5STEP(F4, a, b, c, d, in[ 0]+0xf4292244,  6);
X	MD5STEP(F4, d, a, b, c, in[ 7]+0x432aff97, 10);
X	MD5STEP(F4, c, d, a, b, in[14]+0xab9423a7, 15);
X	MD5STEP(F4, b, c, d, a, in[ 5]+0xfc93a039, 21);
X	MD5STEP(F4, a, b, c, d, in[12]+0x655b59c3,  6);
X	MD5STEP(F4, d, a, b, c, in[ 3]+0x8f0ccc92, 10);
X	MD5STEP(F4, c, d, a, b, in[10]+0xffeff47d, 15);
X	MD5STEP(F4, b, c, d, a, in[ 1]+0x85845dd1, 21);
X	MD5STEP(F4, a, b, c, d, in[ 8]+0x6fa87e4f,  6);
X	MD5STEP(F4, d, a, b, c, in[15]+0xfe2ce6e0, 10);
X	MD5STEP(F4, c, d, a, b, in[ 6]+0xa3014314, 15);
X	MD5STEP(F4, b, c, d, a, in[13]+0x4e0811a1, 21);
X	MD5STEP(F4, a, b, c, d, in[ 4]+0xf7537e82,  6);
X	MD5STEP(F4, d, a, b, c, in[11]+0xbd3af235, 10);
X	MD5STEP(F4, c, d, a, b, in[ 2]+0x2ad7d2bb, 15);
X	MD5STEP(F4, b, c, d, a, in[ 9]+0xeb86d391, 21);
X
X	buf[0] += a;
X	buf[1] += b;
X	buf[2] += c;
X	buf[3] += d;
X}
X#endif
END_OF_FILE
if test 7656 -ne `wc -c <'md5.c'`; then
    echo shar: \"'md5.c'\" unpacked with wrong size!
fi
# end of 'md5.c'
fi
if test -f 'md5.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'md5.h'\"
else
echo shar: Extracting \"'md5.h'\" \(519 characters\)
sed "s/^X//" >'md5.h' <<'END_OF_FILE'
X#ifndef MD5_H
X#define MD5_H
X
Xtypedef unsigned long uint32;
X
Xstruct MD5Context {
X	uint32 buf[4];
X	uint32 bits[2];
X	unsigned char in[64];
X};
X
Xvoid MD5Init(struct MD5Context *context);
Xvoid MD5Update(struct MD5Context *context, unsigned char const *buf, unsigned len);
Xvoid MD5Final(unsigned char digest[16], struct MD5Context *context);
Xvoid MD5Transform(uint32 buf[4], uint32 const in[16]);
X
X/*
X * This is needed to make RSAREF happy on some MS-DOS compilers.
X */
Xtypedef struct MD5Context MD5_CTX;
X
X#endif /* !MD5_H */
END_OF_FILE
if test 519 -ne `wc -c <'md5.h'`; then
    echo shar: \"'md5.h'\" unpacked with wrong size!
fi
# end of 'md5.h'
fi
if test -f 'mkshar' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'mkshar'\"
else
echo shar: Extracting \"'mkshar'\" \(76 characters\)
sed "s/^X//" >'mkshar' <<'END_OF_FILE'
X#!/bin/sh
Xset -x
Xmake clean
Xrm -f .shar
Xshar README Makefile [a-z]* > .shar
END_OF_FILE
if test 76 -ne `wc -c <'mkshar'`; then
    echo shar: \"'mkshar'\" unpacked with wrong size!
fi
# end of 'mkshar'
fi
if test -f 'noiz.doc' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noiz.doc'\"
else
echo shar: Extracting \"'noiz.doc'\" \(9532 characters\)
sed "s/^X//" >'noiz.doc' <<'END_OF_FILE'
XNAME
X
X	noiz -- a simple package for accumulating and dispensing
X		cryptographically-strong noise, using MD5 as 
X		a stirring function
X
XANTICOPYRIGHT
X
X	Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X	This package is placed this package in the public domain.
X
X	Because this package is free, there is no warranty 
X	for it whatsoever.  Caveat hacker.
X
X	This is alpha-quality software.  It seemed to work for
X	me, but it may not do what I say it does.
X
X	The MD5 implementation is by Colin Plumb (1993), 
X	and is also in the public domain.
X
X
XSYNOPSIS
X
X	noizinit
X
X		creates the file /etc/noiz
X
X
X	noizstir < noise-source
X
X		stirs the noise-source into /etc/noiz
X
X
X	noizout < noise-source > output-noise
X
X		produces 16 bytes of noise, for applications to use
X
X
X	noizspin > output-time
X
X		prints a somewhat-random number, with several bits of
X		entropy.
X
X
XFILES
X
X	/etc/noiz       a binary file containing 256 bytes of noise
X			state.   That's 2048 bits of entropy, assuming
X			it has been stirred with that much entropy.
X
X
X
XDESCRIPTION
X
X	noizinit        creates /etc/noiz and initializes it with bytes
X			0, 1, 2, 3, ... 255.
X
X			It must be stirred several times with noizstir
X			before it is ready to be used by noizout.
X
X
X	noizspin        Set an alarm for 1 second.  Using an unsigned
X			long, count until the alarm is received, and
X			print the count, in ascii, as a decimal number,
X			followed by a newline.
X
X
X	noizstir        changes the noise ("stirs" it) in /etc/noiz,
X			based on prior contents of /etc/noiz, current
X			time, pid, ppid, and input bytes read from
X			standard input.
X
X			The standard input may be empty (as in
X
X				noizstir < /dev/null
X
X			) or may be some system-generated noise (as in
X
X				ps uaxg | noizstir
X				ls -li /tmp/ | noizstir
X				netstat -s | noizstir
X
X			) or you may use the "noizspin" command which
X			was designed especially for this purpose:
X
X				noizspin | noizstir
X
X	noizout         Produces 16 bytes of random noise, based on the
X			contents of /etc/noiz, current time, pid, ppid,
X			and input bytes read from standard input.   The
X			output is 16 raw binary bytes; if you want some
X			kind of ascii encoding, you must convert the
X			output.  Piping the output into "od -x" is
X			useful for debugging.
X
X			Unlike noizstir, noizout does not change
X			/etc/noiz.  You may use it without empty
X			standard input, but it is better to feed it
X			some extra noise.  The noizspin command is good
X			for this:
X
X				noizspin | noizout 
X
X			The bytes emitted from noizout do not reveal
X			the contents of /etc/noiz.  In fact, no command
X			does, so all users can share /etc/noiz.
X
X			Because noizout always stirs current time, pid,
X			and ppid into its output, even this command,
X			repeated many times without running noizstir,
X			will generate fairly high-entropy random
X			output:
X
X				noizout < /dev/null
X				
X
X
XDIAGNOSTICS
X
X	All four programs print one line to stderr and exit with a
X	nonzero status if they cannot read or write /etc/noiz and they
X	need to.
X
X	Otherwise the programs execute without writing to stdout, and
X	they exit with status zero.
X
X
X
XRECOMMENDED INSTALLATION
X
X	You should probably be root to do the "make install".  You may
X	use "make BIN=/etc install" to put the four binaries into the
X	/etc/ directory instead of /usr/local/bin/.
X
X	/etc/noiz	owner root 
X			group kmem
X			mode 660     (not publically readable or writable)
X
X	/usr/local/bin/noizinit
X			owner root
X			group kmem
X			mode 550	(no special permissions)
X					(only execute at install time)
X
X	/usr/local/bin/noizstir
X			owner root
X			group kmem
X			mode 2555	(setgid kmem)
X					(anyone can execute)
X
X	/usr/local/bin/noizout
X			owner root
X			group kmem
X			mode 2555	(setgid kmem)
X					(anyone can execute)
X
X	/usr/local/bin/noizspin
X			owner root
X			group kmem
X			mode 555	(no special permissions)
X					(anyone can execute)
X
X
X	For your crontab:
X
X		* * * * * /usr/local/bin/noizspin | /usr/local/bin/noizstir
X
X		This will stir the /etc/noiz with a few bits of noise
X		per minute.
X
X		You may put it in the crontab for root, or for daemon,
X		or users themselves may do it.
X
X
XEXAMPLE SESSION
X
X		gwarn#
Xinitialize	gwarn#
X/etc/noiz	gwarn#
X		gwarn#
X		gwarn# /usr/local/bin/noizinit
Xshow initial	gwarn#
Xcontents 	gwarn#
X		gwarn# od -x /etc/noiz
X		0000000  0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
X		0000020  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
X		0000040  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
X		0000060  3031 3233 3435 3637 3839 3a3b 3c3d 3e3f
X		0000100  4041 4243 4445 4647 4849 4a4b 4c4d 4e4f
X		0000120  5051 5253 5455 5657 5859 5a5b 5c5d 5e5f
X		0000140  6061 6263 6465 6667 6869 6a6b 6c6d 6e6f
X		0000160  7071 7273 7475 7677 7879 7a7b 7c7d 7e7f
X		0000200  8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
X		0000220  9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
X		0000240  a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
X		0000260  b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf
X		0000300  c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf
X		0000320  d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf
X		0000340  e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef
X		0000360  f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd feff
X		0000400
X		gwarn#
Xspin some 	gwarn#
Xrandom numbers	gwarn#
Xwith noizspin	gwarn#
X		gwarn# noizspin
X		3082293
X		gwarn# noizspin
X		3025490
X		gwarn# noizspin
X		3077496
X		gwarn# noizspin
X		2985100
X		gwarn# noizspin
X		3047690
X		gwarn# noizspin
X		3082529
X		gwarn# noizspin
X		3063415
X/etc/noiz	gwarn#
Xis unchanged	gwarn#
Xuntil stirred	gwarn#
X		gwarn# od -x /etc/noiz
X		0000000  0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
X		0000020  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
X		0000040  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
X		0000060  3031 3233 3435 3637 3839 3a3b 3c3d 3e3f
X		0000100  4041 4243 4445 4647 4849 4a4b 4c4d 4e4f
X		0000120  5051 5253 5455 5657 5859 5a5b 5c5d 5e5f
X		0000140  6061 6263 6465 6667 6869 6a6b 6c6d 6e6f
X		0000160  7071 7273 7475 7677 7879 7a7b 7c7d 7e7f
X		0000200  8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
X		0000220  9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
X		0000240  a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
X		0000260  b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf
X		0000300  c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf
X		0000320  d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf
X		0000340  e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef
X		0000360  f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd feff
X		0000400
X		gwarn#
Xso stir it,	gwarn#
Xwith some	gwarn#
Xrandom input	gwarn#
X		gwarn# noizspin | noizstir
X		gwarn# od -x /etc/noiz
X		0000000  b695 3c73 7a0c 73e0 b37b 55f5 e6cf 2dec
X		0000020  1fa7 1544 890e a039 6a21 e2ec 4669 35ea
X		0000040  a9d8 1175 0dd9 9742 fd6a 1501 9039 1d73
X		0000060  2b0e 0864 93e8 63bf 4a63 3398 b63c ef77
X		0000100  2534 cd7e 0e79 fb56 5f53 bcc5 5b68 968d
X		0000120  910e bbf4 e222 03b2 13d8 908c e508 74a8
X		0000140  d056 fb99 ea7f dddb 9b2f c654 4cd0 1384
X		0000160  8899 3507 1dbb c367 43f1 9806 17e0 8780
X		0000200  95f7 af5a 7a78 92e0 126c 4f2d 3721 a5ee
X		0000220  4a12 f7c3 3186 febb 3ea8 f048 4fd1 41b8
X		0000240  812f 1d43 66a7 8e2d 7ca4 cddb 39c6 6b5f
X		0000260  9a8c 646b c511 304b eb9b b235 46da 5d2e
X		0000300  ec53 5816 c742 e92d 2468 8579 302d d932
X		0000320  2f45 03fb 4f2c ff10 b84d 15a5 8e46 8e84
X		0000340  ff12 0d68 26a3 10c2 87b5 4ebc 3b59 afa2
X		0000360  2bb2 bb64 371e 2f99 b108 c7d5 42eb 68c9
X		gwarn#
X		gwarn#
Xnow emit some 	gwarn#
X16-byte		gwarn#
Xhigh-entropy	gwarn#
Xoutput and 	gwarn#
Xdisplay it	gwarn#
Xwith od -x	gwarn#
X		gwarn# noizspin | noizout | od -x
X		0000000  be7b 81f9 744c 2dca e36d a6c6 9394 7bf2
X		0000020
X		gwarn# noizspin | noizout | od -x
X		0000000  1cea b243 2b0e 55c3 7630 886c 3be3 d03f
X		0000020
X		gwarn# noizspin | noizout | od -x
X		0000000  6887 864d b4fc 40e6 7eb1 0d9e 6b47 f148
X		0000020
X		gwarn#
Xdemonstrate	gwarn#
Xhigh-entropy	gwarn#
Xoutput even	gwarn#
Xwithout noise	gwarn#
Xinput and 	gwarn#
Xwithout 	gwarn#
Xstirring	gwarn#
X		gwarn#
X		gwarn# noizout < /dev/null | od -x
X		0000000  e54f 67a6 52ec 3d61 ddfd 1208 5f52 fead
X		0000020
X		gwarn# noizout < /dev/null | od -x
X		0000000  6472 5f9e fe81 fcab bca8 6d22 2400 0d0a
X		0000020
X		gwarn# noizout < /dev/null | od -x
X		0000000  2df4 9d73 ddc2 5aa4 10c6 59b8 e31c efda
X		0000020
X		gwarn# noizout < /dev/null | od -x
X		0000000  7f64 6671 957e b4aa ae4b 8fd8 7e90 601e
X		0000020
X		gwarn# noizout < /dev/null | od -x
X		0000000  2d8e 522c 700a 5367 d67f dae3 0977 0689
X		0000020
X
X
X
XALGORITHMS
X
X   Let the syntax X[i..j] represent a subrange of an array X.
X   Let the syntax X[] represent the entire array X.
X
X   Let the array Noiz[0..15][0..15] represent the 256 bytes of /etc/noiz
X   Let the array Noiz[r] represent the rth row (16 bytes) of Noiz
X
X   Let the array Input[] represent bytes read from standard input
X
X   Let the syntax  MD5( x, y, z... )  represent the MD5 hash of the 
X   concatenation of the arguments x, y, z...
X
X
X
X   Algorithm of "noizstir":
X
X	read Noiz[][] from /etc/noiz
X
X	read Input[] from standard input
X
X	In_hash[0..15] := MD5(  Noiz[][], 
X				Input[],
X				time, 
X				pid,
X				ppid,
X				and some extra stuff from sloppy buffering
X			     );
X
X	FOR r := 0 TO 15
X
X	    Out_hash[0..15] := MD5(	Noiz[r],
X					In_hash[0..15],
X					In_hash[0..r]
X	    		   	  );
X
X	    Noiz[r] := Noiz[r] BITWISE_XOR Out_hash[];
X
X	NEXT r
X
X	write Noiz[][] to /etc/noiz
X
X
X
X   Algorithm of "noizout"
X
X	read Noiz[][] from /etc/noiz
X
X	read Input[] from standard input
X
X	Out_hash[0..15] := MD5(  Noiz[][], 
X				 Input[],
X				 time, 
X				 pid,
X				 ppid,
X				 and some extra stuff from sloppy buffering
X			      );
X
X  	write Out_hash[] to standard output 
X
X
X
X
XEND $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noiz.doc,v 1.6 95/02/07 15:35:37 strick Exp Locker: strick $
END_OF_FILE
if test 9532 -ne `wc -c <'noiz.doc'`; then
    echo shar: \"'noiz.doc'\" unpacked with wrong size!
fi
# end of 'noiz.doc'
fi
if test -f 'noiz.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noiz.h'\"
else
echo shar: Extracting \"'noiz.h'\" \(395 characters\)
sed "s/^X//" >'noiz.h' <<'END_OF_FILE'
X/* 	noiz.h
X
X	Anticopyright (A) 1995 Henry Strickland <strick at yak.net> 
X
X        This package is placed this package in the public domain.
X
X        Because this package is free, there is no warranty
X        for it whatsoever.  Caveat hacker.
X*/
X
X
X
X
X#define	NOIZ_FILE	"/etc/noiz"
X
X
X/* END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noiz.h,v 1.2 95/02/07 14:19:52 strick Exp Locker: strick $ */
END_OF_FILE
if test 395 -ne `wc -c <'noiz.h'`; then
    echo shar: \"'noiz.h'\" unpacked with wrong size!
fi
# end of 'noiz.h'
fi
if test -f 'noizinit.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noizinit.c'\"
else
echo shar: Extracting \"'noizinit.c'\" \(767 characters\)
sed "s/^X//" >'noizinit.c' <<'END_OF_FILE'
X/*      noizinit.c
X
X        Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X
X        This package is placed this package in the public domain.
X
X        Because this package is free, there is no warranty
X        for it whatsoever.  Caveat hacker.
X*/
X
X
X/*
X	This file noizinit.c is dedicated to Richard Stallman,
X	who taught me the joy of free software.
X*/
X
X
X#include <stdio.h>
X#include "noiz.h"
X
Xmain()
X{
X	int e;
X	int i;
X
X	FILE* f= fopen( NOIZ_FILE, "w" );
X	if (!f) goto bad;
X
X	for ( i=0; i<256; i++ ) {
X		e= putc(i,f);
X		if (e==EOF) goto bad;
X	}
X
X	e= fclose(f);
X	if ( e!=0 ) goto bad;
X
X	return 0;
X
Xbad:
X	perror( NOIZ_FILE );
X	exit(255);
X}
X
X/* END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noizinit.c,v 1.3 95/02/07 15:28:59 strick Exp Locker: strick $ */
END_OF_FILE
if test 767 -ne `wc -c <'noizinit.c'`; then
    echo shar: \"'noizinit.c'\" unpacked with wrong size!
fi
# end of 'noizinit.c'
fi
if test -f 'noizout.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noizout.c'\"
else
echo shar: Extracting \"'noizout.c'\" \(1559 characters\)
sed "s/^X//" >'noizout.c' <<'END_OF_FILE'
X/*      noizstir.c   -- stir the noise file with stdin
X
X        Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X
X        This package is placed this package in the public domain.
X
X        Because this package is free, there is no warranty
X        for it whatsoever.  Caveat hacker.
X*/
X
X
X/* 
X	This file noizout.c is dedicated in memory of John Cage,
X	who explained to me the point of his pointless noise. 
X*/
X
X
X
X#include <stdio.h>
X#include "noiz.h"
X#include "md5.h"
X
Xchar noiz[256];
Xchar pad[256];
X
Xunsigned char out_hash[16];
X
Xstruct MD5Context context;
X
Xmain()
X{
X	int e;
X	int i;
X	long seconds;
X	long pid;
X	long ppid;
X	int row;
X
X	FILE* f= fopen( NOIZ_FILE, "r" );
X	if (!f) goto bad;
X
X	for ( i=0; i<256; i++ ) {
X		e= getc(f);
X		if (e==EOF) goto bad;
X		noiz[i]= e;
X	}
X
X	MD5Init( &context );
X	MD5Update(&context, (unsigned char*) &noiz, 256);
X	while ( fread(pad, 1, 256, stdin) > 0 ) {
X		MD5Update(&context, (unsigned char*) &pad, 256);
X	}
X	time( &seconds );
X	pid= getpid();
X	ppid= getppid();
X	MD5Update( &context, (unsigned char*) &seconds, sizeof seconds );
X	MD5Update( &context, (unsigned char*) &pid, sizeof pid );
X	MD5Update( &context, (unsigned char*) &ppid, sizeof ppid );
X	MD5Final( out_hash, &context );
X
X	for ( i=0; i<16; i++ ) {
X		e= putchar(out_hash[i]);
X		if (e==EOF) goto bad;
X	}
X
X	e= fflush(stdout);
X	if (e==EOF) goto bad;
X	e= fclose(stdout);
X	if (e==EOF) goto bad;
X
X	return 0;
Xbad:
X	perror( NOIZ_FILE );
X	exit(255);
X}
X
X/* END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noizout.c,v 1.3 95/02/07 15:29:00 strick Exp Locker: strick $ */
END_OF_FILE
if test 1559 -ne `wc -c <'noizout.c'`; then
    echo shar: \"'noizout.c'\" unpacked with wrong size!
fi
# end of 'noizout.c'
fi
if test -f 'noizspin.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noizspin.c'\"
else
echo shar: Extracting \"'noizspin.c'\" \(729 characters\)
sed "s/^X//" >'noizspin.c' <<'END_OF_FILE'
X/*      noizspin.c
X
X        Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X
X        This package is placed this package in the public domain.
X
X        Because this package is free, there is no warranty
X        for it whatsoever.  Caveat hacker.
X*/
X
X/*
X	This file noizspin.c is dedicated to Matt Blaze,
X	because I learned the trick from his code.
X*/
X
X
X#include <stdio.h>
X#include <sys/types.h>
X#include <signal.h>
X
Xunsigned long x;
X
Xenough()
X{
X	printf("%lu\n", x );
X	fflush(stdout);
X	exit(0);
X}
X
Xmain()
X{
X	signal( SIGALRM, enough );
X	alarm(1);
X
X	while (1) {
X		++x;
X	}
X
X	/*NOTREACHED*/
X	return 255;
X}
X
X/* END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noizspin.c,v 1.1 95/02/07 15:35:39 strick Exp Locker: strick $ */
END_OF_FILE
if test 729 -ne `wc -c <'noizspin.c'`; then
    echo shar: \"'noizspin.c'\" unpacked with wrong size!
fi
# end of 'noizspin.c'
fi
if test -f 'noizstir.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'noizstir.c'\"
else
echo shar: Extracting \"'noizstir.c'\" \(1841 characters\)
sed "s/^X//" >'noizstir.c' <<'END_OF_FILE'
X/*      noizstir.c   -- stir the noise file with stdin
X
X        Anticopyright (A) 1995 Henry Strickland <strick at yak.net>
X
X        This package is placed this package in the public domain.
X
X        Because this package is free, there is no warranty
X        for it whatsoever.  Caveat hacker.
X*/
X
X
X/*
X	This file noizstir.c is dedicated to Jacques Atali,
X	in honor of his book "Noise, The Political Economy
X	of Music."
X*/
X
X
X#include <stdio.h>
X#include "noiz.h"
X#include "md5.h"
X
Xchar noiz[256];
Xchar pad[256];
X
Xunsigned char in_hash[16];
Xunsigned char out_hash[16];
X
Xstruct MD5Context context;
X
Xmain()
X{
X	int e;
X	int i;
X	long seconds;
X	long pid;
X	long ppid;
X	int row;
X
X	FILE* f= fopen( NOIZ_FILE, "r+" );
X	if (!f) goto bad;
X
X	for ( i=0; i<256; i++ ) {
X		e= getc(f);
X		if (e==EOF) goto bad;
X		noiz[i]= e;
X	}
X
X	MD5Init( &context );
X	MD5Update(&context, (unsigned char*) &noiz, 256);
X	while ( fread(pad, 1, 256, stdin) > 0 ) {
X		MD5Update(&context, (unsigned char*) &pad, 256);
X	}
X	time( &seconds );
X	pid= getpid();
X	ppid= getppid();
X	MD5Update( &context, (unsigned char*) &seconds, sizeof seconds );
X	MD5Update( &context, (unsigned char*) &pid, sizeof pid );
X	MD5Update( &context, (unsigned char*) &ppid, sizeof ppid );
X	MD5Final( in_hash, &context );
X
X	for (row=0; row<16; row++ ) {
X		MD5Init( &context );
X		MD5Update( &context, noiz+16*row, 16 );
X		MD5Update( &context, in_hash, 16 );
X		MD5Update( &context, in_hash, row+1 );
X		MD5Final( out_hash, &context );
X		for ( i=0; i<16; i++ ) {
X			noiz[16*row+i] ^= out_hash[i];
X		}
X	}
X
X	fflush(f);
X	rewind(f);
X	
X	for ( i=0; i<256; i++ ) {
X		e= putc(noiz[i],f);
X		if (e==EOF) goto bad;
X	}
X
X	e= fclose(f);
X	if (e==EOF) goto bad;
X
X	return 0;
X
Xbad:
X	perror( NOIZ_FILE );
X	exit(255);
X}
X
X/* END $Header: /mvp/fjord/strick/yaxen/noiz-0.5/RCS/noizstir.c,v 1.3 95/02/07 15:29:01 strick Exp Locker: strick $ */
END_OF_FILE
if test 1841 -ne `wc -c <'noizstir.c'`; then
    echo shar: \"'noizstir.c'\" unpacked with wrong size!
fi
# end of 'noizstir.c'
fi
if test -f 'patchlevel' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'patchlevel'\"
else
echo shar: Extracting \"'patchlevel'\" \(2 characters\)
sed "s/^X//" >'patchlevel' <<'END_OF_FILE'
X0
END_OF_FILE
if test 2 -ne `wc -c <'patchlevel'`; then
    echo shar: \"'patchlevel'\" unpacked with wrong size!
fi
# end of 'patchlevel'
fi
if test -f 'version' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'version'\"
else
echo shar: Extracting \"'version'\" \(9 characters\)
sed "s/^X//" >'version' <<'END_OF_FILE'
Xnoiz-0.5
END_OF_FILE
if test 9 -ne `wc -c <'version'`; then
    echo shar: \"'version'\" unpacked with wrong size!
fi
# end of 'version'
fi
echo shar: End of shell archive.
exit 0





From Dave_Banisar.OFFICE at epic.org  Tue Feb  7 15:55:42 1995
From: Dave_Banisar.OFFICE at epic.org (Dave_Banisar.OFFICE at epic.org)
Date: Tue, 7 Feb 95 15:55:42 PST
Subject: EPIC Alert 2.02
Message-ID: <n1419939228.95186@epic.org>


    =============================================================
      
       @@@@  @@@@  @@@  @@@@      @    @     @@@@  @@@@  @@@@@
       @     @  @   @   @        @ @   @     @     @  @    @
       @@@@  @@@    @   @       @@@@@  @     @@@   @@@     @
       @     @      @   @       @   @  @     @     @  @    @
       @@@@  @     @@@  @@@@    @   @  @@@@  @@@@  @   @   @

   ==============================================================
   Volume 2.02                                   February 6, 1995
   --------------------------------------------------------------
  
                        Published by the
           Electronic Privacy Information Center (EPIC)
                         Washington, DC
                          info at epic.org

=======================================================================
Table of Contents
=======================================================================

 [1] IRS Backs Off Compliance 2000 Program
 [2] New Secrecy Order Needs Work
 [3] Caller ID Blocking Fails in New York
 [4] Post Office Partially Limits Access to Addresses
 [5] Clinton Announces National ID Registry
 [6] Correction: EU Directive Still Under Consideration
 [7] Overview of New Congressional Privacy Legislation
 [8] Upcoming Conferences and Events

=======================================================================
[1] IRS Backing Off of Compliance 2000 Program
=======================================================================

The Internal Revenue Service announced on Friday, January 20, that it
was delaying implemention of the controversial Compliance 2000 program
after heated opposition to the proposal from the Electronic Privacy
Information Center (EPIC) and other privacy advocates appeared in over
two dozen newspapers across the country.  The proposal also drew sharp
criticism from Senator David Prior.  The plan called for IRS
collection and use of personal information from commercial databases.
This data would not be subject to the requirements of the Privacy Act.

IRS officials told the EPIC Alert that the Compliance 2000 notice
published in the Federal Register was going to be revised in the next
few weeks and then reissued.  IRS Privacy Advocate Robert Veeder said
that the notice had been drafted more than a year ago and that the
program had been revised substantially since then.

EPIC has filed a Freedom of Information Act request with the IRS,
asking for more information about the types of data that would be
collected if Compliance 200 goes forward, the sources of the
information and the proposed uses.


=======================================================================
[2] Draft Secrecy Order Still Needs Work
=======================================================================

The White House recently circulated the latest draft of the
President's long-awaited revised Executive Order on the classification
of national security information.  The current version back-pedals on
favorable proposed reforms of the classification system, retreating
from an earlier proposal that prohibited secrecy when the "public
interest in keeping the information unclassified outweighs the need
for classification."  Such a standard would permit the public and the
news media to challenge classification decisions in court.  The draft
also fails to go far enough in opening the government's civilian
cryptographic activities to public scrutiny.

Efforts to revise the current Executive Order (issued by President
Reagan in 1982) began almost two years ago, soon after the Clinton
Administration assumed office.  Several drafts have circulated since
then, and the issuance of a final revision was anticipated more than a
year ago.  The Center for National Security Studies, the Federation of
American Scientists, the National Security Archive, and EPIC have all
urged the relaxation of classification authority.

EPIC has specifically recommended that classification be removed for
cryptographic information.  In comments submitted to the Information
Security Oversight Office in July 1993, EPIC staff urged removal of
"cryptology" from the categories of information presumed to be
classifiable.  The statement said that the "designation of a routine
privacy-enhancing technology as presumptively a national security
matter is inconsistent with the end of the Cold War and the dramatic
growth of commercial and civilian telecommunications networks.  ...
[Cryptographic] technology today plays an essential role in assuring
the security and privacy of a wide range of communications affecting
finance, education, research, and personal correspondence."

The recent Clinton proposal does indeed narrow the government's
classification authority for "cryptology", although the final order
should go further.  Under the original Reagan Order, "cryptology" was
singled out as a separate and independent category. The recent draft
drops cryptology as an independent category and instead refers
generally to "intelligence activities (including special operations),
intelligence sources or methods, or cryptology."

This formulation suggests a recognition that information concerning
encryption technology should only be classified if it relates to
intelligence uses of the technology, as opposed to the increasing use
of encryption in civilian applications.  The language, however, leaves
open the possibility that the government might still attempt to
classify information relating to cryptography.  This position  does
not comport with the overwhelming opinion outside of government that
cryptography  should never be presumptively classified.

The classification of cryptographic information has already hampered
the public's ability to monitor the government's activities in the
area of civilian communications security.  Information relating to the
Digital Signature Standard (intended for the authentication of
unclassified electronic transmissions) has been withheld from
disclosure under the Reagan Executive Order.  Likewise, key
information concerning the Clipper encryption initiative (including
the underlying Skipjack algorithm) has been classified and placed
beyond public review.

Congress sought to prevent such secrecy when it enacted the Computer
Security Act of 1987, which limited the civilian role of the National
Security Agency (NSA).  Congress noted that NSA's "natural tendency to
restrict and even deny access to information that it deems important
would disqualify that agency from being put in charge of the
protection of non-national security information."  The Clinton
Administration, through further revision of its draft Executive Order,
has an opportunity to build upon the openness and accountability that
Congress envisioned.


=======================================================================
[3] Caller ID Blocking Fails in New York
=======================================================================

NYNEX has admitted that the personal phone numbers of at least 30,000
of its customers who requested per-line blocking of Caller ID have
been improperly disclosed.  The problem resulted from a failure to
correctly implement the blocking feature. The New York Times reports
that NYNEX had known of the problem for at least a year before any
action was taken.

The Rhode Island Public Utilities Commission has ordered NYNEX not to
allow customers in that state to order new Caller ID services or per
line blocking until the problem is resolved.  NYNEX must also run ads
telling customers about the problem and provide an 800 number for
consumers to call.

EPIC has received several calls from individuals in New York who have
had their phone numbers disclosed.  The individuals work in sensitive
jobs and have already received threatening phone calls as a result of
the disclosures.


=======================================================================
[4] Post Office Partially Limits Access to Addresses
=======================================================================

The U.S. Postal Service announced on December 28 its final rule on
access to names and addresses.  The agency announced it was
eliminating the service that allows anyone to obtain the new address
of any individual for a $3.00 fee.  The Postal Service, however, left
intact its service that provides the addresses of all postal customers
to large mailers such as direct marketers.

The notice states "Congress has not given the Postal Service the
function of serving as a national registration point for the physical
whereabouts of individuals."

HR 434, The Postal Privacy Act of 1995, (introduced by Rep. Gary
Condit) requires that the Postal Service inform individuals of the
uses of information contained in Change of Address cards and mandates
that customers be offered an option to not have their names and
addresses forwarded.


=======================================================================
[5] Clinton Announces National ID Worker Registry
=======================================================================

In the annual State of the Union address on January 25, President
Clinton announced his support for the creation of a national registry
of all citizens and resident aliens to enforce immigration laws.  The
idea was recommended the U.S. Commission on Immigration Reform, headed
by former Rep. Barbara Jordan.

The proposal would create a national database of all employees based
on Social Security Numbers that every employer would be required to
check before hiring.  Civil liberties groups believe that this
database, once in place, would then be used for other purposes, such
as law enforcement, and would eventually lead to the development of a
national ID card.  The Commission has previously considered requiring
the creation of an ID card but backed off in the face of public
opposition.

Senator Alan Simpson (R-WY) has introduced a bill (S. 269) to
implement the registry.  Sen. Barbara Boxer (D-CA) told USA Today that
Congress was planning to address the issue and that the system is the
only way to provide accurate citizenship information and protect
privacy.


=======================================================================
[6] Overview of New Congressional Privacy Legislation Available
=======================================================================

EPIC has produced an overview of current privacy legislation in the
104th Congress.  Bills that improve privacy protections or negatively
affect privacy are summarized.  The summary will be updated regularly
as new legislation is introduced or pending bills are revised. A
summary will appear in the next issue of the EPIC Alert.

Copies of the new bills are available for retrieval from the EPIC
Archive at cpsr.org.  Also included are floor statements on the
legislation when available and updates on the status of the bills.

To obtain the overview and copies of the house and Senate bills,
ftp/gopher/wais to cpsr.org /cpsr/privacy/epic/104th_congress_bills/


=======================================================================
[7] Upcoming Privacy Related Conferences and Events
=======================================================================

AAAS Annual Meeting & Science Innovation Expo.  Atlanta. Feb 16-21. A
special full-day session on cryptography and privacy will take place
on Tuesday, Feb. 21. Contact: Alex Fowler 202/326-7016 or
afowler at aaas.org

Cryptography: Technology, Law and Economics. New York City. Mar. 3,
1995. Sponsored by CITI, Columbia University. Contact:
citi at research.gsb.columbia.edu

Towards an Electronic Patient Record '95. Orlando, FL. Mar. 14-19,
1995. Sponsored by Medical Records Institute. Contact: 617-964-3926
(fax).

Access, Privacy, and Commercialism:  When States Gather Personal
Information. College of William and Mary, Williamsburg, VA, March 17.
Contact:  Trotter Hardy  804 221-3826.

Computers, Freedom and Privacy '95. Palo Alto, Ca. Mar. 28-31, 1995.
Sponsored by ACM. Contact: cfp95 at forsythe.stanford.edu.

ETHICOMP95:  An international conference on the ethical issues of
using Information Technology. DeMontfort University, Leicester,
ENGLAND, March 28-30, 1995.  Contact: Simon Rogerson srog at dmu.ac.uk 44
533 577475 (phone)  44 533 541891 (Fax).

"Quality of Life in the Electronic Village," March 30, 1995. Live
teleconference, broadcast nationally from Virginia Tech, featuring
eminent presenters from the fields of ethics, law, education,
anthropology, medicine, and government.  Contact 703/231-6476 or
choices at vt.edu.

National Net '95: Reaching Everyone. Washington, DC.  Apr. 5-7, 1995.
Sponsored by EDUCOM.  Contact: net95 at educom.edu or call 202/872-4200.

Information Security and Privacy in the Public Sector. Herndon, VA.
Apr. 19-20, 1995. Sponsored by AIC Conferences.  Contact:
212/952-1899.

1995 IEEE Symposium on Security and Privacy. Oakland, CA, May 8-10.
Contact:  sp95 at itd.nrl.navy.mil.

INET '95. Honolulu, HI. June 28-30, 1995. Sponsored by the Internet
Society. Contact inet95 at isoc.org.

Key Players in the Introduction of Information Technology: Their
Social Responsibility and Professional Training. July 5-6-7, 1995.
Namur, Belgium. Sponsored by CREIS. Contact: nolod at ccr.jussieu.fr.

Advanced Surveillance Technologies. Sept. 4-5, 1995. Copenhagen,
Denmark. Sponsored by Privacy International and EPIC. Contact
pi at epic.org.

          (Send calendar submissions to Alert at epic.org)
  
=======================================================================

The EPIC Alert is a free biweekly publication of the Electronic
Privacy Information Center. To subscribe, send the message:

SUBSCRIBE CPSR-ANNOUNCE Firstname Lastname

to listserv at cpsr.org. You may also receive the Alert by reading the
USENET newsgroup comp.org.cpsr.announce.

Back issues are available via FTP/WAIS/Gopher/HTTP from cpsr.org
/cpsr/alert and on Compuserve (Go NCSA), Library 2 (EPIC/Ethics). An
HTML version of the current issue is available from
epic.digicash.com/epic

=======================================================================

The Electronic Privacy Information Center is a public interest
research center in Washington, DC.  It was established in 1994 to
focus public attention on emerging privacy issues relating to the
National Information Infrastructure, such as the Clipper Chip, the
Digital Telephony proposal, medical record privacy, and the sale of
consumer data.  EPIC is sponsored by the Fund for Constitutional
Government and Computer Professionals for Social Responsibility.  EPIC
publishes the EPIC Alert and EPIC Reports, pursues Freedom of
Information Act litigation, and conducts policy research on emerging
privacy issues.  For more information, email info at epic.org, WWW at
HTTP://epic.digicash.com /epic or write EPIC, 666 Pennsylvania Ave.,
SE, Suite 301, Washington, DC 20003. (202) 544-9240 (tel), (202)
547-5482 (fax).

The Fund for Constitutional Government is a non-profit organization
established in 1974 to protect civil liberties and constitutional
rights.  Computer Professionals for Social Responsibility is a
national membership organization of people concerned about the impact
of technology on society.  For information contact: cpsr-info at cpsr.org

If you'd like to support the work of the Electronic Privacy
Information Center, contributions are welcome and fully
tax-deductible.  Checks should be made out to "The Fund for
Constitutional Government" and sent to EPIC, 666 Pennsylvania Ave.,
SE, Suite 301, Washington DC 20003.

Your contributions will help support Freedom of Information Act
litigation, strong and effective advocacy for the right of privacy and
efforts to oppose Clipper and Digital Telephony wiretapping proposals.

------------------------ END EPIC Alert 2.02 ------------------------







_________________________________________________________________________
Subject: EPIC Alert 2.02
_________________________________________________________________________
David Banisar (Banisar at epic.org)       * 202-544-9240 (tel)
Electronic Privacy Information Center * 202-547-5482 (fax)
666 Pennsylvania Ave, SE, Suite 301  * ftp/gopher/wais cpsr.org 
Washington, DC 20003                * HTTP://epic.digicash.com/epic





From mjwohler at netcom.com  Tue Feb  7 16:16:53 1995
From: mjwohler at netcom.com (Marc Wohler)
Date: Tue, 7 Feb 95 16:16:53 PST
Subject: NYC CPUNKS MEET
Message-ID: <199502080013.QAA13710@netcom8.netcom.com>


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

Attn.: New York City area Cypherpunks

NYC C'punks meeting:

Sat Feb 11, 3:00 P.M., at the home of Linn & Barbara  Stanton
315 West 106 Street  Apt 2A 
(Between West End Ave & Riverside Drive)
212-316-1958.

Once again the gracious Stanton's invite local area Cpunks to
their lovely home which is smoke free and feline friendly.

The agenda is still open and suggestions can be made to
mjwohler at netcom.com
or phone Marc Wohler @ 212-362-0690. Let me know if you plan to
attend.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLy+PL2eikzgqLB7pAQGHigP9HW1Py30O2fcZH/f1SAOToOBZYVZMiB9c
buGQrujaicGVJlvGb1Le/OjJ872JB69BQD1MMsemABSYi4swL15w9qj1rhoTAHIg
yTRDFJD16g1lqqLvEJZ0RijOh1dXLaUg8HNue0JoSAbARkQed8I3+mklP4C4saYn
qW2Fa/kDuZY=
=Rl9C
-----END PGP SIGNATURE-----

-- 
                                              Marc J. Wohler   
                                             mjwohler at netcom.com
***Preserve, Protect and Defend the private use of Strong Crypto***
                 * * * PGP for the masses * * * 





From skaplin at mirage.skypoint.com  Tue Feb  7 16:18:29 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 16:18:29 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <3a0ElKjqRqtP078yn@mirage.skypoint.com>


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

I just had an interesting conversation with a person who works for an ISP.
Basically their response if S.314 becomes law will be to preprocess all
incoming mail. If it is uuencoded or encrypted, into the bit bucket it will
go. They are still thinking about what to do with telnet and ftp.

This is starting to get very scary.

Sam

- --
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
                 Be careful when playing under the anvil tree.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLzgMJ8lnXxBRSgfNAQG3Egf9HewkJYboCW6RNABZiQd8K8JVyw3As0S7
Gwno4Flp3L1y/izbCSgVnrNY+oK7vwB5J0OPq4y1TX7gIb/NPasVKkcW9eET1a5X
HJwjbfg7ZbUle5dcktuD1GLC1bZu5Mt39lV8eQKjqHiXYSxc3sWJT3xvtKQ45Pr+
FWsYNALI6Q9R7sBy0Zh0vg61fZHfnlSNi7SxEvE0GZ3e959L0y+AR44UE2HrI1KQ
zfDgFtWiQsDztbVsbReYb4cwCs34Vxv/7v7GjY29SVZIKbeR1aEarR2TJbuT/jry
dP+l4QIxOFv26OIGf5cHgPiWswf1KjosUkDso0Ps8fKf3Wafm5CH2g==
=0WR8
-----END PGP SIGNATURE-----






From samman at CS.YALE.EDU  Tue Feb  7 16:40:39 1995
From: samman at CS.YALE.EDU (Ben)
Date: Tue, 7 Feb 95 16:40:39 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <3a0ElKjqRqtP078yn@mirage.skypoint.com>
Message-ID: <Pine.SUN.3.91.950207193831.7816I-100000@jaguar.zoo.cs.yale.edu>


On Tue, 7 Feb 1995, Samuel Kaplin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> I just had an interesting conversation with a person who works for an ISP.
> Basically their response if S.314 becomes law will be to preprocess all
> incoming mail. If it is uuencoded or encrypted, into the bit bucket it will
> go. They are still thinking about what to do with telnet and ftp.

Just use netnews for mail then.  We can divide up netnews into different 
regions pgp.us.ca.north  pgp.us.ca.south etc. and then just post pgp'd 
messages to the net.  Kinda like blacknet.  Ok so there's a high cost 
involved in it, granted.

Also writing a bot to search through net news daily for anything signed 
with your PGP key isn't too difficult.

> This is starting to get very scary.

Indeed citizen-unit.  Wait over in the corner for processing.

Ben.





From chen at intuit.com  Tue Feb  7 16:58:57 1995
From: chen at intuit.com (Mark Chen)
Date: Tue, 7 Feb 95 16:58:57 PST
Subject: Seals and Sealing Waxes
In-Reply-To: <ab5d0f8b040210047448@DialupEudora>
Message-ID: <9502080056.AA14295@doom.intuit.com>



> "All crypto is economics," and this is what made seals and sealing wax so
> useful for so long. Saying "seals were duplicatable from the start" does
> not mean this feat was easy, even if technically possible.
> 
> In fact, the fine details produced by a good seal are hard to exactly
> emulate with a copy. Even on a two-dimensional surface. And with the advent
> of three-dimensional surfaces, which sealing wax made possible, the fine
> detail of a good seal was in fact very hard to forge.
> 
> Not impossible, but very costly with the technology of the day. Or even the
> technology of _today_. After all, paper currency is largely based on seal
> technology, with various embossing, printing, etc. methods used (on special
> paper) that remain fairly hard to duplicate.

The House Banking, Finance and Urban Affairs Committee last year held
hearings on the redesign of the U.S. currency.  Some of the testimony
about physical document security was pretty interesting (for those
with the requisite proclivities).  I only have a hardcopy, though if
enough people are interested, I might be persuaded to scan some of it
in.


--
Mark Chen 
chen at intuit.com
415/329-6913
finger for PGP public key
D4 99 54 2A 98 B1 48 0C  CF 95 A5 B0 6E E0 1E 1D




From jcorgan at aeinet.com  Tue Feb  7 17:17:10 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Tue, 7 Feb 95 17:17:10 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <Chameleon.4.01.950207171644.jcorgan@comet.aeinet.com>


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

>I just had an interesting conversation with a person who works for an ISP.
>Basically their response if S.314 becomes law will be to preprocess all
>incoming mail. If it is uuencoded or encrypted, into the bit bucket it will
>go. They are still thinking about what to do with telnet and ftp.

Sounds like a good application for text stego...

>This is starting to get very scary.

Indeed.

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov
WWW:                     ftp://ftp.netcom.com/pub/jc/jcorgan/home.html


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzgbVU1Diok8GKihAQEfJgQAiDd5ha7WCURlwepHgV8qjBYjoT1MxLsF
219ymsRNe/U0bJwSTgt/sBqNjZIS3aQjEQIu+VE3CivvNcVYz0wuZ5KYVf5IADpF
4qtba3bZwENJNjOm9Y/w2m2mWAkEK0I77IPPFdCts0xg6sWWMOVOv4ry2eOQ59uQ
WvTIH1omb58=
=srzZ
-----END PGP SIGNATURE-----







From weidai at eskimo.com  Tue Feb  7 17:32:30 1995
From: weidai at eskimo.com (Wei Dai)
Date: Tue, 7 Feb 95 17:32:30 PST
Subject: a new way to do anonymity
Message-ID: <199502080132.AA26151@mail.eskimo.com>


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

A week ago I made a suggestion for a new protocol for untracibility, 
but only got one response.  I'll try again, this time more 
forcefully.  I'm not trying to convince anyone to implement this 
(though of course you're welcome to!), but just to think about it and 
give me feedback.

Why is another protocol needed?  Right now we have only two, 
each of which has its own set of tradeoffs.  To summarize:

	Mix-Net (i.e., remailer-net): high latency, moderate bandwidth 
		costs, and low complexity
	DC-Net: moderate latency, high bandwidth costs, and high complexity

While the DC-Net will probably never be widely used, the remailer-net 
has a fair chance of one day 
providing a way for many people to send e-mail that not even governments 
can trace.  However, I don't think this is enough.  Efficient 
social and business relationships require that people be able to 
converse to each other in real time.  Cryptoanarchy will not come about 
if people cannot do this anonymously.  How well can two pseudonymous 
agents negotiate a contract if each message they send must be delayed 
several hours?  The protocol I sugguested would have low latency, moderate 
bandwidth costs, and moderate complexity.  It would be well suited for 
people to interact anonymously in a textual environment.

This is what I wrote:
> Imagine a server that allows you to open a 
> low bandwidth (let's say around 100 cps, in order to reduce costs)
> link-encrypted telnet session with it, and provides you with a number 
> of services, for example a link-encrypted talk session with another 
> user.  You'll need to maintain the link 24 hours a day to defend 
> against statistical analysis, and of course you can chain a number of 
> these servers together in a way similiar to chaining remailers.

Lance pointed out the chain cannot be built quickly.  This is not a problem
if servers connect to each other with relatively wide link-encrypted pipes
and multiplex your connection into these pipes.

In this system, latency would never be more than a few seconds, bandwidth
cost is N*100 cps (point to point), N being the number of links in your chain.
Implementation would probably be harder than remailers, but much easier
than DC-Nets.  The protocol would also provide both sender and receiver
untracibility without any need for broadcasting.

Wei Dai

P.S. I never gave a name for the protocol... let's call it Pipe-net.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzgewDl0sXKgdnV5AQGzvAQAgFaOxOzFPgS031z4jZRYUJp/+3BS5Con
Kza7WsvZPvxzaNLh9ecD3aCx5dtf4muaiUKjC2HIItaLKEdZZPdzUGFd4wg1cY8G
k8mvYNzDImr3ZtQ0HiqQ59PWhznad0GuhjQajB7RtpI+K/Z4uBaUEZGVoZZT+LHN
MSjOl/k/yfg=
=jgq6
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From jim at acm.org  Tue Feb  7 17:33:51 1995
From: jim at acm.org (Jim Gillogly)
Date: Tue, 7 Feb 95 17:33:51 PST
Subject: Zimmermann
In-Reply-To: <27154.792199642@dblues.engr.sgi.com>
Message-ID: <199502080133.RAA19105@mycroft.rand.org>



> Jack Repenning <jackr at dblues.engr.sgi.com> writes:
> Has anyone yet discovered the secret reformatting necessary to
> make Phil Dubois' signature check on that message?  The usual

Got it!

	tr ""\022" "\306" < thismessage | pgp26

Some bogus word processor, I'd imagine.

	Jim Gillogly
	Highday, 18 Solmath S.R. 1995, 01:33





From mab at research.att.com  Tue Feb  7 17:48:48 1995
From: mab at research.att.com (Matt Blaze)
Date: Tue, 7 Feb 95 17:48:48 PST
Subject: noiz-0.5: simple noise-emitting package
Message-ID: <9502080149.AA20768@merckx.info.att.com>


This looks really cute, especially given the ability to "precompute"
entropy before the process that needs it is running.

An interface I'd rather see is one that allows a process to grab
random bits that it can be sure are not correlated to bits that
have been given to other processes.  Since everything runs asynchronously
with cron, you have no way of knowing how much time has elapsed since
the last time the file was read or updated, and hence don't know
how "fresh" the bits are.  Also, /etc/noiz is an attractive target
on multi-user machines....

So I'd rather see a /dev/noise, although a portable implementation
of somthing like that is out of the question now that there are
10 gazillion unix vendors.  Perhaps a more reasonable implementation
would be a tcp or rpc service that processes can query to get random bits,
where the server delays responding until it can guarantee that its
state is sufficiently decorrelated from previous responses.  Because you can
"bank up" entropy during idle periods, most requests could probably
be served without delay, making this technique a real advantage over
just implementing the same functions in a library called directly.
(Since good randomness is still rather expensive even when you can store it
up, and useless when sent over a network, you'd probably want the noise
server to refuse requests from outside the local machine.)

Anyway, I'm looking forward to playing with it.  It's a very nice idea.

-matt





From habs at panix.com  Tue Feb  7 18:47:04 1995
From: habs at panix.com (Harry S. Hawk)
Date: Tue, 7 Feb 95 18:47:04 PST
Subject: forward; e-cash
Message-ID: <199502080246.AA02904@panix.com>


NETCHEQUE WANTS TO BE YOUR CYBERBANKER The long-anticipated digital
commerce boom hinges on one important factor -- the ability to safely
and securely conduct monetary transactions in cyberspace. A team of
scientists at the University of Southern California are working on a
system called NetCheque that would allow banks and their customers
send an electronic check over the Internet, complete with a digital
signature that cannot be forged. "With NetCheque, if your balances are
positive it's like a checking account. If they're negative, it's like
a credit-card account... It really depends very much on how you want
to set up this very flexible mechanism," says the USC team leader. The
system was recently released for testing, and those interested in
participation should send mail to netcheque at isi.edu. (Chronicle of
Higher Education 2/10/95 A18)

-- 
Harry S. Hawk  		   habs at panix.com
Product Marketing Manager
PowerMail, Inc. 	   Producers of MailWeir(tm) & PowerServ(tm)




From rarachel at photon.poly.edu  Tue Feb  7 19:24:07 1995
From: rarachel at photon.poly.edu (Arsen Ray Arachelian)
Date: Tue, 7 Feb 95 19:24:07 PST
Subject: !NYC Cypherpunks meeting 2/11/95!
Message-ID: <Pine.3.89.9502072204.B12080-0100000@photon.poly.edu>



Incase you're in the NYC area, there is a meeting this Saturday.  (If 
you're already on the list of NYC Cypherpunks, you'd have received the 
notice with the address.)  If you're in NYC, but not on the NYC 
Cypherpunks list, and you need info, please send email to me, 
rarachel at photon.poly.edu, and I'll give you directions.

See you there..
--Ray.

===============================================================================
| + ^ + || ' . . .   .   . .   .             Ray  (Arsen)  Arachelian        ||
|  \|/  ||   . . .  ' . ' .  : . .           rarachel at photon.poly.edu        ||
|<--+-->||.   . . |' '| .' .  .  ...    ___  sunder at intercom.com             ||
|  /|\  ||   .  . \___/ .  . . : .... __[R]                                  ||
| + v + || . oOOo /o.O\ oOOo :. : ..    |A| "And bugs to kill before I sleep"||
=========/---vvvv-------VVVV------------|I|----------------------------------/
        /      .    :   . ' : '         |D|     This signature pannel is    /
       /  The Next Bug to kill(tm)      ---     now open.                  / 
      /___________________________________________________________________/
GCS d++(---)(-) H s+++/++ !g !p !au a- w-(+) (!v | v)  C+++++ Coherent++++ 
L+ 3 C+ V+ P? E- N++ K- W W--- M++ V-- po- Y+++ t:[tos+, tng--, ds9+] 5 !j
!R G? tv+ b+++ D+ B--- e+(- | *) u--- h+++ f+(++) r++ n+(---) x**(++)







From jcorgan at aeinet.com  Tue Feb  7 19:29:22 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Tue, 7 Feb 95 19:29:22 PST
Subject: a new way to do anonymity
Message-ID: <Chameleon.4.01.950207192939.jcorgan@comet.aeinet.com>


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

>This is what I wrote:

>> Imagine a server that allows you to open a 
>> low bandwidth (let's say around 100 cps, in order to reduce costs)
>> link-encrypted telnet session with it, and provides you with a number 
>> of services, for example a link-encrypted talk session with another 
>> user.  You'll need to maintain the link 24 hours a day to defend 
>> against statistical analysis, and of course you can chain a number of 
>> these servers together in a way similiar to chaining remailers.

There are many, many analogies you can draw about a network of this type
to an ATM (asynchronous transfer mode) network.  By simplifying just slightly
from what you describe to only include an encrypted, switched-pipe methodology,
you now have a "cloud" type network with service entry points that are defined
by a pair of byte streams (one in each direction).

The switched path could be set up and torn down dynamically by the user by
interacting with the "switch" at each point to select the next hop the 
encrypted byte stream will follow.  Of course, just like in remailer chaining,
the data that indicates which hop to follow is encrypted with the data in a
form only the switch can decrypt.  Alternatively, once a path is set up between
switches, it can be assigned a virtual path identifier that has only local
significance at each hop, with the switch performing a lookup to forward
packets and substituting a new path number with significance at the next hop.

The above description is pretty unclear, I think, but many of these concepts 
have been fleshed out to a significant amount of detail in ATM circles.

Fixed length data packets (at the encrypted telnet level) also make it very
easy to aggregate individual circuits into higher bandwidth pipes that
connect server to server.  With these continuously running with cover traffic,
individual circuit establishment is much more immune from traffic analysis.
Cover traffic is substituted with real traffic as necessary, up to the bandwidth
of the pipe.

To summarize, what has been described is a method to establish a "network within
a network", using encrypted telnet, to provide a connection oriented, unreliable
packet switched link layer protocol.  Sounds remarkably similar to IP (except
for the connection oriented portion of it.)

What can you do with a network like this?  By layering a TCP process on top of 
this "Pipe-Net" IP like service, any of the standard TCP based application 
protocols can function between two end point systems, such as SMTP, FTP, HTTP,
etc.

What is so neat about this is that it could probably be done in user space,
and since the packet based protocol is defined as unreliable, switches could
come and go, with some sort of switch-to-switch protocol that propagates route
availability.

Eric, you could probably chew on the trust implications of all this.

Perry, I'm sure all the IPSP/SSL/SOCKS/whatever stuff you know so well could
provide a lot of building blocks for this type of thing.

Wei, your traffic analysis treatment of this sort of thing would go a long way
toward uncovering weaknesses and determining operational requirements and 
limitations.

Tim, what massive social effects would it have if this type of network service
were to become widely deployed? :)

At first glance, this Pipe-Net idea doesn't seem to take a lot of rocket science; 
it seems that most of the components or algorithms are are already in use, just 
in a very different way.

I can think of a number of problems already, however.  Spamming.  Bandwidth
limitations.  Complexity of client and switch software.  Standards.  Flow
control.

In other works, all the stuff the ATM forum is already dealing with :)

Come to think of it, has anyone thought of something like this before?

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov
WWW:                     ftp://ftp.netcom.com/pub/jc/jcorgan/home.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzg6ME1Diok8GKihAQEBygP/do7MnM2Ha/b3nYNeVb/7mpJqAwgke3D6
VlyhtVjxTM2tn42Voz47BtwTMiR+zkiwI5Ha3EQs/fpJGY7x69YGY+arGXAn/VsI
Xq7/onQd/LOv8JAjrxrgH2gLTCmfs57+sLJXqghHmSrxgothsK8XRLY1HDoYDfai
EgiNUmMTXEM=
=ENYC
-----END PGP SIGNATURE-----







From skaplin at mirage.skypoint.com  Tue Feb  7 19:34:36 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 19:34:36 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.SUN.3.91.950207193831.7816I-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <g53ElKjqRy8I078yn@mirage.skypoint.com>


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


On Tue, 7 Feb 1995 19:40:24 -0500 (EST), Ben <samman at CS.YALE.EDU> wrote:

> Just use netnews for mail then.  We can divide up netnews into different
> regions pgp.us.ca.north  pgp.us.ca.south etc. and then just post pgp'd
> messages to the net.  Kinda like blacknet.  Ok so there's a high cost
> involved in it, granted.

The problem is that providers will be responsible for all traffic coming in
and going out of their system. This includes usenet. I would imagine that
the same filters would be applied to news too.

I think we need to start lobbying now. I find it amazing that CPR and EFF
haven't picked this up yet.

- --
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
         "Automatic" simply means that you cannot repair it yourself.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLzg6EclnXxBRSgfNAQEV3Qf+I/Cvkl/4qmCS9InIoECaMf0zqn9ou1G+
W9zB12a15WcbVa71DuToq1CJ8P4pTCwNObDY6L1asn+o5/aMxcSHDlBBBeGFCZBe
dtbKFoOPquQ4w+VWDorqDbZhDkQf38CyK325O5L7hkzEYiw6r2RIu8s6ZyHL6mIh
+h2qlW+HCn+34Q5JM/Ogek3V65kVc605bafkTELhPtMn1j6cLlzF/ZbXK7ecgphu
IBwKsxReOb/TNwZP3FacuM+gLxOtaQlIFTRJsFA6sNWqbbk8E3J7mc6Inoibi/DZ
LFeBIFZ2VNctYMUxZgOs6eJeU0kyEh0p637wga/NOvkge+cJZp8RGw==
=Szsj
-----END PGP SIGNATURE-----






From Chris.Claborne at SanDiego.ATTGIS.COM  Tue Feb  7 20:07:44 1995
From: Chris.Claborne at SanDiego.ATTGIS.COM (Chris Claborne)
Date: Tue, 7 Feb 95 20:07:44 PST
Subject: "encrypt tcp connections" hacks
Message-ID: <9502072307.aa27535@ncrhub1.ATTGIS.COM>


>> Thats because the providers never package things up cleanly. If they
>> sent a client on a disk, a la AOL, and they set things up to
>> autoconfigure, they'd never need to speak to the clients.
>
>    You've obviously never attempted to get a Windows product working for 
>someone whose previous experience with a computer is limited to "Solitaire".
>
>    I've done work with this ISP, and I can tell you it's nearly the most 
>frustrating experience I've had in my life -- Windows has bizzare 
>conflicts with software eating other software, ports getting set up 
>wrong, and just general nastiness.  Even the slickest software needs 
>helpline time - for whatever reason.

   I hate jumping in when I may be completely off base but...

   NT and (possibly Winodws97) may solve some of this, mainly through better
controll over devices and protected memory. I recently installed some NT
services, HTTP server, and Time Service (to get time off a trusted host).
The HTTP server was installed and working in 5 minutes.  I'm a little more
advanced than the typical "Solitare junky", but I was amazed at the ease of
install and controll that some of this stuff gives you.  I would probably
spend atleast 30+ minutes trying to get them properly installed on my UNIX host.
                                     ...  __o
                                    ..   `\<,
Chris.Claborne at SanDiegoCA.ATTGIS.COM...(_)/(_).            CI$: 76340.2422
---------------------------------------------------------------------------
PGP Pub Key fingerprint =  A8 FA 55 92 23 20 72 69  52 AB 64 CC C7 D9 4F CA
Available on any Pub Key server.
PGP encrypted mail welcome.






From eric at remailer.net  Tue Feb  7 20:10:39 1995
From: eric at remailer.net (Eric Hughes)
Date: Tue, 7 Feb 95 20:10:39 PST
Subject: a new way to do anonymity
In-Reply-To: <199502080132.AA26151@mail.eskimo.com>
Message-ID: <199502080409.UAA22376@largo.remailer.net>


   From: "Wei Dai" <weidai at eskimo.com>

   P.S. I never gave a name for the protocol... let's call it Pipe-net.

I don't think we really need a separate name for it just yet.  The
idea is composed of two pretty much independent elements: packet
forwarding and virtual link encryption.  These can be implemented
separately and then combined to yield the kind of network interaction
described.

Getting the details right will be difficult, and I'd suggest that is
where the discussion might profitably turn next.

Eric





From eric at remailer.net  Tue Feb  7 20:23:52 1995
From: eric at remailer.net (Eric Hughes)
Date: Tue, 7 Feb 95 20:23:52 PST
Subject: a new way to do anonymity
In-Reply-To: <Chameleon.4.01.950207192939.jcorgan@comet.aeinet.com>
Message-ID: <199502080422.UAA22395@largo.remailer.net>


   From: Johnathan Corgan <jcorgan at aeinet.com>

   There are many, many analogies you can draw about a network of this
   type to an ATM (asynchronous transfer mode) network.  

Thank you for the analogy.  It's always good not to reinvent the wheel
when you don't need to.

   The switched path could be set up and torn down dynamically by the user by
   interacting with the "switch" at each point to select the next hop the 
   encrypted byte stream will follow.

When you set up a mapping on a packet forwarder, this is exactly the
kind of initialization that would be required.  It is also at this
point that keying would be negotiated, etc.

   Fixed length data packets (at the encrypted telnet level) also make it very
   easy to aggregate individual circuits into higher bandwidth pipes that
   connect server to server.

Now here's an important detail that needs to get done right.  Is the
forwarding for fixed length packets, variable length packets, or
streams?  Is this decision global or local?  What are the latency and
aggregatation effects?  How important are these for different classes
of data?  (telnet v. voice, e.g.)

I'd suggest just getting something running first, to get some
prototyping experience.

Eric





From huntting at glarp.com  Tue Feb  7 20:46:01 1995
From: huntting at glarp.com (Brad Huntting)
Date: Tue, 7 Feb 95 20:46:01 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <3a0ElKjqRqtP078yn@mirage.skypoint.com>
Message-ID: <199502080445.VAA00395@misc.glarp.com>



Can anyone confirm this S.314 thing?  It sounds an awful lot like
the "modem tax" and other urban legends.


brad





From skaplin at mirage.skypoint.com  Tue Feb  7 20:48:24 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 20:48:24 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080445.VAA00395@misc.glarp.com>
Message-ID: <Pine.SV4.3.91.950207224618.23122A-100000@mirage.skypoint.com>




On Tue, 7 Feb 1995, Brad Huntting wrote:

> 
> Can anyone confirm this S.314 thing?  It sounds an awful lot like
> the "modem tax" and other urban legends.
> 
> 
> brad
> 

Web over to: http://thomas.loc.gov

It's on the Senates web server. The bill is for real. I wish it was only 
a hoax.

Sam





From 0003701548 at mcimail.com  Tue Feb  7 20:59:06 1995
From: 0003701548 at mcimail.com (Alan Pugh)
Date: Tue, 7 Feb 95 20:59:06 PST
Subject: Fwd: Seals and Sealing Waxes
Message-ID: <10950208045401/0003701548PJ3EM@MCIMAIL.COM>


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

Date: Tue Feb 07, 1995  10:15 PM EST
To: cypherpunks at toad.com
Subject: Fwd: Seals and Sealing Waxes
Message-Id:                                         

TM> "All crypto is economics," and this is what made seals and sealing wax so
TM> useful for so long. Saying "seals were duplicatable from the start" does
TM> not mean this feat was easy, even if technically possible.

TM> In fact, the fine details produced by a good seal are hard to exactly
TM> emulate with a copy. Even on a two-dimensional surface. And with the
advent
TM> of three-dimensional surfaces, which sealing wax made possible, the fine
TM> detail of a good seal was in fact very hard to forge.

TM> Not impossible, but very costly with the technology of the day. Or even
the
TM> technology of _today_. After all, paper currency is largely based on seal
TM> technology, with various embossing, printing, etc. methods used (on
special
TM> paper) that remain fairly hard to duplicate.
    
true. thanks for the reminder of seals. i need to work this analogy into my
current 'lecture' on the usefullness of encryption.

_puzzle palace_ makes reference to british intellegence making use of people
trained into the use of people trained to reproduce seals. this is something 
for us to look out for from the fine folx at nsa. if there is a way to spoof
signatures (as mentioned in another thread recently), they will be perfecting
and perhaps using these methods if they feel the need is great enough.

i promote encryption using pgp with a lot of stress on the privacy and
veracity of documents in business settings. 

how strong is the hash used by pgp? do you think it will eventually be
hashed out in the courts in our favour?(pun semi-intended)
                                  
i'd like digital signatures w/verifiable timestamps be recognised in a
court of law. i don't know of any cases revolving around this issue.
if anyone out there knows of one, i'd be interested in hearing of it
so i can track it's progress.

btw: though it is a pain sometimes to weed the noise off this list due
to my (very) limited net access, it has proved to be an excellent
resource. my thanks to the regulars. 

- --if i could code worth a damn i'd be a cypherpunk

amp
<0003701548 at mcimail.com>
February 7, 1995   22:17

-----BEGIN PGP SIGNATURE-----
Version: 2.61

iQEVAwUBLzgN4CgP1O9KJoPBAQETZQf/WAY0I+fvEmevc7iwfVglqjIZ26zDnc33
p8Yjc+uQfagS0wavYLpN+OxMphpdUHHjycb98aYLDax8CUW3iDJ54tZKVnQT3pPx
9+v1gq38UbP8k7hvoGl5lIltmMJ/rMl2lZU87l2biYjmQq8n9S+mMoIOAatcmboG
6JQ4MEsNnZvsQVeaZm87qOGqfkeTbzwsBfz8LjLkgnv7TLUNn5wJgMgiC+apYC0V
bJfAHWce3UGEPlaa4JHBbCRyfrC/hk1ggrYKthxHKE+Ceep1O2k7fRkX/tCC2BZC
UaY8ZjogZKZJbfdDNmlG7fBN5EBWlj6Mj9Ti2SRYlx4q8lwSHad+gg==
=HeNj
-----END PGP SIGNATURE-----






From skaplin at mirage.skypoint.com  Tue Feb  7 21:12:51 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 21:12:51 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080445.VAA00395@misc.glarp.com>
Message-ID: <Pine.SV4.3.91.950207230934.23719A-100000@mirage.skypoint.com>




On Tue, 7 Feb 1995, Brad Huntting wrote:

> 
> Can anyone confirm this S.314 thing?  It sounds an awful lot like
> the "modem tax" and other urban legends.

Here is everything T.H.O.M.A.S. had on it. (http://thomas.loc.gov)

 S 314 IS
 104th CONGRESS
1st Session
To protect the public from the misuse of the telecommunications
network and telecommunications devices and facilities.
 IN THE SENATE OF THE UNITED STATES
February 1 (legislative day, January 30), 1995
 
          Mr. Exon (for himself and Mr. Gorton) introduced the following
bill; which was read twice and referred to the Committee on
Commerce, Science, and Transportation A BILL
 
          To protect the public from the misuse of the telecommunications
network and telecommunications devices and facilities.
       Be it enacted by the Senate and House of Representatives of the
United States of America in Congress assembled,
 SECTION 1. SHORT TITLE.
This Act may be cited as the `Communications Decency Act of 1995'.
 
          SEC. 2. OBSCENE OR HARASSING USE OF TELECOMMUNICATIONS FACILITIES
UNDER THE COMMUNICATIONS ACT OF 1934.
 (a) Offenses: Section 223 of the Communications Act of 1934 (47
 
U.S.C. 223) is amended--
 (1) in subsection (a)(1)--
 (A) by striking out `telephone' in the matter above
        subparagraph (A) and inserting `telecommunications device';
 (B) by striking out `makes any comment, request,
        suggestion, or proposal' in subparagraph (A) and inserting
        `makes, transmits, or otherwise makes available any
comment, request, suggestion, proposal, image, or other
communication';
 (C) by striking out subparagraph (B) and inserting the
    following:
      `(B) makes a telephone call or utilizes a
telecommunications device, whether or not conversation or
        communications ensues, without disclosing his identity and
        with intent to annoy, abuse, threaten, or harass any person
      at the called number or who receives the communication;' and
 (D) by striking out subparagraph (D) and inserting the
        following:     
        `(D) makes repeated telephone calls or repeatedly
        initiates communication with a telecommunications device,
during which conversation or communication ensues, solely
      to harass any person at the called number or who receives
3
        the communication; or';
22), by striking `telephone facility'
and inserting `telecommunications facility'; 
(3) in subsection (b)(1)--
A) in subparagraph (A)--
      (i) by striking `telephone' and inserting
    `telecommunications device'; and
      (ii) inserting `or initiated the communication' and
    `placed the call', and
B) in subparagraph (B), by striking `telephone facility'
and inserting `telecommunications facility'; and
(4) in subsection (b)(2)-- 
  (A) in subparagraph (A)--
      (i) by striking `by means of telephone, makes' and  
    inserting `by means of telephone or telecommunications 
    device, makes, knowingly transmits, or knowingly makes  
  available'; and
      (ii) by inserting `or initiated the communication'
  after `placed the call'; and
  (B) in subparagraph (B), by striking `telephone facility'
and inserting in lieu thereof `telecommunications facility'.
(b) Penalties: Section 223 of such Act (47 U.S.C. 223) is amended--
4
(1) by striking out `$50,000' each place it appears and
inserting `$100,000'; and
  (2) by striking `six months' each place it appears and
inserting `2 years'.
(c) Prohibition on Provision of Access: Subsection (c)(1) of such
section (47 U.S.C. 223(c)) is amended by striking `telephone' and
inserting `telecommunications device.'
(d) Conforming Amendment: The section heading for such section is
amended to read as follows:
`obscene or harassing utilization of telecommunications devices and
facilities in the district of columbia or in interstate or foreign
communications'.
SEC. 3. OBSCENE PROGRAMMING ON CABLE TELEVISION.
Section 639 of the Communications Act of 1934 (47 U.S.C. 559) is
amended by striking `$10,000' and inserting `$100,000'.
SEC. 4. BROADCASTING OBSCENE LANGUAGE ON RADIO. 
Section 1464 of title 18, United States Code, is amended by
striking out `$10,000' and inserting `$100,000'.
SEC. 5. INTERCEPTION AND DISCLOSURE OF ELECTRONIC COMMUNICATIONS.
Section 2511 of title 18, United States Code, is amended--
(1) in paragraph (1)--
        (A) by striking `wire, oral, or electronic communication'  
5
  each place it appears and inserting `wire, oral,     
    electronic, or digital communication', and
    (B) in the matter designated as `(b)', by striking `oral
    communication' in the matter above clause (i) and inserting
      `communication'; and
      (2) in paragraph (2)(a), by striking `wire or electronic   
    communication service' each place it appears (other than in the
  second sentence) and inserting `wire, electronic, or digital   
    communication service'.
SEC. 6. ADDITIONAL PROHIBITION ON BILLING FOR TOLL-FREE TELEPHONE  
 CALLS.
  Section 228(c)(6) of the Communications Act of 1934 (47 U.S.C.
228(c)(6)) is amended--
    (1) by striking `or' at the end of subparagraph (C); 
      (2) by striking the period at the end of subparagraph (D) and
    inserting a semicolon and `or'; and
    (3) by adding at the end thereof the following:
 `(E) the calling party being assessed, by virtue of being
        asked to connect or otherwise transfer to a pay-per-call 
      service, a charge for the call.'. 
SEC. 7. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS.
Part IV of title VI of the Communications Act of 1934 (47 U.S.C. 
6
551 et seq.) is amended by adding at the end the following:
`SEC. 640. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS.
`(a) Requirement: In providing video programming unsuitable for 
children to any subscriber through a cable system, a cable operator
shall fully scramble or otherwise fully block the video and audio
portion of each channel carrying such programming so that one not a
subscriber does not receive it. 
`(b) Definition: As used in this section, the term `scramble' 
means to rearrange the content of the signal of the programming so
that the programming cannot be received by persons unauthorized to
receive the programming.'.
SEC. 8. CABLE OPERATOR REFUSAL TO CARRY CERTAIN PROGRAMS. 
  (a) Public, Educational, and Governmental Channels: Section
611(e) of the Communications Act of 1934 (47 U.S.C. 531(e)) is
amended by inserting before the period the following: `, except a  
cable operator may refuse to transmit any public access program or
portion of a public access program which contains obscenity,
indecency, or nudity'.
(b) Cable Channels for Commercial Use: Section 612(c)(2) of the
Communications Act of 1934 (47 U.S.C. 532(c)(2)) is amended by
striking `an operator' and inserting `a cable operator may refuse
to transmit any leased access program or portion of a leased access
7
program which contains obscenity, indecency, or nudity.    
 
  
 
 
 
 
  
 
 





From jpp at markv.com  Tue Feb  7 21:26:30 1995
From: jpp at markv.com (jpp at markv.com)
Date: Tue, 7 Feb 95 21:26:30 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <9502072124.aa20836@hermix.markv.com>


For my congresional 'representatives'.

S.314 is not a moral bill.  Making the owner of a computer (or
computer network) responsible for what its users store (or transmit)
is like making the owners of a parking lot responsible for what is
stored in the cars parked there.  It just isn't moraly reasonable.

S.314 is un-American.  America has always been a place where speach is
freeest.  We have consistently held the expression of ideas to be one
of the very most important rights.  To hold the owner of a buliten
board responsible for the illegal messages posted to it, is to force
the buliten board owner to become a government censor in all but name
(and wages).  It effectively ends the bulliten board's use as a venue
of free speach.

S.314 is harmfull to America.  The kind of 'chilling effect' this bill
wil place on the computer (networking) industry would put american
companies at a serious disadvantage.  Could I really operate an
airline reservtion system for a large airline if I could be held
liable for illegal information transmitted using my equipment?  No.
Could I operate the masive software and hardware networks that the
phone system requires?  No.  But, I bet the company I own in Mexico,
or in Canada could.  They aren't burdened with such (artificially
created) liabilities.  Or perhaps I could get a special waiver from my
friends in Washington. Hmmm.  How much will these sorts of 'work
arounds' cost american bussiness?

S.314 is not enforceable.  There is no certain way to tell if a file
of data is an illegal one.  Stegnography and cryptography, along with
the fact that what a bit means depends on which programs are used to
interpret it, mean that even this message could be porno, terrorist
threats, or arangements for drug trafficing.  Imagin searching all the
cars in your parking lot for drugs.  Very expensive, and not very
reliable.  Tons of drugs travel past just such inspection sites each
year.  Now imagine how tough it would be if the drugs could be turned
into perfectly normal steal in the body panels of the vehicles!  That
is what stegnography and cryptography do to data.  Turn perfectly
'awfull' data into data perfectly indistinguishable from noise, and
then hide the noise as indistinguishable-from-inocent 'errors' in
other data.  Concider the spelling in this message -- convert each
word into a bit -- 1 if it is speled right, 0 if not.  Or how about
spacing, or, punctuation -- Hmmm.  Now supose we add otras idiomas,
aux eble muchos languages en cxiu mesagxon.  Will computer (network)
owners be responsible for the spelling, punctuation, language, word
choice, and grammer of all the electronic mail sent, received, and
stored?

S.314 is bad for *your* career.  If you vote to support it, I will
vote against you in upcoming elections.  I will work to impeach you.
I will never employ you, I will not read your memoirs, I will not do
business with you in any way what so ever.

I urge you to think twice, and then vote no on S.314.

j'





From msattler at jungle.com  Tue Feb  7 21:27:31 1995
From: msattler at jungle.com (Michael Sattler)
Date: Tue, 7 Feb 95 21:27:31 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <v03001400ab5e06968201@[140.174.229.225]>


>Can anyone confirm this S.314 thing?  It sounds an awful lot like
>the "modem tax" and other urban legends.

S 314 IS
104th CONGRESS
1st Session
To protect the public from the misuse of the telecommunications
network and telecommunications devices and facilities.
                 IN THE SENATE OF THE UNITED STATES
           February 1 (legislative day, January 30), 1995
Mr. Exon (for himself and Mr. Gorton) introduced the following
    bill; which was read twice and referred to the Committee on
    Commerce, Science, and Transportation
                               A BILL
To protect the public from the misuse of the telecommunications
network and telecommunications devices and facilities.
  Be it enacted by the Senate and House of Representatives of the
United States of America in Congress assembled,
SECTION 1. SHORT TITLE.
  This Act may be cited as the `Communications Decency Act of 1995'.
SEC. 2. OBSCENE OR HARASSING USE OF TELECOMMUNICATIONS FACILITIES
                  UNDER THE COMMUNICATIONS ACT OF 1934.
  (a) Offenses: Section 223 of the Communications Act of 1934 (47
U.S.C. 223) is amended--
      (1) in subsection (a)(1)--
          (A) by striking out `telephone' in the matter above
        subparagraph (A) and inserting `telecommunications device';
          (B) by striking out `makes any comment, request,
        suggestion, or proposal' in subparagraph (A) and inserting
        `makes, transmits, or otherwise makes available any
        comment, request, suggestion, proposal, image, or other
        communication';
          (C) by striking out subparagraph (B) and inserting the
        following:
          `(B) makes a telephone call or utilizes a
        telecommunications device, whether or not conversation or
        communications ensues, without disclosing his identity and
        with intent to annoy, abuse, threaten, or harass any person
        at the called number or who receives the communication;' and
          (D) by striking out subparagraph (D) and inserting the
        following:
          `(D) makes repeated telephone calls or repeatedly
        initiates communication with a telecommunications device,
        during which conversation or communication ensues, solely
        to harass any person at the called number or who receives
        the communication; or';
      (2) in subsection (a)(2), by striking `telephone facility'
    and inserting `telecommunications facility';
      (3) in subsection (b)(1)--
          (A) in subparagraph (A)--
              (i) by striking `telephone' and inserting
            `telecommunications device'; and
              (ii) inserting `or initiated the communication' and
            `placed the call', and
          (B) in subparagraph (B), by striking `telephone facility'
        and inserting `telecommunications facility'; and
      (4) in subsection (b)(2)--
          (A) in subparagraph (A)--
              (i) by striking `by means of telephone, makes' and
            inserting `by means of telephone or telecommunications
            device, makes, knowingly transmits, or knowingly makes
            available'; and
              (ii) by inserting `or initiated the communication'
            after `placed the call'; and
          (B) in subparagraph (B), by striking `telephone facility'
        and inserting in lieu thereof `telecommunications facility'.
  (b) Penalties: Section 223 of such Act (47 U.S.C. 223) is amended--
      (1) by striking out `$50,000' each place it appears and
    inserting `$100,000'; and
      (2) by striking `six months' each place it appears and
    inserting `2 years'.
  (c) Prohibition on Provision of Access: Subsection (c)(1) of such
section (47 U.S.C. 223(c)) is amended by striking `telephone' and
inserting `telecommunications device.'
  (d) Conforming Amendment: The section heading for such section is
amended to read as follows:
`obscene or harassing utilization of telecommunications devices and
facilities in the district of columbia or in interstate or foreign
communications'.
SEC. 3. OBSCENE PROGRAMMING ON CABLE TELEVISION.
  Section 639 of the Communications Act of 1934 (47 U.S.C. 559) is
amended by striking `$10,000' and inserting `$100,000'.
SEC. 4. BROADCASTING OBSCENE LANGUAGE ON RADIO.
  Section 1464 of title 18, United States Code, is amended by
striking out `$10,000' and inserting `$100,000'.
SEC. 5. INTERCEPTION AND DISCLOSURE OF ELECTRONIC COMMUNICATIONS.
  Section 2511 of title 18, United States Code, is amended--
      (1) in paragraph (1)--
          (A) by striking `wire, oral, or electronic communication'
        each place it appears and inserting `wire, oral,
        electronic, or digital communication', and
          (B) in the matter designated as `(b)', by striking `oral
        communication' in the matter above clause (i) and inserting
        `communication'; and
      (2) in paragraph (2)(a), by striking `wire or electronic
    communication service' each place it appears (other than in the
    second sentence) and inserting `wire, electronic, or digital
    communication service'.
SEC. 6. ADDITIONAL PROHIBITION ON BILLING FOR TOLL-FREE TELEPHONE
                  CALLS.
  Section 228(c)(6) of the Communications Act of 1934 (47 U.S.C.
228(c)(6)) is amended--
      (1) by striking `or' at the end of subparagraph (C);
      (2) by striking the period at the end of subparagraph (D) and
    inserting a semicolon and `or'; and
      (3) by adding at the end thereof the following:
          `(E) the calling party being assessed, by virtue of being
        asked to connect or otherwise transfer to a pay-per-call
        service, a charge for the call.'.
SEC. 7. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS.
  Part IV of title VI of the Communications Act of 1934 (47 U.S.C.
551 et seq.) is amended by adding at the end the following:
`SEC. 640. SCRAMBLING OF CABLE CHANNELS FOR NONSUBSCRIBERS.
  `(a) Requirement: In providing video programming unsuitable for
children to any subscriber through a cable system, a cable operator
shall fully scramble or otherwise fully block the video and audio
portion of each channel carrying such programming so that one not a
subscriber does not receive it.
  `(b) Definition: As used in this section, the term `scramble'
means to rearrange the content of the signal of the programming so
that the programming cannot be received by persons unauthorized to
receive the programming.'.
SEC. 8. CABLE OPERATOR REFUSAL TO CARRY CERTAIN PROGRAMS.
  (a) Public, Educational, and Governmental Channels: Section
611(e) of the Communications Act of 1934 (47 U.S.C. 531(e)) is
amended by inserting before the period the following: `, except a
cable operator may refuse to transmit any public access program or
portion of a public access program which contains obscenity,
indecency, or nudity'.
  (b) Cable Channels for Commercial Use: Section 612(c)(2) of the
Communications Act of 1934 (47 U.S.C. 532(c)(2)) is amended by
striking `an operator' and inserting `a cable operator may refuse
to transmit any leased access program or portion of a leased access
program which contains obscenity, indecency, or nudity.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From jpp at markv.com  Tue Feb  7 21:39:19 1995
From: jpp at markv.com (jpp at markv.com)
Date: Tue, 7 Feb 95 21:39:19 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.SV4.3.91.950207230934.23719A-100000@mirage.skypoint.com>
Message-ID: <9502072138.aa29510@hermix.markv.com>


Uh oh!  Egg on my face.  Will someone explain to me how the amendments
in S.314 make owners of ISPs or other computer systems liable for
'bad' data?  I apologize for my previous uncalled for (so it seams to
me now) ranting.

j*blushing*'





From tcmay at netcom.com  Tue Feb  7 21:50:50 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 7 Feb 95 21:50:50 PST
Subject: S.314, the "Pi Bill"
In-Reply-To: <199502080445.VAA00395@misc.glarp.com>
Message-ID: <199502080547.VAA28367@netcom11.netcom.com>


Brad Huntting wrote:

> Can anyone confirm this S.314 thing?  It sounds an awful lot like
> the "modem tax" and other urban legends.
> 
> 

I wrote a post to comp.org.eff.talk in which I asked if "S.314" isn't
just the "Pi Bill," in which pi = 3.14 is mandated to be pi = 3.00.

S.314 I initially, for a minute or so, thought to be a put-on, a
spoof. But the text lacked other signs of humor and had the trappings
of a real bill. And then versions from reputable groups began to
appear, so I was of course convinced it was real.

If it's a spoof, it's too cute by half.

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From daleh at ix.netcom.com  Tue Feb  7 22:35:37 1995
From: daleh at ix.netcom.com (Dale Harrison AEGIS)
Date: Tue, 7 Feb 95 22:35:37 PST
Subject: USPO & Digital Postage/E-Cash Project
Message-ID: <199502080625.WAA20933@ix3.ix.netcom.com>


The US Post Office just killed a project that would have created a 
digital postage/e-cash system.  This would have been a digital 
replacement for the Pitney-Bose style Postage Metering machines.  To use 
a PM machine one has to take the entire machine physically to a Postal 
Station and purchase some fixed dollar amount of postage.  The Postal 
clerk unseals and unlocks the machine, dials in the amount of postage 
purchased and then relocks and reseals the machine.  

This mechanical system would have been replaced by a serial-port dongle 
and a piece of software.  The dongle would contain an EEPROM in a 
replacable button (made by Dallas Semiconductor) into which would be 
loaded data indicating the amount of postage that had been purchased and 
not yet used.  The software package would be able to print the address, 
postage seal, routing codes, etc directly on the envelope via a laser 
printer and decrement the amount of available postage left in the 
dongle.  In the original test, customers would have to take the dongle 
to a Postal Station to purchase additional postage, but the ultimate 
goal was to have been to have a commerical dial-up service available 
that one could dial into and purchase additional postage directly. 

A proof-of-concept prototype was developed in VB and a production 
prototype was then developed in VC++.  Unfortunately the crypto wasn't 
very strong.  The USPO contracted with Carnege-Mellon to try and break 
the system and they were able to within a couple of weeks.  USPO then 
killed the project.


Dale H.






From skaplin at mirage.skypoint.com  Tue Feb  7 22:41:32 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 22:41:32 PST
Subject: S.314, the "Pi Bill"
In-Reply-To: <199502080547.VAA28367@netcom11.netcom.com>
Message-ID: <Pine.SV4.3.91.950208002952.25082A-100000@mirage.skypoint.com>




On Tue, 7 Feb 1995, Timothy C. May wrote:

> Brad Huntting wrote:
> 
> > Can anyone confirm this S.314 thing?  It sounds an awful lot like
> > the "modem tax" and other urban legends.
> > 
> > 
> 
> I wrote a post to comp.org.eff.talk in which I asked if "S.314" isn't
> just the "Pi Bill," in which pi = 3.14 is mandated to be pi = 3.00.
> 
> S.314 I initially, for a minute or so, thought to be a put-on, a
> spoof. But the text lacked other signs of humor and had the trappings
> of a real bill. And then versions from reputable groups began to
> appear, so I was of course convinced it was real.
> 
> If it's a spoof, it's too cute by half.
> 
> --Tim May

I too thought it was a spoof initally. Hell, what Senator would be dumb 
enough to name a bill this way if it was real. If I were trying to pass a 
bill of this nature, it would be double-speak all of the way. But alas it 
is true...And I thought the DT bill was bad. 

Both of my congresscritters have been faxed and queried as to their 
position. I'll inform the group when they fax me back. I would urge 
others to do this. This will be unbelievably bad if we loose this one. 
The ramifications on this bill are still hammering me in the head.

Sam





From lmccarth at ducie.cs.umass.edu  Tue Feb  7 22:47:49 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Tue, 7 Feb 95 22:47:49 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <v03001400ab5e06968201@[140.174.229.225]>
Message-ID: <199502080649.BAA02589@ducie.cs.umass.edu>


[As always, IANAL. This citizen likes to think he has a reasonable capability
and obligation to assess the laws to which he may be subjected, though.]

After perusing it a couple of times, I'm still not sure I understand why the
specific provisions of the CDA would provoke the extreme monitoring measures
mentioned here. I agree with Sam that it's rather odd that EPIC hasn't put it
on their list of privacy-related bills in the 104th Congress. 

As a start, I'll try to speculate on sore points and their possible
immediate implications. 

+ "This Act may be cited as the `Communications Decency Act of 1995'."

Who elected Miss Manners to Congress ?  Any bill with `decency' in its title
deserves to die in committee, IMNSHO.

+ SEC. 2. OBSCENE OR HARASSING USE OF TELECOMMUNICATIONS FACILITIES UNDER THE 
+ COMMUNICATIONS ACT OF 1934.
[...]
+ (B) by striking out `makes any comment, request, suggestion, or
+         proposal' in subparagraph (A) and inserting `makes, transmits, or
+         otherwise makes available any comment, request, suggestion, proposal,
+         image, or other communication';

I take this section to be extending the ban on harassing phone calls and such
to cover all forms of electronic communication. I'm further assuming that the
subparagraph (A) mentioned above attempts to enumerate possible linguistic and
technical means of conveying the harassing content. What disturbs me is the
phrase "or otherwise makes available". I'm reminded of the arrest in Florida
a few years back of a couple whose lovemaking had been witnessed through their
bedroom window by a neighbor's curious child. My lay understanding of this
language is that passively presented information, such as the contents of a
WWW page or .plan file, could be construed as illegally obscene or harassing
under this act.

+ SEC. 5. INTERCEPTION AND DISCLOSURE OF ELECTRONIC COMMUNICATIONS.
+ Section 2511 of title 18, United States Code, is amended--
[...]
+ (A) by striking `wire, oral, or electronic communication' each place it
+         appears and inserting `wire, oral, electronic, or digital
+         communication', and

Is this the crucial threatening passage ?  Adding electronic communication to
a list presumably subject to "interception and disclosure" sounds ominous.
Without seeing the original legislation, though, I can't tell whether this
totally overturns the ECPA and similar statutes, or does something less 
drastic.

BTW, what sort of "digital communication" is neither "wire communication" nor
"electronic communication" ?

+ SEC. 8. CABLE OPERATOR REFUSAL TO CARRY CERTAIN PROGRAMS.
[...]
+ `, except a cable operator may refuse to transmit
+   any public access program or portion of a public access program which
+   contains obscenity, indecency, or nudity'
[...]
+ `a cable operator may refuse to transmit any leased
+   access program or portion of a leased access program which contains
+   obscenity, indecency, or nudity.

The battle over "obscenity" has been fought long and hard.

"Indecency" seems a remarkably nebulous term (and, of course, ludicrously
Victorian). I'd be interested in seeing a legal definition, and alarmed if
there isn't one (yet).

Don't even get me started on the "nudity" portion. I'm sure Jesse Helms is
already licking his lips over this one.

-L. Futplex McCarthy




From jcorgan at aeinet.com  Tue Feb  7 22:53:33 1995
From: jcorgan at aeinet.com (Johnathan Corgan)
Date: Tue, 7 Feb 95 22:53:33 PST
Subject: a new way to do anonymity
Message-ID: <Chameleon.4.01.950207225342.jcorgan@comet.aeinet.com>


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

>   There are many, many analogies you can draw about a network of this
>   type to an ATM (asynchronous transfer mode) network.  
>
>Thank you for the analogy.  It's always good not to reinvent the wheel
>when you don't need to.

Exactly.  Anywhere we can "stand on the shoulders" of others reduces wasted
time and effort.

>When you set up a mapping on a packet forwarder, this is exactly the
>kind of initialization that would be required.  It is also at this
>point that keying would be negotiated, etc.

Encrypt-Telnet to a switch process.  Use text based command line sequence
to check outbound paths, bandwidth available, negotiate quality of service,
execute digital payment arrangements, etc.  Conclude the transaction and
get bumped to your next hop, where it happens all over again.

Done right, it could probably be automated.  It seems like a lot of effort,
but if you remember that once an initial session is established with your
Pipe-net Service Provider (tm), a given circuit can be relatively long-lived.

>Now here's an important detail that needs to get done right.  Is the
>forwarding for fixed length packets, variable length packets, or
>streams?  Is this decision global or local?  What are the latency and
>aggregatation effects?  How important are these for different classes
>of data?  (telnet v. voice, e.g.)

One of the lessons learned in the years-long debate between the telco folks
pushing synchronous time-division multiplexing point to point circuit switches 
and the data folks pushing variable length packet-switched broadcast medium
networks is that fixed length packets can give you both TDM and statistical
multiplexing.  So, at the bottom most session layer, moving bits around in
fixed chunks allows you to do things easier like bandwidth pre-allocation,
aggregation, circuit based congestion control, and negotiated quality of
service agreements to end points in the network.

To learn from the efforts that have come from the thousands of people working
on ATM, we could take a look at what has emerged as the "ATM Adaptation Layer."

AAL specifies methods to encapsulate various data formats and quality of service
requirements onto this fixed length, continuous stream of data packets.  There
is one for voice traffic, which requires fixed bandwitdth and very little relative
latency, another for LAN type data packets, which have bursty bandwidth requirements 
and variable packet sizes.  Your comment above is accurate in that the
requirements involved in a Telnet session are vastly different from say, PGP
Phone over TCP.

The good part about all this is that a lot of the thinking, testing, prototyping,
and standardization has already been done.  The standards exist today for adapting
variable bandwidth, variable packet length, variable latency data packets onto
a continous stream of fixed length packets moving through a switched network.

This reminds me of the old days of Packet Radio which used intelligent repeaters
that you would access (via command line), determine your next repeater, then
log into it, etc.  I once established virtual circuit from Connecticut to Florida
over 2 meter packet that took 25 or so hops, and had a transit delay of a half
an hour.  Primitive, kludgy, unreliable, and essentially useless, but totally cool.

An opportunity presents itself here to establish this Pipe-net style service
network, that would greatly expand the ability for network users to essentially
bypass all the crap which appears to be coming down on us from our friendly 
representatives in Washington, who are trying so hard to "protect" us from 
ourselves. 

>I'd suggest just getting something running first, to get some
>prototyping experience.

Of course.  What I've outline is a pretty ambitious goal.  I'd be happy to see
primitive switch implementations that do nothing more than forward TCP streams.
Its a start and we would learn a lot along the way.  Alas, I don't do Unix; my
programming expertise is in (gasp) the Windows environment.  So it looks like
I could start looking at the requirements implementation of a Winsock interface
that made all this stuff transparent to an end user.  Important consideration.

I suppose the IRC folks could add their experience to the mix.  In a very real
way, IRC _is_ a packet switched unicast/multicast stream service on top of the
'net.  Do we have any IRC op types onboard here?

==
Johnathan Corgan       "Violence is the last refuge of the incompetent."
jcorgan at aeinet.com                    -Isaac Asimov
WWW:                     ftp://ftp.netcom.com/pub/jc/jcorgan/home.html


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzhqMU1Diok8GKihAQGRxAP/dWIvYMuqX5c1y/Mlmc73WQlQ/1263vqb
YzGMvgTFEP0p/jZZstb8tMOyHY2KKp7WWLXV94jd8/KhdQgYFtGHphVm93WP3Bu8
hRK8kV5UEtANQ/JycVHG6HU3MMxLhE+Yh+M/CFLBwBZZYYglnV3DLqBHv4kq+5Tg
/7ZiTjnHRDk=
=ee6L
-----END PGP SIGNATURE-----







From skaplin at mirage.skypoint.com  Tue Feb  7 23:07:13 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 23:07:13 PST
Subject: Full text of S. 314
Message-ID: <Pine.SV4.3.91.950208010437.25409A-100000@mirage.skypoint.com>







From skaplin at mirage.skypoint.com  Tue Feb  7 23:24:13 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 23:24:13 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080649.BAA02589@ducie.cs.umass.edu>
Message-ID: <Pine.SV4.3.91.950208011435.25409B-100000@mirage.skypoint.com>




On Wed, 8 Feb 1995, L. McCarthy wrote:

> The battle over "obscenity" has been fought long and hard.
> 
> "Indecency" seems a remarkably nebulous term (and, of course, ludicrously
> Victorian). I'd be interested in seeing a legal definition, and alarmed if
> there isn't one (yet).

Last I heard, the Supreme Court had never made a ruling on this. They 
copped out and left it up to "Community Standards." This is partially why 
the AA bbs case was sucessfuly prosecuted in another state.

> Don't even get me started on the "nudity" portion. I'm sure Jesse Helms is
> already licking his lips over this one.

Under the new legislation, might this not be illegal? ;)

On another note, I mailed Stanton McClandish to find out what EFF's 
position is on this. I tried browsing their archives, but lots of stuff 
seems to have vanished from there.

Sam




Sam





From skaplin at mirage.skypoint.com  Tue Feb  7 23:34:23 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Tue, 7 Feb 95 23:34:23 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080649.BAA02589@ducie.cs.umass.edu>
Message-ID: <Pine.SV4.3.91.950208012852.25409C-100000@mirage.skypoint.com>




On Wed, 8 Feb 1995, L. McCarthy wrote:

> 
> BTW, what sort of "digital communication" is neither "wire communication" nor
> "electronic communication" ?

If I stick my middle finger up at you, isn't that non-electronic digital 
communication? (Injected for comic relief on a VERY serious topic. No 
flames please.)

Sam





From strick at techwood.org  Wed Feb  8 00:11:19 1995
From: strick at techwood.org (strick at techwood.org)
Date: Wed, 8 Feb 95 00:11:19 PST
Subject: noiz ... and more SKRONK
Message-ID: <199502080810.AAA08113@nando.yak.net>


MAB:
> Also, /etc/noiz is an attractive target
> on multi-user machines....

Right.   But you notice I made it mode 660, owner root, group kmem, to
parallel the /dev/*mem devices.   You have the same vulnerabilities as
always on a multi-user system, even if you put /dev/noise in the kernel
or run a TCP daemon.  Another parallel is the randseed.bin file in
PGP.

>From an information theory point of view, I don't know how to describe
the kind of shared-entropy that this pool exhibits.  Making the source
of the entropy hidden to the users by crunching on the way out with MD5
adds something to the data -- it's not true entropy, but it's some kind
of effective entropy, from the point of view of the users.  Unless MD5
has weaknesses that I assume it doesn't, it's not really possible for users
to know where their spaces of possible random values overlap, so they
don't know how to exploit it.

A final note -- I should have put /etc/noiz somewhere in the 
/var filesystem.  Perhaps /var/adm/noiz.
But one can edit the Makefile to do that, and no other software
has to actually know where it is, since its access is totally
encapsulated by noizinit, noizstir, and noizout.  The location of
these in /usr/local/bin/ is what needs to be standardized, so I
hope that's good enough for most users.

-------

Oh, I meant to thank everyone for the great discussion and 
constructive criticism of SKRONK and "encrypt tcp connections" hacks.
Especially Perry -- your enumeration of projects was good.

Based on that, and what I know of the others, the priority of 
protocols I'd like to support with skronk are
	0.  my own hack, to get it going
	1.  Matt's ESM
	2.  Kerberized connections (kerb4 or kerb5 or both?)
	3.  Perhaps the SSL from Netscape

Thus SKRONK becomes what I wanted it to be:  a way for sites to
advertize the availability of enhanced services (via the skronk map UDP
daemon) and a way to painlessly integrate crypto with existing code.
(The last aspect always draws user interface problems -- if it's so
transparent, how do you know if you're encrypted?  Right now I have the
client end scribble to stderr when it skronks.)

			strick






From ortenzi at interactive.net  Wed Feb  8 00:14:53 1995
From: ortenzi at interactive.net (Anthony Ortenzi)
Date: Wed, 8 Feb 95 00:14:53 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080649.BAA02589@ducie.cs.umass.edu>
Message-ID: <Pine.BSI.3.91.950208031553.29206A-100000@ns.interactive.net>


> BTW, what sort of "digital communication" is neither "wire communication" nor
> "electronic communication" ?

Depending on how you take the word "digital", flipping someone off?  :)

/****************************************************************************
* Anthony Ortenzi * ortenzi at interactive.net * ortenzi at vivarin.pc.cc.cmu.edu *
*---------------------------------------------------------------------------*
*                 * http://www.interactive.net/~ortenzi/ *                  *
****************************************************************************/






From skaplin at mirage.skypoint.com  Wed Feb  8 00:19:05 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 00:19:05 PST
Subject: URGENT - What S.314 Would Do
In-Reply-To: <3h81qs$ee0@dockmaster.phantom.com>
Message-ID: <Pine.SV4.3.91.950208020311.25943A-100000@mirage.skypoint.com>




On 7 Feb 1995, slowdog wrote:

>    Whoever -
>    
>    (1) in the District of Columbia or in interstate or foreign
>    communication by means of [telephone] telecommunications
>    device -
>    
>    (A) [makes any comment, request, suggestion or proposal] 
>    makes, transmits, or otherwise makes available any comment,
>    request, suggestions, proposal, image, or other communication]
>    which is obscene, lewd, lascivious, filthy, or indecent;

Ding...Ding...Ding... We have a winner here. Goodbye binaries and sex groups.
Please note the "whoever" at the top of the paragraph. No "knowingly." 
The question is: "Is obsene speech, protected speech? Does this negate 
the first ammendment?

> 
>    (B) [makes a telephone call, whether or not conversation
>    ensues, without disclosing his identity and with intent to
>    annoy, abuse, threaten, or harass any person at the called
>    number] makes a telephone call or utilizes a telecommunications
>    device, whether or not conversation or communications ensues,
>    without disclosing his identity with intent to annoy, abuse,
>    threaten, or harass any person at the called number or who
>    receives the communication;

Ding...Ding...Ding... We have another winner. Goodbye remailers. Probably 
90% of remailer traffic violates this one. Well boys and girls we'd 
better get lots more offshore...soon.







From skaplin at mirage.skypoint.com  Wed Feb  8 00:26:37 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 00:26:37 PST
Subject: Full text of S. 314
In-Reply-To: <Pine.SV4.3.91.950208010437.25409A-100000@mirage.skypoint.com>
Message-ID: <Pine.SV4.3.91.950208022428.26104C@mirage.skypoint.com>


I would suggest that everyone forward this to their ISP. It has a direct 
bearing on them and most won't be aware of it.

Sam





From skaplin at c2.org  Wed Feb  8 00:41:10 1995
From: skaplin at c2.org (Samuel Kaplin)
Date: Wed, 8 Feb 95 00:41:10 PST
Subject: Congressional Phone Numbers
Message-ID: <Pine.SUN.3.91.950208003250.25382A-100000@infinity>


In view of recent legislation, I'm going to repost this...No flames please.

NRA.org List of members of 104th Congress

ALASKA
Member                             Phone          Fax Number

Sen. Murkowski, Frank H. (R)       1-202-224-6665 1-202-224-5301
Sen. Stevens, Ted (R)              1-202-224-3004 1-202-224-1044

Young, Donald (R-AL)               1-202-225-5765 1-202-225-5765


ALABAMA
Member                             Phone          Fax Number

Sen. Heflin, Howell T. (D)         1-202-224-4124 1-202-224-3149
Sen. Shelby, Richard C. (R)        1-202-224-5744 1-202-224-3416

Callahan, Sonny (R-01)             1-202-225-4931 1-202-225-0562
Everett, Terry (R-02)              1-202-225-2901
Browder, Glen (D-03)               1-202-225-3261 1-202-225-9020
Bevill, Thomas (D-04)              1-202-225-4876 1-202-225-0842
Cramer, Robert E. (D-05)           1-202-225-4801 1-202-225-4392
Bachus, Spencer (R-06)             1-202-225-4921 1-202-225-2082
Hilliard, Earl F. (D-07)           1-202-225-2665 1-202-226-0772


ARKANSAS
Member                             Phone          Fax Number

Sen. Bumpers, Dale (D)             1-202-224-4843 1-202-224-6435
Sen. Pryor, David (D)              1-202-224-2353 1-202-224-8261

Lambert, Blanche (D-01)            1-202-225-4076 1-202-225-4654
Thornton, Raymond (D-02)           1-202-225-2506 1-202-225-9273
Hutchinson, Tim (R-03)             1-202-225-4301 1-202-226-1163
Dickey, Jay (R-04)                 1-202-225-3772 1-202-225-8646


ARIZONA
Member                             Phone          Fax Number

Sen. Kyl, Jon (R)                  1-202-224-4521 1-202-224-2302
Sen. McCain, John (R)              1-202-224-2235 1-202-228-2862

Salmon, Matt (R-01)                1-202-225-2635 1-202-225-2607
Pastor, Ed (D-02)                  1-202-225-4065 1-202-225-1655
Stump, Robert (R-03)               1-202-225-4576 1-202-225-6328
Shadegg, John (R-04)               1-202-225-3361 1-202-225-1143
Kolbe, James T. (R-05)             1-202-225-2542 1-202-225-0378
Hayworth, J.D. (R-06)              1-202-225-2190 1-202-225-8819


CALIFORNIA
Member                             Phone          Fax Number

Sen. Boxer, Barbara (D)            1-202-225-5161
Sen. Feinstein, Dianne (D)         1-202-224-3841 1-202-228-3954

Riggs, Frank (R-01)                1-202-225-3311 1-202-225-7710
Herger, Walter W. (R-02)           1-202-225-3076 1-202-225-1609
Fazio, Vic (D-03)                  1-202-225-5716 1-202-225-0354
Doolittle, John T. (R-04)          1-202-225-2511 1-202-225-5444
Matsui, Robert T. (D-05)           1-202-225-7163 1-202-225-0566
Woolsey, Lynn (D-06)               1-202-225-5161 1-202-225-5163
Miller, George (D-07)              1-202-225-2095 1-202-225-5609
Pelosi, Nancy (D-08)               1-202-225-4965 1-202-225-8259
Dellums, Ronald V. (D-09)          1-202-225-2661 1-202-225-9817
Baker, Bill (R-10)                 1-202-225-1880 1-202-225-2150
Pombo, Richard (R-11)              1-202-225-1947 1-202-226-0861
Lantos, Thomas (D-12)              1-202-225-3531 1-202-225-3127
Stark, Fortney H. (D-13)           1-202-225-5065
Eshoo, Anna G. (D-14)              1-202-225-8104 1-202-225-8890
Mineta, Norman Y. (D-15)           1-202-225-2631
Lofgren, Zoe (D-16)                1-202-225-3072 1-202-225-9460
Farr, Sam (D-17)
Condit, Gary (D-18)                1-202-225-6131 1-202-225-0819
Radanovich, George (R-19)          1-202-225-4540 1-202-225-5274
Dooley, Calvin M. (D-20)           1-202-225-3341 1-202-225-9308
Thomas, Bill (R-21)                1-202-225-2915 1-202-225-8798
Seastrand, Andrea (R-22)           1-202-225-3601 1-202-226-1015
Gallegly, Elton (R-23)             1-202-225-5811 1-202-225-1100
Beilenson, Anthony (D-24)          1-202-225-5911
McKeon, Howard P. (R-25)           1-202-225-1956 1-202-226-0683
Berman, Howard L. (D-26)           1-202-225-4695 1-202-225-5279
Moorhead, Carlos J. (R-27)         1-202-225-4176 1-202-226-1279
Dreier, David (R-28)               1-202-225-2305 1-202-225-4745
Waxman, Henry A. (D-29)            1-202-225-3976 1-202-225-4099
Becerra, Xavier (D-30)             1-202-225-6235 1-202-225-2202
Martinez, Matthew G. (D-31)        1-202-225-5464 1-202-225-4467
Dixon, Julian C. (D-32)            1-202-225-7084 1-202-225-4091
Roybal-Allard, Lucille (D-33)      1-202-225-1766 1-202-226-0350
Torres, Esteban E. (D-34)          1-202-225-5256 1-202-225-9711
Waters, Maxine (D-35)              1-202-225-2201 1-202-225-7584
Harman, Jane (D-36)                1-202-225-8220 1-202-226-0684
Tucker III, Walter R. (D-37)       1-202-225-7924 1-202-225-7926
Horn, Steve (R-38)                 1-202-225-6676 1-202-226-1012
Royce, Ed (R-39)                   1-202-225-4111 1-202-226-0335
Lewis, Jerry (R-40)                1-202-225-5861 1-202-225-6498
Kim, Jay C. (R-41)                 1-202-225-3201 1-202-226-1485
Brown Jr., George E. (D-42)        1-202-225-6161 1-202-225-8671
Calvert, Kenneth (R-43)            1-202-225-1986
Bono, Sonny (R-44)                 1-202-225-5330 1-202-226-1040
Rohrabacher, Dana (R-45)           1-202-225-2415 1-202-225-7067
Dornan, Robert K. (R-46)           1-202-225-2965 1-202-225-3694
Cox, Christopher (R-47)            1-202-225-5611 1-202-225-9177
Packard, Ronald (R-48)             1-202-225-3906 1-202-225-0134
Bilbray, Brian (R-49)              1-202-225-2040 1-202-225-2042
Filner, Bob (D-50)                 1-202-225-8045 1-202-225-9073
Cunningham, Randy (R-51)           1-202-225-5452 1-202-225-2558
Hunter, Duncan L. (R-52)           1-202-225-5672 1-202-225-0235


COLORADO
Member                             Phone          Fax Number

Sen. Campbell, Ben N. (D)          1-202-225-4761 1-202-225-0228
Sen. Brown, Henry (R)              1-202-224-5941 1-202-224-6471

Schroeder, Patricia (D-01)         1-202-225-4431 1-202-225-5842
Skaggs, David E. (D-02)            1-202-225-2161 1-202-225-9127
McInnis, Scott (R-03)              1-202-225-4761 1-202-226-0622
Allard, Wayne (R-04)               1-202-225-4676 1-202-225-8630
Hefley, Joel (R-05)                1-202-225-4422 1-202-225-1942
Schaefer, Daniel (R-06)            1-202-225-7882 1-202-225-7885


CONNECTICUT
Member                             Phone          Fax Number

Sen. Dodd, Christopher J. (D-CT)   1-202-224-2823
Sen. Lieberman, Joseph I. (D-CT)   1-202-224-4041 1-202-224-9750

Kennelly, Barbara B. (D-01)        1-202-225-2265 1-202-225-1031
Gejdenson, Samuel (D-02)           1-202-225-2076 1-202-225-4977
DeLauro, Rosa (D-03)               1-202-225-3661 1-202-225-4890
Shays, Christopher (R-04)          1-202-225-5541 1-202-225-9629
Franks, Gary (R-05)                1-202-225-3822 1-202-225-5085
Johnson, Nancy L. (R-06)           1-202-225-4476 1-202-225-4488


WASHINGTON, D.C.
Member                             Phone          Fax Number

Del. Norton, Eleanor Holmes (D-AL) 1-202-225-8050 1-202-225-3002


DELAWARE
Member                             Phone          Fax Number

Sen. Biden Jr., Joseph R. (D)      1-202-224-5042 1-202-224-0139
Sen. Roth Jr., William V. (R)      1-202-224-2441 1-202-224-2805

Castle, Michael N. (R-AL)          1-202-225-4165 1-202-225-2291


FLORIDA
Member                             Phone          Fax Number

Sen. Graham, Bob (D)               1-202-224-3041 1-202-224-2237
Sen. Mack, Connie (R)              1-202-224-5274 1-202-224-8022

Scarborough, Joe (R-01)            1-202-225-4136 1-202-225-5785
Peterson, Peter (D-02)             1-202-225-5235 1-202-225-1586
Brown, Corrine (D-03)              1-202-225-0123 1-202-225-2256
Fowler, Tillie (R-04)              1-202-225-2501 1-202-225-9318
Thurman, Karen (R-05)              1-202-225-1002 1-202-226-0329
Stearns, Clifford B. (R-06)        1-202-225-5744 1-202-225-3973
Mica, John L. (R-07)               1-202-225-4035 1-202-226-0821
McCollum, William (R-08)           1-202-225-2176 1-202-225-0999
Bilirakis, Michael (R-09)          1-202-225-5755 1-202-225-4085
Young, C. W. Bill (R-10)           1-202-225-5961 1-202-225-9764
Gibbons, Samuel M. (D-11)          1-202-225-3376
Canady, Charles T. (R-12)          1-202-225-1252 1-202-225-2279
Miller, Dan (R-13)                 1-202-225-5015 1-202-226-0828
Goss, Porter J. (R-14)             1-202-225-2536 1-202-225-6820
Weldon, Dave (R-15)                1-202-225-3671 1-202-225-9039
Foley, Mark (R-16)                 1-202-225-5792 1-202-225-1860
Meek, Carrie (D-17)                1-202-225-4506 1-202-226-0777
Ros-Lehtinen, Ileana (R-18)        1-202-225-3931 1-202-225-5620
Johnston II, Harry (D-19)          1-202-225-3001 1-202-225-8791
Deutsch, Peter (D-20)              1-202-225-7931 1-202-225-8456
Diaz-Balart, Lincoln (R-21)        1-202-225-4211 1-202-225-8576
Shaw Jr., E. Clay (R-22)           1-202-225-3026 1-202-225-8398
Hastings, Alcee L. (D-23)          1-202-225-1313 1-202-225-0690


GEORGIA
Member                             Phone          Fax Number

Sen. Coverdell, Paul (R)           1-202-224-3643 1-202-228-3783
Sen. Nunn, Samuel (D)              1-202-224-3521 1-202-224-0072

Kingston, Jack (R-01)              1-202-225-5831 1-202-226-2269
Bishop, Sanford (D-02)             1-202-225-3631 1-202-225-2203
Collins, Michael (Mac)             (R-03)    1-202-225-5901
1-202-225-2515
Linder, John (R-04)                1-202-225-4272 1-202-225-4696
Lewis, John (D-05)                 1-202-225-3801 1-202-225-0351
Gingrich, Newt (R-06)              1-202-225-4501 1-202-225-4656
Barr, Bob (R-07)                   1-202-225-2931 1-202-225-0473
Chambliss, Saxby (R-08)            1-202-225-6531 1-202-225-7719
Deal, Nathan (D-09)                1-202-225-5211 1-202-225-8272
Norwood, Charles (D-10)            1-202-225-4101 1-202-226-1466
McKinney, Cynthia (D-11)           1-202-225-1605 1-202-226-0691


GUAM
Member                             Phone          Fax Number

Del. Underwood, Robert A. (D-AL)   1-202-225-1188 1-202-226-0341


HAWAII
Member                             Phone          Fax Number

Sen. Akaka, Daniel K. (D)          1-202-224-6361 1-202-224-2126
Sen. Inouye, Daniel K. (D)         1-202-224-3934 1-202-224-6747

Abercrombie, Neil (D-01)           1-202-225-2726 1-202-225-4580
Mink, Patsy T. (D-02)              1-202-225-4906 1-202-225-4987


IOWA
Member                             Phone          Fax Number

Sen. Grassley, Charles E. (R)      1-202-224-3744 1-202-224-6020
Sen. Harkin, Thomas (D)            1-202-224-3254 1-202-224-7431

Leach, James (R-01)                1-202-225-6576 1-202-226-1278
Nussle, James Allen (R-02)         1-202-225-2911 1-202-225-9129
Lightfoot, James R. (R-03)         1-202-225-3806 1-202-225-6973
Ganske, Greg (R-04)                1-202-225-4426
Latham, Tom (R-05)                 1-202-225-5476 1-202-225-6929


IDAHO
Member                             Phone          Fax Number

Sen. Kempthorne, Dirk (R)          1-202-224-6142 1-202-224-5893
Sen. Craig, Larry E. (R)           1-202-224-2752 1-202-224-2573

Chenoweth, Helen (R-01)            1-202-225-6611 1-202-226-1213
Crapo, Michael D. (R-02)           1-202-225-5531 1-202-225-8216


ILLINOIS
Member                             Phone          Fax Number

Sen. Moseley-Braun, Carol (D)      1-202-224-2854 1-202-224-2626
Sen. Simon, Paul (D)               1-202-224-2152 1-202-224-0868

Rush, Bobby L. (D-01)              1-202-225-4372 1-202-226-0333
Reynolds, Mel (D-02)               1-202-225-0773 1-202-225-0774
Lipinski, William O. (D-03)        1-202-225-5701 1-202-225-1012
Gutierrez, Luis V. (R-04)          1-202-225-8203 1-202-225-7810
Flanagan, Mike (R-05)              1-202-225-4061 1-202-225-4064
Hyde, Henry J. (R-06)              1-202-225-4561 1-202-226-1240
Collins, Cardiss (D-07)            1-202-225-5006 1-202-225-8396
Crane, Philip M. (R-08)            1-202-225-3711 1-202-225-7830
Yates, Sidney R. (D-09)            1-202-225-2111 1-202-225-3493
Porter, John E. (R-10)             1-202-225-4835 1-202-225-0157
Weller, Gerald (R-11)              1-202-225-3635 1-202-225-4447
Costello, Jerry F. (D-12)          1-202-225-5661 1-202-225-0285
Fawell, Harris W. (R-13)           1-202-225-3515 1-202-225-9420
Hastert, J. Dennis (R-14)          1-202-225-2976 1-202-225-0697
Ewing, Thomas (R-15)               1-202-225-2371 1-202-225-8071
Manzullo, Donald (R-16)            1-202-225-5676 1-202-225-5284
Evans, Lane (D-17)                 1-202-225-5905 1-202-225-5396
LaHood, Ray (R-18)                 1-202-225-6201 1-202-225-9461
Poshard, Glendal W. (D-19)         1-202-225-5201 1-202-225-1541
Durbin, Richard J. (D-20)          1-202-225-5271 1-202-225-0170


INDIANA
Member                             Phone          Fax Number

Sen. Coats, Daniel R. (R)          1-202-224-5623 1-202-224-8964
Sen. Lugar, Richard G. (R)         1-202-224-4814 1-202-224-7877

Visclosky, Peter J. (D-01)         1-202-225-2461 1-202-225-2493
Mcintosh, David (D-02)             1-202-225-3021 1-202-225-8140
Roemer, Timothy (D-03)             1-202-225-3915 1-202-225-6798
Souder, Mark (R-04)                1-202-225-4436 1-202-225-8810
Buyer, Steve (D-05)                1-202-225-5037
Burton, Daniel (R-06)              1-202-225-2276 1-202-225-0016
Myers, John T. (R-07)              1-202-225-5805 1-202-225-1649
Hostettler, John (R-08)            1-202-225-4636 1-202-225-4688
Hamilton, Lee (D-09)               1-202-225-5315 1-202-225-1101
Jacobs Jr., Andrew (D-10)          1-202-225-4011 1-202-226-4093


KANSAS
Member                             Phone          Fax Number

Sen. Kassebaum, Nancy L. (R)       1-202-224-4774 1-202-224-3514
Sen. Dole, Robert (R)              1-202-224-6521 1-202-224-8952

Roberts, Pat (R-01)                1-202-225-2715 1-202-225-5375
Brownback, Sam (R-02)              1-202-225-6601 1-202-225-1445
Meyers, Jan (R-03)                 1-202-225-2865 1-202-225-0554
Tiahrt, Todd (R-04)                1-202-225-6216 1-202-225-5398


KENTUCKY
Member                             Phone          Fax Number

Sen. McConnell, Mitch (R)          1-202-224-2541 1-202-224-2499
Sen. Ford, Wendell H. (D)          1-202-224-4343 1-202-224-0046

Whitfield, Edward (R-01)           1-202-225-3115 1-202-225-2169
Lewis, Ron (R-02)                  1-202-225-3501
Ward, Mike (R-03)                  1-202-225-5401
Bunning, James (R-04)              1-202-225-3465 1-202-225-0003
Rogers, Harold (R-05)              1-202-225-4601 1-202-225-0940
Baesler, Scotty (D-06)             1-202-225-4706 1-202-225-2122


LOUISIANA
Member                             Phone          Fax Number

Sen. Johnston, J. Bennett (D)      1-202-224-5824 1-202-224-2952
Sen. Breaux, John B. (D)           1-202-224-4623 1-202-224-2435

Livingston, Robert (R-01)          1-202-225-3015 1-202-225-0739
Jefferson, William (D-02)          1-202-225-6636 1-202-225-1988
Tauzin, W. J. (Billy) (D-03)       1-202-225-4031 1-202-225-0563
Fields, Cleo (D-04)                1-202-225-8490 1-202-225-8959
McCrery, James (R-05)              1-202-225-2777 1-202-225-8039
Baker, Richard H. (R-06)           1-202-225-3901 1-202-225-7313
Hayes, James A. (D-07)             1-202-225-2031 1-202-225-1175


MASSACHUSETTS
Member                             Phone          Fax Number

Sen. Kennedy, Edward M. (D)        1-202-224-4543 1-202-224-2417
Sen. Kerry, John F. (D)            1-202-224-2742 1-202-224-8525

Olver, John W. (D-01)              1-202-225-5335 1-202-226-1224
Neal, Richard E. (D-02)            1-202-225-5601 1-202-225-8112
Blute, Peter I. (R-03)             1-202-225-6101 1-202-225-2217
Frank, Barney (D-04)               1-202-225-5931 1-202-225-0182
Meehan, Martin T. (D-05)           1-202-225-3411 1-202-226-0771
Torkildsen, Peter G. (R-06)        1-202-225-8020 1-202-225-8037
Markey, Edward J. (D-07)           1-202-225-2836 1-202-225-8689
Kennedy II, Joseph P. (D-08)       1-202-225-5111 1-202-225-9322
Moakley, John Joseph (D-09)        1-202-225-8273 1-202-225-7304
Studds, Gerry E. (D-10)            1-202-225-3111 1-202-225-2212



MARYLAND
Member                             Phone          Fax Number

Sen. Mikulski, Barbara A. (D)      1-202-224-4654 1-202-224-8858
Sen. Sarbanes, Paul S. (D)         1-202-224-4524 1-202-224-1651

Gilchrest, Wayne T. (R-01)         1-202-225-5311 1-202-225-0254
Ehrlich, Bob (R-02)                1-202-225-3061 1-202-225-4251
Cardin, Benjamin L. (D-03)         1-202-225-4016 1-202-225-9219
Wynn, Albert R. (D-04)             1-202-225-8699 1-202-225-8714
Hoyer, Steny H. (D-05)             1-202-225-4131 1-202-225-4300
Bartlett, Roscoe G. (R-06)         1-202-225-2721 1-202-225-2193
Mfume, Kweisi (D-07)               1-202-225-4741 1-202-225-3178
Morella, Constance (R-08)          1-202-225-5341 1-202-225-1389


MAINE
Member                             Phone          Fax Number

Sen. Snowe, Olympia (R)            1-202-224-5344 1-202-224-6853
Sen. Cohen, William S. (R)         1-202-224-2523 1-202-224-2693

Longley, James (R-01)              1-202-225-6116 1-202-225-9065
Baldacci, John (D-02)              1-202-225-6306 1-202-225-8297


MICHIGAN
Member                             Phone          Fax Number

Sen. Levin, Carl (D)               1-202-224-6221
Sen. Abraham, Spencer (R)          1-202-224-4822 1-202-224-8834

Stupak, Bart (D-01)                1-202-225-4735 1-202-225-4744
Hoekstra, Peter (R-02)             1-202-225-4401 1-202-226-0779
Ehlers, Vernon (R-03)              1-202-225-3831 1-202-225-5144
Camp, David Lee (R-04)             1-202-225-3561 1-202-225-9679
Barcia, James A. (D-05)            1-202-225-8171 1-202-225-2168
Upton, Frederick S. (R-06)         1-202-225-3761 1-202-225-4986
Smith, Nick (R-07)                 1-202-225-6276 1-202-225-6281
Chrysler, Dick (R-08)              1-202-225-4872 1-202-225-1260
Kildee, Dale E. (D-09)             1-202-225-3611 1-202-225-6393
Bonior, David E. (D-10)            1-202-225-2106 1-202-226-1169
Knollenberg, Joe (R-11)            1-202-225-5802 1-202-226-2356
Levin, Sander M. (D-12)            1-202-225-4961 1-202-226-1033
Rivers, Lynn (D-13)                1-202-225-6261 1-202-225-0489
Conyers Jr., John (D-14)           1-202-225-5126 1-202-225-0072
Collins, Barbara (D-15)            1-202-225-2261 1-202-225-6645
Dingell, John D. (D-16)            1-202-225-4071 1-202-225-7426


MINNESOTA
Member                             Phone          Fax Number

Sen. Grams, Rod (R)                1-202-224-3244 1-202-228-0956
Sen. Wellstone, Paul (D)           1-202-224-5641 1-202-224-8438

Gutknecht, Gil (R-01)              1-202-225-2472 1-202-225-0051
Minge, David (D-02)                1-202-225-2331 1-202-226-0836
Ramstad, James M. (R-03)           1-202-225-2871 1-202-225-6351
Vento, Bruce F. (D-04)             1-202-225-6631 1-202-225-1968
Sabo, Martin Olav (D-05)           1-202-225-4755 1-202-225-4886
Luther, William (D-06)             1-202-225-2271 1-202-225-9802
Peterson, Collin C. (D-07)         1-202-225-2165 1-202-225-1593
Oberstar, James L. (D-08)          1-202-225-6211 1-202-225-0699


MISSOURI
Member                             Phone          Fax Number

Sen. Bond, Christopher S. (R)      1-202-224-5721 1-202-224-8149
Sen. Ashcroft, John (R)            1-202-224-6154 1-202-224-7615

Clay, William L. (D-01)            1-202-225-2406 1-202-225-1725
Talent, James M. (R-02)            1-202-225-2561 1-202-225-2563
Gephardt, Richard A. (D-03)        1-202-225-2671 1-202-225-7452
Skelton, Ike (D-04)                1-202-225-2876 1-202-225-2695
McCarthy, Karen (D-05)             1-202-225-4535 1-202-225-5990
Danner, Pat (D-06)                 1-202-225-7041 1-202-225-8221
Hancock, Melton D. (R-07)          1-202-225-6536 1-202-225-7700
Emerson, Bill (R-08)               1-202-225-4404 1-202-225-9621
Volkmer, Harold L. (D-09)          1-202-225-2956 1-202-225-7834


MISSISSIPPI
Member                             Phone          Fax Number

Sen. Cochran, Thad (R)             1-202-224-5054 1-202-224-3576
Sen. Lott, Trent (R)               1-202-224-6253 1-202-224-2262

Wicker, Roger (R-01)               1-202-225-4306 1-202-225-4328
Thompson, Bennie (D-02)            1-202-225-5876 1-202-225-5898
Montgomery, G. V. (D-03)           1-202-225-5031 1-202-225-3375
Parker, Mike (D-04)                1-202-225-5865 1-202-225-5886
Taylor, Gene (D-05)                1-202-225-5772 1-202-225-7074


MONTANA
Member                             Phone          Fax Number

Sen. Burns, Conrad R. (R)          1-202-224-2644 1-202-224-8594
Sen. Baucus, Max (D)               1-202-224-2651

Williams, Pat (D-AL)               1-202-225-3211 1-202-226-0244


NORTH CAROLINA
Member                             Phone          Fax Number

Sen. Helms, Jesse (R)              1-202-224-6342 1-202-224-7588
Sen. Faircloth, Lauch (R)          1-202-224-3154 1-202-224-7406

Clayton, Eva (D-01)                1-202-225-3101 1-202-225-3354
Funderburk, Dave (R-02)            1-202-225-4531 1-202-225-1539
Jones, Walter (R-03)               1-202-225-3415 1-202-225-0666
Heineman, F. (R-04)                1-202-225-1784 1-202-225-6314
Burr, Richard (R-05)               1-202-225-2071 1-202-225-4060
Coble, Howard (R-06)               1-202-225-3065 1-202-225-8611
Rose, Charles (D-07)               1-202-225-2731 1-202-225-2470
Hefner, Bill (D-08)                1-202-225-3715 1-202-225-4036
Myrick, Sue (R-09)                 1-202-225-1976 1-202-225-8995
Ballenger, Cass (R-10)             1-202-225-2576 1-202-225-0316
Taylor, Charles Hart (R-11)        1-202-225-6401 1-202-251-0794
Watt, Melvin (D-12)                1-202-225-1510 1-202-225-1512


NORTH DAKOTA
Member                             Phone          Fax Number

Sen. Dorgan, Byron L. (D)          1-202-225-2611 1-202-225-9436
Sen. Conrad, Kent (D)              1-202-224-2043 1-202-224-7776

Pomeroy, Earl (D-AL)               1-202-225-2611 1-202-226-0893


NEBRASKA
Member                             Phone          Fax Number

Sen. Exon, J. James (D)            1-202-224-4224 1-202-224-5213
Sen. Kerrey, Joseph R. (D)         1-202-224-6551 1-202-224-7645

Bereuter, Douglas (R-01)           1-202-225-4806 1-202-226-1148
Christensen, Jon (R-02)            1-202-225-4155 1-202-225-4684
Barrett, William E. (R-03)         1-202-225-6435 1-202-225-0207


NEW HAMPSHIRE
Member                             Phone          Fax Number

Sen. Gregg, Judd (R)               1-202-224-3324 1-202-224-4952
Sen. Smith, Robert (R)             1-202-224-2841 1-202-224-1353

Zeliff Jr., William (R-01)         1-202-225-5456 1-202-225-4370
Bass, Charles (D-02)               1-202-225-5206 1-202-225-0046


NEW JERSEY
Member                             Phone          Fax Number

Sen. Lautenberg, Frank R. (D)      1-202-224-4744 1-202-224-9707
Sen. Bradley, William (D)          1-202-224-3224 1-202-224-8567

Andrews, Robert E. (D-01)          1-202-225-6501 1-202-225-6583
LoBiondo, Frank (R-02)             1-202-225-6572 1-202-226-1108
Saxton, Jim (R-03)                 1-202-225-4765 1-202-225-0778
Smith, Christopher (R-04)          1-202-225-3765 1-202-225-7768
Roukema, Marge (R-05)              1-202-225-4465 1-202-225-9048
Pallone Jr., Frank (D-06)          1-202-225-4671 1-202-225-9665
Franks, Bob (R-07)                 1-202-225-5361 1-202-225-9460
Martini, Bill (R-08)               1-202-225-5751 1-202-226-2273
Torricelli, Robert (D-09)          1-202-224-5061 1-202-225-0843
Payne, Donald M. (D-10)            1-202-225-3436 1-202-225-4160
Frelinghuysen, Rodney (R-11)       1-202-225-5034 1-202-225-0658
Zimmer, Richard A. (R-12)          1-202-225-5801 1-202-225-9181
Menendez, Robert (D-13)            1-202-225-7919 1-202-226-0792


NEW MEXICO
Member                             Phone          Fax Number

Sen. Bingaman, Jeff (D)            1-202-224-5521 1-202-224-2852
Sen. Domenici, Pete V. (R)         1-202-224-6621 1-202-224-7371

Schiff, Steven H. (R-01)           1-202-225-6316 1-202-225-4975
Skeen, Joseph (R-02)               1-202-225-2365 1-202-225-9599
Richardson, William (D-03)         1-202-225-6190 1-202-225-1950

NEVADA
Member                             Phone          Fax Number

Sen. Reid, Harry (D)               1-202-224-3542 1-202-224-7327
Sen. Bryan, Richard H. (D)         1-202-224-6244 1-202-224-1867
Ensign, John (R-01)                1-202-225-5965 1-202-225-8808
Vucanovich, Barbara (R-02)         1-202-225-6155 1-202-225-2319


NEW YORK
Member                             Phone          Fax Number

Sen. D'Amato, Alfonse M. (R)       1-202-224-6542 1-202-224-5871
Sen. Moynihan, Daniel P. (D)       1-202-224-4451 1-202-224-9293

Forbes, Michael (R-01)             1-202-225-3826 1-202-225-0776
Lazio, Rick A. (R-02)              1-202-225-3335 1-202-225-4669
King, Peter T. (R-03)              1-202-225-7896 1-202-226-2279
Frisa, Danial (R-04)               1-202-225-5516 1-202-225-4672
Ackerman, Gary L. (D-05)           1-202-225-2601 1-202-225-1589
Flake, Floyd H. (D-06)             1-202-225-3461 1-202-226-4169
Manton, Thomas J. (D-07)           1-202-225-3965 1-202-225-1909
Nadler, Jerrold (D-08)             1-202-225-5635 1-202-225-6923
Schumer, Charles E. (D-09)         1-202-225-6616 1-202-225-4183
Towns, Edolphus (D-10)             1-202-225-5936 1-202-225-1018
Owens, Major R. (D-11)             1-202-225-6231 1-202-226-0112
Velazquez, Nydia M. (D-12)         1-202-225-2361 1-202-226-0327
Molinari, Susan (R-13)             1-202-225-3371 1-202-226-1272
Maloney, Carolyn B. (D-14)         1-202-225-7944 1-202-225-4709
Rangel, Charles B. (D-15)          1-202-225-4365 1-202-225-0816
Serrano, Jose E. (D-16)            1-202-225-4361 1-202-225-6001
Engel, Eliot L. (D-17)             1-202-225-2464 1-202-225-5513
Lowey, Nita M. (D-18)              1-202-225-6506 1-202-225-0546
Kelly, Sue (R-19)                  1-202-225-5441 1-202-225-0962
Gilman, Benjamin A. (R-20)         1-202-225-3776 1-202-225-2541
McNulty, Michael R. (D-21)         1-202-225-5076 1-202-225-5077
Solomon, Gerald B. (R-22)          1-202-225-5614 1-202-225-1168
Boehlert, Sherwood (R-23)          1-202-225-3665 1-202-225-1891
McHugh, John M. (R-24)             1-202-225-4611 1-202-226-0621
Walsh, James T. (R-25)             1-202-225-3701 1-202-225-4042
Hinchey, Maurice D. (D-26)         1-202-225-6335 1-202-226-0774
Paxon, Bill (R-27)                 1-202-225-5265 1-202-225-5910
Slaughter, Louise M. (D-28)        1-202-225-3615 1-202-225-7822
LaFalce, John J. (D-29)            1-202-225-3231 1-202-225-8693
Quinn, Jack (R-30)                 1-202-225-3306 1-202-226-0347
Houghton, Amory (R-31)             1-202-225-3161 1-202-225-5574


OHIO
Member                             Phone          Fax Number

Sen. DeWine, Mike (R)              1-202-224-2315 1-202-224-6519
Sen. Glenn, John (D)               1-202-224-3353 1-202-224-7983

Chabot, Steve (R-01)               1-202-225-2216 1-202-225-4732
Portman, Rob (R-02)
Hall, Tony P. (D-03)               1-202-225-6465 1-202-225-6766
Oxley, Michael G. (R-04)           1-202-225-2676 1-202-226-1160
Gillmor, Paul E. (R-05)            1-202-225-6405 1-202-225-1985
Cremeans, Frank (R-06)             1-202-225-5705 1-202-226-0331
Hobson, David L. (R-07)            1-202-225-4324 1-202-225-1984
Boehner, John Andrew (R-08)        1-202-225-6205 1-202-225-0704
Kaptur, Marcy (D-09)               1-202-225-4146 1-202-225-7711
Hoke, Martin R. (R-10)             1-202-225-5871 1-202-226-0994
Stokes, Louis (D-11)               1-202-225-7032 1-202-225-1339
Kasich, John R. (R-12)             1-202-225-5355
Brown, Sherrod (D-13)              1-202-225-3401 1-202-225-2266
Sawyer, Thomas C. (D-14)           1-202-225-5231 1-202-225-5278
Pryce, Deborah (R-15)              1-202-225-2015 1-202-226-0986
Regula, Ralph (R-16)               1-202-225-3876 1-202-225-3059
Traficant Jr., James (D-17)        1-202-225-5261 1-202-225-3719
Ney, Bob (R-18)                    1-202-225-6265 1-202-225-9065
LaTourette, Steve (R-19)           1-202-225-5731 1-202-225-9114


OKLAHOMA
Member                             Phone          Fax Number

Sen. Inhofe, James (R)             1-202-224-4721
Sen. Nickles, Donald (R)           1-202-224-5754 1-202-224-6008

Largent, Steve (R-01)              1-202-225-2211 1-202-225-9187
CoBurn, Tom (R-02)                 1-202-225-2701 1-202-225-2796
Brewster, Billy Kent (D-03)        1-202-225-4565 1-202-225-9029
Watts, J.C. (R-04)                 1-202-225-6165 1-202-225-9746
Istook, Ernest Jim (R-05)          1-202-225-2132 1-202-226-1463
Lucas, Frank (R-06)                1-202-225-5565 1-202-225-8698


OREGON
Member                             Phone          Fax Number

Sen. Packwood, Bob (R)             1-202-224-5244 1-202-228-3576
Sen. Hatfield, Mark O. (R)         1-202-224-3753 1-202-224-0276

Furse, Elizabeth (D-01)            1-202-225-0855 1-202-225-9497
Cooley, Wes (R-02)                 1-202-225-6730 1-202-225-3129
Wyden, Ronald (D-03)               1-202-225-4811 1-202-225-8941
DeFazio, Peter A. (D-04)           1-202-225-6416 1-202-225-0694
Webber, Catherine (D-05)           1-202-225-5711 1-202-225-9477


PENNSYSLVANIA
Member                             Phone          Fax Number

Sen. Specter, Arlen (R)            1-202-224-4254 1-202-224-1893
Sen. Santorum, Rick (R)            1-202-224-6324 1-202-224-4161

Foglietta, Thomas M. (D-01)        1-202-225-4731 1-202-225-0088
Fattah, Chaka (D-02)               1-202-225-4001 1-202-225-7362
Borski, Robert A. (D-03)           1-202-225-8251 1-202-225-4628
Klink, Ron (D-04)                  1-202-225-2565 1-202-226-2274
Clinger Jr., William (R-05)        1-202-225-5121 1-202-225-4681
Holden, Tim (D-06)                 1-202-225-5546 1-202-226-0996
Weldon, Curt (R-07)                1-202-225-2011 1-202-225-8137
Greenwood, Jim (R-08)              1-202-225-4276 1-202-225-9511
Shuster, Bud (R-09)                1-202-225-2431 1-202-225-2486
McDade, Joseph M. (R-10)           1-202-225-3731 1-202-225-9594
Kanjorski, Paul E. (D-11)          1-202-225-6511 1-202-225-9024
Murtha, John P. (D-12)             1-202-225-2065 1-202-225-5709
Fox, Jon (R-13)                    1-202-225-6111 1-202-226-0798
Coyne, William J. (D-14)           1-202-225-2301 1-202-225-1844
McHale, Paul (D-15)                1-202-225-6411 1-202-225-5320
Walker, Robert S. (R-16)           1-202-225-2411 1-202-225-2484
Gekas, George W. (R-17)            1-202-225-4315 1-202-225-8440
Doyle, Michael (D-18)              1-202-225-2135 1-202-225-7747
Goodling, William F. (R-19)        1-202-225-5836 1-202-226-1000
Mascara, Frank (D-20)              1-202-225-4665 1-202-225-4772
English, Philip (R-21)             1-202-225-5406 1-202-225-1081


PUERTO RICO
Member                             Phone          Fax Number

Del. Romero-Barcelo, Carlos (D-AL) 1-202-225-2615 1-202-225-2154


RHODE ISLAND
Member                             Phone          Fax Number

Sen. Pell, Claiborne (D)           1-202-224-4642 1-202-224-4680
Sen. Chafee, John H. (R)           1-202-224-2921

Kennedy, Patrick (D-01)            1-202-225-4911 1-202-225-4417
Reed, John F. (D-02)               1-202-225-2735 1-202-225-9580


AMERICAN SAMOA
Member                             Phone          Fax Number

Del. Faleomavaega, Eni F.H. (D-AL) 1-202-225-8577 1-202-225-8757


SOUTH CAROLINA
Member                             Phone          Fax Number

Sen. Hollings, Ernest F. (D)       1-202-224-6121 1-202-224-4293
Sen. Thurmond, Strom (R)           1-202-224-5972 1-202-224-1300

Sanford, Mark (R-01)               1-202-225-3176 1-202-225-4340
Spence, Floyd (R-02)               1-202-225-2452 1-202-225-2455
Graham, Lindsey (R-03)             1-202-225-5301 1-202-225-5383
Inglis, Bob (R-04)                 1-202-225-6030 1-202-226-1177
Spratt Jr., John M. (D-05)         1-202-225-5501 1-202-225-0464
Clyburn, James E. (D-06)           1-202-225-3315 1-202-225-2302


SOUTH DAKOTA
Member                             Phone          Fax Number

Sen. Pressler, Larry (R)           1-202-224-5842 1-202-224-1630
Sen. Daschle, Thomas A. (D)        1-202-224-2321 1-202-224-2047

Johnson, Timothy P. (D-AL)         1-202-225-2801 1-202-225-2427


TENNESSEE
Member                             Phone          Fax Number

Sen. Thompson, Fred (R)            1-202-224-1036 1-202-228-3679
Sen. Frist, Bill (R)               1-202-224-3344 1-202-224-8062

Quillen, James H. (R-01)           1-202-225-6356 1-202-225-7812
Duncan Jr., John J. (R-02)         1-202-225-5435 1-202-225-6440
Wamp, Zach (R-03)                  1-202-225-3271 1-202-225-6974
Hilleary, Van (R-04)               1-202-225-6831 1-202-225-4520
Clement, Robert (D-05)             1-202-225-4311 1-202-226-1035
Gordon, Bart (D-06)                1-202-225-4231 1-202-225-6887
Bryant, Ed (R-07)                  1-202-225-2811 1-202-225-2814
Tanner, John S. (D-08)             1-202-225-4714 1-202-225-1765
Ford, Harold E. (D-09)             1-202-225-3265 1-202-225-9215


TEXAS
Member                             Phone          Fax Number

Sen. Hutchison, Kay Bailey (R)     1-202-224-5922 1-202-224-0776
Sen. Gramm, Phil (R)               1-202-224-2934 1-202-228-2856

Chapman, Jim (D-01)                1-202-225-3035 1-202-225-7265
Wilson, Charles (D-02)             1-202-225-2401 1-202-225-1764
Johnson, Sam (R-03)                1-202-225-4201 1-202-225-1485
Hall, Ralph M. (D-04)              1-202-225-6673 1-202-225-3332
Bryant, John (D-05)                1-202-225-2231 1-202-225-9721
Barton, Joseph (R-06)              1-202-225-2002 1-202-225-3052
Archer, William (R-07)             1-202-225-2571 1-202-225-4381
Fields, Jack (R-08)                1-202-225-4901 1-202-225-2772
Stockman, Steve (R-09)             1-202-225-6565 1-202-225-1584
Doggett, Lloyd (D-10)              1-202-225-4865 1-202-225-3018
Edwards, Chet (D-11)               1-202-225-6105 1-202-225-0350
Geren, Peter (D-12)                1-202-225-5071 1-202-225-2786
Thornberry, Williams (R-13)        1-202-225-3706 1-202-225-6142
Laughlin, Gregory H. (D-14)        1-202-225-2831 1-202-225-1108
de la Garza, E. Kika (D-15)        1-202-225-2531 1-202-225-2534
Coleman, Ronald D. (D-16)          1-202-225-4831
Stenholm, Charles W. (D-17)        1-202-225-6605 1-202-225-2234
Lee, Sheila (D-18)                 1-202-225-3816 1-202-225-6186
Combest, Larry (R-19)              1-202-225-4005 1-202-225-9615
Gonzalez, Henry B. (D-20)          1-202-225-3236 1-202-225-1915
Smith, Lamar S. (R-21)             1-202-225-4236 1-202-225-8628
DeLay, Thomas (R-22)               1-202-225-5951 1-202-225-5241
Bonilla, Henry (R-23)              1-202-225-4511 1-202-225-2237
Frost, Martin (D-24)               1-202-225-3605 1-202-225-4951
Bentsen, Ken (D-25)                1-202-255-7508 1-202-225-4210
Armey, Richard K. (R-26)           1-202-225-7772 1-202-225-7614
Ortiz, Solomon P. (D-27)           1-202-225-7742 1-202-226-1134
Tejeda, Frank (D-28)               1-202-225-1640 1-202-225-1641
Green, Gene (D-29)                 1-202-225-1688 1-202-225-9903
Johnson, Eddie Bernice (D-30)      1-202-225-8885 1-202-226-1477


UTAH
Member                             Phone          Fax Number

Sen. Hatch, Orrin G. (R)           1-202-224-5251 1-202-224-6331
Sen. Bennett, Robert (R)           1-202-224-5444 1-202-224-6717

Hansen, James V. (R-01)            1-202-225-0453 1-202-225-5857
Waldholtz, Enid (R-02)             1-202-225-3011 1-202-226-0354
Orton, William H. (D-03)           1-202-225-7751 1-202-226-1223


VIRGINIA
Member                             Phone          Fax Number

Sen. Robb, Charles S. (D)          1-202-224-4024 1-202-224-8689
Sen. Warner, John W. (R)           1-202-224-2023 1-202-224-6295

Bateman, Herbert H. (R-01)         1-202-225-4261 1-202-225-4382
Pickett, Owen B. (D-02)            1-202-225-4215 1-202-225-4218
Scott, Robert C. (D-03)            1-202-225-8351 1-202-225-3854
Sisisky, Norman (D-04)             1-202-225-6365 1-202-226-1170
Payne Jr., Lewis F. (D-05)         1-202-225-4711 1-202-226-1147
Goodlatte, Robert W. (R-06)        1-202-225-5431 1-202-225-9681
Bliley Jr., Thomas J. (R-07)       1-202-225-2815 1-202-225-0011
Moran Jr., James P. (D-08)         1-202-225-4376 1-202-225-0017
Boucher, Rick (D-09)               1-202-225-3861 1-202-225-0442
Wolf, Frank R. (R-10)              1-202-225-5136 1-202-225-0437
Davis III, Thomas (R-11)           1-202-225-1492 1-202-225-2274


VIRGIN ISLANDS
Member                             Phone          Fax Number

Del. de Lugo, Ron (D-AL)           1-202-225-1790 1-202-225-9392


VERMONT
Member                             Phone          Fax Number

Sen. Jeffords, James M. (R)        1-202-224-5141 1-202-224-8330
Sen. Leahy, Patrick J. (D)         1-202-224-4242 1-202-224-3595

Sanders, Bernard (I-AL)            1-202-225-4115 1-202-225-6790


WASHINGTON
Member                             Phone          Fax Number

Sen. Murray, Patty (D)             1-202-224-2621 1-202-224-0238
Sen. Gorton, Slade (R)             1-202-224-3441 1-202-224-9393

White, Rick (R-01)                 1-202-225-6311 1-202-225-2286
Metcalf, Jack (R-02)               1-202-225-2605 1-202-225-2608
Smith, Linda (R-03)                1-202-225-3536 1-202-225-9095
Hastings, Dee (R-04)               1-202-225-5816 1-202-226-1137
Nethercutt, George (R-05)          1-202-225-2006 1-202-225-7181
Dicks, Norman D. (D-06)            1-202-225-5916 1-202-226-1176
McDermott, James A. (D-07)         1-202-225-3106 1-202-225-9212
Dunn, Jennifer (R-08)              1-202-225-7761 1-202-225-8673
Tate, Randy (R-09)                 1-202-225-8901 1-202-226-2361


WISCONSIN
Member                             Phone          Fax Number

Sen. Kohl, Herbert H. (D)          1-202-224-5653 1-202-224-9787
Sen. Feingold, Russell (D)         1-202-224-5323 1-202-224-2725

Neumann, Mark (R-01)
Klug, Scott (R-02)                 1-202-225-2906 1-202-225-6942
Gunderson, Steve (D-03)            1-202-225-5506 1-202-225-6195
Kleczka, Gerald D. (D-04)          1-202-225-4572 1-202-225-8135
Barrett, Thomas M. (D-05)          1-202-225-3571 1-202-225-2185
Petri, Thomas E. (R-06)            1-202-225-2476 1-202-225-2356
Obey, David R. (D-07)              1-202-225-3365 1-202-225-0561
Roth, Toby (R-08)                  1-202-225-5665 1-202-225-0087
Sensenbrenner, F. James (R-09)     1-202-225-5101 1-202-225-3190


WEST VIRGINIA
Member                             Phone          Fax Number

Sen. Rockefeller, John D. (D)      1-202-224-6472 1-202-224-1689
Sen. Byrd, Robert C. (D)           1-202-224-3954 1-202-224-4025

Mollohan, Alan B. (D-01)           1-202-225-4172 1-202-225-7564
Wise Jr., Robert E. (D-02)         1-202-225-2711 1-202-225-7856
Rahall II, Nick Joe (D-03)         1-202-225-3452 1-202-225-9061


WYOMING
Member                             Phone          Fax Number

Sen. Simpson, Alan K. (R)          1-202-224-3424 1-202-224-1315
Sen. Thomas, Craig (R)             1-202-224-6441 1-202-224-3230

Cubin, Barbara (R-AL)              1-202-225-2311 1-202-225-0726





From rrothenb at ic.sunysb.edu  Wed Feb  8 01:46:56 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 8 Feb 95 01:46:56 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.SV4.3.91.950208011435.25409B-100000@mirage.skypoint.com>
Message-ID: <199502080946.EAA01638@libws2.ic.sunysb.edu>


> On Wed, 8 Feb 1995, L. McCarthy wrote:
> 
> > The battle over "obscenity" has been fought long and hard.
> > 
> > "Indecency" seems a remarkably nebulous term (and, of course, ludicrously
> > Victorian). I'd be interested in seeing a legal definition, and alarmed if
> > there isn't one (yet).
> 
> Last I heard, the Supreme Court had never made a ruling on this. They 
> copped out and left it up to "Community Standards." This is partially why 
> the AA bbs case was sucessfuly prosecuted in another state.

I beg to differ. Remember the "Seven Dirty Words Case"? (I think WBAI/Pacifica
v. US, year?...). WBAI-FM in NY played George Carlin's "Seven words you can't
say on television" skit and was taken to court. The court ruled that there
were some obscene things which could be censored, but other things were
indecent so could at most be relegated to late night hours (and they've
struck down laws banning indecency 24 hours... I think some stations are
suing with the claim that such relegation constitutes censorship).

Don't remember their exact formulation, which isn't very exact anyway.

> > Don't even get me started on the "nudity" portion. I'm sure Jesse Helms is
> > already licking his lips over this one.
> 
> Under the new legislation, might this not be illegal? ;)
> 
> On another note, I mailed Stanton McClandish to find out what EFF's 
> position is on this. I tried browsing their archives, but lots of stuff 
> seems to have vanished from there.

Perhaps it was deemed too indecent to be on an archive site. Hell, they
cooperated plenty with the government on this.

It's a sad day when you might expect AT&T to stand up for your rights more
than the EFF...

> 
> Sam

Just my opinions,
  Rob






From skaplin at mirage.skypoint.com  Wed Feb  8 02:03:07 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 02:03:07 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502080946.EAA01638@libws2.ic.sunysb.edu>
Message-ID: <Pine.SV4.3.91.950208035054.26559A-100000@mirage.skypoint.com>




On Wed, 8 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> > Last I heard, the Supreme Court had never made a ruling on this. They 
> > copped out and left it up to "Community Standards." This is partially why 
> > the AA bbs case was sucessfuly prosecuted in another state.
> 
> I beg to differ. Remember the "Seven Dirty Words Case"? (I think WBAI/Pacifica
> v. US, year?...). WBAI-FM in NY played George Carlin's "Seven words you can't
> say on television" skit and was taken to court. The court ruled that there
> were some obscene things which could be censored, but other things were
> indecent so could at most be relegated to late night hours (and they've
> struck down laws banning indecency 24 hours... I think some stations are
> suing with the claim that such relegation constitutes censorship).
> 
> Don't remember their exact formulation, which isn't very exact anyway.
> 

The question is: What is obsene? What the community in NYC considers 
obsene is sure a lot different than what the community in Elk River 
Minnesota considers obsene. (They've been trying to eject their one XXX 
bookstore for years now while NYC has the American Museum of Pornography 
at 42nd Street ;) ;) :) ) As you can see, obsenity depends where you are 
geographically located, at least according to our highest court. If 
community standards say it is obsene then it is. They never legally 
defined what constitutes something as being obsene or an obsenity.

Sam





From frissell at panix.com  Wed Feb  8 06:14:02 1995
From: frissell at panix.com (Duncan Frissell)
Date: Wed, 8 Feb 95 06:14:02 PST
Subject: Exon in WSJ
Message-ID: <199502081408.AA15271@panix.com>


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

Today's WSJ - Page B1 - Above the fold

Government Tackles a Surge of Smut on the Internet

"On-line computer services are bracing for a government crackdown against
smut on the Internet -- even though nobody's sure if the Net *can* be
regulated."


Accompanying article on how demand for porno overwhelms sites that try to
supply it.

DCF

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzjPtIVO4r4sgSPhAQF9IgP/Rv8haetVjaFqbd4j3QMSqAw7J219jej1
ZQTBujNlgFMb94TZSUy/X7oReAutJyaiWDvSyS7Nmnxx0xGAWMgR/8K9SlfJleia
Kja7H+cC7DODhGNMo3AUkn+shqKzz/idVZb3EiF1gtP3Xsm5DA5r9vqZyVZlFHxR
1IkGmN76Ax0=
=5UtC
-----END PGP SIGNATURE-----






From eric at remailer.net  Wed Feb  8 06:20:39 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 06:20:39 PST
Subject: a new way to do anonymity
In-Reply-To: <Chameleon.4.01.950207225342.jcorgan@comet.aeinet.com>
Message-ID: <199502081418.GAA23140@largo.remailer.net>


   From: Johnathan Corgan <jcorgan at aeinet.com>

   One of the lessons learned in the years-long debate between the
   telco folks pushing synchronous time-division multiplexing point to
   point circuit switches and the data folks pushing variable length
   packet-switched broadcast medium networks is that fixed length
   packets can give you both TDM and statistical multiplexing.

There's an important difference here.  Namely, the telco/ATM folks
were building hardware from scratch and we're not.  We're layering on
top of an existing Internet routing environment.

This doesn't mean that your point is wrong, but that it may no longer
be true when the base layer is IP.  I'm not familiar enough with the
ATM arguments to know whether they're still valid in this other
domain.

Eric





From daleh at ix.netcom.com  Wed Feb  8 06:37:28 1995
From: daleh at ix.netcom.com (Dale Harrison AEGIS)
Date: Wed, 8 Feb 95 06:37:28 PST
Subject: WSJ Article on Sen. Exon's Legislation
Message-ID: <199502081435.GAA06488@ix3.ix.netcom.com>


"Government Tackles a Surge of Smut on the Internet"
Wall Street Journal
Wednesday, February 8, 1995 
page B1

----------Begin Quote----------

  Instead, the services would prefer to be treated like phone companies, 
which claim no responsibility for telephone conversations. With millions 
of messages passing through each day, the services say couldn't possibly 
monitor everything even if they tried.
  Sen. Exon is unconvinced. "If I were against this <the legislation>, 
if I didn't want to be bothered with it, if I felt it might complicate 
my ability to make money on the superhighway, that's the argument I 
would make," he says, adding that a failure by the government to act 
would be "an open invitation to some of the hardcore pornography getting 
into our homes."

-----------End Quote-----------


Dale H.






From turcotte at io.com  Wed Feb  8 06:42:12 1995
From: turcotte at io.com (Brett Turcotte)
Date: Wed, 8 Feb 95 06:42:12 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <199502081442.IAA29984@pentagon.io.com>


On Feb. 8, Samuel Kaplin wrote:
> The question is: What is obsene? What the community in NYC considers 
> obsene is sure a lot different than what the community in Elk River 
> Minnesota considers obsene. (They've been trying to eject their one XXX 
> bookstore for years now while NYC has the American Museum of Pornography 
> at 42nd Street ;) ;) :) ) As you can see, obsenity depends where you are 
> geographically located, at least according to our highest court. If 
> community standards say it is obsene then it is. They never legally 
> defined what constitutes something as being obsene or an obsenity.
> 
> Sam
> 

And don't forget the recent case where the operators of a California 
bulletin board were prosecuted and convicted in court in 
Memphis....whereas they never would have been convicted under the 
community standards in California.  You want to talk about 
scary....there is a section in Robert Heinlein's "Job: A Comedy of 
Justice" where the protagonist describes some "moral" codes that they 
got passed...one of them was having the community standards of the 
median size community of the state apply to all communities in the 
state.   What's the betting out there that this is what would 
ultimately happen under these kinds of bills?





From eric at remailer.net  Wed Feb  8 06:59:37 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 06:59:37 PST
Subject: WSJ Article on Sen. Exon's Legislation
In-Reply-To: <199502081435.GAA06488@ix3.ix.netcom.com>
Message-ID: <199502081457.GAA23202@largo.remailer.net>


   he says, adding that a failure by the government to act 
   would be "an open invitation to some of the hardcore pornography getting 
   into our homes."

I don't know about the rest of you, but I'd rather have that ol'
hardcore pornography in the privacy of our homes, where it belongs,
than in public, where innocent children might gain access to it.

Eric





From perry at imsi.com  Wed Feb  8 07:15:51 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 8 Feb 95 07:15:51 PST
Subject: USPO & Digital Postage/E-Cash Project
In-Reply-To: <199502080625.WAA20933@ix3.ix.netcom.com>
Message-ID: <9502081514.AA09856@snark.imsi.com>



Dale Harrison (AEGIS) says:
> This would have been a digital replacement for the Pitney-Bose style
> Postage Metering machines.  To use a PM machine one has to take the
> entire machine physically to a Postal Station and purchase some
> fixed dollar amount of postage.  The Postal clerk unseals and
> unlocks the machine, dials in the amount of postage purchased and
> then relocks and reseals the machine.

This is not the only way to get postage in postage meters. Some P-B
machines also let you buy postage by phone.

Perry





From perry at imsi.com  Wed Feb  8 07:20:36 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 8 Feb 95 07:20:36 PST
Subject: MBONE access needed
Message-ID: <9502081520.AA05523@webster.imsi.com>


Hey, guys!

I need to get MBONE access in New York City or nearby this weekend in
order to deliver a presentation for the Cypherpunks meeting this
Saturday on IPSP. If anyone in New York can provide such access,
please get in touch with me ASAP; the site that I thought I could use
has sadly become unavailable...

Perry





From usenet at jeeves.niehs.nih.gov  Wed Feb  8 07:38:43 1995
From: usenet at jeeves.niehs.nih.gov (NIEHS Autoresponder)
Date: Wed, 8 Feb 95 07:38:43 PST
Subject: lwall
Message-ID: <9502081538.AA05136@jeeves.niehs.nih.gov>


Your Usenet test article was received here at the news gateway machine for
the National Institute of Environmental Health Sciences, in Research Triangle
Park, North Carolina, USA 35 47 N by 78 38 W.  The NIEHS newsadmins can 
be reached via e-mail at usenet at news.niehs.nih.gov.
Please note that we do not offer news access to sites outside of our 
organization.

If you're a newsadmin and you'd like to run your own autoresponder, this one
is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

Path: jeeves.niehs.nih.gov!darwin.sura.net!news.udel.edu!udel!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT

test
test





From Jaeson.M.Engle at josaiah.sewanee.edu  Wed Feb  8 08:02:11 1995
From: Jaeson.M.Engle at josaiah.sewanee.edu (Rhys Kyraden)
Date: Wed, 8 Feb 95 08:02:11 PST
Subject: Email Add's of Senators?
Message-ID: <v01510103ab5e8d499d2f@[152.97.12.101]>


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

        Anyone have a list of these? Do they exist? It would be very helpful if they do and someone has a list or a pointer to a list, as my campus is gearing up a petition signing campaign against this S.314.
Thanks in advance,
- -Jaeson
-----BEGIN PGP SIGNATURE-----
Version: 2.6ui

iQCVAgUBLzjdKObIUsJnAZfNAQEknwQA1malQkHdtMdX5okXYd2W/nY29gWr+ICM
cflNswC7ABV3wtmkMEACxP1geLXHI7zyqRWF3h6z23eqeOycYVZTfNKwDD8DykW0
fV+kru2dMuhhRihvTmH6ztdF9QCfB4LIAN38+GP0H0NFkRgZUs8dIXcHJh//pSec
F5bt7iDjwXw=
=vjyH
-----END PGP SIGNATURE-----

_____________________________________                  
{-: Jaeson M. Engle    ||    jme at josaiah.sewanee.edu :-}
{-:      www server: http://josaiah.sewanee.edu/         :-}
{-: Finger 'jme at josaiah.sewanee.edu' for my Public :-}
                                        PGP block.







From haeberli at apple.com  Wed Feb  8 08:06:08 1995
From: haeberli at apple.com (Martin Haeberli)
Date: Wed, 8 Feb 95 08:06:08 PST
Subject: USPO & Digital Postage/E-Cash Project
Message-ID: <v02110101ab5e954ccb48@[198.68.90.31]>


Dale,

I would appreciate any citations you can offer which:
-Describe the proposed system in some detail
-Describe the weaknesses identified by the CMU team.

Also, this group might want to know that CMU has (perhaps independently)
done work in this area over two years ago.  It may well be that the team at
CMU which did the USPO contract research is the same team that proposed
digital postage in a research paper in that time frame, and it may well be
that their system would withstand a much more rigorous attack.  I'm afraid
I've lost the precise citation, but I found the report browsing the CMU
tech reports server about 18 months ago.

Martin

At 10:25 PM 02/07/95, Dale Harrison (AEGIS wrote:
>The US Post Office just killed a project that would have created a
>digital postage/e-cash system.  This would have been a digital
>replacement for the Pitney-Bose style Postage Metering machines.  To use
>a PM machine one has to take the entire machine physically to a Postal
>Station and purchase some fixed dollar amount of postage.  The Postal
>clerk unseals and unlocks the machine, dials in the amount of postage
>purchased and then relocks and reseals the machine.
>
>This mechanical system would have been replaced by a serial-port dongle
>and a piece of software.  The dongle would contain an EEPROM in a
>replacable button (made by Dallas Semiconductor) into which would be
>loaded data indicating the amount of postage that had been purchased and
>not yet used.  The software package would be able to print the address,
>postage seal, routing codes, etc directly on the envelope via a laser
>printer and decrement the amount of available postage left in the
>dongle.  In the original test, customers would have to take the dongle
>to a Postal Station to purchase additional postage, but the ultimate
>goal was to have been to have a commerical dial-up service available
>that one could dial into and purchase additional postage directly.
>
>A proof-of-concept prototype was developed in VB and a production
>prototype was then developed in VC++.  Unfortunately the crypto wasn't
>very strong.  The USPO contracted with Carnege-Mellon to try and break
>the system and they were able to within a couple of weeks.  USPO then
>killed the project.
>
>
>Dale H.







From rrothenb at ic.sunysb.edu  Wed Feb  8 09:03:00 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Wed, 8 Feb 95 09:03:00 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.SV4.3.91.950208035054.26559A-100000@mirage.skypoint.com>
Message-ID: <199502081702.MAA06532@libws3.ic.sunysb.edu>


> > I beg to differ. Remember the "Seven Dirty Words Case"? (I think WBAI/Pacifica
> > v. US, year?...). WBAI-FM in NY played George Carlin's "Seven words you can't
> > say on television" skit and was taken to court. The court ruled that there
> > were some obscene things which could be censored, but other things were
> > indecent so could at most be relegated to late night hours (and they've
> > struck down laws banning indecency 24 hours... I think some stations are
> > suing with the claim that such relegation constitutes censorship).
> > 
> > Don't remember their exact formulation, which isn't very exact anyway.
> > 
> 
> The question is: What is obsene? What the community in NYC considers 
> obsene is sure a lot different than what the community in Elk River 
> Minnesota considers obsene. (They've been trying to eject their one XXX 
> bookstore for years now while NYC has the American Museum of Pornography 
> at 42nd Street ;) ;) :) ) As you can see, obsenity depends where you are 
> geographically located, at least according to our highest court. If 
> community standards say it is obsene then it is. They never legally 
> defined what constitutes something as being obsene or an obsenity.

The definition is not entirely up to "community standards". I think the
court definied it loosely as 'material regarding sexual and excretory
functions' which appeals to "prurient interests".

Anyhw, they have enough of a national "standard" for the FCC to crack
down on broadcasters who breach the rules.

Of course geographic community standards are problematic too with
telecommunications since postal inspectors from Tennessee can call
up adult bulletin boards in California...

> 
> Sam
> 

Rob






From system at decode.com  Wed Feb  8 09:08:22 1995
From: system at decode.com (System Operator)
Date: Wed, 8 Feb 95 09:08:22 PST
Subject: Seals and Sealing Waxes
Message-ID: <umN8Zc1w165w@decode.com>


chen at intuit.com (Mark Chen) writes:

> with the requisite proclivities).  I only have a hardcopy, though if
> enough people are interested, I might be persuaded to scan some of it
> in.

This appears to be an appropriate point for me to extend an offer
to scan any cypherpunk material for this list and/or achives that may
be appropriate. I have a Hewlett-Packard ScanJet IIcx with the
Automatic Document Feeder attachment, and Caere's OmniPro OCR software,
as well as Microsoft Office and WordPerfect 6.0.


Dan
dan at decode.com

--
system at decode.com (System Operator)
Cryptography, Security, Privacy BBS  +1 410 730 6734   Data/FAX





From nsb at nsb.fv.com  Wed Feb  8 09:20:11 1995
From: nsb at nsb.fv.com (Nathaniel Borenstein)
Date: Wed, 8 Feb 95 09:20:11 PST
Subject: MIME based remailing commands
In-Reply-To: <23676.792177411.1@nsb.fv.com>
Message-ID: <ojCAH3b0Eyt5QxSaNd@nsb.fv.com>


Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co..
"Perry E. Metzger"@imsi. (2553)

> > > It is being remailed via a MIME-based structure where two new content types
> > > are defined: multipart/remail and application/remail-commands.  The
> > > multipart/remail type is supposed to be composed of two parts, the
> > > application/remail-commands part which has remailer commands, and the
> > > other part which is the "payload" to be remailed.

Perhaps you might consider writing up an informational RFC to define
these types?  I think that would be very useful. -- Nathaniel





From rishab at dxm.ernet.in  Wed Feb  8 09:39:16 1995
From: rishab at dxm.ernet.in (Rishab Aiyer Ghosh)
Date: Wed, 8 Feb 95 09:39:16 PST
Subject: Selection key crypto protocol trial balloon
In-Reply-To: <9502070328.AA13539@anchor.ho.att.com>
Message-ID: <J84c2c4w165w@dxm.ernet.in>


wcs at anchor.ho.att.com writes:

> I'm not sure I really believe it's workable, but what it does
> sound a bit like is CDMA spread-spectrum, which lets a bunch of

Um no. The main thing is that what is extracted with the selection key is
_different_ from what was put in...


-----------------------------------------------------------------------------
Rishab Aiyer Ghosh                                "In between the breaths is
rishab at dxm.ernet.in                                  the space where we live"
rishab at arbornet.org                                        - Lawrence Durrell
Voice/Fax/Data +91 11 6853410  
Voicemail +91 11 3760335                 H 34C Saket, New Delhi 110017, INDIA  






From strick at techwood.org  Wed Feb  8 10:52:26 1995
From: strick at techwood.org (strick at techwood.org)
Date: Wed, 8 Feb 95 10:52:26 PST
Subject: skronk
In-Reply-To: <9502080951.ZM27700@warp.mcom.com>
Message-ID: <199502081852.KAA01719@gwarn.versant.com>


THUS SPAKE "Kipp E.B. Hickman" <kipp at warp.mcom.com>:
# FYI:
# 
# If you haven't already, I suggest you take a look at the SSL spec
# (http://home.mcom.com/info/SSL.html)

[ carbon to cypherpunks, whom i think would be interested]

i've been looking at that.  

It seems that a special port has to be allocated for each TCP service.
So it's not clear to me how to find out if others on the net offer SMTP
with SSL, or how I can put SSL into my X11 clients & server.  You see
what I'm getting at?

It also looks like some heavy equipment is necessary to manage these
RSA certficiates.  Is there anything like PGP's keyring management for
manipulating my web-of-trust?  Where do I find the docs?

# It does what you are trying to accomplish (I think), and it is already deployed
# in production code (the Netscape client and server products). In addition, we
# announced this week a free (for non-commerical use) reference implementation.
# The code will be out on the net as soon as the lawyers are happy :-)

aha ... that's the missing link.  I'd certainly like to add it to the
protocols that SKRONK advertizes and negotiates, but doing my own
implementation of these complex protocols, and building machinery for
using non-PGP certificates, was way more than I could handle.

Please beat your lawyers to a pulp, until they make it useful for us.
If I can't create generally useful things with it, and share it with
thousands of others on the net for free, it's not going to be used by
the cypherpunk community.

I recommend you put your reference implementation in the public domain
(except for the RSAREF component).  Or take Matt Blaze's crypto
offerings from AT&T as your model.  


		best regards, strick








From strick at techwood.org  Wed Feb  8 11:02:25 1995
From: strick at techwood.org (strick at techwood.org)
Date: Wed, 8 Feb 95 11:02:25 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502081702.MAA06532@libws3.ic.sunysb.edu>
Message-ID: <199502081902.LAA01787@gwarn.versant.com>


# > > I beg to differ. Remember the "Seven Dirty Words Case"? (I think WBAI/Pacifica
# > > v. US, year?...). WBAI-FM in NY played George Carlin's "Seven words you can't

individual words can be "indecent", but not obscene.

obscene refers to the content of the work as a whole, and would
be very difficult to attain with a few dirty words.

# > > say on television" skit and was taken to court. The court ruled that there
# > > were some obscene things which could be censored, but other things were

All obscene things are censored on broadcast radio & TV.  
Massive penalties for broadcasting obscene material.

# > > indecent so could at most be relegated to late night hours (and they've
# > > struck down laws banning indecency 24 hours... I think some stations are
# > > suing with the claim that such relegation constitutes censorship).

In the U. S., you have a first ammendment right to indencent speech.

The question of a late-night "safe harbor" for indecent speech on the
air is about when children are likely to be listening.  First
ammendment rights apparently don't apply to children who are listening
to the radio.  

Right now there is a "safe harbor" from around 10pm (or is it 9pm?)
thru 6am, but this changes regularly, usually as a result of "case law"
(someone being prosecuted under next month's rules, not this month's)

				strick







From slowdog at wookie.net  Wed Feb  8 11:25:17 1995
From: slowdog at wookie.net (slowdog)
Date: Wed, 8 Feb 95 11:25:17 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <9502072138.aa29510@hermix.markv.com>
Message-ID: <Pine.LNX.3.91.950208142556.7197B-100000@chewy.wookie.net>


On Tue, 7 Feb 1995 jpp at markv.com wrote:

> Uh oh!  Egg on my face.  Will someone explain to me how the amendments
> in S.314 make owners of ISPs or other computer systems liable for
> 'bad' data?  I apologize for my previous uncalled for (so it seams to
> me now) ranting.

Sure, read on:

>    (a) Prohibited acts generally
>    
>    Whoever -
>    
>    (1) in the District of Columbia or in interstate or foreign
>    communication by means of [telephone] telecommunications
>    device -
>    
>    (A) [makes any comment, request, suggestion or proposal] 
>    makes, transmits, or otherwise makes available any comment,
>    request, suggestions, proposal, image, or other communication]
>    which is obscene, lewd, lascivious, filthy, or indecent;

Here's an important bit. "Transmits or otherwise makes available" is 
different from the earlier law. It DOES pleace a burden of responsibility 
upon the provider of service. NOTE that unlike other portions of the law, 
boths old and new versions, this part DOES NOT include the word 
"knowingly". Crucial, crucial point.

>    (B) [makes a telephone call, whether or not conversation
>    ensues, without disclosing his identity and with intent to
>    annoy, abuse, threaten, or harass any person at the called
>    number] makes a telephone call or utilizes a telecommunications
>    device, whether or not conversation or communications ensues,
>    without disclosing his identity with intent to annoy, abuse,
>    threaten, or harass any person at the called number or who
>    receives the communication;

No anonymous annoying! Does this mean we can't raid IRC channels anymore? 
Or flame people from anon.petit.fi (sp?) accounts?



- dog







From slowdog at wookie.net  Wed Feb  8 11:28:49 1995
From: slowdog at wookie.net (slowdog)
Date: Wed, 8 Feb 95 11:28:49 PST
Subject: Full text of S. 314
In-Reply-To: <Pine.SV4.3.91.950208022428.26104C@mirage.skypoint.com>
Message-ID: <Pine.LNX.3.91.950208142947.7197C-100000@chewy.wookie.net>


On Wed, 8 Feb 1995, Samuel Kaplin wrote:

> I would suggest that everyone forward this to their ISP. It has a direct 
> bearing on them and most won't be aware of it.

This is exactly what I did here in NYC.


- dog







From kipp at warp.mcom.com  Wed Feb  8 11:37:44 1995
From: kipp at warp.mcom.com (Kipp E.B. Hickman)
Date: Wed, 8 Feb 95 11:37:44 PST
Subject: skronk
In-Reply-To: <199502081852.KAA01719@gwarn.versant.com>
Message-ID: <9502081137.ZM28317@warp.mcom.com>


On Feb 8, 10:52am, strick at techwood.org wrote:
> Subject: Re: skronk
> THUS SPAKE "Kipp E.B. Hickman" <kipp at warp.mcom.com>:
> # FYI:
> #
> # If you haven't already, I suggest you take a look at the SSL spec
> # (http://home.mcom.com/info/SSL.html)
>
> [ carbon to cypherpunks, whom i think would be interested]
>
> i've been looking at that.

good!

> It seems that a special port has to be allocated for each TCP service.
> So it's not clear to me how to find out if others on the net offer SMTP
> with SSL, or how I can put SSL into my X11 clients & server.  You see
> what I'm getting at?

It turns out you want seperate ports for each ssl-ized service because that way
the sysadmin types and the firewall guards are happy. They hate multiplexed
protocols because the standard off the shelf router equipment can't deal with
it.

> It also looks like some heavy equipment is necessary to manage these
> RSA certficiates.  Is there anything like PGP's keyring management for
> manipulating my web-of-trust?  Where do I find the docs?

You are right here. However, our observation is that an interesting chunk of
the world is moving towards using X.509 based certificate infrastructures for
many things. Everybody wants digital signatures and the related capabilities.
For more info, feel free to wade into the X.500 specs (not recommended for the
timid or weak of stomach :-), or go poke around on www.rsa.com and look into
their pkcs specs.

> # It does what you are trying to accomplish (I think), and it is already
deployed
> # in production code (the Netscape client and server products). In addition,
we
> # announced this week a free (for non-commerical use) reference
implementation.
> # The code will be out on the net as soon as the lawyers are happy :-)
>
> aha ... that's the missing link.  I'd certainly like to add it to the
> protocols that SKRONK advertizes and negotiates, but doing my own
> implementation of these complex protocols, and building machinery for
> using non-PGP certificates, was way more than I could handle.
>
> Please beat your lawyers to a pulp, until they make it useful for us.
> If I can't create generally useful things with it, and share it with
> thousands of others on the net for free, it's not going to be used by
> the cypherpunk community.
>
> I recommend you put your reference implementation in the public domain
> (except for the RSAREF component).  Or take Matt Blaze's crypto
> offerings from AT&T as your model.

The implementation will be out very shortly (it's already done and working). It
will be free for non-commerical usage, so hopefully most of the cypherpunks
will be happy (if there is such a state of affairs mind you :^)

We won't be having any of the copy-leftish stuff that is in the RSAREF license
- like not fiddling with the api, and having to give us back your hacks using
it...Of course we want to hear about what people are doing with it (thats
another purpose for the ssl-talk mailing list).


-- 
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp at netscape.com          http://home.mcom.com/people/kipp/index.html






From perry at imsi.com  Wed Feb  8 11:48:24 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 8 Feb 95 11:48:24 PST
Subject: skronk
In-Reply-To: <9502081137.ZM28317@warp.mcom.com>
Message-ID: <9502081947.AA10312@snark.imsi.com>



I agree with much of what you say until you hit this:

"Kipp E.B. Hickman" says:
> You are right here. However, our observation is that an interesting chunk of
> the world is moving towards using X.509 based certificate infrastructures for
> many things.

Like who? Certainly not the internet standards people, no matter what
certain people might tell you. The X.509 body may still be twitching
but I don't think its heart is beating any longer.

Perry





From adam at bwh.harvard.edu  Wed Feb  8 11:55:34 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Wed, 8 Feb 95 11:55:34 PST
Subject: skronk
In-Reply-To: <9502081137.ZM28317@warp.mcom.com>
Message-ID: <199502081954.OAA22660@bwface.bwh.harvard.edu>


	Will there be a commercially licensed version, so that things
built on SSL can be used in freeware and payware?  (Like the recently
announced commercial version of RSAREF)

	Actually, make that "When will there be.." since otherwise SSL
will be yet another standard one company uses.  Such standards are
less than useful.

Adam


Kipp wrote:

| > Please beat your lawyers to a pulp, until they make it useful for us.
| > If I can't create generally useful things with it, and share it with
| > thousands of others on the net for free, it's not going to be used by
| > the cypherpunk community.
| >
| > I recommend you put your reference implementation in the public domain
| > (except for the RSAREF component).  Or take Matt Blaze's crypto
| > offerings from AT&T as your model.
| 
| The implementation will be out very shortly (it's already done and working). It
| will be free for non-commerical usage, so hopefully most of the cypherpunks
| will be happy (if there is such a state of affairs mind you :^)
| 
| We won't be having any of the copy-leftish stuff that is in the
| RSAREF license - like not fiddling with the api, and having to give
| us back your hacks using it...Of course we want to hear about what
| people are doing with it (thats another purpose for the ssl-talk
| mailing list). 


-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From jamesd at netcom.com  Wed Feb  8 12:02:56 1995
From: jamesd at netcom.com (James A. Donald)
Date: Wed, 8 Feb 95 12:02:56 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <g53ElKjqRy8I078yn@mirage.skypoint.com>
Message-ID: <Pine.3.89.9502081135.A7848-0100000@netcom10>


On Tue, 7 Feb 1995, Samuel Kaplin wrote:
> I find it amazing that CPR and EFF 
> haven't picked this up yet.

Really?
 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From cactus at seabsd.hks.net  Wed Feb  8 12:09:54 1995
From: cactus at seabsd.hks.net (Todd Masco)
Date: Wed, 8 Feb 95 12:09:54 PST
Subject: skronk
In-Reply-To: <9502081137.ZM28317@warp.mcom.com>
Message-ID: <199502082006.PAA21801@bb.hks.net>


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

In article <9502081137.ZM28317 at warp.mcom.com>,
Kipp E.B. Hickman <kipp at warp.mcom.com> wrote:
>You are right here. However, our observation is that an interesting chunk of
>the world is moving towards using X.509 based certificate infrastructures for
>many things. 

AFAIK, the only interesting chunk is those corps that want some form of
"True Name" (and PKP/RSADSI, of course).

Everybody else hates them with a passion.  The Hastur crypto toolkit will
support them, but they'll be viewed as special cases of web-of-trust
signed keys with time-outs.
- --
Todd Masco     | "Change is not only necessary, it is inevitable."
cactus at hks.net |                          - Frank Zappa
     Cactus' Homepage
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzkkGCoZzwIn1bdtAQE6BAF+LLnnx8PG3kIHOmK7kcXoKEThYeXtZgG2
Ke9yqab4kXHMyMSlAPT94P1eicQvhWDJ
=BC1t
-----END PGP SIGNATURE-----





From kkirksey at world.std.com  Wed Feb  8 12:12:35 1995
From: kkirksey at world.std.com (Ken Kirksey)
Date: Wed, 8 Feb 95 12:12:35 PST
Subject: Four Horsemen
Message-ID: <199502082012.AA18319@world.std.com>


Message-Id: <v01510101ab5ecb0e67cd at DialupEudora>

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

Just a quick question:  someone asked me the other day what the "Four
Horsemen of the Infocalypse" were, and I told him

  1) Drug Dealers
  2) Terrorists
  3) Pedophiles
  4) Pornographers

Did I get it right, or did I have a synaptic misfire somewhere along
the line?

Ken

= Ken Kirksey            And the Clinton administration launched an attack on =
= kkirksey at world.std.com  people in Texas because those people were religious =
= Mac Guru & Developer    nuts with guns.  Hell, this country was founded by  =
=                         religious nuts with guns.           - P.J. O'Rourke =

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzkbhOsZNYlu+zuBAQHVigQAzkp3fIlEfT82zSaRZPkIqkkaDJ5MNyRK
SOOq0QwAMB1/bGNGda0plC+aNGT1RnSpNJTS/8ISIJTDCwbmJGFYGxvRSgqyUkXO
dQrd6pLbYIxH1sTPIaAoM4BnmUhYzr5L4TauPgqTLYhqGKDa8RWbHggjLyTr/UfF
drRgBOM919Q=
=OcUi
-----END PGP SIGNATURE-----





From kkirksey at world.std.com  Wed Feb  8 12:12:36 1995
From: kkirksey at world.std.com (Ken Kirksey)
Date: Wed, 8 Feb 95 12:12:36 PST
Subject: Jefferson Wheel Cypher
Message-ID: <199502082012.AA18336@world.std.com>


Message-Id: <v01510103ab5ed2c136c8 at DialupEudora>

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

A couple of questions regarding Thomas Jefferson's Wheel Ciphyer:

1) How would you classify this cipher?  It looks to me like a polyalphabetic
   with the plaintext also being the key, kind of like an autokey.  Am 
   I correct, or is this cipher a different animal entirely?

2) Can anyone point me to references on the cryptanalysis of this cipher?
   
Many thanks in advance,

Ken

= Ken Kirksey            And the Clinton administration launched an attack on =
= kkirksey at world.std.com  people in Texas because those people were religious =
= Mac Guru & Developer    nuts with guns.  Hell, this country was founded by  =
=                         religious nuts with guns.           - P.J. O'Rourke =

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzkjt+sZNYlu+zuBAQEwPgP/XMWm/qDr1A0D49iBJdYNOX18j3DNbBvG
xTOvSrzNziq9jq4026+TNpM3+PVGiji85yL3053jG26I0dJbckkVFr1PBfXmLrua
nHBt5t/qy7RSvjsW80ZreeqVKwulo3NtT+XuWjU7EXZDSPUZts4JuHnGdlqQRiMo
1ERDP4+StM0=
=PcEo
-----END PGP SIGNATURE-----





From kkirksey at world.std.com  Wed Feb  8 12:12:41 1995
From: kkirksey at world.std.com (Ken Kirksey)
Date: Wed, 8 Feb 95 12:12:41 PST
Subject: Seals and Sealing Waxes
Message-ID: <199502082012.AA18329@world.std.com>


Message-Id: <v01510102ab5ecd95ffb0 at DialupEudora>

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

> "All crypto is economics," and this is what made seals and sealing wax so
> useful for so long. Saying "seals were duplicatable from the start" does
> not mean this feat was easy, even if technically possible.
> 
> In fact, the fine details produced by a good seal are hard to exactly
> emulate with a copy. Even on a two-dimensional surface. And with the advent
> of three-dimensional surfaces, which sealing wax made possible, the fine
> detail of a good seal was in fact very hard to forge.

But not impossible.  According to Kahn, the Austrian Black Chamber was
quite adept at forging seals in the late 1600's / early 1700's.  They
were able to take sealed correspondence in at 7 a.m., unseal it, copy the
message, re-seal it, and have it back in the postal stream by early
afternoon.  There was only one recorded case of them re-sealing a message
with the wrong seal, and that was because the seals were so similar.

All this is from memory, since I don't have my copy of _The Codebreakers_
here at work, so I may be off in some details.

Ken

= Ken Kirksey            And the Clinton administration launched an attack on =
= kkirksey at world.std.com  people in Texas because those people were religious =
= Mac Guru & Developer    nuts with guns.  Hell, this country was founded by  =
=                         religious nuts with guns.           - P.J. O'Rourke =

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzkeVusZNYlu+zuBAQG5HgP+LuE0aOG6UxgZp/IrZCm2y9ESi9AT13v+
ePMulQHUXUv8cc4m0RTjD35+cmKSKADrP6L1oC6BCia+5d3Rhidh2KcqaoQZQLvc
rSuXbPgUpM7VJBOELtxc68CLJTpyaHBHvORJ//xH+/kN/++2f110+hZMwvgynrRd
Pj54hvqthKA=
=Jhff
-----END PGP SIGNATURE-----





From jamesd at netcom.com  Wed Feb  8 12:25:23 1995
From: jamesd at netcom.com (James A. Donald)
Date: Wed, 8 Feb 95 12:25:23 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <9502072138.aa29510@hermix.markv.com>
Message-ID: <Pine.3.89.9502081213.A7848-0100000@netcom10>


On Tue, 7 Feb 1995 jpp at markv.com wrote:
 
> Uh oh!  Egg on my face.  Will someone explain to me how the amendments
> in S.314 make owners of ISPs or other computer systems liable for
> 'bad' data?  I apologize for my previous uncalled for (so it seams to
> me now) ranting.


 (A) by striking out `telephone' in the matter above
        subparagraph (A) and inserting `telecommunications device'; 
 (B) by striking out `makes any comment, request,
        suggestion, or proposal' in subparagraph (A) and inserting
        `makes, transmits, or otherwise makes available any comment, request,
                ^^^^^^^^^^
         suggestion, proposal, image, or other communication'; 

This appears to make ISP's responsible for content.

It makes them responsible for something that they cannot 
control without violating people privacy.

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From hfinney at shell.portal.com  Wed Feb  8 12:25:47 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 8 Feb 95 12:25:47 PST
Subject: skronk
In-Reply-To: <199502081852.KAA01719@gwarn.versant.com>
Message-ID: <199502082025.MAA00565@jobe.shell.portal.com>


>THUS SPAKE "Kipp E.B. Hickman" <kipp at warp.mcom.com>:
># It does what you are trying to accomplish (I think), and it is already deployed
># in production code (the Netscape client and server products). In addition, we
># announced this week a free (for non-commerical use) reference implementation.
># The code will be out on the net as soon as the lawyers are happy :-)

When we last left this story, only certificates from a few (one?)
signatory authorities were going to be accepted by Netscape clients.
Would this mean that competitors offering Netscape servers would have to
go to Netscape to get their keys signed in order to interoperate with
existing Netscape clients?  I think this is too limiting.

People should be able to choose their own key signers.  This should be a
configuration option.  It should not be compiled into the client!  That
hurts your own flexibility as well as interfering with interoperatbiliy.

Can I use this reference implementation and set up a SSL-compatible
service today, or do I have to go to you and/or everyone's friends at RSA
and get a signature first?  As long as it is the latter I think that SSL
is not going to be able to be a well-established standard.  People are
going to resent having to register with the authorities in order to set
up a secure web page.

Hal Finney
hfinney at shell.portal.com





From hfinney at shell.portal.com  Wed Feb  8 12:38:30 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 8 Feb 95 12:38:30 PST
Subject: MIME based remailing commands
In-Reply-To: <23676.792177411.1@nsb.fv.com>
Message-ID: <199502082037.MAA02640@jobe.shell.portal.com>


Nathaniel Borenstein <nsb at nsb.fv.com> writes:

>Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co..
>"Perry E. Metzger"@imsi. (2553)

>> > > It is being remailed via a MIME-based structure where two new content types
>> > > are defined: multipart/remail and application/remail-commands.  The
>> > > multipart/remail type is supposed to be composed of two parts, the
>> > > application/remail-commands part which has remailer commands, and the
>> > > other part which is the "payload" to be remailed.

>Perhaps you might consider writing up an informational RFC to define
>these types?  I think that would be very useful. -- Nathaniel

Well, that was just an example; I was making those names up off the top
of my head in order to concretize what I understood Perry was suggesting.

I can see that putting remailer commands into a specific part of a MIME
multipart message has some advantages.  Right now we are basically
having the remailing commands be mail header fields.  But really people
aren't supposed to just make up new fields like that.  I think the
"name space" of these fields is protected somewhat more than many other
aspects of communication protocols on the net.  Is there precedent for
adding service-by-mail functionality in this way?  I am not completely
comfortable with it.  And as we think of new functionality and new
commands they all have to get added at this top level, the same
visibility and name space as "Subject", "From", and "To".

OTOH it does have the advantage that it is easy to do, at least with the
"::" pasting token idea (which perhaps would need to be documented in its
own right).

If we did use a separate message part we'd have our own little name space
to use, with no fears of conflicting with someone else.  (Maybe "Latency"
might be used in a future extension of RFC822 for some other meaning than
what we are using it for.)  I am not sure what has to be done to get an
RFC approved but I suspect that adding mail header fields would be much
more likely to hit opposition than adding yet another MIME type.

What does Mixmaster use for its commands?  Does it use "::" followed by
Anon-Send-To: and such?  Or some other format?  Maybe it should be made
MIME compliant from the beginning.  This way we are moving with the
current, the flow of the net, rather than across it.

Hal





From caj at tower.techwood.org  Wed Feb  8 12:44:14 1995
From: caj at tower.techwood.org (Craig A. Johnston)
Date: Wed, 8 Feb 95 12:44:14 PST
Subject: Judges-L FAQ
Message-ID: <199502082043.MAA21652@tower.techwood.org>



It has come to my attention that the Judges-L FAQ is being distributed
by someone who obtained it on this list, and being sent to people made
to look as if it has issued from David Stodolsky.  

I must inform you that this FAQ is copyrighted material, and 
you are requested not to distribute it. 


-Craig





From hfinney at shell.portal.com  Wed Feb  8 12:46:20 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 8 Feb 95 12:46:20 PST
Subject: Selection key crypto protocol trial balloon
In-Reply-To: <J84c2c4w165w@dxm.ernet.in>
Message-ID: <199502082045.MAA03683@jobe.shell.portal.com>


rishab at dxm.ernet.in (Rishab Aiyer Ghosh) writes:

>wcs at anchor.ho.att.com writes:

>> I'm not sure I really believe it's workable, but what it does
>> sound a bit like is CDMA spread-spectrum, which lets a bunch of

>Um no. The main thing is that what is extracted with the selection key is
>_different_ from what was put in...

Let me get straight where we are.  Rishab's concrete proposal was not an
implementation, but rather a set of requirements.  There was no
suggestion about any specific algorithms that would meet those
requirements, right?  The question is whether any such algorithm could
exist.

It is hard for me to see how this could possibly work.  The message
receiver sends this "selection key" to the intermediary, and that somehow
pulls out the saved message, but in a form such that the intermediary
doesn't recognize it.  And the intermediary himself can't tell exactly
which message is produced.  But it is nevertheless exactly the message
which was meant for this particular receiver.

The thing is, the receiver does not have much more information than the
intermediary.  At best he knows a secret key which may help decrypt the
message in some way.  But I don't see how that can be used to pull out
the message data since it can't be revealed to the intermediary.

I can't really prove that this is impossible, but it certainly looks that
way.

Hal





From kipp at warp.mcom.com  Wed Feb  8 13:09:44 1995
From: kipp at warp.mcom.com (Kipp E.B. Hickman)
Date: Wed, 8 Feb 95 13:09:44 PST
Subject: skronk
In-Reply-To: <199502081954.OAA22660@bwface.bwh.harvard.edu>
Message-ID: <9502081309.ZM28575@warp.mcom.com>


On Feb 8,  2:54pm, Adam Shostack wrote:
> Subject: Re: skronk
> 	Will there be a commercially licensed version, so that things
> built on SSL can be used in freeware and payware?  (Like the recently
> announced commercial version of RSAREF)
>
> 	Actually, make that "When will there be.." since otherwise SSL
> will be yet another standard one company uses.  Such standards are
> less than useful.

Yes, there will be. We haven't formalized it yet, but we have been getting
enough interest to warrant it. Understand that this is not the main thrust of
our business (selling source code), so it will certainly take some time to put
it all together.


-- 
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp at netscape.com          http://home.mcom.com/people/kipp/index.html






From adam at bwh.harvard.edu  Wed Feb  8 13:31:05 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Wed, 8 Feb 95 13:31:05 PST
Subject: Wiretaps & terrorism
Message-ID: <199502082130.QAA23309@bwface.bwh.harvard.edu>



	(Why the FBI doesn't really need wiretaps)
	(Part of a continuing series)

>From todays (Feb 8) Boston Globe, page 3 
by Larry Neumeister, AP

	New York- the FBI was on the trail of three of the World Trade
Center bombers nearly four years before teh explosion that killed six
and injured 1,000, the government said yesterday.

	In evidence presented at the trial of Sheik Omar Abdel-Rahman
and 10 others, the FBI also said it had bugged the Sheik's phone a
week before the blast.

	The surprising testimony - a day ater a key defendant switched
sides - indicated that the government had more extensive knowledge of
the planning for the trade center bombing than it had acknowledged.
And it reaised anew questions about why the FBI was unable to prevent
the 1993 bombing, one of the most serious terrorist actions in the
United States.

	...





From perry at imsi.com  Wed Feb  8 13:38:00 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 8 Feb 95 13:38:00 PST
Subject: Judges-L FAQ
In-Reply-To: <199502082043.MAA21652@tower.techwood.org>
Message-ID: <9502082137.AA10512@snark.imsi.com>



"Craig A. Johnston" says:
> 
> It has come to my attention that the Judges-L FAQ is being distributed
> by someone who obtained it on this list, and being sent to people made
> to look as if it has issued from David Stodolsky.  
> 
> I must inform you that this FAQ is copyrighted material, and 
> you are requested not to distribute it. 

If the material is not actually registered with the copyright office,
I'll point out that at most you can get the distribution stopped, but
cannot get damages for the distribution. Unless you actually intend to
spend substantial sums on lawyers, you are unlikely to be able to do
even this much.

Perry





From usenet at news.efn.org  Wed Feb  8 13:42:02 1995
From: usenet at news.efn.org (EFN Autoresponder)
Date: Wed, 8 Feb 95 13:42:02 PST
Subject: lwall
Message-ID: <9502082141.AA28209@mars.efn.org.efn.org>


DO NOT PANIC!  REMAIN CALM!  READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET!

Your Usenet test article was received here at the news gateway machine 
for Oregon Public Networking, located in Eugene, Oregon, USA.
The OPN newsadmins can be reached via e-mail at usenet at news.efn.org.  Please 
note that we do not offer news access to sites outside of our 
organization.

If you're a newsadmin and you'd like to run your own autoresponder, this one
is available from ftp://ftp.cccd.edu/pub/usenet/innautorespond.

Or you can just ask us to mail you a copy.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

There are typically 5 possible reasons why you were sent this e-mail message:

1) You intentionally posted a Usenet news article to a *.test newsgroup.  
These newsgroups exist so you can verify that your articles are being 
propagated correctly.  When your article arrives here, we send you this message
as confirmation.  We will only send you ONE e-mail reply for each of your test
articles that we see.

2) You unintentionally posted a Usenet news article to a *.test newsgroup.  
This is a bit of net.childishness caused by a Followup-To: header directing all
replies into a *.test newsgroup.  This is done by somebody upset with the
content of a discussion thread who wants to "punish" anybody who replies to his
message.  Your reply will be sent to *.test instead of the original newsgroup,
and you will start receiving autoresponder messages similar to this one that
you didn't ask for.  To avoid this in the future, look for a Followup-To:
header and make sure it's appropriate before replying to any articles.

3) You were a victim of a Reply-To: header directing your e-mail into a *.test
newsgroup via a mail->news gateway.  Similar to 2) above.

4) Somebody has forged a posting in your name to one of the *.test newsgroups.
To avoid this in the future, use better net.etiquette and you will make fewer
net.enemies.  If you want to try and identify the forger, use the following
procedure.  Make a legitimate posting to the same *.test newsgroup that the
forger used.  We will send you an e-mail reply.  Compare the Path: header from
this legitimate reply with the Path: header from the forgery.  The front
part of the two headers will be the same or topologically similar path to
your site.  Where the forged header becomes substantially different can
provide clues to where the forger lives.  Note that if you receive multiple
newsfeeds you may need to repeat this process several times so you can discover
all legitimate paths between our site and yours.  Once you think you've
identified the forger's site, try sending POLITE e-mail to the newsadmin/
sysadmin/postmaster explaining the situation.

5) You issued a cancel control message to a *.test newsgroup.  Some users
dislike autoresponses for cancel messages, but the newsadmins here think it
can be a valuable diagnostic tool for verifying cancel propagation.  If you
don't like it, use the "delete" key in your mail client!

All headers plus at most 10 lines of user text from your original article are
reproduced below for your perusal:

Path: mars.efn.org!cs.uoregon.edu!news.uoregon.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT

test
test





From tcmay at netcom.com  Wed Feb  8 13:42:13 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 8 Feb 95 13:42:13 PST
Subject: Four Horsemen
In-Reply-To: <199502082012.AA18319@world.std.com>
Message-ID: <199502082138.NAA17319@netcom13.netcom.com>


Ken Kirksey wrote:

> Just a quick question:  someone asked me the other day what the "Four
> Horsemen of the Infocalypse" were, and I told him
> 
>   1) Drug Dealers
>   2) Terrorists
>   3) Pedophiles
>   4) Pornographers
> 
> Did I get it right, or did I have a synaptic misfire somewhere along
> the line?

I usually just lump pedophiles and child pornographers together and
don't separately mention "normal" pornographers, as there's not much
on-line that competes with "Hustler." (The AA case, though, makes
conventional pornography a Horseman.)

Usually I also cite "money launderers" as the Fourth Horseman. This
lumps in tax evaders, etc.

But, now that we know what the Four Horsemen are, what's in the Seven
Vials? And since the British spelling and pronunciation is "phial,"
which sounds like "file" (but which has a different root: vial vs.
filum), we could call these the "seven files."

(Not to be confused with the "seventh veil.")

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From jim at acm.org  Wed Feb  8 13:44:12 1995
From: jim at acm.org (Jim Gillogly)
Date: Wed, 8 Feb 95 13:44:12 PST
Subject: Judges-L FAQ
In-Reply-To: <199502082043.MAA21652@tower.techwood.org>
Message-ID: <199502082143.NAA20893@mycroft.rand.org>



> "Craig A. Johnston" <caj at tower.techwood.org> writes:
> 
> It has come to my attention that the Judges-L FAQ is being distributed
> by someone who obtained it on this list, and being sent to people made
> to look as if it has issued from David Stodolsky.  

> I must inform you that this FAQ is copyrighted material, and 
> you are requested not to distribute it. 

A version of this FAQ with Message-ID <01050105.hhv9l1 at arch.ping.dk> was
posted from Stodolsky's machine in Denmark on 17 Dec 94 by
judges at arch.ping.dk to news.admin.* and misc.legal, asking for feedback
and asking for no distribution restrictions.  IANAL, but it looks to me
like your genie's out of the bottle.

	Jim Gillogly
	Highday, 18 Solmath S.R. 1995, 21:35





From cme at tis.com  Wed Feb  8 13:53:46 1995
From: cme at tis.com (Carl Ellison)
Date: Wed, 8 Feb 95 13:53:46 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502082023.MAA00749@comsec.com>
Message-ID: <9502082149.AA28226@tis.com>


>Sender: owner-cp-lite at comsec.com
>X-Signed: PGP-Detached-2-3,
>   iQBXAwUBLzhSutC3U5sdKpFdAQEEqwIMCg1PFWC19WuW2BhwmzUyg84RthT/61x9
>   vLrIPbgrYcCXCNB8F51tQogs5lBrry/aOk2Fk3Izl//XC4KDl+cADrCz
>Date: Tue, 7 Feb 95 21:24:01 PST
>From: jpp at markv.com

>of the very most important rights.  To hold the owner of a buliten
>board responsible for the illegal messages posted to it, is to force
>the buliten board owner to become a government censor in all but name
>(and wages).

anyone heard of "no unfunded mandates" ?






From caj at tower.techwood.org  Wed Feb  8 13:59:01 1995
From: caj at tower.techwood.org (Craig A. Johnston)
Date: Wed, 8 Feb 95 13:59:01 PST
Subject: To clear this up.
Message-ID: <199502082158.NAA00214@tower.techwood.org>



Something needs clearing up:

I am not a Judges-L sympathizer.  The previous message was posted
at the request of David Stodolsky.  I am subscribed to the list to
see what is going on.  I find the idea of the Judges-L to be repulsive,
personally, as I have told DS and others.

I saw no harm in relaying this message to the list.  All it is likely
to do is create more anti-Judges-L sentiment.  David Stodolsky
claims that they have no desire to hide their FAQ, but that he wishes
for it to be distributed in a controlled fashion.  

To engage in what I deem "fair use": "...disclosure in the wrong context,
or at the wrong time can cause trouble..."

A beaut.

In sum, I find Judges-L repulsive and plan to keep an eye on it.

-Craig Johnston





From rah at shipwright.com  Wed Feb  8 14:04:36 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Wed, 8 Feb 95 14:04:36 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <v01510103ab5eaa4305cf@[199.0.65.105]>


At 12:02 PM 2/8/95, Robert Rothenburg Walking-Owl wrote:
>Of course geographic community standards are problematic too with
>telecommunications since postal inspectors from Tennessee can call
>up adult bulletin boards in California...

This reminds me of a joke I finally grew tired of, prescient though it may
have been given current legal events in Tennessee:

        It's illegal in Cambridge to smoke in Boston...

Most non-smokers, especially the reformed-smoker non-smokers, didn't think
that that one-liner was very funny. Most small-l libertarians had a hoot or
too about it though.  (Just like the punchline about how many radical
feminists it takes to screw in a lightbulb [A: That's really *not* funny.])


I guess I'll sit down now...

Cheers,
Bob Hettinga

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From msattler at jungle.com  Wed Feb  8 14:11:03 1995
From: msattler at jungle.com (Michael Sattler)
Date: Wed, 8 Feb 95 14:11:03 PST
Subject: Judges-L FAQ
Message-ID: <v03001409ab5ef19cb7c7@[140.174.229.204]>


At 12:43 2/8/95, Craig A. Johnston wrote:

>I must inform you that this FAQ is copyrighted material, and
>you are requested not to distribute it.

What good is a FAQ if you can't distribute it.  The judges are confused in
more ways than one.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From jim at acm.org  Wed Feb  8 14:11:36 1995
From: jim at acm.org (Jim Gillogly)
Date: Wed, 8 Feb 95 14:11:36 PST
Subject: Jefferson Wheel Cypher
In-Reply-To: <199502082012.AA18336@world.std.com>
Message-ID: <199502082211.OAA21023@mycroft.rand.org>


Isn't that the same as Bazeries' Cylinder Cipher, where you have a bunch of
disks with mixed alphabets around the edges, you put them on a rod in some
order, set the plaintext along a row, then read the ciphertext off any
other row?  If so, a short paper of mine was just printed in "The
Cryptogram" (JF95 issue) about cryptanalyzing it.  A US military field
cipher was based on the Jefferson version; I handled a copy (with metal
disks) in the National Cryptologic Museum just outside Ft. Meade last
summer.  There may even be an Aegean Park Press publication on it.  The
servicemen hated it -- fiddling with all the disks in the heat of battle
made it cumbersome for tactical use.

If it's as I describe, I'd call it a multiple-key polyalphabetic: keyed
alphabets, keyed order, and (potentially ambiguous) offset key for
deciding how far around the cylinder to go.  The period is how many disks
you have, since they stay in the same order (but with different relative
offset) for the whole message.  It's not really an autokey under the
Meaning of the Act, since there's no feed-forward from one letter to the next.

I'm sure Kahn's "The Codebreakers" will have more info.

	Jim Gillogly
	Highday, 18 Solmath S.R. 1995, 21:59





From weidai at eskimo.com  Wed Feb  8 14:44:03 1995
From: weidai at eskimo.com (Wei Dai)
Date: Wed, 8 Feb 95 14:44:03 PST
Subject: a new way to do anonymity
Message-ID: <199502082243.AA19005@mail.eskimo.com>


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

> I'd suggest just getting something running first, to get some
> prototyping experience.

Now that I've just spent some time compiling and playing with Matt's ESM
program, it seems almost perfectly suited for prototyping Pipe-Net 
since you can use it to do nested encryption.  All that's needed is 
to hack it so that it implements link encryption (i.e., send a
constant stream of random data in between keypresses).

This is what the user would do: (LESM for Link Encrypted Session Manager)
lesm -l
lesm -l
login to server 1
lesm -s
lesm -l (or better yet take over a free LESM session already running
		 between server 1 and server 2)
login to server 2
lesm -s
lesm -s

I wonder if Matt has the time and interest do this...  If not then I 
guess I can try, but I've never done real crypto programming before...

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzlIdDl0sXKgdnV5AQFKuwQAqhJulKWcPV8GWUM11+2zonT+EQ8q18YV
TAymUlhjuYo0csHP/nmoMDRpf/9veISdBQE/GlRkc1k0JsWpPBD0+6e0nA7kCTMO
xqVoXdM3F/qN31CXjMT9rgAanIXFat2Ox3bjT3g07ReaN372TPnGGvNauxO69Z52
kvWajSSXiSY=
=yF/i
-----END PGP SIGNATURE-----





From xpat at vm1.spcs.umn.edu  Wed Feb  8 14:52:06 1995
From: xpat at vm1.spcs.umn.edu (xpat at vm1.spcs.umn.edu)
Date: Wed, 8 Feb 95 14:52:06 PST
Subject: MIME based remailing commands
Message-ID: <9502082251.AA03118@toad.com>


Hal writes:

>I can see that putting remailer commands into a specific part of a MIME
>multipart message has some advantages.  Right now we are basically
>having the remailing commands be mail header fields.

>OTOH it does have the advantage that it is easy to do, at least with th
>"::" pasting token idea (which perhaps would need to be documented in is
>own right).

IMHO, an ideal message would have the ability to handle nested objects
of varying types, MIME is only a start. To construct a unique format
for remail_messages is reasonable, perhaps even preferable. But of
course, MIME *could* be a start, in a brown'n'serve roll sort of way.

However, with a proprietary approach,
what to use for delimiters, or quasi-parentheses (in the case of n
layers of nesting, encrypted or unencrypted) needs extensive and
careful consideration. This is the same dilemma many developers face
with document-centric interfaces and their plethora of odd-bird formats.

I say take the remail stuff out of the header altogether,
MIME or not.

----------------------------------------------------------------
P M Dierking |





From perry at imsi.com  Wed Feb  8 15:04:29 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Wed, 8 Feb 95 15:04:29 PST
Subject: MIME based remailing commands
In-Reply-To: <9502082251.AA03118@toad.com>
Message-ID: <9502082303.AA10796@snark.imsi.com>



xpat at vm1.spcs.umn.edu says:
> IMHO, an ideal message would have the ability to handle nested objects
> of varying types, MIME is only a start.

What is it precisely that you might want to encapsulate that MIME
can't encapsulate?

.pm





From mab at research.att.com  Wed Feb  8 15:35:55 1995
From: mab at research.att.com (Matt Blaze)
Date: Wed, 8 Feb 95 15:35:55 PST
Subject: a new way to do anonymity
In-Reply-To: <199502082243.AA19005@mail.eskimo.com>
Message-ID: <9502082318.AA21943@merckx.info.att.com>



...
>since you can use it to do nested encryption.  All that's needed is 
>to hack it so that it implements link encryption (i.e., send a
>constant stream of random data in between keypresses).
...
You could just send a stream of some uncomon ascii character, which you
filter out on the receiving end (if you wanted to this right, you could add
a simple escape mechanism for actually passing that character).

To avoid flooding the network and also bringing the machines on which its
running to its knees, you'd probably want to add a bandwidth-choke
mechanism to run the white noise at some reasonable rate.  You'd have to limit
the real traffic output to the same rate.  Link encryption over a broadcast
network is a tricky business.
>
>I wonder if Matt has the time and interest do this...  If not then I 
>guess I can try, but I've never done real crypto programming before...
>

For the next couple of months, I have absolutely no free hacking time.
Things on the stack include:
	- ESM 1.0
	- Diffie-Hellman encrypting and authenticating Telnet (almost ready...)
	- CFS 1.3
	- The course
	- The book
	- My real work

So I don't even have the time to figure out whether I have the interest.

-matt





From cactus at hks.net  Wed Feb  8 16:14:33 1995
From: cactus at hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Wed, 8 Feb 95 16:14:33 PST
Subject: Hastur CT status
Message-ID: <199502082009.TAA22774@seabsd.hks.net>



(Sorry if the signature gets anybody's noses out joint.  I'm in a goofy
 mood.)

-----ORTVA CTC FVTARQ ZRFFNTR-----

It's another Hastur Crypto Toolkit progress report.  Why?  Because many
people expressed an interest in it, because I want to continue to get
comments on what I'm doing, because I want people who might be inclined
to do something similar to know about what I'm doing, and because
cypherpunk projects tend to be assumed to be dead if nothing is heard.

The general IO section skeleton is finished, and all file I/O and memory
I/O types are supported.  Encoding rules now fully coded in are rot13 (for
simple testing), uuencode, and radix64.  There are also unfilled stubs
for DER/BER at the moment.  

I'm about to start in on the framework for crypto code and key management:
Any ideas on handling a generalized concept of keys will be greatly
appreciated!  For instance, I've asserted several times here that
X.509 keys can be fully modelled as special cases of PGP web-of-trust
keys with one additional field, the expiration time.  Nobody has flamed me, but
nobody has agreed with me... since I've only read the X.509 spec and never
actually used them, I'd like some assurance that I'm not missing some
subtleties in this approach.

The general I/O is fairly slow, since items are fetched in blocks
appropriate for the encoding (IE, radix 64 maps 4 bytes r64 to 3 bytes
binary);  I might put the effort into optimizing it later, but my gut
feeling is that the crypto is going to be at least an order of magnitude
slower.

Now, the general outline of what I'm building.  This is pretty much the
same as what I've posted before.  I do want to note that all I/O is
locking, using a library of locking versions of I/O fns I sent to some
folks here a while ago.

- ---
Hastur Crypto Toolkit.

In essence, what I'm building is a crypto library that takes a very general
approach with a few parameters controlling its behavior.  The idea is
to have something that anybody can drop into their mail agent and have
an easy way of using crypto and interface with existing systems such as
PGP.  A major design goal is to be backwards compatable with PGP, but
paramount is having a plug-and-play library that will be flexible enough
to meet future crypto needs.  RIPEM compatability is also desirable.

One of the biggest problems today is that crypto libraries are chiselled out
to deal with very specific cases -- the most general I know of if is RSAREF,
which deals with only with crypto functions that RSADSI happens to find
useful.

The things that I've parametrized in the design are:

	- Type of I/O.  Right now, files (and fds) and a couple of memory
	 configurations	are supported.  I've made it trivial to add new
	 types of I/O as well, and there are flags to support to
	 immediate zeroing of data once it is read into the internal
	 structures.

	- Encoding of data.  There are multiple ways to encode a bytestream
	 and these methods can be nested.  In this library, you can specify
	 the type.  I also want to eventually put logic in (where possible)
	 to determine the type and will also use this to support various
	 compression schemes.  Currently supported are rot13, radix64, and
	 uuencode.

	- Ciphers (this is the big one).  Right now, as I've mentioned,
	 things are very haphazard.  What I want is a way to change one
	 parameter from, for example, CRTYPE_IDEA to CRTYPE_DES and
	 thus change the encryption scheme.

	- Key management.  I know of two major ways of doing things
	 right now, X.509/PEM certificates as pushed by RSADSI, and
	 PGP web-of-trust.  As far as I can tell, PEM-style certificates
	 are just a degenerate case of PGP web-of-trust.

	- Random sources.  People should be offered a pretty good source
	 of random numbers, but should also be allowed to drop in their
	 own sources.  This is going to be relatively tough on platforms
	 I don't know much about, IE Mac and PC, but I'm hoping for some
	 help on this.  I can also salvage some code from RIPEM for those.

	- Autoconfiguration to incoming messages.  People should be
	 able to open a file and have it work, even with schema added
	 to the library after the original adaption to Hastur (assuming
	 an upgrade of the library, of course).

There's some other stuff that I'm probably forgetting here, but that's
the gist of it.  The cipher code is going to be pretty simple: I'm
getting a lot of code from various places on the net;  the code exists,
it just isn't put into a form that is easy to use.  The most difficult is
going to be a generalized scheme for key management: first off, I'm probably
going to simply use PGP's web-of-trust as my model, assuming the X.509/PEM
style certificates can be treated as degenerate cases of web of trust.

I also intend to offer a GSSAPI interface to all of this in release
1.1 or so.

This is so far all in C: I'm not a C++ convert yet and C is still the
most portable of the languages about.  Later, perhaps class libraries
can be designed around the same code.

Comments are actively solicited.

-----ORTVA CTC FVTANGHER-----
Irefvba: 2.6.2

vDPINjHOYmxxvuAutbieCO7qNDSfStDNyU0k5/4/10EHEJGY72kwhzoGEAZMe0z7
oQf4Y+QbtweC9vauOYo8SAXFrI4td2coJ3xbtsojYTuhHamWcX2AxIlLedSWFuuJ
e6mIEDbk6xIpoyLvIsfSLUqKkO6qe4hWXZxORSF6vN6cqvmNaNAuG17nE8IqfiAh
ZeydKo0cNf8=
=oOZD
-----RAQ CTC FVTANGHER-----





From tcmay at netcom.com  Wed Feb  8 17:16:59 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 8 Feb 95 17:16:59 PST
Subject: The drumbeat against anonymity continues....
Message-ID: <199502090115.RAA22929@netcom16.netcom.com>


In addition to the articles and editorials, I'm seeing articles
slamming anonymity and pseudoanonymity (we need a better word!) in
business contexts.

See the latest RISKS Digest (16.79, available on Usenet in the group
comp.risks) for a couple of articles of interest. One is about the
Singapore plans for an automatic vehicle intentification (AVI) system
to implement "road pricing" on congested roads. Phil Agre's article
makes some good points, and mentions using digital cash to avoid the
Big Brother problems, but notes that Singapore is not seriously
considering it.

The real "drumbeat" article is about cellular phone fraud and
toll-free number fraud. Actaully, a couple of related articles.
(Everyone should at least skim "RISKS.")

Anonymity is cited as a problem. But this misses the point, that the
real problem is lack of a proper payment model. As David Chaum points
out, there are really only two basic payment approaches: transfer of
something of value or an account-based transfer. Cash or barter are
examples of the first, checks or credit card payments are examples of
the second (though each has some wrinkles). Digital cash, when online
cleared, behaves mostly like real cash.

The phone companies that are complaining about fraud have inadequately
arranged for security and need to adopt a mode that fixes this. Since
physical money can't be fed into the slots of a handheld cell phone (or
at least can't then be delivered to the service owner!), the solution
has traditionally been an account-based payment system. (Accounts can
also be better protected against fraud by having PINs, etc.)

What about telephone calling cards? I don't recall the details well
enough to know if they could be used on handheld units. Maybe they
could be used.

This could eventually be a market for digital cash. (If fraud is a
serious-enough problem, costing enough, then a service which could
lower costs by using digital cash could make market inroads.)

What we need to watch out for are proposals to limit anonymity, to
mandate national ID cards, so as to somehow limit such cases of fraud.

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From root at einstein.ssz.com  Wed Feb  8 17:28:24 1995
From: root at einstein.ssz.com (root)
Date: Wed, 8 Feb 95 17:28:24 PST
Subject: Not necessarily crypto but scary anyway...
Message-ID: <199502090123.TAA01134@einstein.ssz.com>


Hi all,

A friend advises me that today House Bill 666 passed. This supposedly would
allow police officers to use evidence collected illegaly if they 'believed'
that it was collected in good faith.

Any word on it?

Thanks.






From jamesd at netcom.com  Wed Feb  8 17:42:41 1995
From: jamesd at netcom.com (James A. Donald)
Date: Wed, 8 Feb 95 17:42:41 PST
Subject: Judges-L FAQ
In-Reply-To: <v03001409ab5ef19cb7c7@[140.174.229.204]>
Message-ID: <Pine.3.89.9502081717.A17747-0100000@netcom10>



At 12:43 2/8/95, Craig A. Johnston wrote:
> >I must inform you that this FAQ is copyrighted material, and
> >you are requested not to distribute it.
 
On Wed, 8 Feb 1995, Michael Sattler wrote:
> What good is a FAQ if you can't distribute it.  The judges are confused in
> more ways than one.

I am entirely sympathetic to the judges, but obviously we need
to keep an eye on them.

Their attempt to restrict circulation of their FAQ fails to
inspire confidence.  It is supiciously reminiscent of 
what the Church of Scientology is up to.

But I repeat, I think that the judges list is necessary
and desirable, so long as they remember they are self
appointed and do not start to imagine that they are
the "official" judges.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From samman at CS.YALE.EDU  Wed Feb  8 17:44:38 1995
From: samman at CS.YALE.EDU (Ben)
Date: Wed, 8 Feb 95 17:44:38 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502090123.TAA01134@einstein.ssz.com>
Message-ID: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>


On Wed, 8 Feb 1995, root wrote:

> Hi all,
> 
> A friend advises me that today House Bill 666 passed. This supposedly would
> allow police officers to use evidence collected illegaly if they 'believed'
> that it was collected in good faith.

This sounds like a spoof.  Look at the number.

Ben.






From hugh at ecotone.toad.com  Wed Feb  8 18:19:01 1995
From: hugh at ecotone.toad.com (Hugh Daniel)
Date: Wed, 8 Feb 95 18:19:01 PST
Subject: Meeting Anncouncement for Sat. Feb. 11 1995 SF Bay Area Meeting
Message-ID: <9502090217.AA09964@ecotone.toad.com>



What:	Cypherpunks SF Bay Area Physical Meeting
When:	13:00 February 11 1995
Where:	Silicon Graphics, Inc.,  Building 5 (SGI's Iris Cafeteria)
	2025 North Shoreline Boulevard, Mountain View, CA, Earth, Sol, MW

Topic:	Crypto Networking Protocol Hygiene

Agenda:  (listed times are almost all a joke)
  12:00	Brown Bag Lunches, AV Debugging, Loose Talk
  13:00	Meeting Begins (MBONE broadcast begins)
  13:02	Meeting Announcements, Agenda Rewrite
  13:08	Hugh Daniel on
  	"When What Goes Where: Good Networking Protocol Hygiene"
  13:45	Eric Hughes on
	"Sendmail as a Multiplexor"
  14:30 Michael Sattler on
	"Announcement of CryptDisk v1.0"
  14:40	General Announcements, Questions, Confusion etc.
  15:00	BREAK!
  15:30	Doug Barnes
        "Stream-oriented, analysis-resistant public-key protocols over UDP"
  16:15 Raph Levien & KT Kislitzin on
	"Design philosophy for the upcomming PGP 3.0 API"
  17:00	Hot New Topics of the Week & General Free For All!
  17:59 Mbone Broadcast ends
  18:00	KP room, Thank our SGI hosts & GOTO Dinner

Presentations:

"When What Goes Where: Good Networking Protocol Hygiene"
	Hugh Daniel <hugh at toad.com>
  When designing, coding and testing programs we are confronted with a
myriad of choices as to how various parts of the solution communicate.
Much is known about how to design 'protocols' that are flexible,
debugable & robust.
  We are currently encoding cryptographic protocols in our systems and
networks at a furious rate, yet there are new challenges in keeping such
systems robust, secure and sometimes even anonymous.
  I hope to touch on some of the well known tricks and dangers, what
is new when cryptographic and anonymous systems are combined with
todays systems and where we might learn from the past.
  

"Sendmail as a Multiplexor."
           Eric Hughes <eric at remailer.net>
  The basic architecture of sendmail is a recognizer and a dispatcher.
These two elements provide a good framework for designing systems that
can be changed piece by piece.  Even when a facility seems to have
stabilized, it's often a good idea to keep the flexible framework
around for future experimentation and expansion.


"Announcement of CryptDisk v1.0"
	Michael Sattler <msattler at jungle.com>
  CryptDisk (for the Macintosh) is an example of the kinds of [mostly]
transparent strong crypto that we need.  Integrated smoothly with the
operating system, CryptDisk provides IDEA encryption on a block
read/write level for a virtual hard disk.  It's beauty lies mainly in
that it does exactly what the user expects and requires no more setup
than remembering a pass-phrase.  Source code is available upon
request.  Warning:  Some governments might consider this software a
"Munition", not suitable for "private possession" by free peoples.


"Stream-oriented, analysis-resistant public-key protocols over UDP"
	Doug Barnes <dab at Tadpole.COM>
  Many cypherpunks projects have a need to reliably transmit
variable-length (sometimes quite long) data over unreliable
networks. TCP lends itself to traffic analysis and is not well-suited
for use in a hypothetical system of packet laundries that would lead
to packets within a particular stream appearing to come from a variety
of sources.  We have designed and are currently implementing a
UDP-based, hidden-streams protocol that utilizes fixed-length blocks
and pseudo-random sequence numbering to provide reliable,
stream-oriented services to higher-level applications despite
extremely creative routing and laundering of packets.

Raph Levien <raph at netcom.com> & KT Kislitzin <ktk at sgi.com>
	"Design philosophy for the upcomming PGP 3.0 API"
  PGP is getting a major upgrade soon, some of the team doing the
work will talk about the motivations and directions the work is
going in.

--------------------------------------------------------------------------------






From dmandl at panix.com  Wed Feb  8 18:21:01 1995
From: dmandl at panix.com (David Mandl)
Date: Wed, 8 Feb 95 18:21:01 PST
Subject: Effects of S.314 (Communications Decency Act)
Message-ID: <v01510100ab5f0c4d5b89@[166.84.250.21]>


At 11:02 AM 2/8/95, strick at techwood.org wrote:
>Right now there is a "safe harbor" from around 10pm (or is it 9pm?)
>thru 6am, but this changes regularly, usually as a result of "case law"
>(someone being prosecuted under next month's rules, not this month's)

Yup, this stuff is subject to change about every week--so much so that at
WFMU, our station manager simply imposed one set of fairly "conservative"
restrictions on "obscene" language at _all_ hours, set it down on paper,
and left it at that.  Can't blame him, as the guidelines were changing
literally every few months and at one point it was very easy to be
operating based on last month's rules.  "Safe harbor" loopholes,
disclaimers, etc., are history right now as far as I know, but of course it
may have changed.

I think the important thing is for the program director to have some
"responsible" codified policy to show to the FCC if they hassle you.  They
mainly want to know that s/he's keeping an eye on things and has some
coherent house rules.  This sucks, of course, but probably makes life
easier in the long run.  I have occasionally let a naughty word on a record
slip by (accidentally, of course), and no one's going to make a big deal
about it.

For a while, we were all convinced that the FCC left all these rules
impossibly vague on purpose, just so that you didn't even know how to obey
the law if you wanted to.  Everyone a potential criminal.

   --Dave.

--
Dave Mandl
dmandl at panix.com







From tedwards at src.umd.edu  Wed Feb  8 18:21:35 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Wed, 8 Feb 95 18:21:35 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <Pine.SUN.3.91.950208211930.24981C-100000@thrash.src.umd.edu>


On Wed, 8 Feb 1995, Ben wrote:

> On Wed, 8 Feb 1995, root wrote:

> > A friend advises me that today House Bill 666 passed. This supposedly would
> > allow police officers to use evidence collected illegaly if they 'believed'
> > that it was collected in good faith.

> This sounds like a spoof.  Look at the number.

Unfortunately, it is not.  World Wide Web yourself over to 
http://thomas.loc.gov/ and search for hr 666...you will find it.

"A Bill to control crime by exclusionary rule reform..." maybe if 
"control" means "aiding and abetting"

-Thomas






From lmccarth at ducie.cs.umass.edu  Wed Feb  8 18:29:57 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Wed, 8 Feb 95 18:29:57 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <199502090231.VAA04807@ducie.cs.umass.edu>


root writes:
> A friend advises me that today House Bill 666 passed. This supposedly would
> allow police officers to use evidence collected illegaly if they 'believed'
> that it was collected in good faith.

Ben writes:
# This sounds like a spoof.  Look at the number.

No, it's for real. This is the `Exclusionary Rule Reform Act of 1995', HR 666.
It was introduced Jan. 25 by a Rep. McCollum, referred to the Judiciary Cmte.,
and on Feb. 2 was "committed to the Committee of the Whole House on the State 
of the Union and ordered to be printed", whatever that means.

Here's an excerpt of the main idea: 

"Evidence [...] shall not be excluded [...] on the ground that the search or 
seizure was in violation of the fourth amendment [...] if the search or 
seizure was carried out in circumstances justifying an objectively reasonable 
belief that it was in conformity with the fourth amendment. The fact that 
evidence was obtained pursuant to and within the scope of a warrant 
constitutes prima facie evidence of the existence of such circumstances."

So I suppose this opens the possibility that, if a judge grants a search 
warrant that allows broader police powers than the 4th Amendment would, then 
the police have free reign to use those broader powers.

This is all via http://thomas.loc.gov/home/c104query.html.

-L. Futplex McCarthy




From jrochkin at cs.oberlin.edu  Wed Feb  8 18:45:17 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Wed, 8 Feb 95 18:45:17 PST
Subject: Judges-L FAQ
Message-ID: <ab5f324500021004a86e@[132.162.201.201]>


At 3:43 PM 02/08/95, Craig A. Johnston wrote:
>It has come to my attention that the Judges-L FAQ is being distributed
>by someone who obtained it on this list, and being sent to people made
>to look as if it has issued from David Stodolsky.
>
>I must inform you that this FAQ is copyrighted material, and
>you are requested not to distribute it.

Huh?  What kind of an FAQ is it, that can't be freely distributed?  If you
don't expect people to redistribute the text, don't call it an "FAQ".  The
phrase "FAQ list" is understood internet-wide (or at least usenet-wide) to
mean a freely distributable list of information someone might want on a
certain topic.  (It doesn't neccesarily mean "Frequenty Asked Questions",
literally, these days.  Cause there are often FAQs distributed that just
contain general information on a certain topic, but not actually questions
that have ever been asked before.  The Judges FAQ might be a good example.)


If you don't want people to redistribute the thing, the really should
change it's name.  And write very explicitly at the top of the document
that no one should copy it without permission of the author.   These things
just aren't generally supposed to be true of FAQs.







From clysdale at dragon.achilles.net  Wed Feb  8 18:48:27 1995
From: clysdale at dragon.achilles.net (Don Clysdale)
Date: Wed, 8 Feb 95 18:48:27 PST
Subject: The Rise of "Worse is Better"...
In-Reply-To: <Pine.3.89.9502070839.B31143-0100000@acs6.acs.ucalgary.ca>
Message-ID: <Pine.SUN.3.91.950208201048.26954A-100000@dragon.achilles.net>




On Tue, 7 Feb 1995, jason cooper wrote:

> I like.  I guess I'm basically in with the New Jersey crowd.  Anybody 
> else?

	Definitely...  You've seen some of my code, haven't you...??

Remember that LISP shit at 4:00 in the morning, Stig?  Gack was
that New Jersey code!!!

								-Ian!






From unicorn at access.digex.net  Wed Feb  8 18:50:54 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Wed, 8 Feb 95 18:50:54 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502090123.TAA01134@einstein.ssz.com>
Message-ID: <Pine.SUN.3.91.950208214510.14387A-100000@access4.digex.net>


On Wed, 8 Feb 1995, root wrote:

> Date: Wed, 8 Feb 1995 19:23:31 -0600 (CST)
> From: root <root at einstein.ssz.com>
> To: cypherpunks at toad.com
> Subject: Not necessarily crypto but scary anyway...
> 
> Hi all,
> 
> A friend advises me that today House Bill 666 passed. This supposedly would
> allow police officers to use evidence collected illegaly if they 'believed'
> that it was collected in good faith.
> 
> Any word on it?
> 
> Thanks.
> 

As I understand the bill,(Though I didn't know it was up for passge...)
 this is merely a restatement of the current judicial doctrine which 
prevents officers acting in good faith from being hindered by an 
illegally issued warrant.  In essence the concept is that the 4th 
ammendment is intended to deter police misconduct by kicking out evidence 
gathered illegally.  Once a judge issues a warrant, and assuming it is 
issued illegally, but with no knowledge by the officers who execute the 
search, there is no longer any deterant value in supressing the evidence 
and as such it would be "counterproductive" to bar it from presentment.

This isn't really passage of "new" law, but legislative clairification of 
current judicial doctrine.  If there is enough interest, I would be happy 
to post cites to the key cases establishing the "good faith" exception to 
exclusion.

-uni- (Dark)

--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From unicorn at access.digex.net  Wed Feb  8 18:53:14 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Wed, 8 Feb 95 18:53:14 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <Pine.SUN.3.91.950208215120.14387B-100000@access4.digex.net>


On Wed, 8 Feb 1995, Ben wrote:

> Date: Wed, 8 Feb 1995 20:44:27 -0500 (EST)
> From: Ben <samman at CS.YALE.EDU>
> To: root <root at einstein.ssz.com>
> Cc: cypherpunks at toad.com
> Subject: Re: Not necessarily crypto but scary anyway...
> 
> On Wed, 8 Feb 1995, root wrote:
> 
> > Hi all,
> > 
> > A friend advises me that today House Bill 666 passed. This supposedly would
> > allow police officers to use evidence collected illegaly if they 'believed'
> > that it was collected in good faith.
> 
> This sounds like a spoof.  Look at the number.

This would amuse me, as the spoofer would have, in trying to come up with 
an intimidating law that would result in public outrage, instead hit upon 
the current doctrine.

Truth stranger than fiction?

I do seem, however, to recall some mention of legislative clairification 
of the doctrine, so I suspect it to be legitimate.

> 
> Ben.
> 
> 

-uni- (Dark)

--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From droelke at spirit.aud.alcatel.com  Wed Feb  8 18:54:49 1995
From: droelke at spirit.aud.alcatel.com (Daniel R. Oelke)
Date: Wed, 8 Feb 95 18:54:49 PST
Subject: Not necessarily crypto but scary anyway...
Message-ID: <9502090254.AA11147@spirit.aud.alcatel.com>



> 
> On Wed, 8 Feb 1995, Ben wrote:
> 
> > On Wed, 8 Feb 1995, root wrote:
> 
> > > A friend advises me that today House Bill 666 passed. This supposedly would
> > > allow police officers to use evidence collected illegaly if they 'believed'
> > > that it was collected in good faith.
> 
> > This sounds like a spoof.  Look at the number.
> 
> Unfortunately, it is not.  World Wide Web yourself over to 
> http://thomas.loc.gov/ and search for hr 666...you will find it.
> 
> "A Bill to control crime by exclusionary rule reform..." maybe if 
> "control" means "aiding and abetting"
> 
> -Thomas
> 

I haven't looked it up yet, but I did hear about the bill on news 
last night, so I would say it is legit. 

The number of the devil indeed.
------------------------------------------------------------------
Dan Oelke                                  Alcatel Network Systems
droelke at aud.alcatel.com                             Richardson, TX
http://spirit.aud.alcatel.com:8081/~droelke/





From unicorn at access.digex.net  Wed Feb  8 18:58:03 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Wed, 8 Feb 95 18:58:03 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502090231.VAA04807@ducie.cs.umass.edu>
Message-ID: <Pine.SUN.3.91.950208215408.14387C-100000@access4.digex.net>


On Wed, 8 Feb 1995, L. McCarthy wrote:

> Date: Wed, 8 Feb 1995 21:31:42 -0500 (EST)
> From: L. McCarthy <lmccarth at ducie.cs.umass.edu>
> To: Cypherpunks Mailing List <cypherpunks at toad.com>
> Subject: Re: Not necessarily crypto but scary anyway...
> 
> root writes:
> > A friend advises me that today House Bill 666 passed. This supposedly would
> > allow police officers to use evidence collected illegaly if they 'believed'
> > that it was collected in good faith.
> 
> Ben writes:
> # This sounds like a spoof.  Look at the number.
> 
> No, it's for real. This is the `Exclusionary Rule Reform Act of 1995', HR 666.
> It was introduced Jan. 25 by a Rep. McCollum, referred to the Judiciary Cmte.,
> and on Feb. 2 was "committed to the Committee of the Whole House on the State 
> of the Union and ordered to be printed", whatever that means.
> 
> Here's an excerpt of the main idea: 
> 
> "Evidence [...] shall not be excluded [...] on the ground that the search or 
> seizure was in violation of the fourth amendment [...] if the search or 
> seizure was carried out in circumstances justifying an objectively reasonable 
> belief that it was in conformity with the fourth amendment. The fact that 
> evidence was obtained pursuant to and within the scope of a warrant 
> constitutes prima facie evidence of the existence of such circumstances."
> 
> So I suppose this opens the possibility that, if a judge grants a search 
> warrant that allows broader police powers than the 4th Amendment would, then 
> the police have free reign to use those broader powers.

Precisely.
Again, if the judge issues the warrant, the damage is done, exclusion is 
pointless.  The concept that police should be expected to know the law is 
apparently, silly.  I suppose you don't want police "second guessing" 
judges, but personally I wouldn't mind the implications.

The review process allows the warrant to be overturned and the evidence 
excluded if the issuing judge's basis for signing the warrant is "clearly 
erronious"  (from memory.)  Where there is good faith involved by all the 
parties however....

> This is all via http://thomas.loc.gov/home/c104query.html.
> 
> -L. Futplex McCarthy
> 

--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From bdolan at use.usit.net  Wed Feb  8 19:14:24 1995
From: bdolan at use.usit.net (Brad Dolan)
Date: Wed, 8 Feb 95 19:14:24 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502090123.TAA01134@einstein.ssz.com>
Message-ID: <Pine.SOL.3.90.950208220830.11572B-100000@use.usit.net>


Yes, it passed.  You can get a copy from thomas.loc.gov.

The Senate still has to pass it (but certainly will).
I think the Senate version is S3.

Brad Dolan


On Wed, 8 Feb 1995, root wrote:

> Hi all,
> 
> A friend advises me that today House Bill 666 passed. This supposedly would
> allow police officers to use evidence collected illegaly if they 'believed'
> that it was collected in good faith.
> 
> Any word on it?
> 
> Thanks.
> 
> 
> 





From jmueller at gac.edu  Wed Feb  8 19:20:53 1995
From: jmueller at gac.edu (jmueller at gac.edu)
Date: Wed, 8 Feb 95 19:20:53 PST
Subject: Vernor Vinge info...
Message-ID: <199502090320.VAA04884@poblano.gac.edu>


This may or may not have been already mentioned, but I've noticed that
Vernor Vinge will be the Guest of Honor at this year's Minicon Science
Fiction convention in Minneapolis, MN over easter weekend.  I'm planning
on going, and was just wondering if anyone here had anything in particular
they'd like me to ask him, should I get the chance to talk to him
(considering that I know quite well the chairman of last year's Minicon,
this is distinctly possible).  If anyone would like to attend, memberships
are $25 until February 14, then $55 after that and at the door.  Contact
me for further info if you're interested.

-- 
    Joel Mueller - "Here lies one whose name is writ in water."    -Keats
   		   Check my .plan for my PGP Public Key.  
 		    PGP encrypted mail is very welcome!
  This must be Thursday.  I never could get the hang of Thursdays.  -Dent




From msattler at jungle.com  Wed Feb  8 19:25:52 1995
From: msattler at jungle.com (Michael Sattler)
Date: Wed, 8 Feb 95 19:25:52 PST
Subject: Judges-L FAQ
Message-ID: <v0300141bab5f39c0aa65@[140.174.229.204]>


At 17:40 2/8/95, James A. Donald wrote:

>But I repeat, I think that the judges list is necessary
>and desirable, so long as they remember they are self
>appointed and do not start to imagine that they are
>the "official" judges.

By choosing that name they've shown (to my satisfaction) that they have the
subtlety and self-importance of a lynch mob.  The goofiness about a
copyrighted FAQ only adds to my feelings of them being a dangerous keystone
kops net-alike.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From silly at beat.ugcs.caltech.edu  Wed Feb  8 19:38:08 1995
From: silly at beat.ugcs.caltech.edu (me)
Date: Wed, 8 Feb 95 19:38:08 PST
Subject: S314 and potential hell-raising
Message-ID: <3hb6vd$2q4@gap.cco.caltech.edu>


It seems that 314 is a VERY BIG potental problem, and we should
probably be doing everything in our power to find out what it REALLY
means and fight it tooth and nail.  I think Usenet is the perfect
place to take this fight, but I'm not sure what groups are best 
suited to a discussion.  Any suggestions?

We simply MUST isolate this bill and, if it even comes close to sounding
like what I think it does (ending the near-absolute freedom of expression
and content across the Internet), we must fight it in every way possible,
enlisting the ACLU, the EFF, and any other group potentially willing
to pour money into a legal battle.

(me)





From jrochkin at cs.oberlin.edu  Wed Feb  8 19:40:30 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Wed, 8 Feb 95 19:40:30 PST
Subject: Not necessarily crypto but scary anyway...
Message-ID: <ab5f3ee0020210049ec6@[132.162.201.201]>


At 9:50 PM 02/08/95, Black Unicorn wrote:
>As I understand the bill,(Though I didn't know it was up for passge...)
> this is merely a restatement of the current judicial doctrine which
>prevents officers acting in good faith from being hindered by an
>illegally issued warrant.  In essence the concept is that the 4th
>ammendment is intended to deter police misconduct by kicking out evidence
>gathered illegally.  Once a judge issues a warrant, and assuming it is
>issued illegally, but with no knowledge by the officers who execute the
>search, there is no longer any deterant value in supressing the evidence
>and as such it would be "counterproductive" to bar it from presentment.

Right, just what we want to do. Encourage police officers to remain as
ignorant as humanly possible about constitutional law and citizens' rights.
If the police officers can manage to remain so ignorant of con law that
they have absolutely no idea that sometimes they aren't supposed to search
citizens' property, appearantly all the evidence they aquire will be
admissible in court.

Well, I feel safer knowing that we encourage a police force that won't let
a little knowledge of the bill of rights interfere with there ability to
apprehend drug dealers, terrorists, and pedophiles.

But if it's already current practice, it's already current practice.  Of
course, it would be nice if our legislators took time to write law which
_increased_ our rights, or which more strictly defined rights that previous
legislation and constitution as interpreted by the courts defined loosely.
Instead, we seem to to expect congress to constantly try to get laws by the
supreme court that are completely totalitarian, and feel lucky when they
merely reinforce preexisting undesirable court decisions. sigh.  Jefferson
_and_ Hamilton are both spinning in their graves.







From eric at remailer.net  Wed Feb  8 19:51:32 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 19:51:32 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <v01510100ab5f0c4d5b89@[166.84.250.21]>
Message-ID: <199502090349.TAA24428@largo.remailer.net>


   From: dmandl at panix.com (David Mandl)

   For a while, we were all convinced that the FCC left all these rules
   impossibly vague on purpose, just so that you didn't even know how to obey
   the law if you wanted to.  Everyone a potential criminal.

Just like the banking world, where it's no secret at all.

Did y'all know there's a separate market segment in the banking
business called "Compliance"?

Eric





From tcmay at netcom.com  Wed Feb  8 19:58:00 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 8 Feb 95 19:58:00 PST
Subject: Da Judge-L FAQ -- We are not Amused
Message-ID: <199502090356.TAA04852@netcom10.netcom.com>



It has come to Our attention that Our FAQ, the Da Judge-L FAQ, is being
distributed amongst the rabble.

We are not amused.

The so-called Cypherpunks List, having been a party to this illegal
and "most heinous" distribution, is hereby invited to appear in our
Chambers on the morning of Tuesday, 29 February, 1995, at a place of
our choosing. Defense will be heard, and then the guilty will be
punished.

Royally Yours, 

Da Judge-L








From Jaeson.M.Engle at josaiah.sewanee.edu  Wed Feb  8 20:10:17 1995
From: Jaeson.M.Engle at josaiah.sewanee.edu (Rhys Kyraden)
Date: Wed, 8 Feb 95 20:10:17 PST
Subject: S314 and potential hell-raising
Message-ID: <v0151011cab5f38526c94@[152.97.12.101]>


>enlisting the ACLU, the EFF, and any other group potentially willing
>to pour money into a legal battle.


Fuck the EFF, they already lost they're place in importance. The ACLU is a very good
place to start however. Ideas??

_____________________________________                  
{-: Jaeson M. Engle    ||    jme at josaiah.sewanee.edu :-}
{-:      www server: http://josaiah.sewanee.edu/         :-}
{-: Finger 'jme at josaiah.sewanee.edu' for my Public :-}
                                        PGP block.







From eric at remailer.net  Wed Feb  8 20:10:38 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 20:10:38 PST
Subject: Hastur CT status
In-Reply-To: <199502082009.TAA22774@seabsd.hks.net>
Message-ID: <199502090408.UAA24470@largo.remailer.net>


   From: A Loose Affiliation of Millionaires and Billionaires and Babies <cactus at hks.net>

   For instance, I've asserted several times here that X.509 keys
   can be fully modelled as special cases of PGP web-of-trust keys
   with one additional field, the expiration time.  Nobody has flamed
   me, but nobody has agreed with me... since I've only read the X.509
   spec and never actually used them, I'd like some assurance that I'm
   not missing some subtleties in this approach.
   
The only real question about a particular string of bits claiming to
be a public key of a certain persona is whether the operator trusts
that the key does belong to that persona.  PGP and X.509 models both
provide their own kinds of assurances to individuals who might use a
key.  The relation between the user and the claim of ownership is the
important relationship.  Any sort of key certificate, of whatever
sort, is merely an aid to gaining trust.

Key certificates don't prove ownership.  Key certificates transfer the
need for trust in the key to the need for trust in the certificate.
Put another way, a key distribution system allows a user to trust
something harder to fake than a single key.  The transfer is the
critical point here; instead of trusting one small thing, you can
trust one larger thing.  We hope that the larger system is worthy of
our trust.

Neither PGP nor PEM is a general purpose key distribution system,
although PGP is more general than PEM.  Both have their various
arbitrary and capricious policies hardcoded into both spec and source.

I would recommend, Todd, that you not try to unify the various key
distribution systems.  It's premature.  Rather, provide a local policy
hook for the user (and this is _not_ just the sysadmin, as you know)
to specify how much trust pertains to each given keydist system, and
of what idiosyncratic sorts.

Eric





From eric at remailer.net  Wed Feb  8 20:14:43 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 20:14:43 PST
Subject: skronk
In-Reply-To: <9502081137.ZM28317@warp.mcom.com>
Message-ID: <199502090413.UAA24481@largo.remailer.net>


   From: "Kipp E.B. Hickman" <kipp at warp.mcom.com>

   You are right here. However, our observation is that an interesting
   chunk of the world is moving towards using X.509 based certificate
   infrastructures for many things.

It's that interesting chunk that RSADSI is pointing out to you.  When
you see the world through the eyes of a vendor ...

And you know, of course, that PEM really stands for Patent Extension
Mechanism.

I don't really blame you much.  I mean TIPEM handles all the X.509
stuff just fine and PGP can't get out even the simplest of libraries,
or even a partial library.

Eric





From eric at remailer.net  Wed Feb  8 20:20:48 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 20:20:48 PST
Subject: MIME based remailing commands
In-Reply-To: <199502082037.MAA02640@jobe.shell.portal.com>
Message-ID: <199502090419.UAA24497@largo.remailer.net>


   From: Hal <hfinney at shell.portal.com>

   Is there precedent for
   adding service-by-mail functionality in this way?  

You mean, like MIME?

   (Maybe "Latency"
   might be used in a future extension of RFC822 for some other meaning than
   what we are using it for.)

The command should be Add-Delay: if you want to acheive the result of
some latency.  (Those who don't recognize the double-edged nature of
this remark are welcome to make fools of themselves in public.)

Eric





From eric at remailer.net  Wed Feb  8 20:23:40 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 20:23:40 PST
Subject: skronk
In-Reply-To: <9502081309.ZM28575@warp.mcom.com>
Message-ID: <199502090422.UAA24509@largo.remailer.net>


   From: "Kipp E.B. Hickman" <kipp at warp.mcom.com>

   Yes, there will be. We haven't formalized it yet, but we have been
   getting enough interest to warrant it. Understand that this is not
   the main thrust of our business (selling source code), so it will
   certainly take some time to put it all together.

Pardon me if I point out that when you write a new facility and want
people to be compatible with it, there needs to be source code
available for distribution.  Perhaps this is merely a lapse in
corporate self-awareness and fundamental lack of planning.  I could be
wrong.

Eric





From eric at remailer.net  Wed Feb  8 20:27:14 1995
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 20:27:14 PST
Subject: MIME based remailing commands
In-Reply-To: <9502082303.AA10796@snark.imsi.com>
Message-ID: <199502090425.UAA24521@largo.remailer.net>


   From: "Perry E. Metzger" <perry at imsi.com>

   xpat at vm1.spcs.umn.edu says:
   > IMHO, an ideal message would have the ability to handle nested objects
   > of varying types, MIME is only a start.

   What is it precisely that you might want to encapsulate that MIME
   can't encapsulate?

Perry, you're missing the whole point, just like the exchange a few
days about a remailer format standard.

MIME is primarily a packaging standard.  MIME does not define the
innards, the payload, the contents.  MIME is only a start at what the
complete data format should look like.  You say MIME, and you've not
completely specified the data format, but rather constrained it in a
way that most everybody basically agrees with, including me.

Eric





From rfdutcher at igc.apc.org  Wed Feb  8 20:38:25 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Wed, 8 Feb 95 20:38:25 PST
Subject: S. 314 and existing situation
Message-ID: <199502090439.UAA23399@mail.igc.apc.org>



Gee, fellas, looking over this bill, *most* of what's going on is
just porting existing telephone law over to cybercomm. Given the
existence of 900-sex-talk, the phone companies are clearly not being
held responsible for content.

They are required, of course, to cooperate when complaints of 
harassing or obscene calls are made, to obey properly warranted 
requests for wiretaps, etc.  It's perfectly reasonable to expect 
similar requirements on net service providers.

> 
> Read carefully. There are indeed implications for Internet service 
> providers in terms of their responsibility under the law for the content 
> of their systems and services.
> 

Yeah, but First Amendment and common carrier law is a morass of 
conflicting statutes, interpretations, and case law.  After all, 
libel law puts some content liability on newspapers [too much, IMHO, 
but it has hardly destroyed freedom of the press].

As several posters have noted, the placement of the key words 
"knowingly" and "intentionally" are critical.  It doesn't appear, 
though, that any "knowingly"s or "intentionally"s have been removed.  
I am forwarding copies of this and the whole bill text to my brother, 
the former DA in Telluride, to see if he sees any unusual craptraps.  
I'll post any useful reply ...

>    
>    (a) Prohibited acts generally
>    
>    Whoever -
>    
>    (1) in the District of Columbia or in interstate or foreign
>    communication by means of [telephone] telecommunications
>    device -
>    
>    (A) [makes any comment, request, suggestion or proposal] 
>    makes, transmits, or otherwise makes available any comment,
>    request, suggestions, proposal, image, or other communication]
>    which is obscene, lewd, lascivious, filthy, or indecent;
> 
>    (B) [makes a telephone call, whether or not conversation
>    ensues, without disclosing his identity and with intent to
>    annoy, abuse, threaten, or harass any person at the called
>    number] makes a telephone call or utilizes a telecommunications
>    device, whether or not conversation or communications ensues,
>    without disclosing his identity with intent to annoy, abuse,
>    threaten, or harass any person at the called number or who
>    receives the communication;
>    
>    (C) makes or causes the telephone of another repeatedly or   
>    continuously to ring, with intent to harass any person at the
>    called number; or
>    
>    (D) [makes repeated telephone calls, during which conversation
>    ensues, solely to harass any person at the called number; or]
>    makes repeated telephone calls or repeatedly initiates
>    communication with a telecommunications device, during which
>    comversation or communication ensues, solely to harass any
>    person at the called number of who receives the communication;
>    or

I.e., *just like with phones,* you can't send harrassing or obscene 
messages to unwilling recipients.  Is there a lot of slack for 
bullshit?  You betcha!  A major change from the present?  Doesn't 
look like it.  [no intention of holding up the present as paradise, of 
course  ;-]

>    
>    
>    (b) Prohibited acts for commercial purposes; defense to prosecution
>    
>    (1) Whoever knowingly -
                         ^^^^^^^^^^ [applies to A & B below]
>    
>    (A) within the United States, by means of [telephone], 
>    telecommunications device makes (directly or by recording device)
>    any obscene communication for commercial purposes to any person, 
>    regardless of whether the maker of such communication [placed the
>    call] placed the call or initiated the conversation; or
>    
>    (B) permits any [telephone] telecommunications facility under such 
>    person's control to be used for an activity prohibited by
>    subparagraph (A), shall be fined in accordance with title 18 or 
>    imprisoned not more than two years, or both.
>    
>    (2) Whoever knowingly -
                         ^^^^^^^^^^ [applies to A & B below]
>    
>    (A) within the United States, [by means of telephone, makes]
>    by means of telecommunications device, makes, knowingly
>    transmits, or knowingly makes available (directly or by recording 
>    device) any indecent communication for commercial purposes which is 
>    available to any person under 18 years of age or to any other person 
>    without that person's consent, regardless of whether the maker of
>    such communication [placed the call] placed the call or
>    initiated the communication; or
>    
>    (B) permits any [telephone] telecommunications facility under such 
>    person's control to be used for an activity prohibited by subparagraph 
>    (A), shall be fined not more than [$50,000] $100,000 or imprisoned not 
>    more than [six months] 2 years, or both.
>

===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From msattler at jungle.com  Wed Feb  8 20:44:47 1995
From: msattler at jungle.com (Michael Sattler)
Date: Wed, 8 Feb 95 20:44:47 PST
Subject: Da Judge-L FAQ -- We are not Amused
Message-ID: <v03001423ab5f4cb21df1@[140.174.229.204]>


At 19:56 2/8/95, Timothy C. May wrote:

>It has come to Our attention that Our FAQ, the Da Judge-L FAQ, is being
>distributed amongst the rabble...Defense will be heard, and then the
>guilty will be punished.

Thank you, Sir.  May I have another?

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From slowdog at wookie.net  Wed Feb  8 21:08:42 1995
From: slowdog at wookie.net (slowdog)
Date: Wed, 8 Feb 95 21:08:42 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <9502082149.AA28226@tis.com>
Message-ID: <Pine.LNX.3.91.950209000839.7928B-100000@chewy.wookie.net>


On Wed, 8 Feb 1995, Carl Ellison wrote:

> >From: jpp at markv.com
> 
> >of the very most important rights.  To hold the owner of a buliten
> >board responsible for the illegal messages posted to it, is to force
> >the buliten board owner to become a government censor in all but name
> >(and wages).
> 
> anyone heard of "no unfunded mandates" ?

This is one of my favorite pet arguments in this case. With the no 
unfunded mandates notion in the air for the States, why can't sysops 
demand the same treatment, given the resources that would have to be 
devoted to tracking content on their sysytems.


- dog







From ethridge at netcom.com  Wed Feb  8 21:19:02 1995
From: ethridge at netcom.com (Allen B. Ethridge)
Date: Wed, 8 Feb 95 21:19:02 PST
Subject: The drumbeat against anonymity continues....
Message-ID: <ab5f548601021004d020@DialupEudora>


Late night, off the top of my head, so no quotes, please.

Tim May wrote:
>
>
>The real "drumbeat" article is about cellular phone fraud and
>toll-free number fraud. Actaully, a couple of related articles.
>(Everyone should at least skim "RISKS.")
>
>Anonymity is cited as a problem. But this misses the point, that the
>real problem is lack of a proper payment model. As David Chaum points
>out, there are really only two basic payment approaches: transfer of
>something of value or an account-based transfer. Cash or barter are
>examples of the first, checks or credit card payments are examples of
>the second (though each has some wrinkles). Digital cash, when online
>cleared, behaves mostly like real cash.
>
>The phone companies that are complaining about fraud have inadequately
>arranged for security and need to adopt a mode that fixes this. Since
>physical money can't be fed into the slots of a handheld cell phone (or
>at least can't then be delivered to the service owner!), the solution
>has traditionally been an account-based payment system. (Accounts can
>also be better protected against fraud by having PINs, etc.)
>

The technology to reduce cellular fraud, through encryption and
authentication, is easily implementable, but for some reason neither
the operating companies nor the manufacturers want it.

In contrast, European cellular (GSM) products do implement
encryption and authentication (at least as far as laws allow).
GSM mobile phones can be equipped with a slot for a card that
identifies the subscriber.  Billing is based on the subscriber's
identity, not the phone's.

I'd say that the problem isn't just a lack of a proper payment
model, but also an unwillingness to provide adequate technology
to the problem.  Of course, the GSM approach does nothing for anonymity
or digital cash.

allen at well.sf.ca.us          It's dangerous, child, to come to conclusions
ethridge at netcom.com          when you don't have any facts.
my opinions are my own       Dr. Hemlock, The Eiger Sanction







From skaplin at mirage.skypoint.com  Wed Feb  8 22:05:36 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 22:05:36 PST
Subject: S314 and potential hell-raising
In-Reply-To: <v0151011cab5f38526c94@[152.97.12.101]>
Message-ID: <5QQElKjqRmxA078yn@mirage.skypoint.com>


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


In article <v0151011cab5f38526c94@[152.97.12.101]>, you wrote:
> >enlisting the ACLU, the EFF, and any other group potentially willing
> >to pour money into a legal battle.
>
>
> Fuck the EFF, they already lost they're place in importance. The ACLU is a very good
> place to start however. Ideas??

There are going to be a lot of factions involved with this one. Some
desirable, some not. (I leave it up to the individual to make the
judgment) Maybe we can learn something from the military and apply c3
(Command, Control and Communications) to this. Set up a forum for
coordinating efforts, delegate tasks, most important communicate so we
don't waste resources on redundant efforts. The religious right has
successfully been doing this for years. Perhaps a dose of their own medicine
is in order. Anyone care to create a newsgroup? ;)


- --
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
                 Be careful when playing under the anvil tree.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLzmurMlnXxBRSgfNAQEN/wf9EXER7hq44OeA0mL5QH1S+Px4tV1xlLE+
3DGItShAqwgHfQLxcD4oceIk6ZK1pYCytK7dnKeGNRynKKPoxDyFzAjLnI6xptMr
F72Uonzx/jhtodP7a+N0S3I7f4Hz362E0Wuplw0EItD3NaXEItaqyc7UXnZTXx61
/ER9/w0Pt9Fg56ULXNyp707xzfyeXeynQo51Rnox6/lL21T381KmzpS4npRUF9q4
XyifQYVeG23UHCujsHK6lbKFNVUZJYvaNZC7nSYJntb+rCSNAp983GUoUSPC7x7h
Vp/XfSVttZNVfmUUAtLnN5TYqR3uCUEJOzTam8LzxQi8m0VROTBagg==
=KoNH
-----END PGP SIGNATURE-----






From skaplin at mirage.skypoint.com  Wed Feb  8 22:05:41 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 22:05:41 PST
Subject: S314 and potential hell-raising
In-Reply-To: <3hb6vd$2q4@gap.cco.caltech.edu>
Message-ID: <sDQElKjqRO9A078yn@mirage.skypoint.com>


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


In article <3hb6vd$2q4 at gap.cco.caltech.edu>, you wrote:

> We simply MUST isolate this bill and, if it even comes close to sounding
> like what I think it does (ending the near-absolute freedom of expression
> and content across the Internet), we must fight it in every way possible,
> enlisting the ACLU, the EFF, and any other group potentially willing
> to pour money into a legal battle.

I just got a reply from Stanton M. from EFF today. To paraphrase, "No we're
not in favor of it and we're working on a response."

- --
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
         A pessimist sees "No parking." - An optimist sees "Anytime."

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLzmujslnXxBRSgfNAQFk8gf8DDjpbTHnSAb9os88Xu2UlYfJWsAoNFf5
cT8kY9XS0yRyeTfIuKmiZqC+tc1QqA6+K/EgwFYlpx9TY3dgn44hrWlAQkMRR4a5
P9ugjtNJXIlbWlS6r4XSOZeUABy8WnQfkkHM2UHAKtmxv2dnA7nXBzkeWAuF7kMc
ECgBbb468jMQOVhXjKxVXh/KLQtw/Ujb89jMBlQa5wi2ddnQ0fisDwhH0ZhKQ9Ih
GkJHhZCiIUEoCe09ye3eM5pyM9BuXr5hjV7pPUuXtFjqHeFFHZdLRv/ERuHL7z4n
w7JuxxyHmh84ZG4f9asakuFL3eLHuIEId5LJvtKN7BMnMv+iVPDZHQ==
=pPn0
-----END PGP SIGNATURE-----






From skaplin at mirage.skypoint.com  Wed Feb  8 22:06:51 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Wed, 8 Feb 95 22:06:51 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.3.89.9502081135.A7848-0100000@netcom10>
Message-ID: <PiQElKjqRmN1078yn@mirage.skypoint.com>


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


In article <Pine.3.89.9502081135.A7848-0100000 at netcom10>, you wrote:
> On Tue, 7 Feb 1995, Samuel Kaplin wrote:
> > I find it amazing that CPR and EFF
> > haven't picked this up yet.
>
> Really?

I had at least hoped that they would have their ear to the ground.
Unfortunately I was wrong. ;(


- --
==============================================================================
skaplin at skypoint.com                   | Finger skaplin at infinity.c2.org for
                                       | a listing of crypto related files
PGP encrypted mail is accepted and     | available on my auto-responder.
preferred.                             | (Yes...the faqs are there!)
                                       |
Finger skaplin at mirage.skypoint.com for | "...vidi vici veni" - Overheard
PGP public key.                        | outside a Roman brothel.
                                       |
Fax Number  +1 (612) 928-9771          | An UZI beats five aces every time...
==============================================================================
  "A survey is being made of this":  We need more time to think of an answer.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLzmux8lnXxBRSgfNAQFDMwf/WrbC5T+GG7HB9TfTqJGbucaqlZO7rIVe
R+xIYnG2feHT5vR43UpkpEVELLaMuiZBrQgEmBRY7U5EQcNqJQKcOZlZ4rUeFW29
ZMJtBFxmzx0SfRlx4YBMxNMnmFqlisXZuMzEoZbW5S+phskOeOMGbC/TtrIh1cJO
wNPa2CcpS71xr4P1nWvC2yJevsbcDz49zwPwNxMibKHTz8AgskCKGwbhH1D8nanc
z4Jl6g0bk9DkzQZgiU91FHfRLwmuvzhWa8hN0x6wNxzdt5GFCPR+Ju+i8silhw+u
IlJP61Cn3W+wGkpRXniYhXn8chBwfNvPIKUABMtylQPRRvDB6BCVPw==
=icAg
-----END PGP SIGNATURE-----






From root at einstein.ssz.com  Wed Feb  8 22:17:25 1995
From: root at einstein.ssz.com (root)
Date: Wed, 8 Feb 95 22:17:25 PST
Subject: S314 and potential hell-raising
In-Reply-To: <sDQElKjqRO9A078yn@mirage.skypoint.com>
Message-ID: <199502090612.AAA03687@einstein.ssz.com>


> 
> I just got a reply from Stanton M. from EFF today. To paraphrase, "No we're
> not in favor of it and we're working on a response."
>
What other kind of responce other than no compromise should be entertained?

                                                Ravage
                                                 A
                                                  Konfused
                                                   Xfrmr
 




From nobody at tower.techwood.org  Wed Feb  8 22:28:07 1995
From: nobody at tower.techwood.org (Name Withheld)
Date: Wed, 8 Feb 95 22:28:07 PST
Subject: Coming to a newsserver near you alt.defeat.s314
Message-ID: <199502090627.WAA01928@tower.techwood.org>


Psychic Flash...This group will be up on auto-subscribing news server's
VERY soon.





From slowdog at wookie.net  Wed Feb  8 22:30:35 1995
From: slowdog at wookie.net (slowdog)
Date: Wed, 8 Feb 95 22:30:35 PST
Subject: S314 and potential hell-raising
In-Reply-To: <5QQElKjqRmxA078yn@mirage.skypoint.com>
Message-ID: <Pine.LNX.3.91.950209013119.8049A-100000@chewy.wookie.net>


On Wed, 8 Feb 1995, Samuel Kaplin wrote:

> There are going to be a lot of factions involved with this one. Some
> desirable, some not. (I leave it up to the individual to make the
> judgment) Maybe we can learn something from the military and apply c3
> (Command, Control and Communications) to this. Set up a forum for
> coordinating efforts, delegate tasks, most important communicate so we
> don't waste resources on redundant efforts. The religious right has
> successfully been doing this for years. Perhaps a dose of their own medicine
> is in order. Anyone care to create a newsgroup? ;)

It's coming, soon. Keep your eyes peeled for an announcement.


- dog







From Jaeson.M.Engle at josaiah.sewanee.edu  Wed Feb  8 22:35:05 1995
From: Jaeson.M.Engle at josaiah.sewanee.edu (Rhys Kyraden)
Date: Wed, 8 Feb 95 22:35:05 PST
Subject: S314 and potential hell-raising
Message-ID: <v01510134ab5f5a5a36be@[152.97.12.101]>


>What other kind of responce other than no compromise should be entertained?

Very much agreed. In this type of situation there is no room for compromise.
If we compromise, we lose, thus my earlier snipy comment about EFF. They compromised and lost. We cannot do this now, we must win this or it starts going downhill from here.

_____________________________________                  
{-: Jaeson M. Engle    ||    jme at josaiah.sewanee.edu :-}
{-:      www server: http://josaiah.sewanee.edu/         :-}
{-: Finger 'jme at josaiah.sewanee.edu' for my Public :-}
                                        PGP block.







From lcottrell at popmail.ucsd.edu  Wed Feb  8 22:35:18 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Wed, 8 Feb 95 22:35:18 PST
Subject: MIME based remailing commands
Message-ID: <ab5f62d802021004dd65@[137.110.24.250]>


>Nathaniel Borenstein <nsb at nsb.fv.com> writes:
>
>>Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co..
>>"Perry E. Metzger"@imsi. (2553)
>
>>> > > It is being remailed via a MIME-based structure where two new
>>>content types
>>> > > are defined: multipart/remail and application/remail-commands.  The
>>> > > multipart/remail type is supposed to be composed of two parts, the
>>> > > application/remail-commands part which has remailer commands, and the
>>> > > other part which is the "payload" to be remailed.
>
>>Perhaps you might consider writing up an informational RFC to define
>>these types?  I think that would be very useful. -- Nathaniel
>
>Well, that was just an example; I was making those names up off the top
>of my head in order to concretize what I understood Perry was suggesting.
>
>I can see that putting remailer commands into a specific part of a MIME
>multipart message has some advantages.  Right now we are basically
>having the remailing commands be mail header fields.  But really people
>aren't supposed to just make up new fields like that.  I think the
>"name space" of these fields is protected somewhat more than many other
>aspects of communication protocols on the net.  Is there precedent for
>adding service-by-mail functionality in this way?  I am not completely
>comfortable with it.  And as we think of new functionality and new
>commands they all have to get added at this top level, the same
>visibility and name space as "Subject", "From", and "To".
>
>OTOH it does have the advantage that it is easy to do, at least with the
>"::" pasting token idea (which perhaps would need to be documented in its
>own right).
>
>If we did use a separate message part we'd have our own little name space
>to use, with no fears of conflicting with someone else.  (Maybe "Latency"
>might be used in a future extension of RFC822 for some other meaning than
>what we are using it for.)  I am not sure what has to be done to get an
>RFC approved but I suspect that adding mail header fields would be much
>more likely to hit opposition than adding yet another MIME type.
>
>What does Mixmaster use for its commands?  Does it use "::" followed by
>Anon-Send-To: and such?  Or some other format?  Maybe it should be made
>MIME compliant from the beginning.  This way we are moving with the
>current, the flow of the net, rather than across it.
>
>Hal

With Mixmaster, everything is hidden inside the encrypted and ascii armored
message structure.

I use the :: token to let the remailer know that this is a remailer message
of some sort. The Remailer-Type will eventually be used to indicate the
version that created the message. It would be easy to add support for MIME.
It would just replace the token and version number.

All remailing instructions are inside the ascii armor.
Note that the block of ascii armor is allways exactly the same length.

::
Remailer-Type: 2.0

-----BEGIN REMAILER MESSAGE-----
hQCMAgbmF1BLzawNAQP/RFw2/UagugMFPlnJ94KLmhaxDoplzAhNBCxuFRL2fosL
V1YnFd2XVckJJ6vTe6DB+POO+V7HEdXkp3sWtjb56Am+/B+tM1TdeC6NPNV4g5PC
15oYl7eD0ZxyjB34GdN5z/C2mOMbvP3k9eK3pn3ffkaXHBt1Y0I9ZieHkE6erxem
AAAAusuiqVunPh15+7gttD5pNuIAOFDKfH8NJ39ReSEFAeeiOun6KSneJT+2DJ9Q
LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58
0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h
xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj
<SNIP>
LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58
0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h
xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj
VYbH5jxvKPjF4HEaS++MaBwTvzBkEKxbS+6oh7G/ndkHBxA7d7C0sx+qX9sjJyAs
OIpGERZYA9RVspXUWys5fihnwrhk90dDAVZb8hTsPQfTXLp4
=ouPq
-----END REMAILER MESSAGE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From tcmay at netcom.com  Wed Feb  8 22:35:58 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Wed, 8 Feb 95 22:35:58 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <PiQElKjqRmN1078yn@mirage.skypoint.com>
Message-ID: <199502090633.WAA08858@netcom2.netcom.com>


Samuel Kaplin wrote:

> In article <Pine.3.89.9502081135.A7848-0100000 at netcom10>, you wrote:
> > On Tue, 7 Feb 1995, Samuel Kaplin wrote:
> > > I find it amazing that CPR and EFF
> > > haven't picked this up yet.
> >
> > Really?
> 
> I had at least hoped that they would have their ear to the ground.
> Unfortunately I was wrong. ;(

It's a tough thing for them to be involved enough to know what's going
on, but not so involved as to be a partner in the process.

We mostly all criticized them roundly for the Digital Telephony Bill
(I did too). They seem to have somewhat backed off from this approach,
or so it now appears to many of us. (Caveat:  before this is read by
EFF folks and indignantly denied, I make no claims of what the causal
chain was, what Berman's departure has to do with this, etc. Hence the
"they seem to have" phrasing.)

Anyway, how can we expect them to know about upcoming legislation if
we also despise the "inside the Beltway" mentality?

Frankly, I'd rather have them on our side, helping to fight bad
legislation, than working on the inside of things and thus face
compromise by the whole process.

As scary as S.314 is, I'm not sure it's likely to pass. Unlike the
Digital Telephony Bill, which was on greased skids, this  one seems to
have come out of left field. I could be wrong on this, and maybe it's
got a lot of sponsors, but it sounds like just another Bill that will
die in committee or fail on the floor.

(This is where the D.C.-net people, those who are connected to the
political process, can tell us who's likely to support it and who's
not.)

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From alkahest!joshua at dee.retix.com  Wed Feb  8 23:21:56 1995
From: alkahest!joshua at dee.retix.com (joshua geller)
Date: Wed, 8 Feb 95 23:21:56 PST
Subject: S314 and potential hell-raising
In-Reply-To: <v0151011cab5f38526c94@[152.97.12.101]>
Message-ID: <199502090715.XAA14870@alkahest.isas.com>



>   >enlisting the ACLU, the EFF, and any other group potentially willing
>   >to pour money into a legal battle.

>   Fuck the EFF, they already lost they're place in importance. The ACLU is 
>   a very good place to start however. Ideas??

there's room for another organization I think. there are, in my opinion,
two reasons why the NRA is as effective as it is: it has a single issue
that it concerns itself with and it never compromises.

so what, in very few words and as clearly as possible, is our issue?

josh








From alkahest!joshua at dee.retix.com  Wed Feb  8 23:23:08 1995
From: alkahest!joshua at dee.retix.com (joshua geller)
Date: Wed, 8 Feb 95 23:23:08 PST
Subject: Da Judge-L FAQ -- We are not Amused
In-Reply-To: <199502090356.TAA04852@netcom10.netcom.com>
Message-ID: <199502090712.XAA14865@alkahest.isas.com>



here come de judge:

>   The so-called Cypherpunks List, having been a party to this illegal
>   and "most heinous" distribution, is hereby invited to appear in our
>   Chambers on the morning of Tuesday, 29 February, 1995, at a place of
>   our choosing. Defense will be heard, and then the guilty will be
>   punished.

yes. a fair trial and a speedy execution.

josh











From NSO at delphi.com  Wed Feb  8 23:38:21 1995
From: NSO at delphi.com (Network Security Observations)
Date: Wed, 8 Feb 95 23:38:21 PST
Subject: NSO Challenge 95 Nr. 1
Message-ID: <01HMTVLQZ2MW90GONH@delphi.com>


***********************************
Network Security Observations
Challenge Nr. 1995-001
February 8, 1995
***********************************

Network Security Observations
invites the international research
community to produce a detailed
presentation on the following subject:

> Establishment, authentication, and
verification of a relationship and
untraceability of undeniable secret
transactions <


             Conditions
- Party A (Alice)
- Party B-n (Bob)
- A multitude of Bobs know who Alice is
- Alice - being only one party - does not
personally know who the Bobs are
- It is the desire of Alice to transact
- Bob - only producing a certain proof -
remains further a static party
- At one given time Alice established a
relationship with Bob-n
- Further, from time to time Alice wants
to check this relationship with Bob-n
- Alice may utilize the verification
process only for this purpose
- At a given point Alice might want to
terminate her relationship with Bob-n, or
vice versa

- It is essential that the relationship
between Alice and Bob-n is set up so that
Bob can prove to Alice that he is the
legitimate Bob, but, in such a way that
his real identity remains secret for Alice
- Alice can only use this procedure to
verify Bobs legitimacy
- Alice may only verify, but not register
- Alice may have the option to repeatedly
challenge Bob s legitimacy, but the
conditions under which these separate
verification checks take place may not be
registered as well
- Alice now wants that Bob can undeniably
prove to her that he is who he says he is,
by untraceable number verification, thus
without actually knowing the real identity
of Bob, and without the ability to utilize
the verification process for any other
purpose

The presentation should include the full
theoretical processes, applying known
cryptographic algorithms, the theories of
undeniable untraceable number verification
and secret transactions as developed by
Dr. David Chaum (see proceedings Crypto,
Eurocrypt, etc.), and envision a practical
applicability in a real world environment.

The presentations will be judged by a team
of seven international experts of senior
academic/research level.

The best presentation will receive
international acclaim (including, but not
limited to TV)  and a (secret)
financial reward of substance.

It is essential to register, (name,
surface mail address information,
affiliation, email address, p-pgp key
(optional)). One should do so by sending
an email message with this information to:
nso at delphi.com

Upon registration a notification and
detailed instructions will be mailed to
the individual who registers by surface
mail/airmail.

There is no limitation as to origin,
nationality, position, or seniority of the
researcher(s).

The presentation may be made by more than
one researcher, but a lead-researcher must
be registered. Co-researchers will share
equally in the benefits, allowing for one
extra share for the lead-researcher. 

There is no set maximum number of pages for
the presentation, though an extended abstract 
must be at least 15 pages, while the full paper
must be at least 25 pages in length.

The lead-researcher and at least two co-
researchers (if any) must be prepared to
present the efforts in person during an
international conference.

Commercial entities/companies may not participate.
Employees of commercial entities/companies may
participate individually, but must testify that their
employer shall have no benefit of their efforts.

To allow for proper preparation the
deadlines are as follows:

1. registration with NSO: ends on March 1,
1995.
2. proposed presentations (extended
abstracts) should be received by NSO on or
before August 31, 1995.
3. final presentations must be received by
NSO on or before November 30, 1995.

The presentation selection/review process
takes place in three rounds:
- first selection of the extended
abstracts
- correction selection of first round
passed
- final selection of remaining passed

More details will be available in the next
issue of Internet Security Monthly and the
next supplement of Network Security
Observations.

|    Network Security Observations  -  Internet Security Monthly
|    International Research Journals on 
|    Datacommunications and Network Security 
|    Suite 400, 1825 I Street NW, Washington DC 20006
|                                 United States 
|    Telephone +1 202 775 4947  -   Fax +1 202 429 9574 
|                  Internet:  nso at delphi.com   
                  ----------------------X----------------------









From rparratt at london.micrognosis.com  Thu Feb  9 02:12:00 1995
From: rparratt at london.micrognosis.com (Richard Parratt)
Date: Thu, 9 Feb 95 02:12:00 PST
Subject: The drumbeat against anonymity continues....
Message-ID: <9502091009.AA03503@pero>


Allen B. Ethridge wrote:

> The technology to reduce cellular fraud, through encryption and
> authentication, is easily implementable, but for some reason neither
> the operating companies nor the manufacturers want it.
> 
> In contrast, European cellular (GSM) products do implement
> encryption and authentication (at least as far as laws allow).
> GSM mobile phones can be equipped with a slot for a card that
> identifies the subscriber.  Billing is based on the subscriber's
> identity, not the phone's.

Actually, all GSM phones use a smart card to ID the subscriber.
There was at one point the idea that this card would be useful
for other things, e.g. you could plug it into a fixed line
phone and have that phone take on your personal number, or even
use it as a payment card. However, the desire for ever smaller
phones means that the credit card form factor is dying out for SIM
cards, and one doesn't want to keep popping a 0.5" x 1" mini-SIM
out of the bowels of the phone.

GSM uses less than strong encryption, by the way. I forget the
technical details, but it is of the level that governments can
fairly readily crack, but beyond the reach of most private
organisations. (So no more 'Squidgy-gate'). It would, however,
be quite feasible to add additional second stage encryption
to phones (since the dataflow is digital point-point). I wonder
if Nokia, a Finnish company well outside the scope of COCOM,
might offer a feature like this.

Incidentally, is there likely to be any adoption of GSM
in the US in the near future?

--
Richard Parratt





From nzook at bga.com  Thu Feb  9 04:03:10 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:03:10 PST
Subject: Crusade's End
Message-ID: <Pine.3.89.9502090532.A21224-0100000@lia.bga.com>


Date: Wed Feb  1 20:35:31 1995
From: Rick Busdiecker <rfb at lehman.com>
 
        Date: Wed, 1 Feb 1995 18:59:54 -0600 (CST)
        From: Nathan Zook <nzook at bga.com>
    
        Instead of routing all of those messages to /dev/null, forward
        them back to the authors, perhaps with a notice that the message
        appears to have been mistakenly routed to you?
 
    And then all LD has to do to have lots-o-fun is to send you a whole
    bunch of "your OS sucks" messages with the From: line set to
    alt.religion.scientology at some.mail2news.site . . . .
 
    			Rick
 
Presumably, this sort of censure would occur very rapidly.  The script had
specific from/to lines it was looking for.  Neat idea, though.
 
Nathan






From nzook at bga.com  Thu Feb  9 04:03:10 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:03:10 PST
Subject: Frothing remailers - an immodest proposal
Message-ID: <Pine.3.89.9502090523.D21224-0100000@lia.bga.com>


 
kevin at elvis.wicat.com:
 
>Be gentle, though - it's my first time.
 
Here?  You jest.  ;)
 
>It seems to me that the current remailer web suffers a fundamental flaw.
>It is simply too static. When a remailer disappears, service is
>disrupted and messages are lost. Humans have to statically route their
>messages through the web either by hand or using relatively primitive
>tools such as the chain script (not to belittle the useful work that has
>been done, but it is by no means idiot proof yet). Basically, the
>current web of mailers shows nothing of the dynamic nature that has kept
>the internet alive and has offered us a decent chance at truly anonymous
>communications, nor is it easy to use to its full potential.
>
>Consider a more dynamic web of remailers. I envision remailers that
>actively advertise their presence on the web so that all active
>remailers are aware of all other active remailers. This advertising is
>to have very low latency so that a new mailer can be known to the web
>within minutes (I will address the implementation of this later). Thus,
>remailers can constantly be appearing and disappearing without impact on
>the web as a whole (I refer to this dynamic web of remailers as a
>"froth"). Imagine also that remailers are allowed to dynamically perform
>the routing functions that are currently done statically offline (for
>reasons I will discuss shortly).
>
 
Some version of this discussion came up a few months ago, and I passed on
it then, but I think I've heard enough to comment now:
 
The remailers are based on an inherently different model than the InterNet.
Some of these differences, in fact, are crucial.
 
1) The InterNet is based on mutual cooperation/mutual trust.  Cypherpunks
   trust no one that they don't have to.
 
This is not just a result of our twisted psyche.  If we could trust
everyone, we wouldn't _need_ remailers.  Since we don't even know who is
whom out there, we avoid extending trust.
 
2) The InterNet is concerned first about reliability, and not at all about
   privacy.  The remailers are concerned first about privacy, and can leave
   reliability to the users, if need be.
 
There is nothing to prevent Alice and Bob agreeing to send each other ACK
statements, and retransmitting messages if they don't get the ACK.  There
has been some mention of remailers doing the same with each other, in an
attempt to improve net-wide reliability.  BTW, with T1, sending ACKs is not
unreasonable between remailers.
 
3)  From 1) and 2).  The remailers are heading towards mandatory PGP,
    possibly nested.  All InterNet messages are world-readable--although
    this may be changing as the model breaks down.
 
Again, this has to do with the intrinsic diffences.
 
>The use of such transient routers implies allowing dynamic routing. If
>any given remailer may go down or move at any point, it is impractical
>to expect users to keep track of which are up at the moment and create
>static routes in the current manner. The only reasonable solution I have
>come up with is to allow the remailers themselves to choose routing,
>given that they have full knowledge of the current state of the froth.
 
Here we have the real head of the problem, as Hal so asutely points out:
in your model, if the first remailer is bad, the message is compromised.
If user encrypt to all remailers, they might as well encrypt directly to
mole at snakeoil.nsa.gov.  If they don't, they severly limit who can pick out
their messages.  In particular, they bypass transient remailers.
 
But that isn't all.  If the remailers pick the route, they are in a no
better state than the users.  Since the flushing attack requires remailers
to operate on ticks, with carryover, an hour delay per remailer is almost
minimal, untill traffic really picks up.  So if some message routes through
four remailers, a minimum of four hour delay results.  In your case, this
could easily move between in/out of service modes.
 
 
>                 Think about the proposed extension to MixMaster to
>allow separate parts of a multi-part message to be routed separately,
>and consider whether you really want to have to do this by hand. I
>strongly suspect that most messages are currently routed via boilerplate
>scripts, which has to make the job of traffic analysis much easier for
>our good friend Eve.
 
Stupid is as stupid does.
 
 
>By the way, a brief rant on a related topic; people speak of not
>trusting remailers any further than necessary, while I am clearly
>suggesting granting more authority and trust to the remailers. This
>notion of not assigning trust is simply nonsense. When you send a piece
>of mail to a remailer, encrypted or not, you are assigning complete
>trust in that remailer to keep you anonymous and not to forward your
>mail to the NSA immediately.
 
NOT TRUE.  With proper use of encryption, you are trusting your first
remailer only to not reveal that you sent a message, and not to correlate
that message to the one it sends out.  With rational use of garbage running
two deep, you can even suffer this loss without significant harm.
 
 
>This does lead to a related problem, however; if we allow remailers to
>pop up at random and join in the froth, how do we know that Deitweiller
>won't set up a number of black hole remailers that take your mail and
>throw it away, disrupting the froth, or forward it to nphard at nsa.gov?
 
How indeed?  The reason we chain is because we _don't_ really trust our
first remailer--or any other.
 
>Fortunately, we already have the PGP web of trust model in place and can
>use it to good effect in this case. Remailers should simply not route
>mail through any remailer whose public key is not trusted unless
>explicitly ordered otherwise. This requires remailer operators to
>cooperate to some extent to validate one another's remailer keys, but
>does confer the great advantage of portable remailers as mentioned
>above; if I run a trusted remailer on one machine, I can move it to
>another machine, and as soon as I advertise the new address and the PGP
>public key, it is a trusted and useful part of the froth.
 
Actually, there may be something here.  I don't know about you all, but my
PGP isn't very happy about all these new remailer keys.  We could agree to
the following standard:  Signing a remailers' key means that you believe
the remailer to be secure.  Trusting a remailer key means trusting the
remailer operator to validate other remailer's security.  This adds a whole
new meaning to the phrase, "key compromise certificate".
 
 
>While we are advertising a PGP key and internet address, we might as
>well incorporate other useful information. For instance, remailers could
>advertise their maximum latency. 
 
While I agree that it is useful to post the operating characteristics of
the remailers, the maximum latency must theoretically be infinite in the
standard model to prevent flushing attacks.
 
>    Kevin
 
 
 
Hal <hfinney at shell.portal.com>:
 
 
>I do like Kevin's ideas about a dynamic remailer net, but I think
>another approach would put more smarts into the client program used by
>the originator.  
 
Hear ye, hear ye!  And along those lines...
 
I'm scetchy (at best) by what is meant by "pinging" a remailer.  Would it
not be possible for live-on-the-net remailers to accept a (socket?) quick
check to see if they are online?  If so, then the ping would only work if
the remailer was active when tried.  Furthermore, client software could
startup by sending out these pings, and presenting only responding
remailers to the user--with an exception list for those not "live".
 
Nathan

P.S.:  Late breaking weakness:
Pinging a group of remailers is strong evidence that you are about to 
send a message.






From nzook at bga.com  Thu Feb  9 04:03:19 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:03:19 PST
Subject: Remailer Encryption Module
Message-ID: <Pine.3.89.9502090612.E21224-0100000@lia.bga.com>


   From: eric at remailer.net (Eric Hughes)
      From: Nathan Zook <nzook at bga.com>
 
      I also believe that hacking PGP is a bad thing (tm), because it 
means that
      every time an upgrade comes out, it will need to be re-hacked, and 
once you
      start hacking, when do you stop?
 
   I agree.  PGP just does not have the support for the encryption
   required for mixing remailers.  These deficiencies have been known for
   about two years at this point and still nothing has happened.  I
   expect this not to change anytime soon.
 
   That means that we have to replace PGP as the encryption module for
   remailers.  The first thing to do is to design a data format which
   supports what the remailers need now, and nothing speculative.  Since
   this data format has a single purpose, we can make new revisions more
   easily than for a general purpose package.
 
   Once we get a data format, implementations will follow.
 
   Eric
 
As I've considered this problem, I've arrived at essentially the same
conclusion.  We need an RSA-IDEA package that does something very close to
Mixmaster.  The only caveat is that we _must_ retain compatibility between
signature formats, even though, as I've suggested, a signature on a
remailer's key might mean something different than a signature on an
individual key.
 
Nathan






From nzook at bga.com  Thu Feb  9 04:03:20 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:03:20 PST
Subject: IQ & such
Message-ID: <Pine.3.89.9502090646.F21224-0100000@lia.bga.com>


For what it's worth, I have a tested IQ of 151.  While I am capable of
being trained to perform certain feats quite rapidly via methods that
"average" people don't understand, this is a far cry from the 30-point
never-can-be-explained claim made earlier.  There is one task that I have
observed an intuitive bonus on, but I have _never_ been unable to explain
the methods used to anyone that expressed intrest.
 
I once multiplied two 45 (decimal) digit numbers with no intermediate work
on a challenge.  I claim that my methods could be explained with no trouble
to almost anyone who can multiply two two digit number--I believe that they
are essentially the standard ones for multiprecision multiplication.
 
Nathan
 
A reasoning machine, in the shape of a man, but with no conscious, is not
truly human.
--paraphrase from a letter to the Editor in a Mensa publication






From nzook at bga.com  Thu Feb  9 04:03:49 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:03:49 PST
Subject: Lucky primes--third time's the charm?
Message-ID: <Pine.3.89.9502090512.B21224-0100000@lia.bga.com>


-----BEGIN PGP SIGNED MESSAGE-----
 
The algorithm I posted the second time works, (nice improvement, eh?) but
is likely to take several thousand years to complete.  And when it does, we
can expect weak primes.  The enhancement I propose should fix that.
 
 
As I recall, PGP uses 0x10001 for its e.  It does so in order to be able to
easily determine that e is a primitive root of unity in Fp.  Since we are
assuming that the p we actually work with is prime, we have: n^p = n mod p
ie: n^((p-1)*i+1) = n mod p.  So we want ed = (p-1)*i+1, ie: 
((ed-1)/i)+1 = p.
 
Let 2*x be the target number of bits in the modulous.  We then look for two
primes with approximately x digits such than d (for each prime in turn) is
small.  We know that ed = (p-1)*i+1, so we search for small i's that work.
d = ((p-1)*i+1)/e, so for a given p, d will be small iff i is small.
 
But in general, the calculation to invert e is long.  We therefore fix ed--
that is our n1--and hope for a small i that works.  If none work, we
increment d and try again.
 
Once we have a p that gives us a small d, we then count the 0's in d,
hoping for a high count.  If we don't get it, we increment d.
 
***
 
That is what my previous algorithm did.  Of course, we can expect a halt
exactly when d ends with a bunch of 0's, followed by a few spare bits.
B-A-D bad.
 
The solution, though, is easy: pick a random high-0 d.  Multiply it by
0x10001 to get ed, and search for small i's.  If you fail, increment d.
Doing so won't affect the number of 0's in d by much, and we expect a prime
fast enough that cumlatives won't be a problem, either.
 
***
Let 2*x be the target number of bits in the modulous.
GetPrime twice.
 
GetPrime:
Let d be a large random number with x-15 bits.
 
If d has too many 1's, pick digits at random and 0 them until d is
sufficiently 0-rich.  This would include room for extra 1s to appear as d
is incremented.
 
Let n1 = d * 0x10001
Let t2 be n1 mod 8, t3 be n1 mod 9, t5 be n1 mod 25, t7 be n1 mod 49.
 
Loop:
For i = 2 to 7
 If n1 = 1 mod i and (n1-1)/i + 1 is not a multiple of {2,3,5,7}
/* This can be done very fast, and eliminates most canidates. */
 
    If (n1-1)/i + 1  is prime, record and exit Loop.
/* This would be the long test in RSAREF, or Miller-Rabin. */
 
    EndIf
 EndIf
Next
d++
n1 += 0x10001
EndLoop
EndGetPrime
 
By keeping track of various quantities, we can eliminate all multiprecision
divisions except for the original one needed to get the t's and the first
n1/i's, and doing increments instead.
 
Nathan
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
 
iQEVAwUBLzmnanmgMs8UcStNAQECpQf6Ag8PUhiHySvv/lK8dIsmJhknKCuDR0Fi
dVT0oVnTijmz1mdX0a6tlhnXyrj+oO4sYLCsej03e+685HZSd5orCYMsMXI/12SU
f8PUVbKK7g/tDFYFah0se7cFL4kvQXwnOYDdzmfVnguW82QDDuS0iSssG42mqUKD
e0QH1jZKxMK+usRF53P0Bui7goNfk7MkN2hI/ShMQggywcDQHYRX/d3QHkhZp6iG
P7rJrW2aRxHYQT9MtiSpOv64Ae1JvmJk4DLXYMhXOSQet8xntRTnm4FIoVStBRmb
dTnOj0d//dHyYWWEVKKFz0GoepnglxjQ0/k3PAKvVgPV5DWzn3xFJQ==
=PzTo
-----END PGP SIGNATURE-----






From nzook at bga.com  Thu Feb  9 04:05:18 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:05:18 PST
Subject: Why encrypt intra-remailernet.
Message-ID: <Pine.3.89.9502090621.G21224-0100000@lia.bga.com>


-----BEGIN PGP SIGNED MESSAGE-----
 
I was finally able to read Lance's stuff.  Great work!  Ironically, I
arrived at the conclusion that his methods are necessary just before
downloading my mail (including his stuff).  With that in mind, I have now a
new DRAFT:  model.  I anticapate continued discussions on this matters
mostly under that topic.  Also, could you send me a copy of Chaum's paper?
I don't have metamail, but I can convert GIFs, if you could send it PGP -a.
Thanks!!!!!!!
 
 
> From: Nathan Zook <nzook at bga.com>
> [ Re: remailers checking signatures on incoming messages ]
> > What benefit does Alice gain?
> > 1) Plausible deniability.  Remember, "reasonable doubt."  Remember Abscam?
> >    The gov't is in a good position to fake source info.  This squishes
> >    that.  (It squishes even better if Chaum _requires_ signatures.)
> 
> She doesn't get that.  A signature lets her prove that she sent a
> message.  It doesn't let her prove she didn't send a message.
> 
 
If Chaum only accepts validly signed packets, she can.  (Or at a minimum,
the government must demonstrate that she compromised these other keys.)
 
 
> > 2) If Chaum sends Alice a copy of the message that failed the signature
> >    check, Alice knows that someone is trying to spoof her.  This
> >    information may be critical in determining how serious her opponents
> >    are.
> 
> I don't really understand this threat that Alice may be "spoofed".  Why,
> of all places, would her opponents try to spoof her through an anonymous
> remailer?  Isn't this kind of like sending mail with no return address,
> and pretending it comes from someone else?  This seems terribly subtle.
> 
 
It's called "faking evidence".  It's a real problem, especially if you are a
religious nut with guns.  Or just a nut with guns.  If the government knows
you are using the remailers, and wants to establish that you are using them
to conspire, this is the only way to fake evidence.
 
 
As for hacking PGP, I am convinced that the mixmaster-type remailers
require their own package.  Coming soon.
 
 
> I can see the problem with standard packets in a chaining context, that
> they would shrink slightly in size as each successive remailer stripped
> off its envelope.  Re-encrypting would solve this by providing more
> padding.  OTOH you can actually stick padding into a PGP packet if you
> know what you're doing.  I have a perl script around somewhere which will
> do this.
> 
 
But padding is worthless if Eve runs some of the remailers.  I know I just
changed the threat model, but stay tuned...
 
 
> > The most obvious one: Eve checks messages (in vs out) for matching tails.
> > If the tails match, the messages match.  The only way around this is for
> > the entire message to be wrapped.  Thus, the extropian requirement.  
> 
> It is true that encrypting messages intra-remailer would prevent this
> attack as far as that one remailer in the chain is concerned.  But it
> seems to me that the message still suffers from this attack against the
> remailer network as a whole.  This points up the fundamental problem with
> this form of encrypted reply block.  They are really not secure unless
> the body itself gets transformed at each step as in Chaum's model.
> 
 
This attack fails if the last link encrypts on the way out, since the
session key changes.  Bob still gets the dupe message, Eve gets no info.
There may be another way to handle dupe messages, stay tuned...
 
 
> > When I say that the Mark I remailers are laughably easy to crack, I mean
> > laughably easy.
> 
> None of this is news.  
 
Then why did you say, "Let's not start rumors..."?
 
 
> > Get stuck?  Need a hint?  Resend a message.  Watch for the repeat on the
> > out.
> That's why Chaum identified one of the main features of a remailer being
> that it would reject duplicates.  Mixmaster does some version of this,
> although that needs improvement to really meet this attack.
> 
 
Not if Chaum encrypts to Bob.  Chaum encrypting to Bob pushes Eve back to
Wei Dai's work.
 
 
> > Alice has been hauled into court.  The Feds claim that she is the one that
> > actually sent messages M1,...Mx to Bob through Chaum, even though these
> > messages have varied From: (and From) lines.  As root, she cannot claim
> > that this is not possible.  OTOH, if Chaum requires a match, the Feds would
> > have to claim that she compromised the secret keys of all of all the
> > cooresponding From: addresses.  Much tougher.
> 
> OTOH, if Alice actually has signed those messages, her jig is up pretty
> good, wouldn't you say?  Do we really want to force people to use the
> nets in a mode in which they can be incriminated like this by a hostile
> government?
> 
 
I suppose that depends on the threat model.  If the gov't has control of
all the remailers, she's toast, except for being able to claim that the
message was forged.  Here, she loses.  In all other models, the gov't gains
only the proof that she used the remailer net.  In and of itself suspicious
(some places and times), but presumably _not_ a hanging offense.
 
 
> > Seriously, if a sight is being shadowed, then it is insecure.  It is to our
> > advantage to know this.  You are right that we "don't care" where a message
> > comes from only if we assume that the message _didn't_ come from an LEA.
> > (Or a big corporation.  Some of them probably have the power to do this,
> > too.)
> 
> Hell, Detweiler has the power to do this!  He's spoofed messages plenty
> of times.  How do we know?  Because of remailer logging.  That's the real
> threat, IMO (the logging).
> 
 
I mean the power to spoof a remailer, in the sense of processing messages
for it, possibly altering them.  I admit, with intra-remailer encryption,
this is equivalent to compromising the key.  
 
 
> > If it did, then the remailer net is under attack, and we most
> > definitely _do_ care about that.
> 
> Even if a message comes from a fake address that is hardly evidence of an
> attack by a powerful opponent.  It could just be an extra-paranoid
> legitimate remailer user who doesn't want to extend any more trust than
> necessary.
> 
 
Yes, but...  If the address faked is nzook at bga.com, then I have something
to be upset about, no?
 
 
> I meant to refer to encrypted messages identical in size and otherwise
> opaque, so that your apparent rate of output is constant.
> 
 
Okay, but in practice we need a lot of garbage.
 
 
> > >Do you see your suggestion as protecting against Wei's in/out correlation
> > >attack?  
> >  
> > Yes!  Well, not by itself.  My suggestions about "rational use of garbage"
> > do that.  If Bob recieves x messages each tick, 0 to x of which are real,
> > Eve is hosed--if all messages are standard sized & encrypted!.  Eve is even
> > more hosed if the x messages are concatenated & superencrypted.  If Alice
> > sends y messages each tick, Eve is hosed.  Even more so if the messages are
> > concatenated & superencrypted.
> 
> How can Bob arrange to receive a constant number of messages each tick?
 
Every remailer knows to send Bob x messages per tick.  It's right after his
PGP key in the database.
 
 
> Do all his messages come from one remailer?  Or do all of the remailers
> which might send to him check among themselves before sending to him so
> they can mutually know how many fake messages to send?
> 
 
Each remailer does its own work.  The sum of equals is equal.
 
 
> IMO the real solution to the correlation attack is to have a constant
> message generation rate.  That is sufficient.  Solutions to the other
> attacks mentioned in Chaum are described in Chaum.  (This attack was not
> described in Chaum's paper.)
> 
 
But the correlation attack might mean more than just A sending to B.  It
could be B recieves message, then commits act X.
 
 
> > >Of course it was Chaum himself in his 1981 paper (which I think is available
> > >from the CP FTP site) who described the duplicate-message attack.  I don't
> > >see that inter-remailing encryption helps much, because the attacker can
> > >still notice that whenever they inject message A, _something_ goes to
> > >Bob.  The real solution, as Chaum pointed out, is that the remailer must
> > >reject duplicate messages, even when separated by days.  Doing this without
> > >keeping a database of all messages ever sent is left as an exercise.
> > >
> >  
> > I disagree.  If identical input to Chaum does not produce identical output
> > to Bob, how does Eve coorelate them?  Repeating, she can match the top of
> > the body of messages, so random tails reveal the actual encrypted message,
> > for whatever that is worth.
> 
> I'm not sure what you mean by "matching the top of the body of messages".
> Are you referring to an encrypted reply block, which might be the same
> for two different messages to the same user?  Or are you suggesting that
> messages would have some headers or some other structures at their top
> which would be preserved through a remailer?
> 
 
No.  I was refering to your trust in packing garbage on the end of a pgp
message.  If the headers and bodies are encrypted separately, and the
remailers just tack garbage onto the end of the message, you get 12345xyz
one time, and 12345pqr the second.  Match.
 
 
> > And if Bob receivs x packets per tick, or a BIG packet every tick, how does
> > Eve trace it?
> 
> If the input to Bob really can be made constant across the whole remailer
> net then this does seem to largely protect against duplicate-message
> insertion, in conjunction with the intra-remailer encryption.  However it
> would apparently also be necessary for every remailer to send a constant
> number of packets to every other remailer.  Otherwise a bolus of
> duplicates into one remailer would all leave to go to the next remailer
> at once and would show up.  This means that the net as a whole has to
> carry a constant traffic load on all inter-node links, which could mean a
> large cost in bandwidth load.
> 
 
Your analysis, as I see it, is essentially correct.  I think that the total
load can be time-dependent, but should be even across all remailers on each
tick.  We need a lot of garbage in the net in order to cover all types of
attacks/foolish useage.
 
 
> No, of course message size standardization is a necessary step.  This has
> been recognized for 15 years.
> 
 
So why mention it in this context?
 
 
> > >          It's one thing if I send a message along with thousands of
> > >other people, and Bob gets a message along with everyone else.  But if I
> > >send 10 messages and Bob gets 10 from that batch, that fact alone can
> > >help to link us up.  So splitting my big message into 10 standard ones
> > >isn't that great if they're all sent at once.  Ideally you'd want to
> > >dribble them out at some standard rate, a rate at which you always send
> > >a message whether you have something to send or not.  But this may introduce
> > >unacceptable latency.
> >  
> > "Dribble them out at some standard rate".  Yes.  y packets per tick.  Set y
> > equal to your average number of real packets per tick, plus 3 standard
> > deviations.  Since you are chaining, the latency of you input will be less
> > than the latency of the remailernet.
> 
> OK, but chances are your average number of real packets per tick is < 1,
> e.g. if a tick is a few hours and you only send one or two messages
> a day.  So when you do need to send that 500KB GIF it's going to take a
> lot of ticks.
> 
 
But I said average plus 3 standard deviations.  If you know you are going
to send GIFs at some point, you make a point of setting you standard that
high.  BTW, I envision a tick period of 30 minutes to an hour.
 
 
> I would sum up by agreeing with several points: the need for standard
> message sizes, and for a standard rate of message output.  I am neutral
> on whether a remailer may want to super-encrypt a message to the next
> link in the chain (whether a remailer or an end user) if it happens to
> have a key handy.  I don't see any harm in this and the remailer
> software will already handle this transparently on the receiving end.
> I disagree with the idea of remailers checking signatures.  I don't
> agree that inter-node remailer encryption provides significantly more
> protection than padding.  I think that encrypted reply blocks are
> unsafe even with inter-node remailer encryption.  See Chaum's paper for
> ways that encrypted reply blocks can be used safely.  We have also had
> some suggestions here for modifications to Chaum's method.  And I don't
> see how you can arrange to receive a constant load from the net without
> a highly centralized system, which would have its own dangers.
> 
> Hal
> 
 
Hopefully, I made my positions on these matters clear.  As I said, I have
new ideas, several of which supercede these.
 
Nathan
 
 
On multiple Request-Remailing-To:'s
 
> I don't follow how requiring pgp wrappers would kill this.  Couldn't
> he create a remailing request to 10 remailers, wrap that in pgp, stick
> on a remailing request to 10 remailers, wrap that... and end up with
> the same effect?
 
> Hal
 
Yeah.  I realised this right after sending it.  Genius that I am.  I guess
you have to limit the number of remailers in the multiples to 1.  Even
then, you could end up with a remailer-based spam.  (joy)  I guess you have
to, as a matter of policy, allow 1 remailer and nothing else or any number
of others.
 
Nathan
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
 
iQEVAwUBLzmmLnmgMs8UcStNAQHk4Af/Qn+azQ9MDiWEbiQgGSfnn1a7w2xS2ktG
RJTEBlVXAduurz7e+DGxS4ggfvtU61QVpn/rJkM7Q5vk2gZMzdb0v6f9sMkex8ew
tFFMLf2Q9JXlahONyxiW5yLWHdOjpj18Gf4jfGWVM9DZxWwaA25l8x/qROEzg1Hi
TM04/mmF+yJVLHJLfyxSTG6d2oaXpbOMsbwwosvWc91iCTA5QqSFNpQFIRqWQE3n
UKl9+Ym9I93hfJiLL3xvnBrfZQZC26DMZUugoxTUaXfWjUiSeDlc2b0UBpSOn/VN
FTPr9C5Wa4rDC8gT8BVq4F+M4b0lVcgqijyoQhgMItvA3eZ7Vdd1iQ==
=Hh4N
-----END PGP SIGNATURE-----






From nzook at bga.com  Thu Feb  9 04:09:32 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:09:32 PST
Subject: Threat models. [was: Why encrypt intra-remailernet]
Message-ID: <Pine.3.89.9502090648.I21224-0100000@lia.bga.com>


 
>    From: Nathan Zook <nzook at bga.com>
> 
>    When I say that the Mark I remailers are laughably easy to crack, I mean
>    laughably easy.
> 
> By whom?  I am hearing a general denunciation of the current remailer
> system.  These blanket denials are false on their face, because they
> are not true in every circumstance.
> 
 
By anyone with the resources to snoop up- and down- stream of all the
remailers.
 
>    The only reason that our systems are actually able to do any good is 
that
>    our threat model _is not_ an LEA--with government resources, and 
government
>    patience.
> 
> _Our_ threat model?
> 
> There is not one threat model.  Each person has their own threat model
> and their own desired level of security.  An individual also desires
> more security for some messages than others.  The current remailer
> network is good for some purposes and bad for others.
> 
> Every evaluation of security _must_ include the nature of the security
> desired, because there is no single concept called "security" which is
> the same in every situation.
> 
> Eric
 
Yes, but...  The very act of going to the trouble of using these remailers
means that you are dealing with someone powerful enough to read past forged
From/From: lines.  Does it take that much more to snoop these sites?  My
gut says no.  Everybody harps chaining.  Does snooping take more effort
than compromising?  I think it would be hard indeed to say so.
 
So if we think Eve can compromise some remailers, and/or read past
From/From: faking, we are, I believe, forced to believe that Eve can snoop
all the remailers.  Threat models need to be uniform in the power of the
opponent.
 
Nathan
 
 






From nzook at bga.com  Thu Feb  9 04:11:02 1995
From: nzook at bga.com (Nathan Zook)
Date: Thu, 9 Feb 95 04:11:02 PST
Subject: Mixmaster + T1
Message-ID: <Pine.3.89.9502090624.J21224-0100000@lia.bga.com>


-----BEGIN PGP SIGNED MESSAGE-----
 
 
*** Background
 
Cypherpunk remailers have been very effectively keeping the net.cops at
bay--mostly because the net.cops aren't _real_ cops.  Lance has offered a
standard that goes quite a distance towards defeating the latter opponent.
I hope that my suggestions can close the gap.  The remailers, and their
mailers, use IDEA, RSA, MD5, PGP, and D-H.
 
 
 
*** Threat Model
 
Our attacker, Eve, is a wealthy national government.  Eve has corrupted at
least some of the law enforcement agencies, but not much of the judiciary.
Contact with the remailers has not been outlawed.  Individual use of strong
crypto has not been outlawed.  ( I know this probably violates the equality
of power demand, but...)  Alice and Bob are sending each other messages
through the net, and know that they are being watched.  Eve does not have
the secret (PGP/RSA) keys of anyone she has not explicitly compromised.
 
The historical examples might be Chinese dissidents, Afgan or Nicuaraguian
freedom fighters, David Koresh, Randy Weaver, or Mary of Scotland.
 
 
 
*** Goal
 
Our goal is to help Alice and Bob carry on an extended conversation without
Eve being able to produce proof that either one of them actually sent any
real message.  This include the possibility that on occasion, theirs is the
only real message in the remailer net.  By produce I include manufacture.
Forward security for all involved is preferable.
 
 
 
*** Attack Modes
 
I believe that there are five primary modes of attack:  traffic analysizing
individual remailers, traffic analysizing the remailer net as a whole,
compromising remailers, correlating the reception of messages by Bob or
Alice with their later outside actions, and fabricating messages from Alice
to Bob.
 
 
 
*** Basic Abilities
 
Eve knows all of our protocals, and can convince the Internet that she is
anyone.  She records all traffic into or out of all remailers, as well as
Alice and Bob.  She runs most of the remailers, and can temporarily and
selectively block traffic through the remailers.
 
 
 
*** Attack Methods.
 
I will not redetail the standard attacks which include flushing, spam-
copying, single copying (stuttering), size matching, or We Dai.  I will,
however, detail certain attacks that I believe are either new or have not
been generally discussed.
 
 
** Fabricating Evidence
 
As we have seen with our own government, lack of evidence is a condition
that governments can correct by fiat.  (Randy Weaver)  Alice has to be able
to prove that a message on the Internet "from" her to a remailer did not in
fact originate with her.
 
 
** Sandwiching
 
(This attack may not be possible at this time.  But it is hard to know...)
If Eve owns remailers on either side of another, she may seed "random" data
with particular data in order to determine what IDEA key was used on the
data.
 
 
** Remailer Spoofing
 
Eve can attempt to process messages on a remailer's behalf.
 
 
** Message Body Matching
 
If a copy of a message can be sent through, the first part of the body
(following the headers) can be compared.  If random garbage has been tacked
on by the other remailer, it will be distinguished.  
 
 
 
*** Definitions for Standard
 
Remailers and mailers together are generically called users.  Alice is
sending a message to Bob.
 
All remailers operate on ticks.  At certain GMTs, all remailers process all
of their accumulated messages, then forward them, holding some over for the
next batch.
 
The term message refers to either the final message to be sent to Bob, or
its encrypted counterparts--including padding.  A header is a set of
communications to a remailer, or to Bob.  A message packet is a message
with all of its headers.  A T1 packet is the collection of all message
packets going from one user to another on a given tick, with additional
header information.
 
 
 
*** Standard for Exchanging T1 Packets
 
T1 packets are IDEA encrypted.  The key is exchanged through a DH exchange
which takes place inside previous T1 packets.  The keys are DHed so that
the compromise of one T1 packet does not lead to the compromise of all
subsequent packets.
 
In order to establish the original IDEA keys, a sender would contact a
reciever with a special "origination" packet request.  Such requests would
intiate contact between users, or could be used to establish secure IDEA
tick keys in the event of a failed connection, or compromised key.  This
packet includes a disposable RSA key, which the receiver would use to PGP a
disposable RSA key in return.  IDEA keys for future packets could be passed
through these RSA keys.  The RSA keys would themselves be signed by the
public key associated with each user.
 
 
 
*** The Structure of a T1 Packet
 
T1 packets would include the DH key exchanges for future ticks, a
timestamp, all message packets destined for the reciever this tick, an MD5
of the previous T1 packet recieved (decrypted), and an MD5 of the rest of
the message, as a checksum.  This could be turned into a signature,
possibly with the timestamp.  If the MD5 from the previously recieved
packet matches, the copy of the old sent T1 packet is destroyed.  If it is
bad, the old packet is resent, with a different key.
 
 
 
*** Selection of Message Packets to a User
 
Mailers specify a number of message packets that they receive each tick
from various remailers.  If a remailer has more messages packets for a
mailer on a given tick than the mailer receives, the extras are held over,
and a notice is sent so that the mailer can determine if he should raise
his limit.  If the number of "real" packets to a user is below his limit,
dummy packets are sent to him through other remailers, on a sliding scale.
 
A user sends the same number of message packets to each remailer every
tick.  There is a minimum number of message packets that a remailer will
send to each other remailer each turn.
 
/* This eliminates the ability to trace a flood of messages, even if they
all took the same path. */
 
Messages being held are flaged with the number of ticks that they have been
held.  There is a maximum number of ticks that a message packet can be held.
 
Mailers send the same number of message packets each tick to each remailer
that they might use.
 
 
 
*** Use of Dummy Message Packets
 
Dummy message packets are used to pad traffic.  Dummy messages are always
sent at least to third party remailers.  The distribution of these third
parties is random.
 
/* If Eve runs some remailers, she can immediately eliminate dummy message
sent to her machines.  But if these do not originate in the machine that
sent the message, her gain is much weakened.  If Eve controls most of the
remailers, it may be necessary to send dummy messages through three
remailers in order to obscure traffic flow.  If the distrubtion were flat,
real messages would stand out. */
 
 
 
*** The Structure of a Message Packet
 
All message bodies are standard sized, and have a standard number of
standard sized headers.  The reconstitution of oversized messages is
handled by Bob's client.  The division of oversized messages is handled by
Alice's client.  An exception is made for mail-to-news gateways, to
reconstitute the oversized message at the last remailer.  Such exceptions
include a rough check to insure that the message is either valid ASCII
armour, or some language.
 
The header to a remailer includes the forwarding address, a timestamp, and
the IDEA keys to be used on each other header, as well as the body.  (Each
is different.  See below.) After decrypting, the headers are circulated.
When creating the timestamp for a header number n, Alice uses the time of
the nth tick coming.
 
The top header itself is RSAed with the user's public key.
 
/*  If Eve manages, though a sandwich attack, to divine the idea key used
on a header, she can use this to trace the message.  If we include only the
key and an increment, she can get this information if she has two remailers
before the good one.  If we include the key, an increment, and a
permutation of the headers, she can guess the key.  */
 
The header for Bob includes an MD5 of the message, flags in case the
message is oversized, and a timestamp.
 
 
 
*** Elimination of Duplicate Packets
 
An MD5 record is kept of every message, every header, and every T1 packet
recieved or sent for M ticks.  M is related to the number of headers and
the maximum number of ticks that a message is held--with room for error.
If a match is found, the entire packet is rejected.  If a message arrives
with a timestamp older than M ticks, it is rejected.  If a message arrives
with a timestamp in the future, it is held until that time.
 
 
 
*** Incorporation of Encrypted Reply Blocks
 
Encrypted Reply Blocks would be the PGPed version of a header set.  The
receiver would know the IDEA keys used on the body, and the order, so he
could reverse the operation.  The keys could even be included in the final
header.  It is not possible in this system to allow multiple encrypted
reply block responses without possible compromise of the recipient.
 
 
 
*** Weaknesses
 
Clients are required to be as sophisticated as hosts.  Clients must be able
to handle lots of dummy mail.  Both hosts and clients must have access to
good, secure, random data sources.  Hosts must be able to protect their
data for a period of hours or days.  Hosts and clients need to be able to
protect their DH information.
 
Nathan
 
Flame on!!
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
 
iQEVAwUBLzmk/XmgMs8UcStNAQEQQQgAkJyeh2vgOnsbVzuHrqGKVPE0pIoh37ms
DtMxD7mJVMp40fGlQJmk8dT3WeVUpgeFIvJxeNvMZ86jyN51smZkjqUBNWFhJikT
HBnAlDuf82g1GbuhPsR9J2vMTtTHcsfs+ytTWDp2g+xr1nWHngki4wBjPy2oOCP9
dxu5vamUnDy0oFatMmGxIZyN9jTzB7NynaXVLkDWL3Hh8amUwyW9nq7LGQJ8Oiuh
2xY4uizxJ+/SjxnATxUznT9i099xC3ClpRGX1n/3fdXY5Mu5MAJoRO6sjL5Fakz4
3i0qWNlv8ZJCqCetSqnQrINFFd6bpDhiAz5/CU4kQ9/HtStIVl/88A==
=kziG
-----END PGP SIGNATURE-----






From erc at s116.slcslip.indirect.com  Thu Feb  9 05:31:27 1995
From: erc at s116.slcslip.indirect.com (Ed Carp [khijol Sysadmin])
Date: Thu, 9 Feb 95 05:31:27 PST
Subject: Best encryption device driver for MS-DOS?
Message-ID: <m0rcYxl-0004IOC@s116.slcslip.indirect.com>


Being in the consulting business, I often write prototype software for
clients in Visual Basic as proof-of-concept and also to make sure I
understand the client's needs before I accept a project.  On occasion,
I have to leave my laptop unattended on someone's desk while I go into
meetings with senior management and try to convince them that I know what
I'm talking about and that I'm worth whatever (exorbitant to them) I'm
asking to do their application for them.  I also do volunteer programming
for several volunteer organizations, and it's the same situation - unattended
laptop while I wander off and chat with management to tell them why it
will take so long to do the impossible. ;)

As you might imagine, I have a full suite of programming tools on the laptop,
including MS Office Pro and VB Pro, both of which are worth about $500
apiece - I'd sure hate to lose them to a malicious cracker, or someone who
would like a personal copy of my source code for their own use, or who just
wants to "borrow" my secret key for awhile.

What do people recommend as the solution for this?  Some sort of IDEA-based
or triple-DES-based device driver would seem to be the answer to this, but
I'm not sure which is the "best" (most reliable, fastest, easiest to set up)
one to use.  I like the sound of Michael Sattler's encryption driver for the
Mac, but alas, I'm running MS-DOS :(

Also, if anyone has any suggestions for a similar driver for Linux, I'd
appreciate it - thanks!
-- 
Ed Carp, N7EKG    			Ed.Carp at linux.org, ecarp at netcom.com
801/534-8857 voicemail			801/460-1883 digital pager
Finger ecarp at netcom.com for PGP 2.5 public key		an88744 at anon.penet.fi
                       ** PGP encrypted email preferred! **

Cop: "How many beers have you had tonight, bro?"
Suspect: "Seventy."  -- from the TV show "Cops"




From root at einstein.ssz.com  Thu Feb  9 05:48:21 1995
From: root at einstein.ssz.com (root)
Date: Thu, 9 Feb 95 05:48:21 PST
Subject: Best encryption device driver for MS-DOS?
In-Reply-To: <m0rcYxl-0004IOC@s116.slcslip.indirect.com>
Message-ID: <199502091343.HAA04180@einstein.ssz.com>


> 
> Being in the consulting business, I often write prototype software for
> clients in Visual Basic as proof-of-concept and also to make sure I
> understand the client's needs before I accept a project.  On occasion,
> I have to leave my laptop unattended on someone's desk while I go into
> meetings with senior management and try to convince them that I know what
> I'm talking about and that I'm worth whatever (exorbitant to them) I'm
> asking to do their application for them.  I also do volunteer programming
> for several volunteer organizations, and it's the same situation - unattended
> laptop while I wander off and chat with management to tell them why it
> will take so long to do the impossible. ;)
>
You leave your laptop turned on and out of your immediate reach? Geesh.
I would NEVER leave my laptop anywhere that I didn't have it in eyeshot. It
was the whole reason I got one.
 
> As you might imagine, I have a full suite of programming tools on the laptop,
> including MS Office Pro and VB Pro, both of which are worth about $500
> apiece - I'd sure hate to lose them to a malicious cracker, or someone who
> would like a personal copy of my source code for their own use, or who just
> wants to "borrow" my secret key for awhile.
>
Business must be good, you are more worried about somebody stealing a $500
dollar program than a several thousand dollar laptop?
 
> What do people recommend as the solution for this?  Some sort of IDEA-based
> or triple-DES-based device driver would seem to be the answer to this, but
> I'm not sure which is the "best" (most reliable, fastest, easiest to set up)
> one to use.  I like the sound of Michael Sattler's encryption driver for the
> Mac, but alas, I'm running MS-DOS :(
> 
Try Lo-Jak so that when your laptop goes a wanderin' you can find it....:)





From erc at s116.slcslip.indirect.com  Thu Feb  9 06:02:54 1995
From: erc at s116.slcslip.indirect.com (Ed Carp [khijol Sysadmin])
Date: Thu, 9 Feb 95 06:02:54 PST
Subject: Best encryption device driver for MS-DOS?
In-Reply-To: <199502091343.HAA04180@einstein.ssz.com>
Message-ID: <m0rcZRT-0004IhC@s116.slcslip.indirect.com>


> You leave your laptop turned on and out of your immediate reach? Geesh.
> I would NEVER leave my laptop anywhere that I didn't have it in eyeshot. It
> was the whole reason I got one.

Well, it's rather tacky to turn off the laptop, unplug it, etc., just to
lug it into a boardroom.  Not impressive.

> > As you might imagine, I have a full suite of programming tools on the laptop,
> > including MS Office Pro and VB Pro, both of which are worth about $500
> > apiece - I'd sure hate to lose them to a malicious cracker, or someone who
> > would like a personal copy of my source code for their own use, or who just
> > wants to "borrow" my secret key for awhile.
> >
> Business must be good, you are more worried about somebody stealing a $500
> dollar program than a several thousand dollar laptop?

Oh, I'm not worried about the laptop walking off, I'm worried about the
software I've written walking off...

> > What do people recommend as the solution for this?  Some sort of IDEA-based
> > or triple-DES-based device driver would seem to be the answer to this, but
> > I'm not sure which is the "best" (most reliable, fastest, easiest to set up)
> > one to use.  I like the sound of Michael Sattler's encryption driver for the
> > Mac, but alas, I'm running MS-DOS :(
> > 
> Try Lo-Jak so that when your laptop goes a wanderin' you can find it....:)

I've never had anyone even attempt to rip off the laptop, but I've had people
ask for "free samples" of the prototype code...
-- 
Ed Carp, N7EKG    			Ed.Carp at linux.org, ecarp at netcom.com
801/534-8857 voicemail			801/460-1883 digital pager
Finger ecarp at netcom.com for PGP 2.5 public key		an88744 at anon.penet.fi
                       ** PGP encrypted email preferred! **

Cop: "How many beers have you had tonight, bro?"
Suspect: "Seventy."  -- from the TV show "Cops"




From slowdog at wookie.net  Thu Feb  9 06:07:31 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 06:07:31 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502090633.WAA08858@netcom2.netcom.com>
Message-ID: <Pine.LNX.3.91.950209090753.8172B-100000@chewy.wookie.net>


On Wed, 8 Feb 1995, Timothy C. May wrote:

> As scary as S.314 is, I'm not sure it's likely to pass. Unlike the
> Digital Telephony Bill, which was on greased skids, this  one seems to
> have come out of left field. I could be wrong on this, and maybe it's
> got a lot of sponsors, but it sounds like just another Bill that will
> die in committee or fail on the floor.

I would not count on this. The goal of the bill is to combat 
indecency/pornography/onscenity online - the kind of things pols LOVE to 
vote for.


- dog







From slowdog at wookie.net  Thu Feb  9 06:09:13 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 06:09:13 PST
Subject: S314 and potential hell-raising
In-Reply-To: <199502090715.XAA14870@alkahest.isas.com>
Message-ID: <Pine.LNX.3.91.950209090919.8172C-100000@chewy.wookie.net>


On Wed, 8 Feb 1995, joshua geller wrote:

> there's room for another organization I think. there are, in my opinion,
> two reasons why the NRA is as effective as it is: it has a single issue
> that it concerns itself with and it never compromises.
> 
> so what, in very few words and as clearly as possible, is our issue?

I don't know what your issue is, but a small group of people are at the 
moment formulating the beginnings of a new "group" of sorts with a very 
specific agenda in mind.

Which is an utterly obscure and non-descriptive thing to say. But hold 
on. We should have an initial announcement ready, I hope, shortly.


- dog







From barrett at daisy.ee.und.ac.za  Thu Feb  9 06:47:05 1995
From: barrett at daisy.ee.und.ac.za (Alan Barrett)
Date: Thu, 9 Feb 95 06:47:05 PST
Subject: Best encryption device driver for MS-DOS?
In-Reply-To: <m0rcZRT-0004IhC@s116.slcslip.indirect.com>
Message-ID: <Pine.NEB.3.91.950209162432.23367N-100000@daisy.ee.und.ac.za>


I don't know which is the "best" encrypting file system for MS-DOS.  I
currently use Peter Gutmann's SFS, and am very happy with it.  I have used
SecureDevice (from Max Loewenthal and Arthur Helwig) in the past, and
found it painfully slow on my 25MHz 386SX.  I also know of Mike Ingle's
SecureDrive, but I have not used it.  SFS and SecureDrive require a
separate partition.  SecureDevice uses a container file instead of a
separate partition. 

You also asked about Linux.  I think that Matt Blaze's CFS would work 
there, but I don't know.

--apb (Alan Barrett)







From rrothenb at ic.sunysb.edu  Thu Feb  9 06:54:08 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 9 Feb 95 06:54:08 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502081902.LAA01787@gwarn.versant.com>
Message-ID: <199502091453.JAA26458@libws4.ic.sunysb.edu>


[ .. ]

No disagreements with your reply. Of course the first amendment (or the rest
of the Bill of Rights) has stopped legislators from passing restrictive laws.

The line between indecency and obscenity is vague. Legal defense fees are
not... not are opportunistic prosecutors-- which is a real problem. Look at
what happened to Jello Biafra and the Dead Kennedys if you'd like an
example. I've heard that there were recently busts in Florida of some BBS
systems that carried the alt.sex* groups while universities in the area which
also carried them weren't touched.


The "safe harbor" is 10pm, but many radio stations (like WUSB here in Stony
Brook, where I do some radio programming) use midnight as a safe time and
give periodic warnings during shows in any indecent material is aired.

Problems with these vague and-or unenforcable "decency" laws is that they
allow for selective enforcement which is often motivated more by politics
and personal greed than by their alleged concerns for decency.

> 
> In the U. S., you have a first ammendment right to indencent speech.
> 
> The question of a late-night "safe harbor" for indecent speech on the
> air is about when children are likely to be listening.  First
> ammendment rights apparently don't apply to children who are listening
> to the radio.  
> 
> Right now there is a "safe harbor" from around 10pm (or is it 9pm?)
> thru 6am, but this changes regularly, usually as a result of "case law"
> (someone being prosecuted under next month's rules, not this month's)
> 
> 				strick
> 

Rob





From rrothenb at ic.sunysb.edu  Thu Feb  9 06:58:53 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 9 Feb 95 06:58:53 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <9502082149.AA28226@tis.com>
Message-ID: <199502091458.JAA26730@libws4.ic.sunysb.edu>



> >Date: Tue, 7 Feb 95 21:24:01 PST
> >From: jpp at markv.com
> 
> >of the very most important rights.  To hold the owner of a buliten
> >board responsible for the illegal messages posted to it, is to force
> >the buliten board owner to become a government censor in all but name
> >(and wages).
> 
> anyone heard of "no unfunded mandates" ?

It's not a mandate. It's an order from god. (As if you didn't know, it
says in the bible that the Republican party is his official mouthpiece.)






From perry at imsi.com  Thu Feb  9 06:58:55 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Thu, 9 Feb 95 06:58:55 PST
Subject: MIME based remailing commands
In-Reply-To: <199502090425.UAA24521@largo.remailer.net>
Message-ID: <9502091458.AA11554@snark.imsi.com>



Eric Hughes says:
>    From: "Perry E. Metzger" <perry at imsi.com>
> 
>    xpat at vm1.spcs.umn.edu says:
>    > IMHO, an ideal message would have the ability to handle nested objects
>    > of varying types, MIME is only a start.
> 
>    What is it precisely that you might want to encapsulate that MIME
>    can't encapsulate?
> 
> Perry, you're missing the whole point, just like the exchange a few
> days about a remailer format standard.

If I am missing the whole point, it is because people are being
extremely vague about stating the point. This is engineering, not
social science. One specifies things precisely, as in "I think MIME
can't specify how to encapsulate a sound file", or "I think MIME
doesn't have the right headers defined to specify how long a mail
message is to be delayed". This fuzzy-engineering might feel good to
some of you but from my perspective it does nothing to enhance the
information content fo the discussion.

Perry





From rrothenb at ic.sunysb.edu  Thu Feb  9 07:02:48 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 9 Feb 95 07:02:48 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <199502091502.KAA27022@libws4.ic.sunysb.edu>


> On Wed, 8 Feb 1995, root wrote:
> 
> > Hi all,
> > 
> > A friend advises me that today House Bill 666 passed. This supposedly would
> > allow police officers to use evidence collected illegaly if they 'believed'
> > that it was collected in good faith.
> 
> This sounds like a spoof.  Look at the number.

I heard yesterday that someone in the House of Representatives proposed an
amendment to the new crime bill which was soundly defeated it. Turns out the
Amendment was worded exactly as the Fourht Amendment in the Bill 'o Rights.
Apparently many a congressman/woman has egg on their face...
> 
> Ben.
> 
> 
Rob





From samman at CS.YALE.EDU  Thu Feb  9 07:10:31 1995
From: samman at CS.YALE.EDU (Ben)
Date: Thu, 9 Feb 95 07:10:31 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502091502.KAA27022@libws4.ic.sunysb.edu>
Message-ID: <Pine.SUN.3.91.950209100901.12976A-100000@jaguar.zoo.cs.yale.edu>


On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> > On Wed, 8 Feb 1995, root wrote:
> > 
> > > Hi all,
> > > 
> > > A friend advises me that today House Bill 666 passed. This supposedly would
> > > allow police officers to use evidence collected illegaly if they 'believed'
> > > that it was collected in good faith.
> > 
> > This sounds like a spoof.  Look at the number.

I regret that my previous hope was dead wrong.

There's  front page story on it in today's NYT.  Hopefully for those of 
you that are NYT challenged, maybe John Young will make it available as 
per his usual gracious self.

Shit!

Ben.






From pdlamb at iquest.com  Thu Feb  9 07:37:05 1995
From: pdlamb at iquest.com (Patrick Lamb)
Date: Thu, 9 Feb 95 07:37:05 PST
Subject: Best encryption device driver for MS-DOS?
Message-ID: <199502091537.JAA13636@vespucci.iquest.com>


>> You leave your laptop turned on and out of your immediate reach? Geesh.
>> I would NEVER leave my laptop anywhere that I didn't have it in eyeshot. It
>> was the whole reason I got one.
>
>Well, it's rather tacky to turn off the laptop, unplug it, etc., just to
>lug it into a boardroom.  Not impressive.
>
>> > As you might imagine, I have a full suite of programming tools on the
laptop,
>> > including MS Office Pro and VB Pro, both of which are worth about $500
>> > apiece - I'd sure hate to lose them to a malicious cracker, or someone who
>> > would like a personal copy of my source code for their own use, or who just
>> > wants to "borrow" my secret key for awhile.
>> >
>> Business must be good, you are more worried about somebody stealing a $500
>> dollar program than a several thousand dollar laptop?
>
>Oh, I'm not worried about the laptop walking off, I'm worried about the
>software I've written walking off...
>

How about an obvious solution, like the password feature on After Dark?  If
I remember correctly, there's a hot-key combination you can use to bring up
the screen saver mode immediately as you get up from the machine.  It's
obviously not foolproof, but just blanking the screen and going into a
password mode would probably deter the casual browser.  If you're really
worried, change your autoexec so it goes into windows and starts AD immediately.

Low tech, maybe, but easy!

        Pat







From slowdog at wookie.net  Thu Feb  9 07:52:27 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 07:52:27 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502091453.JAA26458@libws4.ic.sunysb.edu>
Message-ID: <Pine.LNX.3.91.950209105014.8284B-100000@chewy.wookie.net>


On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> The line between indecency and obscenity is vague. Legal defense fees are
> not... not are opportunistic prosecutors-- which is a real problem. Look at
> what happened to Jello Biafra and the Dead Kennedys if you'd like an
> example. I've heard that there were recently busts in Florida of some BBS
> systems that carried the alt.sex* groups while universities in the area which
> also carried them weren't touched.

This is part of the danger. It to omse degree doesn't matter how 
restictive or "enforceable" the law might be, or even whether or not 
prosecutins will stick. Arrests and prosecutions will take a financial 
toll on those targetted, and will create a chillinf effect in the online 
community, meaning sysops and BBS operators will start policing 
themselves too severely in an effort to avoid politcial or legal scrutiny.

> The "safe harbor" is 10pm, but many radio stations (like WUSB here in Stony
> Brook, where I do some radio programming) use midnight as a safe time and
> give periodic warnings during shows in any indecent material is aired.

Unfortunately, this only works for media which operate within the old 
broadcast paradigm, while the online world operates within the network 
paradigm. There are no hours in which it is safe to broadcast because 
there is no "broadcast" in the tradition sense.

> Problems with these vague and-or unenforcable "decency" laws is that they
> allow for selective enforcement which is often motivated more by politics
> and personal greed than by their alleged concerns for decency.

And is also, as stated above, often motivated out of a desire to force 
the public to overly-police themselves to avoid prosecution.


- dog







From pdn at drmail.dr.att.com  Thu Feb  9 07:58:30 1995
From: pdn at drmail.dr.att.com (Philippe Nave)
Date: Thu, 9 Feb 95 07:58:30 PST
Subject: Best encryption device driver for MS-DOS?
Message-ID: <2F3A49A4@mspost.dr.att.com>



Ho, cyphernauts!

My $.02 votes for SecureDevice as an MS-DOS encryption mechanism because:
  1) It works within a file (or files) rather than requiring a dedicated
     hard disk partition; you can put up and take down encrypted "drives"
     without wiping out the whole disk drive and repartitioning. (VERY
     handy when you suddenly need to increase the size of your "drive"
     *RIGHT NOW*).
  2) It keeps a regular DOS directory structure within the "drive" file;
     you set up the "drive" one time and then just throw stuff in it at
     will. You can encrypt single files a variety of ways, but then you
     have to manage them all - this way, you just chuck 'em in the safe
     together.
  3) In a pinch, you can move the whole encrypted "drive" from place to
     place - since it's a self-contained data file and is encrypted
     throughout, you can FTP it all over the place as a binary file
     without hurting it.

The only time I've gotten in trouble with it was when I had SmartDrive 
turned
on for the encrypted "drive" and went down hard; now, I have a SMARTDRV -D:
or whatever in my AUTOEXEC so that SmartDrive won't try to buffer I/O to
the encrypted drive.

My one and only gripe - it won't work under Windows NT 3.5 ! I have to boot
DOS (blech!) to get at the encrypted drive. (Hint, Hint, Hint....)

    -Philippe





From slowdog at wookie.net  Thu Feb  9 07:59:22 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 07:59:22 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502091502.KAA27022@libws4.ic.sunysb.edu>
Message-ID: <Pine.LNX.3.91.950209105922.8309A-100000@chewy.wookie.net>


On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> I heard yesterday that someone in the House of Representatives proposed an
> amendment to the new crime bill which was soundly defeated it. Turns out the
> Amendment was worded exactly as the Fourht Amendment in the Bill 'o Rights.
> Apparently many a congressman/woman has egg on their face...

Yes indeed, in response to the H666 bill. The Dems placed up for vote the 
text of the 4th Amendment without attributing it to be such. It was 
defeated. Dems then immediately took to the floor of the House accusing 
the Repubs of tryingto dismantle the Constitution.


- dog







From storm at marlin.ssnet.com  Thu Feb  9 08:06:21 1995
From: storm at marlin.ssnet.com (Don Melvin)
Date: Thu, 9 Feb 95 08:06:21 PST
Subject: Cooperation
In-Reply-To: <9502071321.AA19736@cfdevx1.lehman.com>
Message-ID: <fbZElKJXYHRU078yn@ssnet.com>



I would think that MIME support would be extremely important to some
of the overall goals of the remailer net, i.e. popularity and off-shore
remailers.  Now, I'm not that familiar with MIME, but I believe it
has much better support (that is, it has some) for the extended character
sets that are needed for many languages.

The remailers as the stand today, are great as long as you don't want
to send a message in Chinese, Russian, etc.

As far as RFCs, I think documenting the current remailer system then
the new version is a good idea.  The current system can be done now,
done faster, and provide a better understanding for others who can
then add to the discussion for the next version.

--
America - a country so rich and so strong we can reward the lazy 
          and punish the productive and still survive (so far)

Don Melvin                  storm at ssnet.com                finger for PGP key.





From joshua at dee.retix.com  Thu Feb  9 08:13:00 1995
From: joshua at dee.retix.com (joshua geller)
Date: Thu, 9 Feb 95 08:13:00 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.LNX.3.91.950209105922.8309A-100000@chewy.wookie.net>
Message-ID: <199502091612.IAA25397@sleepy.retix.com>



>   On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

>   > I heard yesterday that someone in the House of Representatives proposed 
>   > an amendment to the new crime bill which was soundly defeated it. Turns 
>   > out the Amendment was worded exactly as the Fourht Amendment in the Bill 
>   > 'o Rights. Apparently many a congressman/woman has egg on their face...

>   Yes indeed, in response to the H666 bill. The Dems placed up for vote the 
>   text of the 4th Amendment without attributing it to be such. It was 
>   defeated. Dems then immediately took to the floor of the House accusing 
>   the Repubs of tryingto dismantle the Constitution.

so is there a list of names of the people who voted against it? I use
the term "people" very loosely.

actually though, both the democrats and the republicans consider parts
of the constitution to be obsolete. they just differ amongst themselves
as to which part. 

I wish someone would find the elixir of youth and feed it to barry
goldwater.

josh








From mac5tgm at hibbs.vcu.edu  Thu Feb  9 08:15:31 1995
From: mac5tgm at hibbs.vcu.edu (Greg Morgan)
Date: Thu, 9 Feb 95 08:15:31 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <Pine.SUN.3.91.950208204415.11813A-100000@jaguar.zoo.cs.yale.edu>
Message-ID: <9502091615.AA13172@hibbs.vcu.edu>


Ben originally said the following...
> 
> On Wed, 8 Feb 1995, root wrote:
> 
> > Hi all,
> > 
> > A friend advises me that today House Bill 666 passed. This supposedly would
> > allow police officers to use evidence collected illegaly if they 'believed'
> > that it was collected in good faith.
> 
> This sounds like a spoof.  Look at the number.

Nope... wish it was... but I saw it pass on C-SPAN.  Boy was I
pissed.
Looks like it's time to make a 2048 bit PGP key.  *8)


-----------------------------------------------------------------------------
Greg Morgan <mac5tgm at hibbs.vcu.edu>    | "I dunno Brain, me and Pipi
Mail me for PGP Key: 0xE0D222A9        |  Longstocking?  I mean what would
Key Fingerprint : 2430 BAA4 1EE4 AA2F  |  the children look like?" - Pinki
                  3B76 3516 3DEF 5529  |
-----------------------------------------------------------------------------





From mac5tgm at hibbs.vcu.edu  Thu Feb  9 08:40:50 1995
From: mac5tgm at hibbs.vcu.edu (Greg Morgan)
Date: Thu, 9 Feb 95 08:40:50 PST
Subject: Best encryption device driver for MS-DOS?
In-Reply-To: <m0rcYxl-0004IOC@s116.slcslip.indirect.com>
Message-ID: <9502091640.AA16231@hibbs.vcu.edu>


Ed Carp [khijol Sysadmin] originally said the following...

> apiece - I'd sure hate to lose them to a malicious cracker, or someone who
> would like a personal copy of my source code for their own use, or who just
> wants to "borrow" my secret key for awhile.

"Is that a PGP key in your pocket or are you just happy to see
me?" :)

The best way I can think of to protect your secret key is to
store it off of your laptop.  Put it on a floppy disk or a
PCMCIA card and keep the sucker in your pocket or in a safe.

> What do people recommend as the solution for this?  Some sort of IDEA-based
> or triple-DES-based device driver would seem to be the answer to this, but
> I'm not sure which is the "best" (most reliable, fastest, easiest to set up)
> one to use.  I like the sound of Michael Sattler's encryption driver for the
> Mac, but alas, I'm running MS-DOS :(

There's a program for DOS called SecureDrive (I think) that
uses IDEA encryption to protect hard drives.
Only problem you'll have is you'll have to repartition your
hard drive.  This is because the bootable partition needs to be
unencrypted.

What I'd setup is a small partition that's bootable and has a
version of DOS installed on it.  Then I would keep all the
software/data you want to protect on the much larger encrypted
partition.

Another thing I'd note is that while it works great with
uncompressed hard drives and floppies, I'm not certain that it
would work or work safely with compressed drives.  I haven't
tried it yet.

I'm at my school's computer lab so I can't dig up a copy of it
yet (or remember where the FTP site I got it from) but if you
want I'll try to track it down for you (if it hasn't been
posted here already).
-----------------------------------------------------------------------------
Greg Morgan <mac5tgm at hibbs.vcu.edu>    | "I dunno Brain, me and Pipi
Mail me for PGP Key: 0xE0D222A9        |  Longstocking?  I mean what would
Key Fingerprint : 2430 BAA4 1EE4 AA2F  |  the children look like?" - Pinki
                  3B76 3516 3DEF 5529  |
-----------------------------------------------------------------------------





From hfinney at shell.portal.com  Thu Feb  9 08:41:47 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 9 Feb 95 08:41:47 PST
Subject: Lucky primes--third time's the charm?
In-Reply-To: <Pine.3.89.9502090512.B21224-0100000@lia.bga.com>
Message-ID: <199502091641.IAA12454@jobe.shell.portal.com>


Nathan Zook <nzook at bga.com> writes:

>-----BEGIN PGP SIGNED MESSAGE-----
> 
>The algorithm I posted the second time works, (nice improvement, eh?) but
>is likely to take several thousand years to complete.  And when it does, we
>can expect weak primes.  The enhancement I propose should fix that.
> 

I did not realize before that p was an output of your algorithm, rather
than an input.  That explains better what you were trying to do.  You are
in effect trying to search for a prime such that e's multiplicative
inverse has a lot of 0's.

This looks like it will work pretty well, with the caveat as we discussed
before that going too far with this could make searching for the primes
easier.  But the only obvious attack would be to try to reproduce your
prime-finding algorithm to find a p which divides the modulus n, and that
is basically a sqrt(n) algorithm, which is far from the worst-case attack
we face.  The search space can be reduced by a considerable factor before
it becomes competitive with modern algorithms.

I guess another point is that if i is 2 or 4 then p itself will likely be
0-rich and conceivably there could be some attacks against a modulus
known to be the product of two 0-rich primes even when the primes are not
weak in the normal sense.  (p = (ed-1)/i+1, d is 0-rich, and e has only
2 bits on so ed is likely also to be somewhat 0-rich; dividing by i is
just a shift right if i is 2 or 4, and adding 1 won't make much
difference.)

Restricing i to other numbers would still give p a simple arithmetical
relation to a 0-rich number (i=3 --> p*3 is 0-rich).  Maybe you could
choose a d such that d itself was 0-rich while ed happens not to be
0-rich; this might feel safer since p would have less of an
arithmetical relation to a 0-rich number.

(Admittedly, I don't know of any factoring attacks directly applicable to
0-rich factors but there is at least a superficial similarity to weak
primes and that suggests caution.)

Hal





From bdolan at use.usit.net  Thu Feb  9 08:49:37 1995
From: bdolan at use.usit.net (Brad Dolan)
Date: Thu, 9 Feb 95 08:49:37 PST
Subject: Senate Version of HR666 (fwd)
Message-ID: <Pine.SOL.3.90.950209114334.2474A-100000@use.usit.net>


It is still *theoretically* possible to stop the legislative
revocation of the 4th amendment, if you believe we have a 
representative government.

Brad D.

---------- Forwarded message ----------
Date: 9 Feb 1995 11:14:58 U
From: Cooley Stephen <cooley_stephen at space.honeywell.com>
To: UWSA <uwsa at shell.portal.com>, baron_mark_a at smtpmm.space.honeywell.com,
    Bostock#m#_Craig_W.FL40-P02 at smtpmm.space.honeywell.com,
    Kidd_Lee.FL51-P03 at smtpmm.space.honeywell.com
Subject: Senate Version of HR666

S54 - the Senate version of HR666 subverts the 4th Amendment!

   I called Sen Mack's (R-FL) DC office this morning for info on S54.  This
bill has been submitted to the Senate Judiciary Committee for consideration.
Hearings for S3-The "New" Crime bill, are scheduled for Fed 15th.  The new
crime bill also has a Exclusionary Evidence section too.  I have appended this
section after S54 below.    No hearings for S54 are scheduled as of yet.  The
aid I talked to didn't know if any hearings on S54 would even occur before it
is passed onto the floor for a vote.  The committe could mark up the bill and
pass it on without hearings.

  Please pass this info onto other groups and reflectors.  We have to get the
word out on this bill. S54 modifies the requirements of the 4th amendment to

          ".....if the search or seizure was undertaken in an objectively 
          reasonable belief that it was in conformity with the fourth
          amendment."

Given the court rulings allowing traffic stops and searches due to an officer's
descretion, "probably cause", S54 hammers another nail into the 4th Amendment
coffin.  Call your Senators and let them know your thoughts on this bill. 
There is no time to waste.

FILE s54.is
          S 54 IS
          104th CONGRESS
          1st Session

          To amend title 18 to limit the application of the exclusionary rule.

                           IN THE SENATE OF THE UNITED STATES
                                     January 4, 1995

          Mr. Thurmond introduced the following bill; which was read twice 
              and referred to the Committee on the Judiciary

                                         A BILL

          To amend title 18 to limit the application of the exclusionary rule.

            Be it enacted by the Senate and House of Representatives of the
          United States of America in Congress assembled, That this Act may 
          be cited as the `Exclusionary Rule Limitation Act of 1995'.

            Sec. 2. (a) Chapter 223 of title 18, United States Code, is
          amended by adding the following two sections:

          `Sec. 3508. Limitation of   the fourth amendment exclusionary rule
            `Evidence which is obtained as a result of a search or seizure
          shall not be excluded in a proceeding in a court of the United
          States on the ground    that the search or seizure was in violation
          of the fourth amendment  to the Constitution of the United States,
          if the search or seizure was undertaken in an objectively 
          reasonable belief that it was in conformity with the fourth
          amendment. A showing that evidence was obtained pursuant to and
          within the scope of a warrant constitutes prima facie evidence of
          such a reasonable belief, unless the warrant was obtained through
          intentional and material misrepresentation.

          `Sec. 3509. General limitation of the exclusionary rule
            `Except as specifically provided by statute or rule of procedure,
          evidence which is otherwise admissible shall not be excluded in a
          proceeding in a court of the United States on the ground that the
          evidence was obtained in violation of a statute or rule of
          procedure, or of a regulation issued pursuant thereto.'.
            (b) The table of sections of chapter 223 of title 18, United
          States Code, is amended by adding at the end thereof:

          `3508. Limitation of the fourth amendment exclusionary rule.
          `3509. General limitation of the exclusionary rule.


Exclusionary Evidence section in the new crime bill S3:


          SEC. 507. ADMISSIBILITY OF CERTAIN EVIDENCE.

          `Sec. 3502A. Admissibility of evidence obtained by search or seizure

            `(a) Evidence Obtained by Objectively Reasonable Search or
          Seizure: Evidence obtained as a result of a search or seizure that
          is otherwise admissible in a Federal criminal proceeding shall not
          be excluded in a proceeding in a court of the United States on the
          ground that the search or seizure was in violation of the fourth
          amendment to the Constitution.
            `(b) Evidence Not Excludable by Statute or Rule: Evidence shall
          not be excluded in a proceeding in a court of the United States on
          the ground that it was obtained in violation of a statute, an
          administrative rule, or a rule of court procedure unless exclusion
          is expressly authorized by statute or by a rule prescribed by the
          Supreme Court pursuant to chapter 131 of title 28.
            `(c) Rule of Construction: This section shall not be construed to
          require or authorize the exclusion of evidence in any proceeding.'.
                (2) Technical amendment: The chapter analysis for chapter 223
              of title 18, United States Code, is amended by inserting after
              the item for section 3502 the following new item:
          `3502A. Admissibility of evidence obtained by search or seizure.'.
            (c) Illegal Search and Seizure: 
                (1) In general: Title 28, United States Code, is amended by
              inserting after chapter 171, the following new chapter:











From hfinney at shell.portal.com  Thu Feb  9 09:10:03 1995
From: hfinney at shell.portal.com (Hal)
Date: Thu, 9 Feb 95 09:10:03 PST
Subject: MIME based remailing commands
In-Reply-To: <ab5f62d802021004dd65@[137.110.24.250]>
Message-ID: <199502091709.JAA15742@jobe.shell.portal.com>


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

lcottrell at popmail.ucsd.edu (Lance Cottrell) writes:
>With Mixmaster, everything is hidden inside the encrypted and ascii armored
>message structure.
 
>I use the :: token to let the remailer know that this is a remailer message
>of some sort. The Remailer-Type will eventually be used to indicate the
>version that created the message. It would be easy to add support for MIME.
>It would just replace the token and version number.
 
>All remailing instructions are inside the ascii armor.
>Note that the block of ascii armor is allways exactly the same length.
 
>::
>Remailer-Type: 2.0
 
>-----BEGIN REMAILER MESSAGE-----
>hQCMAgbmF1BLzawNAQP/RFw2/UagugMFPlnJ94KLmhaxDoplzAhNBCxuFRL2fosL
>V1YnFd2XVckJJ6vTe6DB+POO+V7HEdXkp3sWtjb56Am+/B+tM1TdeC6NPNV4g5PC
>[...]

Ah, I see how you are doing it.  Having re-read your docs, I gather
that when un-armored the file is in an encrypted binary format, and
when decrypted at least the non-header portion of the file is still
binary?  I think this is a good way to do it; it addresses the point
Eric made recently about size expansion when an armored file is
encrypted at each step.

The one thing I would mention is that "::" was not originally intended
as an indication that the message was to be remailed.  Rather, this was
simply a "header pasting token" which could be used to move a few lines
from the body up into the header for those people who can't set header
fields on outgoing mail.  Then the presence of "Anon-To:" or whatever
in the header is what actually causes the action.  So you don't need to
use "::", you can just set your headers directly and get the same
effect.  (This is not to say you need to do it like this, just that
that is how the original design that Eric created worked.)
 
If you did want to follow this model, you could think about using a
MIME header to indicate the type of the message contents rather than
the "::".  Another alternative would be to use a different special
field in the mail header, like perhaps your "Remailer-Type: 2.0", but
I'm not sure that a new top-level header field is the right place for
this.  It looks to me like most of the standard headers deal more with
moving the message around rather than with telling what would be done
with it on receipt.  It's kind of a fine line but it looks to me like
more of a job for a MIME content type since that is really what it is
for.  You could use something like:
 
MIME-Version: 1.0
Content-Type: application/remail; version="2.0"

or

MIME-Version: 1.0
Content-Type: application/remail-mark-2
 
Then the rest of the message could look just as you have it.  Or, to use
a little more of the existing standard, you could add:
 
Content-Transfer-Encoding: base64
 
and take out your BEGIN and END lines since it looks like you are using
base64, although the augmented kind that PGP uses with the CRC at the
end; you'd have to lose the CRC in that case.  (I wonder if PGP will do
that in the MIME-PGP integration draft that is supposedly being worked
on.)

One question is, how do you actually send your messages in the
mixmaster client and servers?  Do you go directly to sendmail, or do
you use a user agent like /bin/mail?  If the former then it doesn't
seem like it would be too hard to add these header fields.  On the
receiving end then hopefully also it would not be much harder to match
the Content-Type: string than the one you are using.

The advantage, again, is that to a considerable extent this kind of
application is exactly what MIME was planning for with the "application"
content-type.  This lets you mark the contents of the message in a
standard way.  And you are already using something very close to the
base64 encoding that MIME specifies.  So this does seem like a good
opportunity to go with the internet mainstream by following this
standard.  If this seems like something you want to do I'm sure our MIME
experts here can tell how to define a new content type.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzpMORnMLJtOy9MBAQHWTwIA5k+6zO6/mMagKrNZELu7gHO2USlPnVGI
+SnIaj1jGtkzaodyIaEiUptAB4v5xfX8Lg7f+lcGzJYcEGrIi3+UPQ==
=NK01
-----END PGP SIGNATURE-----





From jpp at markv.com  Thu Feb  9 09:33:50 1995
From: jpp at markv.com (jpp at markv.com)
Date: Thu, 9 Feb 95 09:33:50 PST
Subject: My pgp emacs code in ftp://ftp.markv.com/pub/jpp/pgpelisp/*
Message-ID: <9502090927.aa02278@hermix.markv.com>


  I have been hacking yet another emacs to pgp interface for some time
now.  I am happy with the current state of affairs, and am releasing
it for general consumption.  It supports automatic decrypting,
signing, signature checks and interfaces nicely with rmail.el and
sendmail.el.

  Also it includes a set of remailer functions which parse the ping
reports from Raph Levien <raph at CS.Berkeley.EDU> and give you a simple
interface to chaining a bunch of remailers together.

  The code is liscense free; use it, sell it, hack it up, export it,
claim it is yours, I don't care.  Feel free.  (How could I stop you
any way?  I suspect that number theory, and complexity theory *are*
the real natural rights.)

  My code is in ftp://ftp.markv.com/pub/jpp/pgpelisp/*

  It is not yet very well packaged.  Read 2b.emacs.  I still want to
clean up the remailer stuff a little before I spend time packaging.
(C-C commands, reply block building, and estimates of a chain's
reliability, (support for ghio and julf {pseudo, ano}nyms?))

  Unfortuneately my net connection, and means of support here at markv
will likely soon be gone :(...  This may be the last chance I have to
distribute or work on this code for a while.  If the code impreses you
with my ability to hack, you might want to make me a job offer :) Or
point me to jobs.  OTOH, if my ability to hack doesn't impress you,
please be quiet until I do get another job :).

j'





From sandfort at crl.com  Thu Feb  9 09:52:02 1995
From: sandfort at crl.com (Sandy Sandfort)
Date: Thu, 9 Feb 95 09:52:02 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <9502072124.aa20836@hermix.markv.com>
Message-ID: <Pine.SUN.3.91.950209092021.25204A-100000@crl.crl.com>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          SANDY SANDFORT
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C'punks,

THIS IS A GRAMMAR FLAME.  Delete now if you don't like that sort
of thing.

Recently, several folks on this list have posted `letters to the
editor' or `letters to their representatives' that they had 
already sent or intended to send.  While most stated their case
clearly and dramatically, much of their impact was lost due to
grammar and spelling errors.  If your purpose is to persuade, 
don't shoot yourself in the foot by writing like an illiterate.

I know, I know, Net dwellers fancy themselves `above' such 
pedestrian nit picking.  The truth is, though, those who you 
intend to persuade will judge your intellect by these standards 
as much as by your content.  And in a way, they are right.  If 
you are too sloppy or lazy to write correct English, how unlikely 
is it that your thinking is equally sloppy and lazy?

In previous postings I have kept my comments to private e-mail.
I apologize to J Prime for going off on him publicly, but (a) it 
had to be someone, and (b) his posting is particularly egregious
in this regard.  (I did like *what* he said, just now *how* he
said it.)

Among ourselves, we can be less formal, but when we go public, I
think we would be a lot more effective if we had more respect for
the technical aspects of our prose.


 S a n d y

P.S.  I hope I didn't misplace any modifiers or misspell 
      anything in this post.  But if I did, please do as I
      say, not as I do.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





From tedwards at src.umd.edu  Thu Feb  9 09:55:25 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Thu, 9 Feb 95 09:55:25 PST
Subject: S. 314 and existing situation
In-Reply-To: <199502090439.UAA23399@mail.igc.apc.org>
Message-ID: <Pine.SUN.3.91.950209125321.25320B-100000@thrash.src.umd.edu>


On Wed, 8 Feb 1995, Richard F. Dutcher wrote:

> Gee, fellas, looking over this bill, *most* of what's going on is
> just porting existing telephone law over to cybercomm. Given the
> existence of 900-sex-talk, the phone companies are clearly not being
> held responsible for content.

Doesn't the common carrier status of RBOCs give them protection from 
this?

-Thomas






From jya at pipeline.com  Thu Feb  9 10:02:37 1995
From: jya at pipeline.com (John Young)
Date: Thu, 9 Feb 95 10:02:37 PST
Subject: NYT on HR666
Message-ID: <199502091801.NAA11707@pipe2.pipeline.com>


Katherine Seelye writes on Page One today about House passage 
of the new Search and Seizure bill.


It covers a parallel revision of appeals of the death penalty.  
And notes on abusive BATF.


For email copy send blank message to <jya at pipeline.com> with 
subject:   666_zap






From kipp at warp.mcom.com  Thu Feb  9 10:04:03 1995
From: kipp at warp.mcom.com (Kipp E.B. Hickman)
Date: Thu, 9 Feb 95 10:04:03 PST
Subject: skronk
In-Reply-To: <199502081852.KAA01719@gwarn.versant.com>
Message-ID: <3hdl7u$35a@flop.mcom.com>



In article <199502082025.MAA00565 at jobe.shell.portal.com>, hfinney at shell.portal.com writes:
> >THUS SPAKE "Kipp E.B. Hickman" <kipp at warp.mcom.com>:
> ># It does what you are trying to accomplish (I think), and it is already deployed
> ># in production code (the Netscape client and server products). In addition, we
> ># announced this week a free (for non-commerical use) reference implementation.
> ># The code will be out on the net as soon as the lawyers are happy :-)
> 
> When we last left this story, only certificates from a few (one?)
> signatory authorities were going to be accepted by Netscape clients.
> Would this mean that competitors offering Netscape servers would have to
> go to Netscape to get their keys signed in order to interoperate with
> existing Netscape clients?  I think this is too limiting.

The SSL protocol doesn't define how certificates are truly validated:
It does indicate what operations should be performed, but it doesn't
say how you go about getting the data to perform the operations.

Because there isn't a solid public-key infrastructure in place today,
the Netscape Navigator product (1.0 and the up and coming 1.1) only
support a few well known CA's that are built into the client
(ick). The CA's that are supported today are:

    C=US, OU=Test CA, O=Netscape Communications Corp.
    C=US, O=RSA Data Security, Inc., OU=Commercial Certification Authority
    C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
    C=US, O=MCI, OU=internetMCI, OU=MALL

So you see, you don't have to come to Netscape Communications Corp. to
get a certificate. Of course, this list is kinda short, etc. etc. etc.
We have IPRA's certificate too, but because IPRA has no financial
backbone, we have not included it in the Navigator product.

> People should be able to choose their own key signers.  This should be a
> configuration option.  It should not be compiled into the client!  That
> hurts your own flexibility as well as interfering with interoperatbiliy.

Of course this sucks. We plan on fixing this in a future release of
the navigator (after the 1.1 release).

> Can I use this reference implementation and set up a SSL-compatible
> service today, or do I have to go to you and/or everyone's friends at RSA
> and get a signature first?  As long as it is the latter I think that SSL
> is not going to be able to be a well-established standard.  People are
> going to resent having to register with the authorities in order to set
> up a secure web page.

SSL requires server operators to be certified so that the end users
(e.g. consumers) can have some faith in the data they are receiving,
and believe in the privacy of the communications. IMHO, before you can
get the consumers to truly believe, you must have a technically sound
solution.

It would be possible to modify the protocol to allow a non-certified
server to operate. However, this sort of thing is subject to the
man-in-the-middle attack. If we allow this sort of attack, and it
turns out to be the only easy way for an attack to occur, guess what
will happen?

---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp at netscape.com          http://home.mcom.com/people/kipp/index.html





From perry at imsi.com  Thu Feb  9 10:39:42 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Thu, 9 Feb 95 10:39:42 PST
Subject: skronk
In-Reply-To: <3hdlgr$35a@flop.mcom.com>
Message-ID: <9502091838.AA12032@snark.imsi.com>



Kipp E.B. Hickman says:
> Har! Besides the certificate problems, are there other problems with
> PEM that have prevented its adoption?

Its kind of ugly, too. The new PEM-MIME stuff should do much better,
but its no longer really PEM per se. Look at the drafts if you are
interested. 

> > I don't really blame you much.  I mean TIPEM handles all the X.509
> > stuff just fine and PGP can't get out even the simplest of libraries,
> > or even a partial library.
> 
> Our implementation supports this X.509 stuff as well. We don't have a
> DUA yet though...

Just so you know, Kipp, there is no real support for X.500 directories
over the internet, and there never will be. No one likes the things
outside of fogeys in MIS departments who program in Cobol.
Certificates as currently envisioned by the IETF are probably
going to be stored in the DNS.

.pm





From jpp at markv.com  Thu Feb  9 10:58:57 1995
From: jpp at markv.com (jpp at markv.com)
Date: Thu, 9 Feb 95 10:58:57 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.SUN.3.91.950209092021.25204A-100000@crl.crl.com>
Message-ID: <9502091057.aa19104@hermix.markv.com>


Sandy, and other C'punks,

THIS IS A RESPONSE TO A GRAMMAR FLAME.  But not, I hope, a flame
itself.

I respect your opinion, Sandy, and am glad you like what I wrote.  And I
certainly don't take your grammar 'flame' personally.  In fact, I
_agree_ with what you have said.  But for one thing -- one of my
points was to rub their noses in a particularly stinky example of
stegnography.  What secret messages are concealed in my letter?  Can
anyone know?  That was an essential point to my letter.

In retrospect I would change the analogy from parking lots to mail
carriers.  (Does it make sense for a mail carrier to be held liable
for the 'bad' mail they happen to deliver?)  I would also probably
point out that the internet community standard for what is obscene is
awfully loose, and seems to focus mainly on a brand of pork meat
product. ;)

I just got off the phone with my 'representatives.'  Perhaps calling
them doesn't have the same impact that a letter does, but it is very
immediately gratifying.

j(who _can_ drive a spelling checker)'

P.S.  Yes, you made an error in your post :).  If you will proof my
letters to my reps I will proof yours.  Deal?





From slowdog at wookie.net  Thu Feb  9 11:01:54 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 11:01:54 PST
Subject: S. 314 and existing situation
In-Reply-To: <Pine.SUN.3.91.950209125321.25320B-100000@thrash.src.umd.edu>
Message-ID: <Pine.LNX.3.91.950209140130.8757A-100000@chewy.wookie.net>


On Thu, 9 Feb 1995, Thomas Grant Edwards wrote:

> On Wed, 8 Feb 1995, Richard F. Dutcher wrote:
> 
> > Gee, fellas, looking over this bill, *most* of what's going on is
> > just porting existing telephone law over to cybercomm. Given the
> > existence of 900-sex-talk, the phone companies are clearly not being
> > held responsible for content.
> 
> Doesn't the common carrier status of RBOCs give them protection from 
> this?

Hard to tell from this bill what the deal is on this. Common carriers 
aren;t completely immune from prosecution or lawsuit or whatnot to begin 
with. But in addition, S.314 introduces "transmit or otherwise make 
available" into the language of the law. Which makes the -carrier- of the 
"offending" information responsible.


- dog







From rsalz at osf.org  Thu Feb  9 11:11:25 1995
From: rsalz at osf.org (Rich Salz)
Date: Thu, 9 Feb 95 11:11:25 PST
Subject: PEM
Message-ID: <9502091907.AA13921@sulphur.osf.org>


> Har! Besides the certificate problems, are there other problems with
> PEM that have prevented its adoption?

That's it.

PEM "blew it" by relying on Internet-wide X.500/X.509 deployments.

They're now looking at self-signed certificates as a transition aide
to work around the adoption problems, particular in face of the pressure
brought by the success of PGP.
	/r$






From cactus at seabsd.hks.net  Thu Feb  9 11:44:32 1995
From: cactus at seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Thu, 9 Feb 95 11:44:32 PST
Subject: Remailer Encryption Module
Message-ID: <199502091940.OAA10609@bb.hks.net>


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

In article <Pine.3.89.9502090612.E21224-0100000 at lia.bga.com>,
Nathan Zook <nzook at bga.com> wrote:
>As I've considered this problem, I've arrived at essentially the same
>conclusion.  We need an RSA-IDEA package that does something very close to
>Mixmaster.

I'm a-hackin' as fast as I can!

Seriously, this is exactly what I had in mind when I started out on the
Hastur Crypto Toolkit.  Data formats will be parameterized, with parameters
for well-known systems like PGP included with at least minimal
auto-selection support.

See the Hastur Status thread for the one real problem that isn't just a
SMOP: key management.
- --
Todd Masco     | "No matter how peculiar the medium or incongruous the scale,
cactus at hks.net |   the instinct to build persists."   - Joy Of Cooking
     Cactus' Homepage
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzpvqSoZzwIn1bdtAQG2+AGA2mP0eRIcgMKBAaeeMPr2Ik/mTN1SZ5y8
9MA8dM11fOvKah/EJRMwaTZ2RGuE/bv6
=r9eh
-----END PGP SIGNATURE-----





From eric at remailer.net  Thu Feb  9 12:33:43 1995
From: eric at remailer.net (Eric Hughes)
Date: Thu, 9 Feb 95 12:33:43 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502090633.WAA08858@netcom2.netcom.com>
Message-ID: <199502092033.MAA25822@largo.remailer.net>


   From: tcmay at netcom.com (Timothy C. May)

   Unlike the
   Digital Telephony Bill, which was on greased skids, [...]

As far as I have been able to puzzle out, the source of this claim
were the same parties that wanted to work a "compromise".  I have
never really trusted its veracity.

There was lobbying by the FBI, to be sure, but was there not also
lobbying for previous such bills (including S.266)?

Eric





From weidai at eskimo.com  Thu Feb  9 14:17:09 1995
From: weidai at eskimo.com (Wei Dai)
Date: Thu, 9 Feb 95 14:17:09 PST
Subject: LESM - Link Encrypted Session Manager
Message-ID: <199502092216.AA09906@mail.eskimo.com>

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

I finished hacking Matt's ESM to do link encryption yesterday, but 
for some reason the mail I sent to cypherpunks didn't get echoed back 
to me, so I'm sending this again.

To install: get ESM and RSAREF, make sure you can compile ESM, 
then replace the esm.c with my hacked version and recompile.

To use: same as ESM, but there's an extra option "-b bandwidth", the 
default is 100 cps.

I've attached the modified esm.c here since it doesn't include any 
crypto code.  To get ESM, write to cfs at research.att.com and state the 
following:

	- you are in the US or Canada, and
	- you are a US or Canadian citizen or legal permanent
	  resident, and
	- You've read and understand the license and export
	  conditions.

RSAREF is in ftp://rsa.com/rsaref/

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzqTtTl0sXKgdnV5AQEmbgP8CRxE+RCGsDXwwShWhZKGytSywyWZ8RXB
RPBHZmk6UgdpCR2VVo8wXjcPuEv4SHp9ZjhFTq53JZ/s3YcV5FxF33/ivSlh1Ra4
P8GSYnoEaIJoFrJyagukbBUaY6zWCx0PcnsLoVArCxujwRYwfrQvHdiNx13z7bJh
OSEhhoE9djg=
=PY8P
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?

This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.

   ---- File information -----------
     File:  lesm.c
     Date:  8 Feb 1995, 23:57
     Size:  19769 bytes.
     Type:  Text

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00000.bin
Type: application/octet-stream
Size: 19769 bytes
Desc: "lesm.c"
URL: <https://lists.cpunks.org/pipermail/cypherpunks-legacy/attachments/19950209/b5ad8c8b/attachment.bin>

From rrothenb at ic.sunysb.edu  Thu Feb  9 14:58:47 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 9 Feb 95 14:58:47 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.LNX.3.91.950209105014.8284B-100000@chewy.wookie.net>
Message-ID: <199502092258.RAA02881@libws2.ic.sunysb.edu>



> On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:
> 
> > The line between indecency and obscenity is vague. Legal defense fees are
> > not... not are opportunistic prosecutors-- which is a real problem. Look at
> > what happened to Jello Biafra and the Dead Kennedys if you'd like an

[ .. ]

> This is part of the danger. It to omse degree doesn't matter how 
> restictive or "enforceable" the law might be, or even whether or not 
> prosecutins will stick. Arrests and prosecutions will take a financial 
> toll on those targetted, and will create a chillinf effect in the online 
> community, meaning sysops and BBS operators will start policing 
> themselves too severely in an effort to avoid politcial or legal scrutiny.

Exactly. It's already happening. I've noticed on local BBS's they are afraid
of conversation about controversial subjects or files having to do with
things like do-it-yourself-birth control methods, drug legalization, or
crypto... some of the networks like RIME are also jittery about certain
topics like crypto or how telephones work.

> > The "safe harbor" is 10pm, but many radio stations (like WUSB here in Stony

[ message accidentally zapped ]

> broadcast paradigm, while the online world operates within the network 
> paradigm. There are no hours in which it is safe to broadcast because 
> there is no "broadcast" in the tradition sense.

Yes, I was discussing broadcasting. Scary thought is that because networks
are different they will try to outright ban everything.

What boggles my mind is how that hypothetical ratings system(s) the WSJ
article mentioned would operate... let alone who would rate content (very
controversial in movie ratings here in the US).

> > Problems with these vague and-or unenforcable "decency" laws is that they
> > allow for selective enforcement which is often motivated more by politics
> > and personal greed than by their alleged concerns for decency.

> And is also, as stated above, often motivated out of a desire to force 
> the public to overly-police themselves to avoid prosecution.

And "voluntarily" comply with their sense of values.

> - dog

Rob.






From rrothenb at ic.sunysb.edu  Thu Feb  9 15:03:44 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Thu, 9 Feb 95 15:03:44 PST
Subject: Not necessarily crypto but scary anyway...
In-Reply-To: <199502091612.IAA25397@sleepy.retix.com>
Message-ID: <199502092303.SAA03244@libws2.ic.sunysb.edu>


> >   Yes indeed, in response to the H666 bill. The Dems placed up for vote the 
> >   text of the 4th Amendment without attributing it to be such. It was 
> >   defeated. Dems then immediately took to the floor of the House accusing 
> >   the Repubs of tryingto dismantle the Constitution.
> 
> so is there a list of names of the people who voted against it? I use
> the term "people" very loosely.

A list of what congresspersons voted for/against various bills (even previous
ones like Cantwell and DT) would be useful. A lot of groups do that.


> 
> josh
> 

Rob






From jamesd at netcom.com  Thu Feb  9 15:13:35 1995
From: jamesd at netcom.com (James A. Donald)
Date: Thu, 9 Feb 95 15:13:35 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502091458.JAA26730@libws4.ic.sunysb.edu>
Message-ID: <Pine.3.89.9502091515.A5767-0100000@netcom10>


On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:
> It's not a mandate. It's an order from god. (As if you didn't know, it
> says in the bible that the Republican party is his official mouthpiece.)

Exon, who is the primary sponsor and spokesman for the 
"Communications Decency Act" is a tax-and-spend Democrat.

This conforms to my expectations, prejudices, and assumptions
about the way the world works.

I assume your prejudices are different.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From gnu  Thu Feb  9 15:56:12 1995
From: gnu (gnu)
Date: Thu, 9 Feb 95 15:56:12 PST
Subject: Wed 15 Feb, 730pm: BayFF's first monthly Bay Area EFF meeting
Message-ID: <9502092356.AA05230@toad.com>


EFF is pleased to introduce a series of monthly `BayFF' meetings in
the San Francisco Bay Area.  All EFF members, guests, and the public
are invited.

The first meeting will be in San Francisco on February 15, 1995, at
7:30PM.  The gracious donor of our first meeting place is:

	Wired Magazine
	520 Third Street, Fourth Floor
	San Francisco, CA
	+1 415 222 6200  voice

John Gilmore and Cindy Cohn will speak on the constitutional issues
around export controls on cryptography.  John is a co-founder of EFF
and Chair of the EFF Board's Crypto Committee.  Cindy is an attorney
in private practice at McGlashen and Sarrail in San Mateo.  These
controls inhibit free speech, publication of software and papers,
academic freedom of inquiry, and personal privacy, as well as having a
strong negative impact on computer security.  We'll explore some of
the implications and prospects for change.

Dave Farber will speak on "Living in the Global Information
Infrastructure -- some concerns".  Dave is an EFF Board member and has
more years of experience in computers and networking than the total
experience at many startup companies.  Vice President Gore has proposed
that the nations of the world undertake the building of a Global
Information Infrastructure -- the GII.  While most leaders agree with
the sprit of the Gore proposal -- namely to provide a mechanism which
could invigorate the world economy in the forthcoming information age,
many disagree with his belief that it will bring democracy to the
world.  They interpret such statements as being another example of
American colonialism.  It is this basic lack of uniform global
agreement on what terms mean, what rules apply to electronic commerce
and what impact a GII will have on their nation that underlies the
comments Dave will make.  These raise questions about the universality
of Cyberspace.  He will seek to table a set of questions that may
stimulate your thinking in this area.

There will also be plenty of time for general and specific questions,
issues, discussion, meeting people, and socializing with frontier-
minded folks.

We will schedule the second monthly meeting near the Computers,
Freedom, and Privacy conference -- tentatively on Friday night,
March 31.  Watch this space for more information.

We hope to see you on Wednesday!

	John Gilmore
	Jane Metcalfe
	Denise Caruso
	(Bay Area members of the EFF Board)





From g4frodo at cdf.toronto.edu  Thu Feb  9 16:23:46 1995
From: g4frodo at cdf.toronto.edu (Richard Martin ( frodo ))
Date: Thu, 9 Feb 95 16:23:46 PST
Subject: S.314 on Web
Message-ID: <95Feb9.192339edt.2438@marvin.cdf.toronto.edu>


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

The text of S.314 (the pi bill, as Doug pointed out to me earlier
today -- why I didn't realise earlier...) is available at
	http://baldric.resnet.cornell.edu/frodo/s.314.txt.html
with a rapidly hypertextified version of Slowdog's text on what
the bill will do to American law at
	http://baldric.resnet.cornell.edu/frodo/s.314.changes.html

   If there are errors or omissions, please tell me. If the URLs
are wrong, the failsafe is my homepage,
	http://baldric.resnet.cornell.edu/frodo/frodo.html
which has links to both. (Really. They're there. There's some
bumf about me. But the links are there.)

This may be useful to some. I find it handier to have it there
than in an odd text file lying around here.

frodo =)


Richard Martin    ChemPhysCompSci 9T7+PEY = 9T8   g4frodo at cdf.toronto.edu
Trinity College University of Toronto SVW92 martinrd at gpu.utcc.toronto.edu
My opinions, when not poached. (or fried) frodo at uhura.trinity.toronto.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQCVAgUBLzqwH6+lG3+zwTCVAQEGfwP+MOSWEAB2kbbabdai/y3o6QIDIWNefRle
UPTCVyqadfIIs7s8bJjymlJs/OCutm76Pdfst8U40Tpi4DcE6NGyuLe9TauHkQEf
+wFtgOYrju35YV/pdiXvIBmdnv8etthbtLA+b0KcaRVEKXVYP2NsZ7+WBT/gAVV1
XPbBwe1UJXw=
=kaQ8
-----END PGP SIGNATURE-----





From cactus at hks.net  Thu Feb  9 16:57:51 1995
From: cactus at hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Thu, 9 Feb 95 16:57:51 PST
Subject: Key management in Hastur
Message-ID: <199502092115.QAA11291@bb.hks.net>


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


Eric, if I understand you correctly, you're saying that the manner in
which trust is bestowed in keys should not be generalized.  Is this
correct?  I don't have a problem with that, and wasn't terribly interested
in defining trust parameters.  I do want to finish this in the next 4 to 6
weeks, after all.

However, that's not exactly the problem I'm trying to solve;  The phrase
"key management" is likely too vague or perhaps has specific connotations
that I'm unaware of, such that I'm using it wrongly.  I was never strong
on jargon, and "key management" is the phrase that came closest to an
expression of the problem I'm trying to solve.

The problem is this: You have a bitstream and you want to perform
a cryptographic function on it.  Therefore, you need a key.  For RSA
functions, I know of two different ways that keys are distributed:
PGP and X.509.  My intent is to support PGP keyrings and PEM-style
keyrings (I am not yet familiar with the latter)... having a way to
place keys into their proper keyrings would be nice, too, but there's
no way I'm going to worry about that in the first rev.  Would I be
understanding you correctly if I characterized your advice as being
to not plan to implement that at all?

There are two ways that I could approach handling keys in the code:

	1- Have a general RSA key format.  The would include parameters
	that are defined in either PGP and X.509 keys and would allow
	the code to hand back warnings such as "this key is not trusted
	by you" and "this key has expired."  This seems to be what you're
	advising against... 

	2- Have only a bare-bones key format that includes only the
	information necessary for crypto functions.  This is the way
	I'm leaning for several reasons, not the least of which is
	what you cite.

In either case, there must be an import function, extracting the key from
the appropriate keyrings or otherwise supplying the key.  Including functions
that extract keys from the appropriate PGP/PEM keyrings would be a Good
Thing and is right now The Plan: one can hardly expect the code to get
used if it needs Yet Another (undefined) Key Distribution method.

My X.509 vs PGP key question boils down to this: is it reasonable to try to
convert keys of one sort into keys of the other sort, providing the
functionality of converting a key obtained through an X.509 certificate
into a PGP-key?  Converting the other seems like a less desirable thing
to do, so I'm not really thinking about that problem.

I should note that in all cases in HCT where something is parameterized,
the caller can supply a callback function that matches the defined
interface and expect to win.  Thus, it's already supported (in the
general interface and soon the key handling) that a user could say
(in pseudo C code, missing parameters):

	erics_key_stub_fn(char *id, struct keytype *key, ...);

	...
	struct keytype *thiskey;
	thiskey = keyinit( KEYTYPE_RSA, (void *) erics_key_stub_fn, ...);
	if (!(get_key( thiskey, "eric at remailer.net",...))) {
          /* ... Do the right thing, etc. */
        }

Are we on a similar wavelength here, or am I totally missing the point?
The input is appreciated.

	-- Todd
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzqEYCoZzwIn1bdtAQHUcwF/QO2s178YMsxdSWQj6UDDErCDRv6+gaB5
CJnEyrRPwpS8jqRLOSDQmyjHDvOJbJS2
=xm8Q
-----END PGP SIGNATURE-----





From slowdog at wookie.net  Thu Feb  9 17:01:10 1995
From: slowdog at wookie.net (slowdog)
Date: Thu, 9 Feb 95 17:01:10 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <199502092258.RAA02881@libws2.ic.sunysb.edu>
Message-ID: <Pine.LNX.3.91.950209195950.9468A-100000@chewy.wookie.net>


On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

> > prosecutins will stick. Arrests and prosecutions will take a financial 
> > toll on those targetted, and will create a chillinf effect in the online 
> > community, meaning sysops and BBS operators will start policing 
> > themselves too severely in an effort to avoid politcial or legal scrutiny.
> 
> Exactly. It's already happening. I've noticed on local BBS's they are afraid
> of conversation about controversial subjects or files having to do with
> things like do-it-yourself-birth control methods, drug legalization, or
> crypto... some of the networks like RIME are also jittery about certain
> topics like crypto or how telephones work.

Which might the time is ripe for a sort of user-to-user and 
sysop-to-sysop outreach effort, an attempt to create a sort of solidarity 
amongst users of the various extant networks to stand together in 
supporting the free exchange of information.

> > broadcast paradigm, while the online world operates within the network 
> > paradigm. There are no hours in which it is safe to broadcast because 
> > there is no "broadcast" in the tradition sense.
> 
> Yes, I was discussing broadcasting. Scary thought is that because networks
> are different they will try to outright ban everything.

I wonder though sometimes if it's even occurred to lawmakers that they 
can't apply the safe harbor notion for indency to computer networks.


- dog







From msattler at jungle.com  Thu Feb  9 17:03:59 1995
From: msattler at jungle.com (Michael Sattler)
Date: Thu, 9 Feb 95 17:03:59 PST
Subject: Wed 15 Feb, 730pm: BayFF's first monthly Bay Area EFF meeting
Message-ID: <v0300141dab606b6fed94@[140.174.229.220]>


At 15:56 2/9/95, gnu at toad.com wrote:

>John Gilmore and Cindy Cohn will speak on the constitutional issues
>around export controls on cryptography.

Forget export; I fear that among the next n logical steps is to ban private
strong crypto for US citizens.  Otherwise what's the point of the
legislative path we're seeing trod.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From jltocher at CCGATE.HAC.COM  Thu Feb  9 17:25:31 1995
From: jltocher at CCGATE.HAC.COM (jltocher at CCGATE.HAC.COM)
Date: Thu, 9 Feb 95 17:25:31 PST
Subject: No Subject
Message-ID: <9501097923.AA792379483@CCGATE.HAC.COM>


     From Edupage:
     
     ONLINE SPYING
     While you're connected to your favorite Web page, it's also connected 
     to you, and could be copying all sorts of information off your hard 
     drive, say industry experts. In fact, it happened last year when 
     Central Point Software used registration software developed by 
     Pipeline Communications, and inadvertently also gathered descriptions 
     of the users' systems -- the type of microprocessor, the version of 
     DOS and Windows, the type of display and mouse, and the amount of free 
     space available on the hard drive. Customers squawked, and Central 
     Point had Pipeline change the software. However, Pipeline reports that 
     at least one of its clients is using the scanning feature now -- but 
     only after getting the owner's permission. The lesson? "If you can't 
     trust it, don't connect to it." (Forbes 2/13/95 p.186)
     
John L. Tocher                THE CITY-a bounded infinity.   A labyrinth where
JLTocher at ccgate.HAC.com       you are never lost. Your private map where every
PGP:  CE 72 1A 11 07 47 35    block bears exactly the same number. Even if you
35 9A C1 DE EA 64 21 BC 94    lose your way, you cannot go wrong.   --Kobo Abe


     






From emerth at gpu.srv.ualberta.ca  Thu Feb  9 17:27:21 1995
From: emerth at gpu.srv.ualberta.ca (Eric Merth)
Date: Thu, 9 Feb 95 17:27:21 PST
Subject: So, what's it all about?
Message-ID: <199502100127.SAA82871@gpu2.srv.ualberta.ca>


I went to a UNIX trade show yesterday, and the main speaker was a 
security type. He talked about "the cypherpunks" among other things.
He said you are really scary and dangerous and ...
But of course he had to also project this adress (cypherpunks at toad.com)
on the screen.

So are you really scary and dangerous? What are the cypherpunks?

Just curious,

-EWM




From weidai at eskimo.com  Thu Feb  9 17:50:02 1995
From: weidai at eskimo.com (Wei Dai)
Date: Thu, 9 Feb 95 17:50:02 PST
Subject: a new way to do anonymity
Message-ID: <199502100149.AA28876@mail.eskimo.com>


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

Eric Hughes wrote:

> Now here's an important detail that needs to get done right.  Is the
> forwarding for fixed length packets, variable length packets, or
> streams?  Is this decision global or local?  What are the latency and
> aggregatation effects?  How important are these for different classes
> of data?  (telnet v. voice, e.g.)

I'm not sure I understand the first question.  My idea was originally 
based on link encrypted streams.  How can forwarding variable length 
packets help untracibility?  Wouldn't an attacker just have to match 
up the sizes of incoming and outgoing packets?  Forwarding fixed 
length packets, on the other hands, just makes the system a 
remailer-net (so you'll have to do mixing, etc.).  What am I 
misunderstanding here?

> I'd suggest just getting something running first, to get some
> prototyping experience.

I just finished hacking ESM to do link encryption.  (see my 
other post)  Now if someone is willing to run a MUD type program and 
hook LESM up with it, then we'd have the first prototype of a 
pipe-net.

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzrFzzl0sXKgdnV5AQFfOAP7BpGWmo7FLK02a10NVTfgLEeheBosazzz
0TbFs2dwhtL4IRtY6To25e7MN2cz4X+qKJOleWy6uGbUowygHKbd1uiHOS9DNRmx
/fKeyIlGd/Ogv6hSpiL/JDd0vx7vVx9Ho1CIy+oAFq4v8Kwd0sqQenqqvhBdoEfA
zmVUpc+82nU=
=3mfe
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From joshua at dee.retix.com  Thu Feb  9 17:52:12 1995
From: joshua at dee.retix.com (joshua geller)
Date: Thu, 9 Feb 95 17:52:12 PST
Subject: So, what's it all about?
In-Reply-To: <199502100127.SAA82871@gpu2.srv.ualberta.ca>
Message-ID: <199502100151.RAA25844@sleepy.retix.com>



>   I went to a UNIX trade show yesterday, and the main speaker was a 
>   security type. He talked about "the cypherpunks" among other things.
>   He said you are really scary and dangerous and ...
>   But of course he had to also project this adress (cypherpunks at toad.com)
>   on the screen.

can't imagine he is much of a security stud if he is that deluded.

what was his name?

josh





From weidai at eskimo.com  Thu Feb  9 17:52:22 1995
From: weidai at eskimo.com (Wei Dai)
Date: Thu, 9 Feb 95 17:52:22 PST
Subject: a new way to do anonymity
Message-ID: <199502100152.AA29075@mail.eskimo.com>


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

Johnathan Corgan wrote:

> Wei, your traffic analysis treatment of this sort of thing would go a long way
> toward uncovering weaknesses and determining operational requirements and 
> limitations.

It seems to me that if a user maintains a 24-hour a day pipe to an 
uncompromised server, then the method I described earlier against 
remailers should not work against that user.  Otherwise, some kind of 
in-out statistical analysis may work.

> Tim, what massive social effects would it have if this type of network service
> were to become widely deployed? :)

See Verner Vinge's _True Names_ for a fictional description of a future 
where real time anonymous interactions are possible.

> At first glance, this Pipe-Net idea doesn't seem to take a lot of rocket science; 
> it seems that most of the components or algorithms are are already in use, just 
> in a very different way.

This is certainly true.  The system Vinge describes is almost a 
pipe-net.  But he didn't say anything about link encryption, without 
which the system can be trivially broken.

> I can think of a number of problems already, however.  Spamming.  Bandwidth
> limitations.  Complexity of client and switch software.  Standards.  Flow
> control.
>
> In other works, all the stuff the ATM forum is already dealing with :)

I haven't responded to the comments you made about the similarity between 
pipe-net and ATM, mostly because I'm not very familiar with ATM.  But 
as I understand it, ATM is based on forwarding fixed length cells, 
whereas pipe-net is based on fixed-bandwidth link encrypted streams.

Spamming, and flow control shouldn't be problems, since all users 
of a server will connect to it with pipes of the same bandwidth, so it 
can just accept a certain number and then stop.

Bandwidth limitations will depend on how fast the server CPU can do 
the encryption and decryption.  With LESM at 100 cps, each connection 
took 2% of the CPU capacity of a Sun 4-CPU(90Hz) 4/670MP.  Of course, 
I made no consideration for efficiency when I hacked ESM, so this can 
probably be decreased quite a bit.

Wei Dai

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzrGOzl0sXKgdnV5AQE1TQP/UR0xfaS/Nxk7ta/AfdRhzV+v+BmpxT4O
UqiMkCpXRZbMFTuw/hnhlJ9fuOF2QS/50MUHXu+kiFSASH5wBFpLNSgWuFIHADny
76RYSjpA+A4IpWomihGT1/BPZkyIcooDXCKGUbgWjZhi50S0oCfAILjV/1ti2f02
AOyBxRYRYvM=
=IhUw
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From unicorn at access.digex.net  Thu Feb  9 17:58:22 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Thu, 9 Feb 95 17:58:22 PST
Subject: So, what's it all about?
In-Reply-To: <199502100127.SAA82871@gpu2.srv.ualberta.ca>
Message-ID: <Pine.SUN.3.91.950209205700.28249A-100000@access4.digex.net>


On Thu, 9 Feb 1995, Eric Merth wrote:

> Date: Thu, 9 Feb 1995 18:27:04 -0700 (MST)
> From: Eric Merth <emerth at gpu.srv.ualberta.ca>
> To: cypherpunks at toad.com
> Subject: So, what's it all about?
> 
> I went to a UNIX trade show yesterday, and the main speaker was a 
> security type. He talked about "the cypherpunks" among other things.
> He said you are really scary and dangerous and ...
> But of course he had to also project this adress (cypherpunks at toad.com)
> on the screen.
> 
> So are you really scary and dangerous? What are the cypherpunks?

Only to totalatarian dictator types who want to control the flow and 
access to information.

Did he cite reasons for our scaryness or just slander us generally?

> 
> Just curious,
> 
> -EWM
> 

--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From msattler at jungle.com  Thu Feb  9 18:43:40 1995
From: msattler at jungle.com (Michael Sattler)
Date: Thu, 9 Feb 95 18:43:40 PST
Subject: web pages sucking secrets from your hard drive
Message-ID: <v03001424ab6082e37022@[140.174.229.220]>


At 17:13 2/9/95, jltocher at CCGATE.HAC.COM wrote:

>While you're connected to your favorite Web page, it's also connected
>to you, and could be copying all sorts of information off your hard
>drive, say industry experts.

Wrong.

>In fact, it happened last year when
>Central Point Software used registration software developed by
>Pipeline Communications

Can you tell the difference between a web session and an installer?

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From weidai at eskimo.com  Thu Feb  9 18:43:52 1995
From: weidai at eskimo.com (Wei Dai)
Date: Thu, 9 Feb 95 18:43:52 PST
Subject: LESM - Link Encrypted Session Manager (3rd try)
Message-ID: <199502100243.AA03571@mail.eskimo.com>


I tried to distribute LESM to the cypherpunks mailing list twice, and 
neither of them made it to the nntp.hks.com list archive (my 
laster posts HAVE).  What is going on here?  This is a second repost.

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

I finished hacking Matt's ESM to do link encryption yesterday, but 
for some reason the mail I sent to cypherpunks didn't get echoed back 
to me, so I'm sending this again.

To install: get ESM and RSAREF, make sure you can compile ESM, 
then replace the esm.c with my hacked version and recompile.

To use: same as ESM, but there's an extra option "-b bandwidth", the 
default is 100 cps.

I've attached the modified esm.c here since it doesn't include any 
crypto code.  To get ESM, write to cfs at research.att.com and state the 
following:

	- you are in the US or Canada, and
	- you are a US or Canadian citizen or legal permanent
	  resident, and
	- You've read and understand the license and export
	  conditions.

RSAREF is in ftp://rsa.com/rsaref/

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzqTtTl0sXKgdnV5AQEmbgP8CRxE+RCGsDXwwShWhZKGytSywyWZ8RXB
RPBHZmk6UgdpCR2VVo8wXjcPuEv4SHp9ZjhFTq53JZ/s3YcV5FxF33/ivSlh1Ra4
P8GSYnoEaIJoFrJyagukbBUaY6zWCx0PcnsLoVArCxujwRYwfrQvHdiNx13z7bJh
OSEhhoE9djg=
=PY8P
-----END PGP SIGNATURE-----


-------------- Enclosure number 1 ----------------
/*
 * LESM - Link Encrypted Session Manager
 * v0.6a.01
 * Wei Dai
 * 2/8/1995
 *
 * This program is a quick and dirty hack of:
 */

/*
 * ESM - Encrypted Session Manager
 * v0.6a
 * matt blaze
 * January 1995
 */

/*
 * The author of this software is Matt Blaze.
 *              Copyright (c) 1995 by AT&T.
 * Permission to use, copy, and modify this software without fee
 * is hereby granted, provided that this entire notice is included in
 * all copies of any software which is or includes a copy or
 * modification of this software and in all copies of the supporting
 * documentation for such software.
 *
 * This software is subject to United States export controls.
 *
 * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
 * WARRANTY.  IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY
 * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
 * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
 */
/*
 * Some of this file was stolen from the BSD "script" program, which
 * is covered under the following notice:
 *
 * Copyright (c) 1980 Regents of the University of California.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *	This product includes software developed by the University of
 *	California, Berkeley and its contributors.
 * 4. Neither the name of the University nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

#ifndef lint
char copyright1[] =
"@(#) Copyright (c) 1980 Regents of the University of California.\n\
 All rights reserved.\n";
char copyright2[] =
"@(#) Copyright (c) 1995 AT&T\nAll rights reserved.\n";
#endif /* not lint */

#include <sys/types.h>
#include <sys/stat.h>
#include <termios.h>
#ifndef SUN
#include <sys/ioctl.h>
#endif
#include <sys/time.h>
#include <sys/file.h>
#include <sys/signal.h>
#include <unistd.h>
#include <stdio.h>
#include "global.h"
#include "rsaref.h"
#include "esm.h"


char	*shell;
int	master;
int	slave;
int	subchild;

int escape=036; /* ^^ */
int ciphstate=0;
int ciphbyte=0;

int keyed=0;

struct	termios tt;
struct	winsize win;
int	lb;
int	l;
char	line[] = "/dev/ptyXX";
int	aflg;

#define REMOTE 0
#define LOCAL 1
#define CALC 2

int mode=LOCAL;
int paranoid=0;

#define SL_START 0
#define SL_GOT1 1
#define SL_GOT2 2
#define SL_GOT3 3
#define SL_GOT4 4
#define SL_KEYING 5
#define SL_CRYPT 6
int sloutstate=SL_START;
char *cmd=NULL;

#define TRANS 0
#define CMDWAIT 1
#define CIPHER 2
#define KEYWAIT 3

#define IV0 0
#define IV1 1
#define IV2 2
#define IV3 3
#define C0  4
#define C1  5

int state=TRANS;
int cstate=IV0;

FILE *fpmaster;

struct timeval tvPause={0,10000};
struct timeval tvNoPause={0,0};

unsigned char filler = (unsigned char) 31;

#define bwrite(fp,buf,len) (fwrite(buf,len,1,fp))

main(argc, argv)
	int argc;
	char *argv[];
{
	extern char *optarg;
	extern int optind;
	int ch, result;
	void finish();
	char *getenv();
	fd_set fds;
        struct timeval tv;

	while ((ch = getopt(argc, argv, "e:b:splrci")) != EOF)
	  	switch((char)ch) {
	  	    case 'e':
	  		cmd=optarg;
	  		break;
                    case 'b':
                    	tvPause.tv_usec=(long)1000000/atol(optarg);
                        break;
	  	    case 'i':
	  	    case 's':
	  	    case 'p':
	  		paranoid=1;
	  	    case 'r':
	  		mode=REMOTE;
	  		break;
	  	    case 'l':
	  		mode=LOCAL;
	  		break;
	  	    case 'c':
	  		mode=CALC;
	  		break;
	  	    case '?':
	  	    default:
	  		fprintf(stderr,
	  		   "usage: lesm [-rlc] [-b bandwidth] [-e program\n");
	  		exit(1);
	  	}
	argc -= optind;
	argv += optind;

	if ((shell=getenv("SHELL")) == NULL)
		shell = "/bin/sh";
	
      	getmaster();

	(void) signal(SIGCHLD, finish);
	subchild = fork();
	if (subchild < 0) {
		perror("fork");
		fail();
	}
	if (subchild==0)
		doshell();
	else {
		/* main loop */
		printf("LESM v0.6a.01, hacked by Wei Dai from ESM v0.6a - encrypted session manager\n");
		printf("    by Matt Blaze, AT&T Bell Labs, January 1995\n");
	       	randinit();
		cipherinit();
		switch (mode) {
		    case REMOTE:
			if (paranoid)
			     printf("remote server ready\n");
			else
			     printf("remote server ready; ctl-^ to escape\n");
			break;
		    case LOCAL:
			printf("local layer ready (run 'lesm -s' on remote)\n");
			break;  
		    default:  /* not yet */
			printf("lesm ready\n");
		}
		rawtty();
		fpmaster=fdopen(master,"w");
		if (fpmaster == NULL)
			done();
		if (paranoid)
			startsession();
            
                while(1)
                {
			FD_ZERO(&fds);
			FD_SET(0,&fds);
                        
                        tv=tvNoPause;
                        result=select (FD_SETSIZE,&fds,NULL,NULL,&tv);

                        if (result==1)
                        	doinput();

      	                if (mode==LOCAL && sloutstate==SL_CRYPT && result==0)
                        	doslavein(filler);
                                
                        if (result<0)
                        	break;

	       		FD_ZERO(&fds);
	       		FD_SET(master,&fds);
                        
                        tv=tvNoPause;
                        result=select (FD_SETSIZE,&fds,NULL,NULL,&tv);
	       		                    	
                        if (result==1)
                                dooutput();

                        if (mode==REMOTE && state==CIPHER && result==0)
                        	domasterout(filler);

                        if (result<0)
                        	break;
		}
		done();
	}                                          
}

doinput()
{
	int cc;
	int i;
	static unsigned char ibuf[512];
	
	if ((cc = read(0, ibuf, 512)) > 0) {
		switch (mode) {
		    case REMOTE:
			for (i=0; i<cc; i++)
				domasterin(ibuf[i]);
			break;
		    case LOCAL:
			for (i=0; i<cc; i++)
				doslavein(ibuf[i]);
			break;
		    default:
			for (i=0; i<cc; i++)
				bwrite(fpmaster,&ibuf[i],1);
			break;
		}
		fflush(fpmaster);
		fflush(stdout);
	} else
		done();
}

doslavein(ibuf)
     unsigned char ibuf;
{
	int c;
	static int count=0;
        struct timeval tv;
	
	switch (sloutstate) {
	    case SL_CRYPT:
		if (ibuf==escape) {
			bwrite(stdout,">>",2);
			fflush(stdout);
			if (slescape()) {
				printf("q\r\nEntering CLEARTEXT mode\r\n");
				bwrite(fpmaster,"PPPPPPPPPPPPPPPP",16);
				sloutstate=SL_START;
			}
			break;
		}			
		c=cfb8_encrypt(ibuf);
		if (!(++count % 8))
			bwrite(fpmaster,"!",1);
		sendhex(fpmaster,c);
        	tv=tvPause;
                select (FD_SETSIZE,NULL,NULL,NULL,&tv);
		break;
	    default:
		bwrite(fpmaster,&ibuf,1);
		break;
	}
}

slescape()
{
	char buf;
	int c;
	int escaped=0;
	
	while (read(0,&buf,1)>0) {
		if (escaped) {
			escaped=0;
			bwrite(fpmaster,&buf,1);
			continue;
		}
		if (buf==escape) {
			c=cfb8_encrypt(buf);
			sendhex(fpmaster,c);
			return 0;
		}
		bwrite(stdout,&buf,1);
		fflush(stdout);
		if (buf=='\\') {
			mode=escaped;
			continue;
		}
		if (buf=='\r')
			return 0;
		if (buf=='C') {
			return 1;
		}
		printf("\r\nType one of the following:\r\n");
		printf("  \\[char] to send char as cleartext\r\n");
		printf("  ctrl-^ to send escape character\r\n");
		printf("  'C' to return to CLEARTEXT session\r\n");
		printf("  <enter> to return to encrypted session\r\n");
	}
	return 1; /* should never happen */
}

			       

domasterin(ibuf)
     unsigned char ibuf;
{
	int c;
	char ch;
	static int bad=0;
	
	switch (state) {
	    case TRANS:
	  	if (ibuf != escape)
	  		bwrite(fpmaster, &ibuf, 1);
	  	else {
	  		state=CMDWAIT;
	  		bwrite(stdout,">>",2);
	  		cstate=IV0;
	  	}
	  	break;
	    case CMDWAIT:
	  	if (ibuf == escape) {
	  		bwrite(fpmaster, &ibuf, 1);
	  		state=TRANS;
	  	} else switch (ibuf) {
	  	    case '\r':
	  	    case '\n':
	  		bwrite(stdout,"\r\n",2);
	  		state=TRANS;
	  		break;
	  	    case 's':
	  	    case 'S':
	  		startsession(LONG);
	  		break;
	  	    case 'Q':
	  		done();
	  		break;
	  	    default:
	  		printf("Type 's' to start encrypted session\r\n");
	  		printf("     'Q' to terminate remote session\r\n");
	  		printf("     ctrl-^ to send escape character\r\n");
	  		printf("     <enter> to return to session\r\n");
	  		break;
	  	}
	  	break;
	    case CIPHER:
	  	if (strchr("0123456789abcdef!",ibuf)!=NULL) {
	  		bad=0;
	  		if ((c = cipherout(ibuf)) >= 0) {
	  		      	ch=c;
                                if (ch!=filler)
	  			      	bwrite(fpmaster,&ch,1);
	  		}
	  	} else if (bad++ > 16) {
	  		delkey();
	  		bwrite(stdout,"XXXXXXXXXXXXXXXX",16);
	  		if (paranoid)
	  		      	done();
	  		state=TRANS;
	  	} else
	  		ciphstate=0;
	  	break;
	    case KEYWAIT:
	  	if (strchr("0123456789abcdef:",ibuf)!=NULL) {
			masterkeyin(ibuf);
		} else {
			delkey();
			bwrite(stdout,"XXXXXXXXXXXXXXXX",16);
			if (paranoid)
				done();
			state=TRANS;
		}
		break;
	}
}

int pubstat=0;
int pubpos=0;
unsigned char pubbyte=0;
int pksize = -1;

startsession()
{
	static unsigned char buf[5] = {0177, '~', 0177, '~', 'L'};
	static unsigned char colon=':';
	int i;

	pklen=dhparams[LONG].primeLen;
	printf("Starting remote side of %d bit key exchange.\r\n",pklen*8);
	if (createdh(LONG) < 0)
		return -1;
	bwrite(stdout,buf,5);
	for (i=0; i<pklen; i++)
		sendhex(stdout,ourpub[i]);
	bwrite(stdout,&colon,1);
	pksize=LONG;
	pubstat=0;
	pubpos=0;
	pubbyte=0;
	state=KEYWAIT;
	return 0;
}

sltranspub(len)
{
	static unsigned char colon=':';
	int i;
	
	printf("\r\nStarting local key exchange.\r\n");
	for (i=0; i<len; i++)
		sendhex(fpmaster,ourpub[i]);
	bwrite(fpmaster,&colon,1);
	printf("entering ENCRYPTED mode; type ctrl-^ to escape\r\n");
}

masterkeyin(c)
     char c;
{
	int bits;

	if (c==':') {
		if (pubpos!=(pklen+2)) /* +2 for trailing checkword */
			goto abort;
		if (mcalckeys(pksize)<0) /* also verifies */
			goto abort;
		ciphstate=0;
		state=CIPHER;
		return;
	} else if (pubpos<MAXPUBKEY) {
		bits=atoh(c);
		if (bits<0)
			goto abort;
		if (pubstat) {
			pubbyte |= bits;
			otherpub[pubpos]=pubbyte;
			pubpos++;
		} else {
			pubbyte = bits<<4;
		}
		pubstat = 1-pubstat;
		return;
	}
    abort:
	bwrite(stdout,"XXXXXXXXXXXXXXXX",16);
	if (paranoid)
		done();
	state=TRANS;
}

int mcalckeys(len)
     int len;
{
	int i;
	
	if (dhagree(len)<0) /* sets up session keys */
		return -1;
	for (i=0; i<8; i++) {
		ivin[i]=0;
		ivout[i]=0xff;
	}
	if (cfb8_decrypt(otherpub[pklen]) ||
	    cfb8_decrypt(otherpub[pklen+1]))
		return -1;
	return 0;
}

int slcalckeys(len)
     int len;
{
	int i;
	
	if (dhagree(len)<0) /* sets up session keys */
		return -1;
	for (i=0; i<8; i++) {
		ivout[i]=0;
		ivin[i]=0xff;
	}
	ourpub[pklen]=cfb8_encrypt(0);
	ourpub[pklen+1]=cfb8_encrypt(0);
	return 0;
}

initslkey(param)
     int param;
{
	if ((param<0) || (param>2))
		return -1;
	pklen=dhparams[param].primeLen;
	pksize=param;
	pubstat=0;
	pubpos=0;
	pubbyte=0;
}

slkeyin(c)
     char c;
{
	int bits;

	if (c==':') {
		if (pubpos!=pklen)
			goto abort;
		if (createdh(pksize)<0)
			goto abort;
		if (slcalckeys(pksize)<0)
			goto abort;
		sltranspub(pklen+2);
		ciphstate=0;
		sloutstate=SL_CRYPT;
		return;
	} else if (pubpos<MAXPUBKEY){
		bits=atoh(c);
		if (bits<0)
			goto abort;
		if (pubstat) {
			pubbyte |= bits;
			otherpub[pubpos]=pubbyte;
			pubpos++;
		} else {
			pubbyte = bits<<4;
		}
		pubstat = 1-pubstat;
		return;
	}
    abort:
	bwrite(stdout,"X",1);
	state=SL_START;

}



int cipherout(ch)
     char ch;
{
	int bits;
	
	if (ch=='!') {
		ciphstate=0;
		return -1;
	}
	bits=atoh(ch);
	if (ciphstate) {
		ciphbyte |= bits;
		ciphstate=0;
		return(cfb8_decrypt(ciphbyte));
	} else {
		ciphbyte = bits<<4;
		ciphstate=1;
		return -1;
	}
}

int ciphercalcin(ch)
     unsigned char ch;
{
	static unsigned char iv[8];
	static unsigned int cbuf;
	int c;
	int i;

	c = atoh(ch);
	switch (cstate) {
	    case IV0:
		for(i=0; i<8; i++)
			iv[i]=0;
		cbuf = (c&0xf)<<4;
		cstate=IV1;
		return '.';
	    case IV1:
		cbuf = cbuf | (c&0xf);
		iv[7]=cbuf;
		cstate=IV2;
		return '.';
	    case IV2:
		cbuf = (c&0xf)<<4;
		cstate=IV3;
		return '.';
	    case IV3:
		cbuf = cbuf | (c&0xf);
		iv[6]=cbuf;
		cstate=C0;
		return '.';
	    case C0:
		cbuf = (c&0xf)<<4;
		cstate=C1;
		return '.';
	    case C1:
		cbuf = cbuf | c&0xf;
		c=cfb8_decrypt(cbuf);
		cstate=C0;
		if (isprint(c)) {
			bwrite(fpmaster,&c,1);
			return '_';
		} else {
			return '?';
		}
	    default:
		return '?';
	}
}

#include <sys/wait.h>

void
finish()
{
	union wait status;
	register int pid;
	register int die = 0;

	while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0)
		if (pid == subchild)
			die = 1;

	if (die)
		done();
}

dooutput()
{
	register int cc;
	int i;
	unsigned char obuf[512];
	
	if ((cc = read(master, obuf, 512)) > 0) {
		switch (mode) {
		    case REMOTE:
			for (i=0; i<cc; i++)
				domasterout(obuf[i]);
			break;
		    case LOCAL:
			for (i=0; i<cc; i++)
				doslaveout(obuf[i]);
			break;
		    default:
			for (i=0; i<cc; i++)
				bwrite(stdout, &obuf[i], 1);
			break;
		}
		fflush(fpmaster);
		fflush(stdout);
	} else
		done();
}

domasterout(obuf)
     unsigned char obuf;
{
	int c;
	static int count=0;
        struct timeval tv;
	
	switch (state) {
	    case CIPHER:
		c=cfb8_encrypt(obuf);
		if (!(++count % 8))
			bwrite(stdout,"!",1);
		sendhex(stdout,c);
        	tv=tvPause;
                select (FD_SETSIZE,NULL,NULL,NULL,&tv);
		break;
	    case TRANS:
		bwrite(stdout, &obuf, 1);
		break;
	    default:
		/* throw away since i/o screws up keying */
		break;
	}
}


doslaveout(obuf)
     unsigned char obuf;
{
	static int bad=0;
	int c;
	char ch;
	
	switch (sloutstate) {
	    case SL_START:
	   	bwrite(stdout, &obuf, 1);
	   	if (obuf==0177)
	   		sloutstate=SL_GOT1;
	   	break;
	    case SL_GOT1:
	   	bwrite(stdout, &obuf, 1);
	   	if (obuf=='~')
	   		sloutstate=SL_GOT2;
	   	else
	   		sloutstate=SL_START;
	   	break;
	    case SL_GOT2:
	   	if (obuf==0177)
	   		sloutstate=SL_GOT3;
	   	else {
	   		bwrite(stdout, &obuf, 1);
	   		sloutstate=SL_START;
	   	}
	   	break;
	    case SL_GOT3:
	   	if (obuf=='~')
	   		sloutstate=SL_GOT4;
	   	else {
	   		bwrite(stdout, &obuf, 1);
	   		sloutstate=SL_START;
	   	}
	   	break;
	    case SL_GOT4: /* key size indicator */
	   	bwrite(stdout, &obuf, 1);
	   	if (obuf=='S') {
	   		initslkey(SHORT);
	   		sloutstate=SL_KEYING;
	   	} else if (obuf=='M') {
	   		initslkey(MEDIUM);
	   		sloutstate=SL_KEYING;
	   	} else if (obuf=='L') {
	   		initslkey(LONG);
	   		sloutstate=SL_KEYING;
	   	} else
	   		sloutstate=SL_START;
	   	break;
	    case SL_KEYING:
	   	if (strchr("0123456789abcdef:",obuf) != NULL) {
	   		slkeyin(obuf);
	   	} else {
	   		bwrite(stdout,"U",1);
	   		sloutstate=SL_START;
	   	}
	   	break;
	    case SL_CRYPT:
	   	if (strchr("0123456789abcdef!",obuf) != NULL) {
	   		bad=0;
	   		if ((c = cipherout(obuf))>=0) {
	   			ch=c;
                                if (ch!=filler)
		   			bwrite(stdout,&ch,1);
	   		}
	   	} else if (bad++ > 8) {
	   		fprintf(stderr,"\r\nEncrypted session terminated -");
	   		fprintf(stderr,"\r\npress enter for CLEARTEXT mode: ");
	   		waitenter();
	   		delkey();
	   		sloutstate=SL_START;
	   	} else
	   		ciphstate=0;
	   	break;
	    default:
	   	bwrite(stdout, &obuf, 1);
	   	break;
	}
}



doshell() 
{
	int t;

	/***
	t = open(_PATH_TTY, O_RDWR);
	if (t >= 0) {
		(void) ioctl(t, TIOCNOTTY, (char *)0);
		(void) close(t);
	}
	***/
	getslave();
	(void) close(master);
	(void) dup2(slave, 0);
	(void) dup2(slave, 1);
	(void) dup2(slave, 2);
	(void) close(slave);
	if (cmd==NULL)
		execl(shell, "sh", "-i", 0);
	else
		system(cmd);
	perror(shell);
	fail();
}

rawtty()
{

	struct termios sbuf;

        sbuf = tt;
        sbuf.c_iflag &= ~(INLCR|IGNCR|ICRNL|IXON);
        sbuf.c_oflag &= ~OPOST;
        sbuf.c_lflag &= ~(ICANON|ISIG|ECHO);
        sbuf.c_cc[VMIN] = 1;
        sbuf.c_cc[VTIME] = 0;
	(void) tcsetattr(0, TCSAFLUSH, &sbuf);
}

cookedtty()
{
	(void) tcsetattr(0, TCSAFLUSH, &tt);
}

fail()
{

	(void) kill(0, SIGTERM);
	done();
}

done()
{
	cookedtty();
	switch (mode) {
	    case REMOTE:
		if (state==CIPHER)
			printf("XXXXXXXXXXXXXXXX\n");
		printf("lesm remote ");
		break;
	    case LOCAL:
		printf("lesm local ");
		break;
	}
	printf("done\n");
	exit(0);
}

getmaster()
{
	char *pty, *bank, *cp;
	struct stat stb;

	pty = &line[strlen("/dev/ptyp")];
	for (bank = "pqrstuvwxyz"; *bank; bank++) {
		line[strlen("/dev/pty")] = *bank;
		*pty = '0';
		if (stat(line, &stb) < 0)
			break;
		for (cp = "0123456789abcdef"; *cp; cp++) {
			*pty = *cp;
			master = open(line, O_RDWR);
			if (master >= 0) {
				char *tp = &line[strlen("/dev/")];
				int ok;

				/* verify slave side is usable */
				*tp = 't';
				ok = access(line, R_OK|W_OK) == 0;
				*tp = 'p';
				if (ok) {
					(void) tcgetattr(0, &tt);
				    	(void) ioctl(0, TIOCGWINSZ, 
						(char *)&win);
					return;
				}
				(void) close(master);
			}
		}
	}
	fprintf(stderr, "Out of pty's\n");
	fail();
}

getslave()
{

	line[strlen("/dev/")] = 't';
	slave = open(line, O_RDWR);
	if (slave < 0) {
		perror(line);
		fail();
	}
	(void) tcsetattr(slave, TCSAFLUSH, &tt);
	(void) ioctl(slave, TIOCSWINSZ, (char *)&win);
	(void) setsid();
	(void) ioctl(slave, TIOCSCTTY, 0);
}

waitenter()
{
	unsigned char b;
	do {
		read(0,&b,1);
	} while (b!='\r');
	printf("\r\n");
}

sendhex(fp,c)
     FILE *fp;
     unsigned int c;
{
	static char buf[16];

	sprintf(buf,"%02x",c);
	bwrite(fp,buf,2);
}





From jrochkin at cs.oberlin.edu  Thu Feb  9 18:48:28 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Thu, 9 Feb 95 18:48:28 PST
Subject: a new way to do anonymity
Message-ID: <ab60837505021004ea5d@[132.162.201.201]>


At 8:51 PM 02/09/95, Wei Dai wrote:
>It seems to me that if a user maintains a 24-hour a day pipe to an
>uncompromised server, then the method I described earlier against
>remailers should not work against that user.  Otherwise, some kind of
>in-out statistical analysis may work.

Ay, what a good point.  I know this connection is incredibly obvious, but
just in case no one has yet made it, I will.  A "pipe-net" host running
Wei's L- modification to Matt's ESM, which was also running a remailer,
would provide pretty much untraceable entrance to the remailer net.  The
remailer software wouldn't even need to be integrated with the pipe
software in any way, as long as the user had a secure connection to the
host, he could just connect to the SMTP port and send the message to the
remailer that way.

I would guess that the attack Wei described, as well as almost every other,
if not every other, traffic analysis attack would fail if users were
utilizing this.  You could trace the message to a given "pipe net" host
using traffic analysis, but you wouldn't be able to trace it to a user, if
he was using the pipe net appropriately.  Obviously, this also requires a
sufficient number of people to be using the pipe net host, so that no real
information is gained just by tracing the connection to a given pipenet
host.  And of course non-pipe-net users are using the remailer on the
machine to, which makes things a tiny bit more complicated for the traffic
analysits

Note also that the bandwith could be kept extremely low.  Even something
like 10cps.  So, maybe it takes you up to a couple hours to actually
transit your message to the pipe-net host remailer,  but we currently dont'
expect instantaneous remailernet transmission anyway.  We've learned to
live with latency on the order of hours, as opposed to seconds, so adding
several more hours onto the chain isn't a problem.  And with a bandwith
maintained that low, the pipenet host could theoretically host many many
"pipe net remailer" client users, without causing a serious problem.

This seems like a really exciting thing to me.  That we already have the
tools available for, right now at this very second, now that Wei has done
the link encryption mod to ESM.







From cactus at seabsd.hks.net  Thu Feb  9 19:58:32 1995
From: cactus at seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Thu, 9 Feb 95 19:58:32 PST
Subject: LESM - Link Encrypted Session Manager (3rd try)
Message-ID: <199502100354.WAA15146@bb.hks.net>


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

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

In article <199502100243.AA03571 at mail.eskimo.com>,
Wei Dai <weidai at eskimo.com> wrote:
>I tried to distribute LESM to the cypherpunks mailing list twice, and 
>neither of them made it to the nntp.hks.com list archive (my 
>laster posts HAVE).  What is going on here?  This is a second repost.

nntp.hks.*net*.  hks.com is someone else.

We were off-line for several hours today, so it's possible that they're
still sitting in a mail queue somewhere.  Netcom is our denial of
service provider, colluding with NyNex... 'nuff said.
- - --
Todd Masco     | "Don't be too proud of this technological terror you've
cactus at hks.net |   constructed."        - Darth Vader   
     Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzqp4xNhgovrPB7dAQGrxAP+Ota+9gBiOGmkE0XLxiIcLlE+rq0FMvcg
STYMFJPZbGc0QymyNZWWIQrFZS5yo7Zr8hRmmw6a/h3+MjzioiWvDJzDFdmPhwNd
CAvlvfAV97ZC4sYqc+KeeLjjxEGXpUbUQFbcKe4KAqx4XG6UXtWseeGbz+ZzSstu
iP1KSx5Oznw=
=QaIT
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLzrjMCoZzwIn1bdtAQF6rQF/e9K678EztVO+4lr/oH+POXVFZm4Eg8ao
4DqXfTkbQ+fpnWHacueth1/9xFrt8RJd
=s71u
-----END PGP SIGNATURE-----





From dshayer at netcom.com  Thu Feb  9 21:07:18 1995
From: dshayer at netcom.com (dshayer at netcom.com)
Date: Thu, 9 Feb 95 21:07:18 PST
Subject: Not necessarily crypto but scary anyway...
Message-ID: <v02110101ab60a4d6d80d@DialupEudora>


>A friend advises me that today House Bill 666 passed. This supposedly would
>allow police officers to use evidence collected illegaly if they 'believed'
>that it was collected in good faith.
>
>Any word on it?

Yes, this bill is real, and it passed the house resoundingly.  (I don't
know if the bill number is accurate.)  According to the ny times, the
republicans have been trying to pass this for a long time, and now they
control congress.

Interestingly, the ATF and IRS are specifically excluded!  The bill was
opposed by both civil liberties groups and gun nuts.  (Hope I don't offend
too many gun nuts.)  The ATF was excluded as a sop to the NRA I suppose.


During debate, Rep. John Dingell (MI) called the ATF "jackbooted American
fascists."  Way to go John!

David


+------------------------------------------------------------------------+
|David Shayer                                 dshayer at netcom.com         |
|Sentient Software / Symantec                 shayer at applelink.apple.com |
|"Shoot Newt."                                                           |
+------------------------------------------------------------------------+







From peterb at telerama.lm.com  Thu Feb  9 21:15:50 1995
From: peterb at telerama.lm.com (Peter Berger)
Date: Thu, 9 Feb 95 21:15:50 PST
Subject: Da Judge-L FAQ -- We are not Amused
In-Reply-To: <199502090712.XAA14865@alkahest.isas.com>
Message-ID: <3hesqj$cqn@ivory.lm.com>


In article <199502090712.XAA14865 at alkahest.isas.com>,
joshua geller  <alkahest!joshua at dee.retix.com> wrote:
>here come de judge:
>>   The so-called Cypherpunks List, having been a party to this illegal
>>   and "most heinous" distribution, is hereby invited to appear in our
>>   Chambers on the morning of Tuesday, 29 February, 1995, at a place of
>>   our choosing. Defense will be heard, and then the guilty will be
>>   punished.
>
>yes. a fair trial and a speedy execution.

"Like a dog," thought Joseph K.

-- 
......................................................................
  Peter G. Berger, Esq.  Telerama Public Access Internet, Pittsburgh
Internet: peterb at telerama.lm.com Phone: 412/481-3505 Fax: 412/481-8568
	   	 	http://www.lm.com/~peterb





From unicorn at access.digex.net  Thu Feb  9 22:28:29 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Thu, 9 Feb 95 22:28:29 PST
Subject: The question is moot: (Was: Not crypto, but scary.)
In-Reply-To: <v02110101ab60a4d6d80d@DialupEudora>
Message-ID: <Pine.SUN.3.91.950210010704.5527A-100000@access3.digex.net>




With all the gafawing about the bill (666) which just flew by, and the 
"Dem's" running off about how the constitution is being dismantled, I 
thought I would cite some case law.

I direct your attention to _United States v. Leon_, 468 U.S. 897 (1984).

Justice White:

This case presents the question whether the Fourth Ammendment 
exclusionary rule should be modified so as not to bar the use in the 
prosecution's case-in-chief of evidence obtained by officers acting in 
reasonable reliance on a search warrant issued by a detached and neutral 
magistrate but ultimately found to be unsupported by probable cause.

[...]

The Fourth Amendment contains no provision expressly precluding the use 
of evidence obtained by violation if its commands, and an examination of 
its orgin and purposes makes clear that the use of fruits of a past 
unlawful search or seizure "work[s] no new Fourth Amendment wrong."  The 
wrong condemned by the Amendment is "fully accomplished" by the unlawful 
search or seizure itself, and the exclusionary rule is neither intended 
nor able to "cure the invasion of the defendant's rights which he has 
already suffered."  The rule thus operates as "a judicially created 
remedy designed to safeguard Fourth Amendment rights generally through 
its deterrant effect, rahter than a personal constitutional right of the 
person aggrieved."

[...]

First, the exclusionary rule is designed to deter police misconduct 
rather than to punish the errors of judges and magistrates.  Second, 
there exists no evidence suggesting that judges and magistrates are 
inclined to ignore or subvert the Fourth Amendment or that lawlessness 
among these actors requires application of the extreme sanction of exclusion.

[...]

[The exclusionary rule cannot be expected to deter objectively reasonable 
law enforcement activity...]

This is particularly true, we believe, when an officer acting with objective
good faith has obtained a search warrant from a judge or magistrate and acted
within its scope.  In most such cases, there is no police illegality and this
nothing to deter. It is the magistrate's responsibility to determine whether
the officer's allegations estlablish probable cause and, if so, to issue a
warrant comporting in form with the requirements of the Fourth Amendment.
In the ordinary case, an officer cannot be expected to question the
magistrate's probable-cause determination or his judgement that the form of
the warrant is technically sufficent.  "[O]nce the warrant issues, there is 
literally nothing more the policeman can do in seeking to comply with the 
law."  Penalizing the officer for the magistrate's error, rather than his 
own, cannot logically contribute to the deterrence of Fourth Amendment 
violations.

END.
++++

The bill is really just a restatement.  This has been the state of the 
law for 11 years now.

If the bill fails, the essence of the doctrine that everyone is concerned 
about stands in any event.

The question is moot.

-uni- (Dark)

--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From lcottrell at popmail.ucsd.edu  Thu Feb  9 22:57:19 1995
From: lcottrell at popmail.ucsd.edu (Lance Cottrell)
Date: Thu, 9 Feb 95 22:57:19 PST
Subject: MIME based remailing commands
Message-ID: <ab60b81304021004b962@[137.110.24.250]>


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

<SNIP my comments>
>Ah, I see how you are doing it.  Having re-read your docs, I gather
>that when un-armored the file is in an encrypted binary format, and
>when decrypted at least the non-header portion of the file is still
>binary?  I think this is a good way to do it; it addresses the point
>Eric made recently about size expansion when an armored file is
>encrypted at each step.
>
That is about right. Inside the armor is a bunch of binary data. 20 header
blocks, and the message block. The first message block is a PGP encrypted
to the remailer, and contains the next destination. The other 19 headers,
and the message block are IDEA encrypted with a key and IV in the first
header. When decrypted, the second header is seen to be PGP encrypted to
the next remailer, and the rest is encrypted with the key in that header.
The remailer Shifts up all the headers, sticks junk in the 20th header, and
rearmors the whole thing.

This is rather more active manipulation than the current remailers.


>The one thing I would mention is that "::" was not originally intended
>as an indication that the message was to be remailed.  Rather, this was
>simply a "header pasting token" which could be used to move a few lines
>from the body up into the header for those people who can't set header
>fields on outgoing mail.  Then the presence of "Anon-To:" or whatever
>in the header is what actually causes the action.  So you don't need to
>use "::", you can just set your headers directly and get the same
>effect.  (This is not to say you need to do it like this, just that
>that is how the original design that Eric created worked.)
>

I realize that. It was easy to implement, since I already had to check for
:: to be compatible with type 1 messages.

>If you did want to follow this model, you could think about using a
>MIME header to indicate the type of the message contents rather than
>the "::".  Another alternative would be to use a different special
>field in the mail header, like perhaps your "Remailer-Type: 2.0", but
>I'm not sure that a new top-level header field is the right place for
>this.  It looks to me like most of the standard headers deal more with
>moving the message around rather than with telling what would be done
>with it on receipt.  It's kind of a fine line but it looks to me like
>more of a job for a MIME content type since that is really what it is
>for.  You could use something like:
>
>MIME-Version: 1.0
>Content-Type: application/remail; version="2.0"
>
>or
>
>MIME-Version: 1.0
>Content-Type: application/remail-mark-2
>
>Then the rest of the message could look just as you have it.  Or, to use
>a little more of the existing standard, you could add:
>
>Content-Transfer-Encoding: base64
>
>and take out your BEGIN and END lines since it looks like you are using
>base64, although the augmented kind that PGP uses with the CRC at the
>end; you'd have to lose the CRC in that case.  (I wonder if PGP will do
>that in the MIME-PGP integration draft that is supposedly being worked
>on.)
>
>One question is, how do you actually send your messages in the
>mixmaster client and servers?  Do you go directly to sendmail, or do
>you use a user agent like /bin/mail?  If the former then it doesn't
>seem like it would be too hard to add these header fields.  On the
>receiving end then hopefully also it would not be much harder to match
>the Content-Type: string than the one you are using.
>
>The advantage, again, is that to a considerable extent this kind of
>application is exactly what MIME was planning for with the "application"
>content-type.  This lets you mark the contents of the message in a
>standard way.  And you are already using something very close to the
>base64 encoding that MIME specifies.  So this does seem like a good
>opportunity to go with the internet mainstream by following this
>standard.  If this seems like something you want to do I'm sure our MIME
>experts here can tell how to define a new content type.
>
>Hal
>

I agree that changing mixmaster to search for a MIME line, rather than the
:: would be no effort at all.

I use sendmail for the client and the remailer (actually they are the same
code), so adding new headers is easy. Unfortunately I am having some
problems with sendmail. Sendmail is marking the messages as "Apperently
To:" rather than "To:". Any idea what might cause that?

I am not sure I want to give up the CRC on the armor (esp. since I am using
the PGP tools routines and not my own), but I would be interested in
defining a new MIME content type. So, experts, what all is involved in
that, and is there any problem with starting to use a MIME type before it
is official?

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLzsIElVkk3dax7hlAQFlmgP9FNxSrabWU7CyiRu1Kv28Lz2htuukq1Ul
ANG4y/arJ9gseBvOxDKVDLVKWN1c2XyOKrEbUTVXxHDhk/WwhfpvJE/UrVWQuFEP
eaFZB4G1xBvyjkx+DoQxsLVTEVcF1V54Mo5tfARBGCqf7aHqQGoLiRu8kR6i04fj
nPgOrMeE5Bk=
=vg7R
-----END PGP SIGNATURE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Check out my essay on the next generation remailer Mixmaster on the WWW page.
For anon remailer info, mail remailer at nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche







From skaplin at mirage.skypoint.com  Thu Feb  9 23:02:22 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Thu, 9 Feb 95 23:02:22 PST
Subject: (fwd) OREGON HOUSE BILL 2319 - Outlaw Anoniminty??
Message-ID: <m0rcpMi-0001eTC@skypoint.com>



Damn!! Has this been a crappy week!!!

Sam



Path: skypoint.com!scipio.cyberstore.ca!math.ohio-state.edu!howland.reston.ans.net!news.sprintlink.net!uunet!news.fc.net!ima!libertybbs!terry.liberty-parker
From: Terry.Liberty-Parker at libertybbs.ima.infomail.com (Terry Liberty-Parker)
Date: 09 Feb 95 08:26:51 
Newsgroups: comp.org.eff.talk
Subject: OREGON HOUSE BILL 2319 -
Message-ID: <ff3_9502091822 at ima.infomail.com>
Organization: Austin InfoMail Association - Austin, TX
Lines: 112

-=> Note:
Forwarded (from: LIBALERT) by Terry Liberty-Parker using timEd.
Originally from ERIC GRAY (76:48/200.0) to ALL.
Original dated: Feb 05 '95, 03:42

This message was from LES LEMKE to ALL,
and was forwarded to you by ERIC GRAY.
                    -------------------------
( HB 2319 Page 1 )



       68th OREGON LEGISIATIVE ASSEMBLY - 1995 Regular Session


                       HOUSE BILL 2319

Ordered printed by the Speaker pursuant to House Rule 12.00A (5),
Presession filed (at the request of Representative Kevin Mannix)


                            SUMMARY

The following summary is not prepared by the sponsors of the measure
and is not a part of the body thereof subject to consideration by the
Legislative Assembly, It is an editor's brief statement of the
essential features of the measure as introduced.

     Directs operators of computer networks to keep records of
identity of users of network and of personal information about
individuals that is disclosed to users. Requires disclosure to
individual when information about individual is accessed by user of
network. Sets rules for disclosures. Allows injunction or maximum
civil penalty of $100,000, or both, for violation.


                          A BILL FOR AN ACT

Relating to computer information systems.

Be It Enacted by the People of the State of Oregon:

SECTION 1. As used in sections 1 to 3 of this Act:

(1) To "access" means to instruct, communicate with, store data in,
    retrieve data from or otherwise make use of any resources of a
    computer, computer system or computer network.

(2) "Computed' means, but is not limited to, an electronic device
    that performs logical, arithmetic or memory functions by the
    manipulations of electronic, magnetic or optical signals or
    impulses, and includes all input, output, processing, storage,
    software or communication facilities that are connected or
    related to such a device in a system or network.

(3) "Computer network" means, but is not limited to, the
    interconnection of communi cationlines, including microwave or
    other means of electronic communication, with a computer through
    remote terminals or a complex consisting of two or more
    interconnected computers.

(4) "Computer program" means, but is not limited to, a series of
    instructions or statements, in a form acceptable to a computer,
    that permits the functioning of a computer system in a manner
    designed to provide appropriate products from or usage of such
    computer system.

(5) "Computer software" means, but is not limited to, computer
    programs, procedures and associated documentation concerned with
    the operation of a computer system.

(6) "Computer system" means, but is not limited to, a set of related,
    connected or un connected, computer equipment, devices and
    software.

(7) "Data" means a representation of information, knowledge, facts,
    concepts, computer software, computer programs or instructions.
    "Data" may be in any form, in storage media, or as stored in the
    memory of the computer, or in transit, or presented on a display
    device. "Data" includes, but is not limited to, computer or human
    readable forms of numbers, text, stored voice, graphics and images.


SECTION 2.

(1) An owner or operator of a computer network or computer system
    shall establish procedures requiring each person who accesses the
    network or system to disclose

NOTE: Matter in boldfaced type in an amended section is new; matter
[italic and bracketed] is existing law to be omitted. New sections
are in boldfaced type.

LC 984




                                [1]



---
 * Origin: Stargate Oregon - North Bend, Oregon USA (1:356/3)

 * OLX 2.2 TD * The oldest question known to man: "Where are my keys?!"

___ GOMail v2.0t Beta [94-0145]
 - Origin: The Desert Reef * LIB * Tuc.Az * V.34 * 602 624 6386 (76:48/200)

--- timEd 1.00
 * Origin: LibertyBBS Austin,Tx [512]462-1776 (1:382/804)





From rishab at dxm.ernet.in  Thu Feb  9 23:09:19 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Thu, 9 Feb 95 23:09:19 PST
Subject: Labour and capital in a post-industrial economy
Message-ID: <gate.T140Zc1w165w@dxm.ernet.in>


Earlier I'd written on the fall of corporations due to cryptoanarchy. This one
is on the decline of (knowledge) capital and property rights, and the rise of
labour.

------cut here-------
Electric Dreams
Weekly column for The Asian Age by Rishab Aiyer Ghosh
#47, 6/February/1995: Labour and capital in a post-industrial economy

The information economy will require not only knowledge
capital, but also knowledge labour. Labour has
historically been subservient to capital (or land, in
agricultural societies) as a source of power and wealth,
leading to various forms of political upheaval contrary to
the naturally unequal relationship between these two
essentials of an economy. But the knowledge revolution
will change the nature of labour even more than it will
that of capital, while also decreasing the distinction
between them.

One of the major differences between capital and labour in
the past is that capital, owned and protected by property
rights, can earn for its owners without their making any
significant effort. Labour, though, is inherent in its
'owners' - you really don't need laws to protect your
ownership of your capacity to work - and earns only with
considerable effort from them. It follows that owners of
capital are wealthier than providers of labour, at least
until a digital deluge changes the rules altogether.

A strict (but not universally accepted) definition of
knowledge capital would consist primarily of those
relatively static forms of intellectual output - specific
ideas, software, works of art - that can be treated as
property, thereby inviting legal protection in the form of
patent and copyright. Like traditional capital, these
don't necessarily require the intervention of their owner
(after the work of painting or inventing is over) to
generate cash. Intellectual property rights will do the
earning.

Unfortunately for fans of intellectual property rights,
they are unworkable. As the sprawling information economy
grows volatile and fast-changing, copyrights and patents
are simply not going to be enforced. The ease of
undetectable duplication, together with the suffocating
effects of strong protection on growing markets, have been
acknowledged by everyone familiar with both the
technological as well as economic aspects. Expertise,
then, not information, is the key.

Expertise, which is dynamic and constantly adapting, is
not 'intellectual property'. It hardly requires legal
protection, and cannot be separated from its owners, the
experts, in whom it inheres. Nor do experts earn without
themselves making active use of their skills. Experts are,
in fact, knowledge labourers.

Not, of course, that these labourers own no capital. Quite
the contrary -experts almost always rely on more static
works, ideas, resources, that are their own. However, this
'property' being less important than their expertise,
knowledge labourers (or knowledge workers, to use a more
familiar but not always equivalent term) often don't
bother about patents or copyrights. Knowledge capital is
not, after all, as valuable as expertise and is also more
inconvenient to rely on - so it will act as the auxiliary
resource, rather as labour has done in industry.

Once we realize this reversal of roles between labour and
capital in a post-industrial economy, we face the prospect
of a vast labour force of experts of all sorts. Knowledge
labour will not always be high-end, though - for every
millionaire quant plotting coffee futures against money-
market derivatives, there will be the human agent,
cybrarian in the jargon, hunting for curious clients rare
species of data amid the information jungle. And there
will always be some who cling on to their intellectual
property rights and attempt to extract license fees from
the on-line universe. But their share of the economy will
shrink, and finally, in the era of expertise, what you
have will matter less, than what you do.



Rishab Aiyer Ghosh is a freelance technology consultant
and writer. You can reach him through voice mail (+91 11
3760335) or e-mail (rishab at dxm.ernet.in).

--====(C) Copyright 1994 Rishab Aiyer Ghosh. ALL RIGHTS RESERVED====--
 This article may be redistributed in electronic form only, PROVIDED 
 THAT THE ARTICLE AND THIS NOTICE REMAIN INTACT. This article MAY NOT 
 UNDER ANY CIRCUMSTANCES be redistributed in any non-electronic form,
 or redistributed in any form for compensation of any kind, WITHOUT 
PRIOR WRITTEN PERMISSION from Rishab Aiyer Ghosh (rishab at dxm.ernet.in)
--==================================================================--

------cut here-------


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From rishab at dxm.ernet.in  Thu Feb  9 23:09:20 1995
From: rishab at dxm.ernet.in (Rishab Aiyer Ghosh)
Date: Thu, 9 Feb 95 23:09:20 PST
Subject: Selection key crypto protocol trial balloon
In-Reply-To: <9502082007.AA09524@anchor.ho.att.com>
Message-ID: <awLe2c4w165w@dxm.ernet.in>


wcs at anchor.ho.att.com writes:

> > Um no. The main thing is that what is extracted with the selection key is
> > _different_ from what was put in...
> 
> But the only things the selectioon key can extract are what the senders
> put in plus what the system did to it once it was there, which is not
> informationally different than what the senders put there.

True, just as ciphertext is not different, informationally, from plaintext.
It's just a pair of transformations, both by the system, one in response to
the sender and the other in response to the receiver. A bit like an airlock -
if the two transformations are the right ones, extraneous information such as
the identity should not pass through.

> I suppose you could play some games by sending the message in 
> multiple parts, with parts sent by 1-way anonymous remailer,
> but there's still a certain amount of traffic analysis you can do.
> 
> 	Bill


-----------------------------------------------------------------------------
Rishab Aiyer Ghosh                                "In between the breaths is
rishab at dxm.ernet.in                                  the space where we live"
rishab at arbornet.org                                        - Lawrence Durrell
Voice/Fax/Data +91 11 6853410  
Voicemail +91 11 3760335                 H 34C Saket, New Delhi 110017, INDIA  






From rishab at dxm.ernet.in  Thu Feb  9 23:12:39 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Thu, 9 Feb 95 23:12:39 PST
Subject: Selection key crypto protocol trial balloon
Message-ID: <gate.as70Zc1w165w@dxm.ernet.in>


Hal <hfinney at shell.portal.com>:
> Let me get straight where we are.  Rishab's concrete proposal was not an
> implementation, but rather a set of requirements.  There was no
> suggestion about any specific algorithms that would meet those
> requirements, right?  The question is whether any such algorithm could
> exist.

Right.

> It is hard for me to see how this could possibly work.  The message
> receiver sends this "selection key" to the intermediary, and that somehow
> pulls out the saved message, but in a form such that the intermediary
> doesn't recognize it.  And the intermediary himself can't tell exactly
> which message is produced.  But it is nevertheless exactly the message
> which was meant for this particular receiver.

It need not be the same information - i.e. if the encryption process adds 
enough noise to the message, the extraction process might by lossy, without 
any total loss for the receiver. This may be possible particularly if 
Fourier-style transforms are used, as the "selection key" could pick up 
less "frequencies" of a message than are stored at the intermediary.

> The thing is, the receiver does not have much more information than the
> intermediary.  

The same could be said of a private/public key pair. What is crucial is the
association between the keys.

This said, while I can imagine separate systems for the intermediary loosing 
correlation between incoming and outgoing messages (eg - it's _really_ tough,
without fancy pattern recognition, to associate a JPEG with the original), 
and for generating three associated keys (secret splitting? something to do
with Brands' blind signatures?), I really can't imagine a way of putting it
all together. Someone will have to be inspired, as Diffie was...


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From greg at ideath.goldenbear.com  Fri Feb 10 00:25:51 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Fri, 10 Feb 95 00:25:51 PST
Subject: stupid legislation in Oregon
Message-ID: <199502100806.AA02116@ideath.goldenbear.com>


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


Ugh. This has been a stupid week. Oregon House bill 2319 was introduced
by Rep. (Kevin?) Mannix on 1/16/95, and referred to the House committee
on Commerce on 1/18/95. Rep. Mannix has also introduced another bill, 
HB 2310, which "Creates the crime of electronically furnishing obscene
material to minors; punishes by maximum one year imprisonment,
$10,000 fine, or both." HB 2310 was introduced 1/13/95, and referred
to the House Judiciary committee on 1/16/95. 

He's introduced 38 bills so far this session - including others re
mandatory minimum sentencing for felony convictions, one which appears
to bar surrogate-pregnancy agreements, and another (HB2303) which 
prohibits physicians from performing artificial insemination on an
unmarried woman.

Damn this fucking state. I'll be on the phone with my representative
in the morning to see if I can find out more. Westlaw's legislative
tracking database doesn't have much information.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzsecH3YhjZY3fMNAQH9DwP9GA1oai9JA2ftMSCLKH+jnfqxD/svI0ZD
N1yWpHwStmoZ3x6fr9MRpqFIwAfsTzfj+P0B07HBy1V53pVhKw+bFyCZZ+/ZmA7u
lAXR/eR6xr53ZMZJt2SSsFElE8VB8syjJRWe48a37q+3Ma9iGhvlfLx5IuX+qZR7
E9de+WMg/Pw=
=rOtS
-----END PGP SIGNATURE-----




From rrothenb at ic.sunysb.edu  Fri Feb 10 02:32:10 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Fri, 10 Feb 95 02:32:10 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.LNX.3.91.950209195950.9468A-100000@chewy.wookie.net>
Message-ID: <199502101031.FAA23805@libws4.ic.sunysb.edu>



> On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

[ .. ]

> > > broadcast paradigm, while the online world operates within the network 
> > > paradigm. There are no hours in which it is safe to broadcast because 
> > > there is no "broadcast" in the tradition sense.
> > 
> > Yes, I was discussing broadcasting. Scary thought is that because networks
> > are different they will try to outright ban everything.
> 
> I wonder though sometimes if it's even occurred to lawmakers that they 
> can't apply the safe harbor notion for indency to computer networks.
> 

The lawmakers have been trying to eliminate indecency (not just obscenity)
altogether... they don't want a safe harbor--that's something that came down
from the courts.

> 
> - dog
> 

Rob




From habs at panix.com  Fri Feb 10 04:19:46 1995
From: habs at panix.com (Harry S. Hawk)
Date: Fri, 10 Feb 95 04:19:46 PST
Subject: Delphi and Encryption??
Message-ID: <199502101219.AA10971@panix.com>


RUPERT'S BIG PLANS Media mogul Rupert Murdoch has big plans for his
Delphi Internet Services -- he wants to boost it from fifth to first
place in online service providers. "Internet, Delphi and TV as it
becomes interactive, all will become very much integrated," predicts
HarperCollins' publishing VP. By choosing existing software modules,
such as Mosaic, instead of developing its own graphical user
interface, Murdoch hopes to leapfrog the competition and come out on
top.

Delphi's data encryption technology will also enhance its
^^^^^^^^^^^^^^^^^^^^^^^^
position among privacy-conscious consumers. (Upside Feb.'95 p.39)



Anyone know anything??

/hawk




From wfgodot at iquest.com  Fri Feb 10 04:55:05 1995
From: wfgodot at iquest.com (Michael Pierson)
Date: Fri, 10 Feb 95 04:55:05 PST
Subject: The question is moot:
In-Reply-To: <Pine.SUN.3.91.950210010704.5527A-100000@access3.digex.net>
Message-ID: <AZrElu1u6tTT079yn@iquest.com>


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

Black Unicorn <unicorn at access.digex.net> wrote:

>
> With all the gafawing about the bill (666) which just flew by, and the
> "Dem's" running off about how the constitution is being dismantled, I
> thought I would cite some case law.
>
> I direct your attention to _United States v. Leon_, 468 U.S. 897 (1984).


666 and 1984.  Talk about irony.

Let's see... Fourth Amendment:

 "The right of the people to be secure in their persons, houses,
  papers, and effects, against unreasonable searches and seizures,
  shall not be violated, and no warrants shall issue, but upon
  probable cause, supported by oath or affirmation, and particularly
  describing the place to be searched, and the persons or things to
  be seized."

What part of "shall not be violated" does Justice White not get?


> Justice White:
>
> This case presents the question whether the Fourth Amendment
> exclusionary rule should be modified so as not to bar the use in the
> prosecution's case-in-chief of evidence obtained by officers acting in
> reasonable reliance on a search warrant issued by a detached and neutral
> magistrate but ultimately found to be unsupported by probable cause.
>
> [...]
>
> The Fourth Amendment contains no provision expressly precluding the use
> of evidence obtained by violation if its commands, and an examination of
> its orgin and purposes makes clear that the use of fruits of a past
> unlawful search or seizure "work[s] no new Fourth Amendment wrong."  The
> wrong condemned by the Amendment is "fully accomplished" by the unlawful
> search or seizure itself, and the exclusionary rule is neither intended
> nor able to "cure the invasion of the defendant's rights which he has
> already suffered."  The rule thus operates as "a judicially created
> remedy designed to safeguard Fourth Amendment rights generally through
> its deterrant effect, rahter than a personal constitutional right of the
> person aggrieved."
>


Obscured in White's casuistry is the fact that if evidence from
improper searches can be admitted, then the Fourth Amendment itself
is largely made "moot."  White's "this shit don't stink" sophism
notwithstanding.


>  ... Second,there exists no evidence suggesting that judges and
>  magistrates are inclined to ignore or subvert the Fourth Amendment
>  or that lawlessness among these actors requires application of the
>  extreme sanction of exclusion.


Uh Huh...


[ The rest of Justice White's police state apologia omitted.]


> END.
> ++++


> The bill is really just a restatement.  This has been the state of the
> law for 11 years now.
>
> If the bill fails, the essence of the doctrine that everyone is concerned
> about stands in any event.
>
> The question is moot.



This is actually one of the arguments that some proponents of the
bill were using during the House Floor Debate that I was watching on
CSPAN.  If this were the case, then I wondered: Why were they so
intent to pass the bill in the first place??

I don't think that the codification of this earlier Fourth Amendment 
evisceration in federal statute is something I would characterize as 
moot.  I would regard it as a pretty sickening development even if it 
only added insult to injury.  Unfortunately, I doubt that the 666 
seal of approval will fail to further contribute to the ongoing 
destruction of our rights to privacy and due process in this country.



- -Michael




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLztgftGJlWF+GPx9AQH6jwP8DWSNaOKoF7WORQjsRV3E/UbUxBYCGfLi
MKBBCC4TEQPMXy74H4CxJYjwOxBlwFcP0oB9HCAWq1XUX7JYaf7PujdlqHG/j92f
ZaoXfXdX052aXlh24P+dvMH9GZkfT71qla7Y78mfraFEXKzglcuVoE2kbgQFms/f
MaQSnMWFpuk=
=Ox0q
-----END PGP SIGNATURE-----





From bdolan at use.usit.net  Fri Feb 10 05:05:09 1995
From: bdolan at use.usit.net (Brad Dolan)
Date: Fri, 10 Feb 95 05:05:09 PST
Subject: The question is moot: (Was: Not crypto, but scary.)
In-Reply-To: <Pine.SUN.3.91.950210010704.5527A-100000@access3.digex.net>
Message-ID: <Pine.SOL.3.90.950210075752.11373A-100000@use.usit.net>


I've got a solution that everyone should love:

Let's go ahead and allow illegally obtained evidence - but let's
make it a capital offense for a law-enforcement officer to 
knowingly violate the 4th amendment.  

Strong 4th amendment protection and another wonderful death
penalty all in one!

Brad D.

On Fri, 10 Feb 1995, Black Unicorn wrote:

> 
> 
> With all the gafawing about the bill (666) which just flew by, and the 
> "Dem's" running off about how the constitution is being dismantled, I 
> thought I would cite some case law.
> 
> I direct your attention to _United States v. Leon_, 468 U.S. 897 (1984).
> 
> Justice White:
> 
> This case presents the question whether the Fourth Ammendment 
> exclusionary rule should be modified so as not to bar the use in the 
> prosecution's case-in-chief of evidence obtained by officers acting in 
> reasonable reliance on a search warrant issued by a detached and neutral 
> magistrate but ultimately found to be unsupported by probable cause.
> 
> [...]
> 
> The Fourth Amendment contains no provision expressly precluding the use 
> of evidence obtained by violation if its commands, and an examination of 
> its orgin and purposes makes clear that the use of fruits of a past 
> unlawful search or seizure "work[s] no new Fourth Amendment wrong."  The 
> wrong condemned by the Amendment is "fully accomplished" by the unlawful 
> search or seizure itself, and the exclusionary rule is neither intended 
> nor able to "cure the invasion of the defendant's rights which he has 
> already suffered."  The rule thus operates as "a judicially created 
> remedy designed to safeguard Fourth Amendment rights generally through 
> its deterrant effect, rahter than a personal constitutional right of the 
> person aggrieved."
> 
> [...]
> 
> First, the exclusionary rule is designed to deter police misconduct 
> rather than to punish the errors of judges and magistrates.  Second, 
> there exists no evidence suggesting that judges and magistrates are 
> inclined to ignore or subvert the Fourth Amendment or that lawlessness 
> among these actors requires application of the extreme sanction of exclusion.
> 
> [...]
> 
> [The exclusionary rule cannot be expected to deter objectively reasonable 
> law enforcement activity...]
> 
> This is particularly true, we believe, when an officer acting with objective
> good faith has obtained a search warrant from a judge or magistrate and acted
> within its scope.  In most such cases, there is no police illegality and this
> nothing to deter. It is the magistrate's responsibility to determine whether
> the officer's allegations estlablish probable cause and, if so, to issue a
> warrant comporting in form with the requirements of the Fourth Amendment.
> In the ordinary case, an officer cannot be expected to question the
> magistrate's probable-cause determination or his judgement that the form of
> the warrant is technically sufficent.  "[O]nce the warrant issues, there is 
> literally nothing more the policeman can do in seeking to comply with the 
> law."  Penalizing the officer for the magistrate's error, rather than his 
> own, cannot logically contribute to the deterrence of Fourth Amendment 
> violations.
> 
> END.
> ++++
> 
> The bill is really just a restatement.  This has been the state of the 
> law for 11 years now.
> 
> If the bill fails, the essence of the doctrine that everyone is concerned 
> about stands in any event.
> 
> The question is moot.
> 
> -uni- (Dark)
> 
> --
> 073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
> 6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!
> 
> 





From MFROOMKI at umiami.ir.miami.edu  Fri Feb 10 06:52:59 1995
From: MFROOMKI at umiami.ir.miami.edu (Michael Froomkin)
Date: Fri, 10 Feb 95 06:52:59 PST
Subject: Not moot? [Was Re: The question is moot: (Was: Not crypto, but scary.)]
In-Reply-To: <Pine.SUN.3.91.950210010704.5527A-100000@access3.digex.net>
Message-ID: <Pine.3.89.9502100954.A589347486-0100000@umiami.ir.miami.edu>


I was under the  impression that the House bill would change the status 
quo in one important respect: under Leon and similar cases, the "good 
faith" exception only applies when a judge or magistrate has issued a 
warrant which turns out not to be valid.  Under the House bill, this 
erosion of the exclusionary rule is extended to warrantless searches 
(presumably including electronic searches) made in "good faith".  Since 
knowledge of what the Constitution requires can destroy good faith, the 
changes likely to be made in police procedure manuals and curricula are 
left as an exercise for the reader.

OBCrypto: Buy shares in commercial crypto suppliers now.  Demand should 
be going up.

A.Michael Froomkin          | +1 (305) 284-4285; +1 (305) 284-6506 (fax)
U.Miami Law School          | MFROOMKI at UMIAMI.IR.MIAMI.EDU
PO Box 248087               | 
Coral Gables, FL 33146 USA  | It's barely warm here.






From rishab at dxm.ernet.in  Fri Feb 10 06:54:56 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Fri, 10 Feb 95 06:54:56 PST
Subject: Indian Supreme Court ends state control of the airwaves
Message-ID: <gate.J12B1c1w165w@dxm.ernet.in>



The Indian Supreme Court yesterday (9th February, 1995) directed the 
government to create an independent autonomous regulatory body for the 
airwaves (like the US FCC) and end the state monopoly on broadcasting and 
satellite uplinks.

The judges took an interesting position that the "GREATER IMPACT" OF 
ELECTRONIC MEDIA and its "wider range of circulation of information" as 
opposed to the press, CANNOT BE USED TO RESTRICT or deny THE RIGHT TO FREE 
EXPRESSION. This may have important consequences, for all over the world, 
including in the US and India, the electronic media is denied freedoms 
allowed to the press with the excuse that it's somehow different.

The three-judge bench, comprising of Justices PB Sawant, S Mohan and BP Jeevan
Reddy, made the ruling after an government appeal against a previous ruling 
by the Calcutta High Court. The Calcutta High Court had earlier upheld the 
right to telecast as fundamental, which would theoretically prevent any 
regulation or censorship whatsoever. The consensual Supreme Court judgement,
while denying the government's power of monopoly, upheld its right to subject 
the electronic media to regulation and censorship. 

However, Justice Reddy, in his separate ruling did not mention censorship.
He pointed out that the century-old Indian Telegraph Act of 1885, which has
been ingeniously extrapolated to support the government's monopoly over 
electronic media and right to 'licence' data networks, was "wholly inadequate
and unsuited for" electronic media, and said that Parliament should enact
new laws to govern such media.

Unfortunately the Supreme Court has no powers to legislate, and new laws have
a habit (as seen with the Digital Telephony Bill in the US) of increasing,
rather than decreasing, government authority. The explicit statement that
the electronic media should not be more restricted than the press will, 
hopefully, prevent that.

The legal battle started with the Doordarshan, the state TV monopoly, 
objecting to the Cricket Association of Bengal's contract with Trans World
International granting the latter worldwide broadcasting rights to a cricket
tournament. Doordarshan used the 1885 Act to prevent TWI from uplinking to
satellite, till the courts intervened.


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From rishab at dxm.ernet.in  Fri Feb 10 06:56:02 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Fri, 10 Feb 95 06:56:02 PST
Subject: GSM and cellular crypto
Message-ID: <gate.og1B1c1w165w@dxm.ernet.in>


Richard Parrett (?) wrote:
> GSM uses less than strong encryption, by the way. I forget the
> technical details, but it is of the level that governments can
> fairly readily crack, but beyond the reach of most private
> organisations. (So no more 'Squidgy-gate'). It would, however,
> be quite feasible to add additional second stage encryption
> to phones (since the dataflow is digital point-point). I wonder
> if Nokia, a Finnish company well outside the scope of COCOM,
> might offer a feature like this.

All operaters of cellular networks in India are to use GSM, and Nokia has
been running an enormous ad campaign, it is very likely to be the market
leader in instruments. I don't know about any encryption provided, though.


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From slowdog at wookie.net  Fri Feb 10 06:56:08 1995
From: slowdog at wookie.net (slowdog)
Date: Fri, 10 Feb 95 06:56:08 PST
Subject: a draft petition against S.314
Message-ID: <Pine.LNX.3.91.950210095638.10065A-100000@chewy.wookie.net>


[A draft petition, comment, but do it QUICKLY.]


In united voice, we sign this petition against passage of S.314 ("The 
Communications Decency Act of 1995") for these reasons:

S.314 would prohibit not only individual speech that is "obscene, lewd,
lascivious, filthy, or indecent", but would prohibit any provider of
telecommunications service from carrying such traffic, under threat of
stiff penalty. Even aside from the implications for free speech, this
would cause an undue - and quite possibly unjust - burden upon operators
of various telecommunications services. In a time where the citizenry and
their lawmakers alike are calling for and passing "no unfunded mandates" 
laws, it is unfortunate that Congress might seek to impose unfunded
mandates upon businesses that provide the framework for the information
age. 

The threat of such penalty alone might result in a chilling effect in the
telecommunications service community, again creating an environment
contrary to the principles of free speech, press, and assembly -
principles which entities such as the internet embody as nothing has
before.

We ask that the Senate halt any further progress of this bill. We ask 
that the Senate be an example to Congress as a whole, and to the nation 
at large - to promote the general welfare as stated in the Preamble to 
the Constitution by protecting the free flow of information and ideas 
across all of our telecommunications services.




- dog







From mgh5868 at ultb.isc.rit.edu  Fri Feb 10 08:34:32 1995
From: mgh5868 at ultb.isc.rit.edu (M.G. Hunsberger)
Date: Fri, 10 Feb 95 08:34:32 PST
Subject: HR830 - Anyone tracking this?
Message-ID: <9502101634.AA18707@ultb.isc.rit.edu>


 
The recent version of the EFFector Online had some information about the
House of Representative's Bill HR830.  They say that this bill is being
rammed through Congress and would cripple FOIA.  It would seemingly 
change any public information that is given value to non-public
information.  Does anyone have any further information?  
 
Mike 

 





From hfinney at shell.portal.com  Fri Feb 10 08:40:21 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 10 Feb 95 08:40:21 PST
Subject: MIME based remailing commands
In-Reply-To: <ab60b81304021004b962@[137.110.24.250]>
Message-ID: <199502101639.IAA21710@jobe.shell.portal.com>


lcottrell at popmail.ucsd.edu (Lance Cottrell) writes:

>I agree that changing mixmaster to search for a MIME line, rather than the
>:: would be no effort at all.

>I use sendmail for the client and the remailer (actually they are the same
>code), so adding new headers is easy. Unfortunately I am having some
>problems with sendmail. Sendmail is marking the messages as "Apperently
>To:" rather than "To:". Any idea what might cause that?

I think this might be caused by a disagreement between the To: address in
the message itself and whatever "To" address was passed to sendmail on
the command line.  If you pass -t to sendmail then it won't look for a
"To" address on the command line, at least as configured at my site.

Hal





From lethin at ai.mit.edu  Fri Feb 10 09:22:43 1995
From: lethin at ai.mit.edu (Rich Lethin)
Date: Fri, 10 Feb 95 09:22:43 PST
Subject: Global Filesystem Guild
Message-ID: <9502101722.AA04330@grape-nuts>



To reduce the vulnerability of a single user/BBS to having their files
confiscated/stolen, could a distributed WAN filesystem be implemented with
k-redundancy, e.g. the files wouldn't disappear until k servers (located in
various unknown or inaccessible places) failed?  The price of storage would
vary with the level of redundancy desired.  For security the servers would
only store cyphertext, etc.  Local cacheing to reduce network load.

Andrew File System (from Transarc/IBM) implements the distributed
filesystem and namespace and some security, but not the redundancy for RW
files. (And it's not shareware).

Issues:
Quota management.
Pricing (for space or time)
Security: (only store cyphertext?)
Ownership: (who gets to delete files?)
...

Sort of the next level beyond SecureFS?





From sameer at c2.org  Fri Feb 10 09:37:33 1995
From: sameer at c2.org (sameer)
Date: Fri, 10 Feb 95 09:37:33 PST
Subject: MIME based remailing commands
In-Reply-To: <199502101639.IAA21710@jobe.shell.portal.com>
Message-ID: <199502101735.JAA18715@infinity.c2.org>


> 
> I think this might be caused by a disagreement between the To: address in
> the message itself and whatever "To" address was passed to sendmail on
> the command line.  If you pass -t to sendmail then it won't look for a
> "To" address on the command line, at least as configured at my site.
> 

	It doesn't matter if they disagree. If you don't have a To:
line in the header then "Apparently-To:" gets tacked on using the "To"
from the envelope.

-- 
sameer						Voice:   510-841-2014
Network Administrator				Pager:	 510-321-1014
Community ConneXion: The NEXUS-Berkeley		Dialin:  510-549-1383
http://www.c2.org (or login as "guest")			sameer at c2.org




From jya at pipeline.com  Fri Feb 10 09:43:36 1995
From: jya at pipeline.com (John Young)
Date: Fri, 10 Feb 95 09:43:36 PST
Subject: PSI Gulps Pipeline
Message-ID: <199502101742.MAA05625@pipe3.pipeline.com>



Forwarding mail by: gleick at pipeline.com (James Gleick) on Fri, 
10 Feb  0:12 AM
-------------------


Dear Pipeliners,


I'm pleased to be able to tell you that the Pipeline has become 
part of  a larger enterprise: Performance Systems International 
(PSINet), the  nation's leading Internet access provider.


That means two things immediately. 


First, PSINet has a state-of-the-art dialup network in many 
cities  across the nation, and these will shortly be available 
to our users at  a cost much less than our current out-of-town 
SprintNet surcharges.


Second, PSINet plans to use our Internaut software as the basis 
for a  national service--not to replace the New York-based 
Pipeline but to  provide an alternative for out-of-towners who 
don't especially care  about New York information and services.


PSINet is a company a lot like ours--small (though not so small 
 anymore), enthusiastic, fast-moving, and steeped in Internet 
history.  The people there care about the Internet as an 
environment worth  preserving even as it grows so explosively.  
And they admire what we've  accomplished here at the Pipeline 
in forming a model online service.


That's enough for now--there will be more information following 
along  behind, but I wanted you to hear it here first.  As for 
me--this isn't  goodbye, exactly, but I have gotten a little 
behind on a book I was  supposed to be writing . . .


I am deeply grateful to all of you--staff and customers--for 
making  the Pipeline what it is and for letting me get to know 
you a little bit.


Jim


--
James Gleick
The Pipeline






From rfb at lehman.com  Fri Feb 10 09:57:50 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 09:57:50 PST
Subject: URGENT - What S.314 Would Do
In-Reply-To: <Pine.SV4.3.91.950208020311.25943A-100000@mirage.skypoint.com>
Message-ID: <9502101755.AA04883@cfdevx1.lehman.com>


    Date: Wed, 8 Feb 1995 02:18:27 -0600 (CST)
    From: Samuel Kaplin <skaplin at mirage.skypoint.com>

    . . .

    >    (B) [makes a telephone call, whether or not conversation
    >    ensues, without disclosing his identity and with intent to
    >    annoy, abuse, threaten, or harass any person at the called
    >    number] makes a telephone call or utilizes a telecommunications
    >    device, whether or not conversation or communications ensues,
    >    without disclosing his identity with intent to annoy, abuse,
    >    threaten, or harass any person at the called number or who
    >    receives the communication;
    
    Ding...Ding...Ding... We have another winner. Goodbye remailers. Probably 
    90% of remailer traffic violates this one. Well boys and girls we'd 
    better get lots more offshore...soon.

Actually, unless the quote dropped important context, this part
doesn't seem to outlaw remailers, but rather certain classes of
remailer use (``makes a call'', ``utilizes...'').  It is the user, not
the provider that this seems to address.

--
Rick Busdiecker <rfb at lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu





From frissell at panix.com  Fri Feb 10 09:58:29 1995
From: frissell at panix.com (Duncan Frissell)
Date: Fri, 10 Feb 95 09:58:29 PST
Subject: http://www.vocaltec.com/gti.html
Message-ID: <199502101758.MAA08815@ios.com>


As seen on page B1 of today's WSJ:


> [Image]
> 
>               Talk over the Internet with your own voice.
>         Communicate with people from all over the world.
>           And all this with your existing Internet account.
> 
> Internet Phone (TM) is a unique software product that opens a new and
> exciting dimension for Internet users. With Internet Phone you can use
> the Internet to speak with any user all over the world! Yes, real-time
> voice conversations over the Internet, at the price of a local phone
> call or even less.
> 
> All you need is Internet Phone, a TCP\IP Internet connection and a
> Windows-compatible audio device. Plug in a microphone and speaker, run
> Internet Phone, and, by clicking a button, get in touch with Internet
> users all over the world. Whether you want to meet new friends, get
> information personally, or make the direct business contact, Internet
> Phone is for you. A friendly graphic user interface and a smart
> Voice-Activation feature make conversation a snap. VocalTec's
> sophisticated voice compression and voice transfer technology makes
> sure your voice gets across in a flash, using only a fraction of the
> available bandwidth.
> 
> Internet Phone always presents you with an updated list of topics and
> on-line users for you to choose. You can even set up Quick-Dial
> buttons which give you immediate access to frequently called users.
> Once you establish contact with a user, communication is carried out
> directly over the Internet.
> 
> [Image]
> 
> How can I order Internet Phone?
> 
> To be able to fully use Internet Phone over the Internet, you need a
> unique registration code. The Internet Phone software license can be
> purchased for only US$49! This is a special limited time offer (The
> standard retail price is $99). All you need to do is fill out and send
> us this order form, and we will supply you with the registration code.
> 
> You can even download the Internet Phone software and evaluate it for
> free! Without the registration code, you can use all of the Internet
> Phone features, but are limited to 90 seconds of speech. You have
> nothing to lose - check it out.
> 
> You can download your free evaluation copy of Internet Phone from
> ftp://ftp.vocaltec.com/iphone.zip.
> 
> For business and power users, VocalTec offers the Internet Phone Kit.
> The Internet Phone Kit includes, in addition to the Internet Phone
> software, unique hardware that improves sound quality and dramatically
> reduces bandwidth consumption.
> 
> Internet Phone System Requirements:
> 
>      486SX PC - 25 MHZ, 8MB RAM (recommended)
> 
>      WinSock 1.1
> 
>      An Internet TCP\IP connection (minimum connection: a modem
>      SLIP\PPP connection of 14,400 baud)
> 
>      Windows 3.1
> 
>      Windows-compatible audio device
> 
> SEE ALSO:
> 
> 
> [Image]  Ordering Internet Phone
> 
> [Image]  Internet Phone: Main Features
> 
> [Image]  Request More Information
> 
> [Image]  VocalTec Home Page
> 
> 
>     ------------------------------------------------------------------------
> 
> VocalTec Inc. * 157 Veterans Drive, Northvale, NJ 07647 * Tel:
> 201-768-9400 Fax: 201-768-8893 * info at vocaltec.com







From pcassidy at world.std.com  Fri Feb 10 10:16:28 1995
From: pcassidy at world.std.com (Peter F Cassidy)
Date: Fri, 10 Feb 95 10:16:28 PST
Subject: Bernstein! Where are YOU!
In-Reply-To: <199502101742.MAA05625@pipe3.pipeline.com>
Message-ID: <Pine.3.89.9502101309.A13216-0100000@world.std.com>


Friends - and Bernstein,
-	I am a writer on assignment from the Economist writing about a 
certain cryptographers' tussle with the State Department, a fellow who is 
known around the beltway crypto-anarchy, privacy, 
niceness-on-the-Internet advocacy crowds as Bernstein. I have the outline 
of the case from the attorney's handling it. But my editors would really 
like to be able to name the party and sketch his background. All I have 
now is a last name, that he is a professor/and/or graduate student at UC 
Berkeley and is being roughed up by the State Department. Can anyone here 
- or the hero of the hour himself - come forward and help me complete my 
assignment?
-					Regards,
-						Peter Cassidy

-	PS: By the way, thanks to the guys who helped me shore up some 
basic concepts for the pieces I've done for OMNI and the Covert Action 
Quarterly that have touched on cryptography. Weirdly, one editor actually 
knew the fellow from Texas that I'd interviewed on technical points. 
(They worked together on a newspaper. What a ruck!)






From perry at imsi.com  Fri Feb 10 10:22:33 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 10:22:33 PST
Subject: Bernstein! Where are YOU!
In-Reply-To: <Pine.3.89.9502101309.A13216-0100000@world.std.com>
Message-ID: <9502101822.AA13995@snark.imsi.com>



I have never heard of such an individual, and I strongly suspect I
would have heard of them. I believe you have the name and details
wrong if the individual you are looking for exists at all.

Perry

Peter F Cassidy says:
> Friends - and Bernstein,
> -	I am a writer on assignment from the Economist writing about a 
> certain cryptographers' tussle with the State Department, a fellow who is 
> known around the beltway crypto-anarchy, privacy, 
> niceness-on-the-Internet advocacy crowds as Bernstein. I have the outline 
> of the case from the attorney's handling it. But my editors would really 
> like to be able to name the party and sketch his background. All I have 
> now is a last name, that he is a professor/and/or graduate student at UC 
> Berkeley and is being roughed up by the State Department. Can anyone here 
> - or the hero of the hour himself - come forward and help me complete my 
> assignment?
> -					Regards,
> -						Peter Cassidy
> 
> -	PS: By the way, thanks to the guys who helped me shore up some 
> basic concepts for the pieces I've done for OMNI and the Covert Action 
> Quarterly that have touched on cryptography. Weirdly, one editor actually 
> knew the fellow from Texas that I'd interviewed on technical points. 
> (They worked together on a newspaper. What a ruck!)
> 





From mab at crypto.com  Fri Feb 10 10:36:41 1995
From: mab at crypto.com (Matt Blaze)
Date: Fri, 10 Feb 95 10:36:41 PST
Subject: Global Filesystem Guild
In-Reply-To: <9502101722.AA04330@grape-nuts>
Message-ID: <199502101839.NAA24397@crypto.com>



>
>To reduce the vulnerability of a single user/BBS to having their files
>confiscated/stolen, could a distributed WAN filesystem be implemented with
>k-redundancy, e.g. the files wouldn't disappear until k servers (located in
>various unknown or inaccessible places) failed?  The price of storage would
>vary with the level of redundancy desired.  For security the servers would
>only store cyphertext, etc.  Local cacheing to reduce network load.
>

You've brought up three separate issues - fault-tolerance,  secrecy and
secret sharing.  They are probably best dealt with separately, for the
purposes of understanding them as well as implementing them.

There are replicating file systems that provide the kind of fault
tolerance that you seem to be looking for, although I'm not aware
of any "production grade" systems that can replicate read-write
files in any reasonable way.  Done right, such a system would
probably involve guarantees, implemented partially at the server
side, that a file has been replicated in some number of places
prior to any write operation returning.  You could kludge this at
the client side alone by just modifying your file system interface
to make an approprate number of replicas each time something is
written.  There are a whole bunch of issues surrounding failure
semantics - how do you handle writes when one of the replica servers
is unavailable, and so on.

Secrecy, on the other hand, is best thought of as a client-side
issue, and can be handled with existing client file system encryption
tools that run at the client file system interface level.  For
example, on Unix clients, CFS can store its underlying data on most
any remote file system, and requires no changes or special attention
from the server side.  I have no idea whether the various PC
encrypting file systems (SFS, etc) that have since come along
separate their functions from the low-level storage in a way that
makes it possible to use them with remote file servers, but there's
probably no reason you couldn't build such a system if one didn't
already exist.  The main issue in practice is key management.
Depending on the application, you might want to back up keys under
some secret sharing scheme that allows keys to be recovered by some
subset of key holders.  This is especially important for commercial
applications.

-matt





From hh at xcf.Berkeley.EDU  Fri Feb 10 11:03:28 1995
From: hh at xcf.Berkeley.EDU (Eric Hollander)
Date: Fri, 10 Feb 95 11:03:28 PST
Subject: why pgp sucks
Message-ID: <9502101849.AA21833@xcf.Berkeley.EDU>


if i use a command like

	pgp filename

it will automatically figure out the right thing to do with the file.  if
it's encrypted, and i have the key, it will attempt to decrypt it.  if it
contains keys, it will ask if i want to add them to my keyring.  if it's
signed, it checks the signature.

this sucks!

if i'm trying to write a program to automatically process incoming mail (for
instance, to see if it's encrypted with a specific key), i certainly don't
want to have the possibility of people being able to add garbage to my
keyring just by mailing it to me.

is there a way of saying

	pgp -decrypt-with-key user_id filename

and have it return some error code indicating whether or not the file was in
fact encrypted with user_id, and also gauranteeing that it won't do other
fun stuff with the file, like add it to my keyring?

is there a way of using pgp in a diagnostic mode, to just inform me of what
the file contains (is it signed and/or encrypted, from who and to whom?),
without processing it, and without interaction, and without messing around
with the keyring?  has anyone written some scripts to do this kind of thing?

or should i just wait until some of the groups working on the other
encryption software get it out?

e





From tedwards at src.umd.edu  Fri Feb 10 11:08:17 1995
From: tedwards at src.umd.edu (Thomas Grant Edwards)
Date: Fri, 10 Feb 95 11:08:17 PST
Subject: The question is moot: (Was: Not crypto, but scary.)
In-Reply-To: <Pine.SUN.3.91.950210010704.5527A-100000@access3.digex.net>
Message-ID: <Pine.SUN.3.91.950210135809.26929B-100000@thrash.src.umd.edu>


On Fri, 10 Feb 1995, Black Unicorn wrote:

[about HR 666]

> The bill is really just a restatement.  This has been the state of the 
> law for 11 years now.

Right - it is time to change the law.  HR 666 won't help in that direction.


-Thomas






From hendrix at acs.bu.edu  Fri Feb 10 11:39:10 1995
From: hendrix at acs.bu.edu (hendrix at acs.bu.edu)
Date: Fri, 10 Feb 95 11:39:10 PST
Subject: HR830 - Anyone tracking this?
Message-ID: <199502101934.OAA62015@acs-mail.bu.edu>


> 
>The recent version of the EFFector Online had some information about the
>House of Representative's Bill HR830.  They say that this bill is being
>rammed through Congress and would cripple FOIA.  It would seemingly 
>change any public information that is given value to non-public
>information.  Does anyone have any further information?  
> 
>Mike 
>
In response to your post I am passing on some info that came my way on 
Tuesday, please excuse the length. Apart from the message below there is a 
letter written by James Love of TAP to Honorable William Clinger, Jr. the 
Chairman of the Committee on Government Reform and Oversight, but due to 
it's length I have not included it here. I can E-mail it to anyone who is 
interested. 

                                Julian Burke



------- Forwarded Message Follows -------

Date sent:      Tue, 7 Feb 1995 02:45:55 -0800
Send reply to:  love at Essential.ORG
From:           James Love <love at Essential.ORG>
To:             Multiple recipients of list <law-lib at ucdavis.edu>
Subject:        Help! West Publishing seeks broad change in FOIA (fwd)
Originally to:  law librarians <law-lib at ucdavis.edu>,


Distributed to TAP-INFO, a free Internet Distribution List
(subscription requests to listproc at tap.org) 

TAXPAYER ASSETS PROJECT - INFORMATION POLICY NOTE
CROWN JEWELS CAMPAIGN - Juris, Legal Information
February 7, 1995

We need help from everyone!!!!!!!!  Please distribute this
widely.  jamie love   (love at tap.org, 610/658-0880 or 202/387-
8030)


-    Hearings set for today (Tuesday February 7) on bill
     containing special interest provision for West Publishing. 
     Hearings will be held before the subcommittee on "Regulatory
     Affairs."

-    House republicans have slated quick action on the bill. 
     Subcommittee Mark-up is set for thursday and full committee
     mark-up is set for friday.  (Telephone and Fax numbers of
     committee members given below)

-    House republicans introduce legislation with a section
     requested by West Publishing that will provide sweeping
     changes in federal freedom of information act, and prevent
     federal agencies from creating a public database that use
     the West Publishing page numbers to reference case law.

-    The "West Provision" would also end its lawsuit with Tax
     Analyst, a Virginia publisher, who is seeking access to the
     Department of Justice JURIS database of court decisions in
     order to put the information into the public domain.  Tax
     Analysts alleges the JURIS database of court decisions are
     subject to FOIA and not protected by copyright.  A victory
     by Tax Analysts in this case will lead to a public domain
     database of federal court decisions.

-    The West Provision in the legislation would extend far
     beyond West Publishing's struggle to maintain its grip on
     the market for legal information.  It would exclude all
     contractor generated records from the federal Freedom of
     Information Act.  Examples of databases that would be
     affected by provision would be the SEC's EDGAR database and
     the Department of Education ERIC database.

-    Help needed in removing this special interest provision. 
     Telephone and fax numbers for the Subcommittee on Regulatory
     Affairs are given below.

>From best we can determine, the so called "Paperwork Reduction
Act" bill was introduced late yesterday or will be introduced
early today.  We do not have a bill number yet.  There will be a
hearing on today (Tuesday February 7) before the "Subcommittee on
National Economic Growth, Natural Resources, and Regulatory
Affairs," more commonly referred to as the subcommittee on
"Regulatory Affairs."  Subcommittee Mark-up is set for thursday
and full committee (the apparently misnamed Committee on
Government Reform and Oversight) mark-up is set for friday.

A provision in this bill [Section 3518 (f) of the "Chairman's
Mark"] would do the following.

     If any person "adds value" to public information, the
     federal government would not have "any right to obtain,
     collect, acquire, disseminate, use or convert," the
     data, database or information product, or "any method
     used by the person to identify such resulting data,
     databases or information product," except "under terms
     that are expressly agreed to by such person."

This provision is being sold as a simple restatement of the law,
but that is a far from true (or more bluntly, a lie).  The
provision in the bill is so broad that it covers all contractor
performed work on behalf of agencies, and effectively exempts
contractor generated records from the federal Freedom of
Information Act (FOIA).  For example, since LEXIS "adds value" to
the EDGAR database by taking the incomming filings from the
government and putting them in a database, even if the government
had a copy of the database, it could not dissmeinate the records
without the consent of LEXIS.  Likewise, many databases, such as
the Department of Education ERIC database, are largely put
together by private contactors.  Indeed, if Oliver North had used
a private contractor for the White House email system, those
records would appear to be off limits to both FOIA and a
government supeana.  Moreover, the provison would apply even in
cases where the firm did not have a copyright or any other
protectable intellectually property right, a huge change in
federal law.

The provision would specifically apply to an active federal
lawsuit between West Publishing and Tax Analysts, over the
Department of Justice JURIS database.  West Publishing was a
contractor on JURIS, an online system run by the Department of
Justice, which contains several decades of federal court
decisions.  West Publishing is trying to prevent Tax Analysts
from obtaining copies of court decisions contained in the
government's JURIS database.  Tax Analyst believes the records
are subject to FOIA, and not protected by copyright.  If Tax
Analysts (fmi, Tom Field, 703/533-4400 or Eleanor Lewis 301/652-
3453) wins the law suit, which has been very expensive, it plans
to put the data into the public domain, creating a public
database of federal court decisions -- something that West
Publishing is fighting against.  Moreover, the West assertion of
its copyright of legal citations is being challenged in federal
court in New York by Hyperlaw, a small CD-ROM publisher (fmi,
Alan Sugarman, President, 212/877-1371, sugarman at panix.com).  If
Sugarman wins his case, the West provision would prevent the
Department of Justice from using the West citations in a public
database.


---------------------------------------------------------------------
TAP-INFO is an Internet Distribution List provided by the Taxpayer
Assets Project (TAP).  TAP was founded by Ralph Nader to monitor the
management of government property, including information systems and
data, government funded R&D, spectrum allocation and other government
assets.  TAP-INFO reports on TAP activities relating to federal
information policy.  tap-info is archived at essential.org
and cpsr.org.

Subscription requests to tap-info to listproc at tap.org with
the message:  subscribe tap-info your name
---------------------------------------------------------------------
Taxpayer Assets Project; P.O. Box 19367, Washington, DC  20036
v. 202/387-8030; f. 202/234-5176; internet:  tap at tap.org
---------------------------------------------------------------------







From mab at crypto.com  Fri Feb 10 11:48:38 1995
From: mab at crypto.com (Matt Blaze)
Date: Fri, 10 Feb 95 11:48:38 PST
Subject: why pgp sucks
In-Reply-To: <9502101849.AA21833@xcf.Berkeley.EDU>
Message-ID: <199502101951.OAA28877@crypto.com>



>if i use a command like
>
>	pgp filename
>
>it will automatically figure out the right thing to do with the file.  if
>it's encrypted, and i have the key, it will attempt to decrypt it.  if it
>contains keys, it will ask if i want to add them to my keyring.  if it's
>signed, it checks the signature.
>
>this sucks!
>
>if i'm trying to write a program to automatically process incoming mail (for
>instance, to see if it's encrypted with a specific key), i certainly don't
>want to have the possibility of people being able to add garbage to my
>keyring just by mailing it to me.
>
...

PGP suffers from its failure to separate cleanly its primary
mechanism (encrypting and signing messages) from policy (what to
do with those signed and encrypted mechansims).  Without a clean
separation, the mechanism is limited to use in those applications
narrowly envisioned by the system's authors.  Of course, PGP is
hardly unique here; designing clean interfaces and separation-of-
functions isn't easy, and its even harder in the face of meeting
the needs of an existing installed base of first-generation users.

Personally, I'd much rather see a suite of tools: an encryption/signature
tool (or maybe tools - let me apply them in whatever order is
approprate), a decryption verification tool, a certificate management
system that operates on messages signed with the signature tool and a
top level that glues all this together and implements local policy
(like what consitutes a valid signature, key revocation, etc).  If
we had a system that worked like this,, we could more easily create
richer key certificates that specify restrictions on what is being
signed, revocation conditions, etc.  (As it is, there isn't even
any way for a key signer to revoke a signature, let alone describe
what purpose the signature exists for.)

Of course, you could probably build all this ON TOP of the existing
pgp and pem, but you'd still be left with bloated underlying tools
that implement more policy than they need to.

Oh well.

-matt





From perry at imsi.com  Fri Feb 10 11:48:45 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 11:48:45 PST
Subject: Bernstein! Where are YOU!
In-Reply-To: <Pine.3.89.9502101309.A13216-0100000@world.std.com>
Message-ID: <9502101846.AA14694@snark.imsi.com>



Actually, it is possible that you are talking about Dan Bernstein
(djb at silverton.berkeley.edu), but to my knowledge he hasn't had any
criminal problems with the state department. He's just requested some
export licenses that have been refused.

Perry

Peter F Cassidy says:
> Friends - and Bernstein,
> -	I am a writer on assignment from the Economist writing about a 
> certain cryptographers' tussle with the State Department, a fellow who is 
> known around the beltway crypto-anarchy, privacy, 
> niceness-on-the-Internet advocacy crowds as Bernstein. I have the outline 
> of the case from the attorney's handling it. But my editors would really 
> like to be able to name the party and sketch his background. All I have 
> now is a last name, that he is a professor/and/or graduate student at UC 
> Berkeley and is being roughed up by the State Department. Can anyone here 
> - or the hero of the hour himself - come forward and help me complete my 
> assignment?
> -					Regards,
> -						Peter Cassidy
> 
> -	PS: By the way, thanks to the guys who helped me shore up some 
> basic concepts for the pieces I've done for OMNI and the Covert Action 
> Quarterly that have touched on cryptography. Weirdly, one editor actually 
> knew the fellow from Texas that I'd interviewed on technical points. 
> (They worked together on a newspaper. What a ruck!)
> 





From perry at imsi.com  Fri Feb 10 11:58:46 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 11:58:46 PST
Subject: why pgp sucks
In-Reply-To: <199502101951.OAA28877@crypto.com>
Message-ID: <9502101958.AA15039@snark.imsi.com>



Matt Blaze says:
> PGP suffers from its failure to separate cleanly its primary
> mechanism (encrypting and signing messages) from policy (what to
> do with those signed and encrypted mechansims).  Without a clean
> separation, the mechanism is limited to use in those applications
> narrowly envisioned by the system's authors.
[...]
> Personally, I'd much rather see a suite of tools: an encryption/signature
> tool (or maybe tools - let me apply them in whatever order is
> approprate), a decryption verification tool, a certificate management
> system that operates on messages signed with the signature tool and a
> top level that glues all this together and implements local policy
> (like what consitutes a valid signature, key revocation, etc).  If
> we had a system that worked like this,, we could more easily create
> richer key certificates that specify restrictions on what is being
> signed, revocation conditions, etc.

I've been saying this for a long time, and I want to triple-reiterate
it -- PGP needs to be broken down into simple Unix-philosophy style
tools, or it isn't going to be useful in the long run.

I'll also note, yet again, that unless PGP quits this bad practice of
identifying counterparties only by a number, it is NOT going to be
universally deployed. Counterparties need to be identified by a name
that can be looked up in the DNS -- meaning "joe at foo.com" rather than
some key ident number.

Perry





From rfb at lehman.com  Fri Feb 10 12:20:29 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 12:20:29 PST
Subject: MIME based remailing commands
In-Reply-To: <199502082037.MAA02640@jobe.shell.portal.com>
Message-ID: <9502102017.AA11002@cfdevx1.lehman.com>


    Date: Wed, 8 Feb 1995 12:37:54 -0800
    From: Hal <hfinney at shell.portal.com>
    
    Nathaniel Borenstein <nsb at nsb.fv.com> writes:

    Right now we are basically having the remailing commands be mail
    header fields.  But really people aren't supposed to just make up
    new fields like that.  I think the "name space" of these fields is
    protected somewhat more than many other aspects of communication
    protocols on the net.

If you start your header name with X-, then you are conforming that
gross, ugly atrocity that is MIME.  And yet, by using headers rather
than TGUATIM, you help to preserve sanity and avoid that vast majority
of MIME slime.

Note that I'm not suggesting that MIME has no place.  When you truly
need to mix data types and you *want* the different parts to be easily
processed by all, it makes perfect sense.

Given the privacy goals of a remailing, MIME has only disadvantages.

    Is there precedent for adding service-by-mail functionality in
    this way?  I am not completely comfortable with it.  And as we
    think of new functionality and new commands they all have to get
    added at this top level, the same visibility and name space as
    "Subject", "From", and "To".

So, do what you have to in C and C++-sans-namespaces, use a prefix.
X-RM- could prefix the Remailer namespace.  It's ugly, but compared to
the alternative it is pure beauty.
    
--
Rick Busdiecker <rfb at lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu





From hfinney at shell.portal.com  Fri Feb 10 12:27:59 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 10 Feb 95 12:27:59 PST
Subject: why pgp sucks
In-Reply-To: <9502101849.AA21833@xcf.Berkeley.EDU>
Message-ID: <199502102027.MAA20904@jobe.shell.portal.com>


Eric Hollander <hh at xcf.Berkeley.EDU> writes:

>if i use a command like

>	pgp filename

>it will automatically figure out the right thing to do with the file.  if
>it's encrypted, and i have the key, it will attempt to decrypt it.  if it
>contains keys, it will ask if i want to add them to my keyring.  if it's
>signed, it checks the signature.

>this sucks!

>if i'm trying to write a program to automatically process incoming mail (for
>instance, to see if it's encrypted with a specific key), i certainly don't
>want to have the possibility of people being able to add garbage to my
>keyring just by mailing it to me.

In my remailer, I use: pgp -f < infile > outfile.  This won't add keys.
If you capture standard error you can parse it (grep is probably good
enough) to see whether the message was signed, encrypted, had a bad
signature, had keys, etc.

Hal





From hfinney at shell.portal.com  Fri Feb 10 12:32:05 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 10 Feb 95 12:32:05 PST
Subject: why pgp sucks
In-Reply-To: <9502101958.AA15039@snark.imsi.com>
Message-ID: <199502102031.MAA21422@jobe.shell.portal.com>


"Perry E. Metzger" <perry at imsi.com> writes:
>I'll also note, yet again, that unless PGP quits this bad practice of
>identifying counterparties only by a number, it is NOT going to be
>universally deployed. Counterparties need to be identified by a name
>that can be looked up in the DNS -- meaning "joe at foo.com" rather than
>some key ident number.

PGP of course looks up keys by strings in addition to numbers.  A widely
accepted practice is to use <joe at foo.com> in the user ID which allows the
lookups to be by internet address.  PGP was intended for use beyond the
internet, such as in bbs's, fidonet, corporate networks, etc., where DNS
style addresses may not be useful.

Hal





From perry at imsi.com  Fri Feb 10 12:36:40 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 12:36:40 PST
Subject: why pgp sucks
In-Reply-To: <199502102031.MAA21422@jobe.shell.portal.com>
Message-ID: <9502102036.AA15222@snark.imsi.com>



Hal says:
> "Perry E. Metzger" <perry at imsi.com> writes:
> >I'll also note, yet again, that unless PGP quits this bad practice of
> >identifying counterparties only by a number, it is NOT going to be
> >universally deployed. Counterparties need to be identified by a name
> >that can be looked up in the DNS -- meaning "joe at foo.com" rather than
> >some key ident number.
> 
> PGP of course looks up keys by strings in addition to numbers.  A widely
> accepted practice is to use <joe at foo.com> in the user ID which allows the
> lookups to be by internet address.

The problem is that incoming messages are tagged with the number, not
the string. You can't check the signature if you don't have the number
in your own database. Global databases don't scale. Distributed
databases like DNS do scale. DNS style naming doesn't hurt non-DNS
users, so its a shame that it isn't there -- I, for one, can't specify
PGP style keys in the internet key management system I'm working on
because of this.

Perry





From xpat at vm1.spcs.umn.edu  Fri Feb 10 12:42:13 1995
From: xpat at vm1.spcs.umn.edu (xpat at vm1.spcs.umn.edu)
Date: Fri, 10 Feb 95 12:42:13 PST
Subject: West (was:HR830 - Anyone tracking this?)
Message-ID: <9502102042.AA20803@toad.com>


>-    House republicans introduce legislation with a section
>     requested by West Publishing that will provide sweeping
>     changes in federal freedom of information act, and prevent
>     federal agencies from creating a public database that use
>     the West Publishing page numbers to reference case law.

Well, the West citation system *is* proprietary, without a doubt.
This is a case where ease-of-use has completely dominated. Court
records are completely laced with West citations.

>-    The "West Provision" would also end its lawsuit with Tax
>     Analyst, a Virginia publisher, who is seeking access to the
>     Department of Justice JURIS database of court decisions in
>     order to put the information into the public domain.  Tax
>     Analysts alleges the JURIS database of court decisions are
>     subject to FOIA and not protected by copyright.  A victory
>     by Tax Analysts in this case will lead to a public domain
>     database of federal court decisions.

The Tax Analyst lawsuit: destined to fail from the start.
If they want to do this they will have to come up with their own
indexing/citation system, and then get everyone to adapt to it.
About as likely as putting 73v AC wiring in every home in America.





From rfb at lehman.com  Fri Feb 10 12:42:18 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 12:42:18 PST
Subject: MIME based remailing commands
In-Reply-To: <9502082251.AA03118@toad.com>
Message-ID: <9502102039.AA11466@cfdevx1.lehman.com>


    Date:         Wed, 08 Feb 95 16:37:06 CST
    From: xpat at vm1.spcs.umn.edu
    
    I say take the remail stuff out of the header altogether,
    MIME or not.

If by this, you mean to follow more of the model used by
remail at extropia.wimsey.com, then I completely agree.  What travels in
the clear should not *require* any header data.  It could even include
misleading headers.  A remailer should be able to accept mail which is
encrypted for it.  It can then decode the encrypted part and discard
the rest.  The format of the decrypted message could be whatever works
best for remailers which might or might not have anything at all to do
with MIME.

OTOH, if you are going to have information in the clear to support
naive users or whatever, put the information in the header.  The whole
purpose of headers is for auxiliary information about the message and
its delivery.  The body is for the message itself.

With MIME's approach of making every piece of information as big and
clunky as possible, I'm mildly suprised that it hasn't done away with
headers altogether :-)

--
Rick Busdiecker <rfb at lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu





From abostick at netcom.com  Fri Feb 10 12:43:17 1995
From: abostick at netcom.com (Alan Bostick)
Date: Fri, 10 Feb 95 12:43:17 PST
Subject: So, what's it all about?
In-Reply-To: <199502100151.RAA25844@sleepy.retix.com>
Message-ID: <OGwElyczBC4M075yn@netcom.com>


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

In article <199502100151.RAA25844 at sleepy.retix.com>, you wrote:
> 
> >   I went to a UNIX trade show yesterday, and the main speaker was a 
> >   security type. He talked about "the cypherpunks" among other things.
> >   He said you are really scary and dangerous and ...
> >   But of course he had to also project this adress (cypherpunks at toad.com)
> >   on the screen.
> 
> can't imagine he is much of a security stud if he is that deluded.
> 
> what was his name?

Lance or Vance something.  Rottweiler, maybe?


   Alan Bostick           | The nice thing about quotes is that they give   
   abostick at netcom.com    | a nodding acquaintance with the originator
finger for PGP public key | which is often socially impressive.
Key fingerprint:          |         Kenneth Williams
50 22 FB 46 41 A3 17 9D F7 33 FF E1 4E 1C 89 79  +legal_kludge=off

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQB1AgUBLzukWOVevBgtmhnpAQGX4gL/bsv8KcRiQcoyl+DolBYDz3/dC6sgvTDK
SGXlHo4l9t9g9IALlk4QXTmXehLTiCkVpHOc8VzjGFOi7FQ4oF3yX5TghPObNiKE
hxJrzvlYaFecq7yI74IV9mB0SFfodtRn
=sbdR
-----END PGP SIGNATURE-----





From rfb at lehman.com  Fri Feb 10 12:46:16 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 12:46:16 PST
Subject: MIME based remailing commands
In-Reply-To: <9502082303.AA10796@snark.imsi.com>
Message-ID: <9502102043.AA11506@cfdevx1.lehman.com>


    Date: Wed, 08 Feb 1995 18:03:57 -0500
    From: "Perry E. Metzger" <perry at imsi.com>

    xpat at vm1.spcs.umn.edu says:
    > IMHO, an ideal message would have the ability to handle nested objects
    > of varying types, MIME is only a start.

    What is it precisely that you might want to encapsulate that MIME
    can't encapsulate?

And in what way does MIME encapsulation aid in the privacy goals of
remailing?

It seems far more likely to require that you expose information which
you might prefer not to expose, much as the Privacy Enhanced Mail
standard does.

--
Rick Busdiecker <rfb at lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu





From mac5tgm at hibbs.vcu.edu  Fri Feb 10 12:48:05 1995
From: mac5tgm at hibbs.vcu.edu (Greg Morgan)
Date: Fri, 10 Feb 95 12:48:05 PST
Subject: why pgp sucks
In-Reply-To: <9502101958.AA15039@snark.imsi.com>
Message-ID: <9502102047.AA25106@hibbs.vcu.edu>


Perry E. Metzger originally said the following...
> 
> 
> I'll also note, yet again, that unless PGP quits this bad practice of
> identifying counterparties only by a number, it is NOT going to be
> universally deployed. Counterparties need to be identified by a name
> that can be looked up in the DNS -- meaning "joe at foo.com" rather than
> some key ident number.

Doesn't having some kind of central record of keys go against
the principle of PGP?  Unless you're just talking about having
a name attached to each key, but not exactly a DNS for key
id's...  I'll admit I'm a little confused.

-----------------------------------------------------------------------------
Greg Morgan <mac5tgm at hibbs.vcu.edu>    | "I dunno Brain, me and Pipi
Mail me for PGP Key: 0xE0D222A9        |  Longstocking?  I mean what would
Key Fingerprint : 2430 BAA4 1EE4 AA2F  |  the children look like?" - Pinki
                  3B76 3516 3DEF 5529  |
-----------------------------------------------------------------------------





From warlord at MIT.EDU  Fri Feb 10 12:59:12 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 10 Feb 95 12:59:12 PST
Subject: why pgp sucks
In-Reply-To: <9502101849.AA21833@xcf.Berkeley.EDU>
Message-ID: <9502102058.AA07955@josquin.media.mit.edu>


> if i use a command like
> 
> 	pgp filename

The problem is that you are using the wrong command....

> it will automatically figure out the right thing to do with the file.  if
> it's encrypted, and i have the key, it will attempt to decrypt it.  if it
> contains keys, it will ask if i want to add them to my keyring.  if it's
> signed, it checks the signature.

This is the correct behavior of "pgp filename".  If you want other
behavior, you should tell PGP how you want it to behave.

> if i'm trying to write a program to automatically process incoming mail (for
> instance, to see if it's encrypted with a specific key), i certainly don't
> want to have the possibility of people being able to add garbage to my
> keyring just by mailing it to me.

A very noble effort, combining PGP with mailers.  Btw: When you run
"pgp filename" and filename contains public keys, it will ask you
before it adds them to your keyring!

You can use "pgp -d" to force it to do a decryption (although you
cannot specify which key to use for the decryption; it will choose any
of the keys on your secret keyring).

> is there a way of using pgp in a diagnostic mode, to just inform me of what
> the file contains (is it signed and/or encrypted, from who and to whom?),
> without processing it, and without interaction, and without messing around
> with the keyring?  has anyone written some scripts to do this kind of thing?

Well, I'm not exactly sure what you want.  You can give PGP no
password and it will tell you to whom a message is encrypted.  You can
call pgp -ka and it will _only_ add keys (and complain if you are
given anything else).  There is no way to ask PGP "what kind of
message is this"; that is sort of what the ASCII ARMOR header is for.

> or should i just wait until some of the groups working on the other
> encryption software get it out?

No, you should, at this point, consider working around the problems in
the monolithic PGP, until a more modular library is available, to
which multiple end programs can be built to do multiple little tasks,
as Matt explained.

Does this help?

-derek





From nsb at nsb.fv.com  Fri Feb 10 13:00:01 1995
From: nsb at nsb.fv.com (Nathaniel Borenstein)
Date: Fri, 10 Feb 95 13:00:01 PST
Subject: MIME based remailing commands
In-Reply-To: <18386.792449215.1@nsb.fv.com>
Message-ID: <0jCxBn=0Eyt5AxShYL@nsb.fv.com>


Excerpts from mail: 10-Feb-95 Re: MIME based remailing co.. Rick
Busdiecker at lehman.c (1667)

> If you start your header name with X-, then you are conforming that
> gross, ugly atrocity that is MIME.  And yet, by using headers rather
> than TGUATIM, you help to preserve sanity and avoid that vast majority
> of MIME slime.

Well, I have no idea why you think that MIME is an "atrocity" or
"slime", but it is perfectly clear that you have no idea what it
actually *is*, since "X-" headers have nothing whatsoever to do with
MIME.  The "X-" headers are defined by RFC 822, which has been the
standard for Internet mail formats since 1982.

Perhaps you should learn what MIME is before you embarass yourself
further.  -- Nathaniel





From rfb at lehman.com  Fri Feb 10 13:00:57 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 13:00:57 PST
Subject: MIME based remailing commands
In-Reply-To: <199502090425.UAA24521@largo.remailer.net>
Message-ID: <9502102057.AA11903@cfdevx1.lehman.com>


    Date: Wed, 8 Feb 1995 20:25:32 -0800
    From: Eric Hughes <eric at remailer.net>
    
    You say MIME, and you've not completely specified the data format,
    but rather constrained it in a way that most everybody basically
    agrees with, including me.

Could one of the MIME supporters (I guess that would be `most
everybody') explain why anything more than a To: header and an
encrypted block is desireable for the in-the-clear message?

Specifically, why is it desireable to broadcast additional information
about a message for which privacy is a primary concern?

--
Rick Busdiecker <rfb at lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu





From rfb at lehman.com  Fri Feb 10 13:02:58 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Fri, 10 Feb 95 13:02:58 PST
Subject: Coming to a newsserver near you alt.defeat.s314
In-Reply-To: <199502090627.WAA01928@tower.techwood.org>
Message-ID: <9502102101.AA11999@cfdevx1.lehman.com>


    Date: Wed, 8 Feb 1995 22:27:59 -0800
    From: Name Withheld <nobody at tower.techwood.org>

    Psychic Flash...This group will be up on auto-subscribing news server's
    VERY soon.

It was available via CMU news servers quite some time ago.  Haven't
checked recently, but I would assume that it still is.

			Rick





From warlord at MIT.EDU  Fri Feb 10 13:10:58 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 10 Feb 95 13:10:58 PST
Subject: why pgp sucks
In-Reply-To: <9502102047.AA25106@hibbs.vcu.edu>
Message-ID: <9502102110.AA07984@josquin.media.mit.edu>


> Doesn't having some kind of central record of keys go against
> the principle of PGP?  Unless you're just talking about having
> a name attached to each key, but not exactly a DNS for key
> id's...  I'll admit I'm a little confused.

Not at all.

The point is to have a centralized, distributed key distribution
mechanism, similar in concept to the PGP Public Keyservers, but which
scale much much better.  The concept is similar to a DNS of PGP keys
(think of the DNS model, not the DNS implementation) where you have
keys distributed based upon site.  For example, MIT could server MIT's
keys, and CMU would server CMU's keys.

This does not go against PGP in any way.  In fact, it augments PGP
wonderfully.  How else would we be able to have a world-wide white
pages of PGP Public Keys?

-derek






From perry at imsi.com  Fri Feb 10 13:14:00 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 13:14:00 PST
Subject: MIME based remailing commands
In-Reply-To: <9502102043.AA11506@cfdevx1.lehman.com>
Message-ID: <9502102113.AA15560@snark.imsi.com>



Rick Busdiecker says:
>     What is it precisely that you might want to encapsulate that MIME
>     can't encapsulate?
> 
> And in what way does MIME encapsulation aid in the privacy goals of
> remailing?

With the security multiparts MIME standard.

Perry





From perry at imsi.com  Fri Feb 10 13:17:31 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 13:17:31 PST
Subject: MIME based remailing commands
In-Reply-To: <9502102057.AA11903@cfdevx1.lehman.com>
Message-ID: <9502102116.AA15570@snark.imsi.com>



Rick Busdiecker says:
> Could one of the MIME supporters (I guess that would be `most
> everybody') explain why anything more than a To: header and an
> encrypted block is desireable for the in-the-clear message?
> 
> Specifically, why is it desireable to broadcast additional information
> about a message for which privacy is a primary concern?

No one said that it was desirable to do so, and MIME does not force
you to do so.

.pm





From perry at imsi.com  Fri Feb 10 13:19:27 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 13:19:27 PST
Subject: why pgp sucks
In-Reply-To: <9502102110.AA07984@josquin.media.mit.edu>
Message-ID: <9502102118.AA15581@snark.imsi.com>



Derek Atkins says:
> The point is to have a centralized, distributed key distribution
> mechanism, similar in concept to the PGP Public Keyservers, but which
> scale much much better.  The concept is similar to a DNS of PGP keys
> (think of the DNS model, not the DNS implementation) where you have
> keys distributed based upon site.  For example, MIT could server MIT's
> keys, and CMU would server CMU's keys.
> 
> This does not go against PGP in any way.  In fact, it augments PGP
> wonderfully.  How else would we be able to have a world-wide white
> pages of PGP Public Keys?

Unfortunately, the current PGP practice of using only numeric key-ids
in message packets makes it hard to do this -- sigh. I hope that
the next version of PGP changes this.

Perry





From weidai at eskimo.com  Fri Feb 10 13:33:34 1995
From: weidai at eskimo.com (Wei Dai)
Date: Fri, 10 Feb 95 13:33:34 PST
Subject: law vs technology
Message-ID: <199502102133.AA16472@mail.eskimo.com>


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

Recently there's been a great deal of discussion on this list
about upcoming legislations (HR666 S314 etc.).  Maybe it's time
to step back a little and look at the bigger picture.  I've
been assuming (perhaps incorrectly) for some time that most
cypherpunks hold a belief somewhat like the following:

There has never been a government that didn't sooner or later
try to reduce the freedom of its subjects and gain more control
over them, and there probably never will be one.  Therefore,
instead of trying to convince our current government not to
try, we'll develop the technology (e.g., remailers and ecash)
that will make it impossible for the government to succeed.
Efforts to influence the government (e.g., lobbying and
propaganda) are important only in so far as to delay its
attempted crackdown long enough for the technology to mature
and come into wide use.

But even if you do not believe the above is true, think about
it this way:  If you have a certain amount of time to spend on
advancing the cause of greater personal privacy (or freedom, or
cryptoanarchy, or whatever), can you do it better by using the
time to learn about cryptography and develop the tools to
protect privacy, or by convincing your government not to invade
your privacy?  I argue that since there are many more people
doing the former (EFF, CPSR, etc) than latter, that you'd be
more effective if you spent the time on the former.

Wei Dai


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzvayTl0sXKgdnV5AQEBvAP+MqsGer5pg2xM6+pYG7DgCSttUyAoG8I6
Hm/atFUdRauZ1WREpi3XTXEmNgT9m+QuON5+6rnUrfkizAdjr9EPFnXxMa8am8TZ
W7iQBuKb/KktbClbQyKzndeAOQ3oIOi4ahdn5eseOCWc3wX/WcjR6w9WJ6yPWoTJ
6fcglCGgo/8=
=Pc1V
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From warlord at MIT.EDU  Fri Feb 10 13:36:08 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 10 Feb 95 13:36:08 PST
Subject: why pgp sucks
In-Reply-To: <9502102118.AA15581@snark.imsi.com>
Message-ID: <9502102135.AA08054@josquin.media.mit.edu>


> Unfortunately, the current PGP practice of using only numeric key-ids
> in message packets makes it hard to do this -- sigh. I hope that
> the next version of PGP changes this.

I doubt PGP will change this in the near future.  That would require a
major packet format change, and would not be anywhere near backwards
compatible.  

I dont consider this to be a big problem.  If you limit key lookups in
the database to be lookup on userID only, that solves your database
problem.  As for the keyID->userID, well, this would only be required
to _verify_ a signature.  In that case, you know who sent the message
to you so you can ask them for the key.  When you want to encrypt to
someone, you already know to whom you want to encrypt, so the same
thing applies.

I don't see the problem!

-derek

PS: I should state that I know what problem you are trying to solve,
and I'm saying that there are other workarounds to get around the
problem.





From perry at imsi.com  Fri Feb 10 13:42:13 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 13:42:13 PST
Subject: why pgp sucks
In-Reply-To: <9502102135.AA08054@josquin.media.mit.edu>
Message-ID: <9502102141.AA15657@snark.imsi.com>



Derek Atkins says:
> > Unfortunately, the current PGP practice of using only numeric key-ids
> > in message packets makes it hard to do this -- sigh. I hope that
> > the next version of PGP changes this.
> 
> I doubt PGP will change this in the near future.  That would require a
> major packet format change, and would not be anywhere near backwards
> compatible.  
> 
> I dont consider this to be a big problem.

I do. It means that I can't use PGP for IPSP key management -- period.

> If you limit key lookups in the database to be lookup on userID
> only, that solves your database problem.  As for the keyID->userID,
> well, this would only be required to _verify_ a signature.  In that
> case, you know who sent the message to you so you can ask them for
> the key.  When you want to encrypt to someone, you already know to
> whom you want to encrypt, so the same thing applies.
> 
> I don't see the problem!

Sorry, but I see the problem. If I want to follow an arbitrary chain
of signatures, check arbitrary signatures, etc, I'm forced to go
through kludges or worse. I don't see it as acceptable to just ask
someone for their key, either.

Perry





From rishab at dxm.ernet.in  Fri Feb 10 13:44:31 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Fri, 10 Feb 95 13:44:31 PST
Subject: Bernstein
Message-ID: <gate.8DLc1c1w165w@dxm.ernet.in>


Peter F Cassidy <pcassidy at world.std.com>:
> -       I am a writer on assignment from the Economist writing about a 
> certain cryptographers' tussle with the State Department, a fellow who is 
> known around the beltway crypto-anarchy, privacy, 
> niceness-on-the-Internet advocacy crowds as Bernstein. I have the outline 

There are two of them in my archives: "D. J. Bernstein" 
(djb at silverton.berkeley.edu) at Berkeley who visited the list once; and E.
Bernstein, the author of papers on quantum complexity along with U Vazirani.

I've never heard of either of them tussling with the State Department. Apart
from the name, though, several cryptographer/cypherpunks could fit the bill, 
from Phil Zimmerman of course to various people who've tried to extract ITAR
clearance or FOIA requests.


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From rrothenb at ic.sunysb.edu  Fri Feb 10 13:59:19 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Fri, 10 Feb 95 13:59:19 PST
Subject: The drumbeat against anonymity (Cellphone security?)
In-Reply-To: <ab5f548601021004d020@DialupEudora>
Message-ID: <199502102157.QAA20682@libws3.ic.sunysb.edu>


I remember watching some of the hearings onthe DT Bill on CSPAN and seeing
the cellular industry people note that the DT Bill would make it difficult
to implement encryption/authentication measures.

Rob

> >The phone companies that are complaining about fraud have inadequately
> >arranged for security and need to adopt a mode that fixes this. Since
> >physical money can't be fed into the slots of a handheld cell phone (or
> >at least can't then be delivered to the service owner!), the solution
> >has traditionally been an account-based payment system. (Accounts can
> >also be better protected against fraud by having PINs, etc.)
> >
> 
> The technology to reduce cellular fraud, through encryption and
> authentication, is easily implementable, but for some reason neither
> the operating companies nor the manufacturers want it.
> 
> In contrast, European cellular (GSM) products do implement
> encryption and authentication (at least as far as laws allow).
> GSM mobile phones can be equipped with a slot for a card that
> identifies the subscriber.  Billing is based on the subscriber's
> identity, not the phone's.
> 
> I'd say that the problem isn't just a lack of a proper payment
> model, but also an unwillingness to provide adequate technology
> to the problem.  Of course, the GSM approach does nothing for anonymity
> or digital cash.
> 
> allen at well.sf.ca.us          It's dangerous, child, to come to conclusions
> ethridge at netcom.com          when you don't have any facts.
> my opinions are my own       Dr. Hemlock, The Eiger Sanction
> 
> 
> 






From hfinney at shell.portal.com  Fri Feb 10 14:05:41 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 10 Feb 95 14:05:41 PST
Subject: MIME based remailing commands
In-Reply-To: <9502102057.AA11903@cfdevx1.lehman.com>
Message-ID: <199502102205.OAA04014@jobe.shell.portal.com>


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

Rick Busdiecker <rfb at lehman.com> writes:
>Could one of the MIME supporters (I guess that would be `most
>everybody') explain why anything more than a To: header and an
>encrypted block is desireable for the in-the-clear message?

For one thing, you might want to know that you have an encrypted
message on your hands and not just somebody's misfired GIF.  For
another, you might want to know where the encrypted block begins and
where it ends.  You might also want to have information about what
kind of encoding has been done on the output of the encryption (base64,
uuencode, leave it as pure 8-bit binary, etc.)  And you might want to
have information about what kind of encryption was used, what key
was used, etc., in case you are supporting multiple encryption
formats and keys.

PGP, FYI, does include most of this information in the clear, albeit some
in binary format.

This information is generally needed for the receiver to successfully
decode and receive the message, so it does have to be in the clear.  Now,
there may be some circumstances where this is not desired, and where you
really do just want to hand the receiver a block of apparently random
data, with no indications whatsoever what it is.  Then by some
out-of-band means you have to have arranged with the receiver that he
will know exactly what transformation to do to get back the original
data.  For that I suppose you could just use text/plain (or something
like application/data?), and it looks as opaque as could be desired.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLzvjARnMLJtOy9MBAQFxigIAyzjDVvkgb85h2gbEMqAjuATlNGo1V1u0
YQdlJannRuUX+p0kXepHJ7101ROKFUjPwCjGZXNFFmvWvGz7tByoMw==
=aj4b
-----END PGP SIGNATURE-----





From rfdutcher at igc.apc.org  Fri Feb 10 14:10:42 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Fri, 10 Feb 95 14:10:42 PST
Subject: Laws, Feds, & the Internet
Message-ID: <199502102211.OAA22129@mail.igc.apc.org>



The following was in today's San Francisco Chronicle.  BTW, quoting 
the entire article as I have done is probably a violation of "fair 
use" - but de minimis ...

All under *current* law, folks.

[hmmm -- encryption doesn't do much for exhibitionists and 
braggarts, does it?  ;-]

==============================

MAN JAILED FOR INTERNET MESSAGES

Associated Press

Detroit

	A college student was charged yesterday with posting computer 
messages describing the imaginary binding, rape, torture and murder 
of a woman who used to be in his Japanese class.

	"Torture is foreplay, rape is romance, snuff (killing) is climax," 
prosecutors say one of Jake Baker's messages read.

	The student, 20, was charged with the federal crime of transmitting a 
threat to injure.  He was jailed pending a bond hearing today.

	Baker, who was suspended from the University of Michigan last week,
told reporters he was within his rights to post the messages on the
Internet.  By posting the messages, he gave other Internet users
access to them.

	If convicted, Baker could be sentenced to up to five years in 
prison.  The name of the woman was not released.

==================================

===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From rrothenb at ic.sunysb.edu  Fri Feb 10 14:29:15 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Fri, 10 Feb 95 14:29:15 PST
Subject: why pgp sucks
In-Reply-To: <9502101849.AA21833@xcf.Berkeley.EDU>
Message-ID: <199502102228.RAA21755@libws3.ic.sunysb.edu>


> 
> if i use a command like
> 
> 	pgp filename
> 
> it will automatically figure out the right thing to do with the file.  if
> it's encrypted, and i have the key, it will attempt to decrypt it.  if it
> contains keys, it will ask if i want to add them to my keyring.  if it's
> signed, it checks the signature.
> 
> this sucks!

>From whose point of view? Remember the thread about Getting things right
v. Getting the software out?

The above way is easier for most people with little computer techie
knowledge. Requiring a whole complex set of commands would mean less
PGP users.

As people get used to it and learn about the issues, key management,
etc. they'll be more willing to use a more advanced version of PGP...
at the very least, they'll eventually RTFM and realize that you actally
have more control of what it can do...

Rob

> if i'm trying to write a program to automatically process incoming mail (for
> instance, to see if it's encrypted with a specific key), i certainly don't
> want to have the possibility of people being able to add garbage to my
> keyring just by mailing it to me.

Have your program check what's in the mail before doing anything with it...?








From mab at crypto.com  Fri Feb 10 14:31:27 1995
From: mab at crypto.com (Matt Blaze)
Date: Fri, 10 Feb 95 14:31:27 PST
Subject: why pgp sucks
In-Reply-To: <9502102047.AA25106@hibbs.vcu.edu>
Message-ID: <199502102233.RAA02974@crypto.com>



>Doesn't having some kind of central record of keys go against
>the principle of PGP?  

The only "principle" of which I'm aware (and particularly interested
in supporting) is that of having widely fielded, useful and strong
privacy and authentication tools that work properly and transparently.
That means, among a great many other things, flexible protocols
and tools that support remote key distribution services.

As much as people want to believe that privacy can be reduced to
some kind of romantic struggle between the evil forces of Centralization
(PEM?) and the civilizing forces of Anarchy (PGP?), the world most
of us live in is a lot more complex than that.

More seriously, the problem that Perry brought up is that it's hard
to deploy any kind of scaleable key distribution infrastructure
that works with PGP (as it currently exists - and yes, I realize
there are work-arounds for some specific situations).  That, as well
as other shortcomings (like its fixed trust/certification model)
that work against its serious use, make it doubtful that PGP 2.x
has much long-term future as anything other than a plaything for
nerds like us.  Hopefully, PGP and other good tools will evolve to
work well on a larger scale before Microsoft has a chance to give
everyone what _it_ thinks the world needs.

(I'm not trying to attack anyone here, by the way - part of the
problem is that we're just now learning what the privacy problems
of the real world even _are_.  Experimental tools like PGP are
important as much for providing experience and exposing problems
and limitations as they are for their immediate function.  Indeed,
the fact that PGP and PEM are as useful as they are may actually
work _against_ the spread of really large-scale crypto tools; the
people who they are aimed at stay happy while the rest of the world
never finds out what it's missing.)

-matt





From lmccarth at ducie.cs.umass.edu  Fri Feb 10 14:51:36 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Fri, 10 Feb 95 14:51:36 PST
Subject: law vs technology
In-Reply-To: <199502102133.AA16472@mail.eskimo.com>
Message-ID: <199502102253.RAA10658@ducie.cs.umass.edu>


Wei Dai writes:
> If you have a certain amount of time to spend on
> advancing the cause of greater personal privacy (or freedom, or
> cryptoanarchy, or whatever), can you do it better by using the
> time to learn about cryptography and develop the tools to
> protect privacy, or by convincing your government not to invade
> your privacy?  I argue that since there are many more people
> doing the former (EFF, CPSR, etc) than latter, that you'd be
> more effective if you spent the time on the former.

[Presumably you meant, "many more people doing the *latter* than *former*"]

Speaking strictly for myself, I agree. I'm relatively well-positioned to
design and produce privacy- and security-preserving protocols and programs.
OTOH, while I find politics absorbing, I don't have any special expertise or
influence. Once the legal scholars start to debate legislation, I step out
of the way.

There is, however, an awfully wide spectrum of interests and abilities 
among the subscribers to this list, from what I can tell. Plenty of people
here lack some of the requisite technical skills, but can offer significant
assistance in other ways. So I think your point applies to some people here,
but not everyone. 

I'm reminded of the controversy over the essential identity of cypherpunks.
There was interminable wrangling over who (if anyone) "owned" the list, 
whether the list and Cypherpunks were identical, etc. AFAI can tell, the list
comprises many of both run-of-the-mill privacy/security advocates (whatever 
that means) and Cypherpunks according to strict definitions as written by Tim 
and others.

As a separate issue, there are quite a few vocal opponents of groups such as
EFF on the list. I've no idea whether there's a silent majority ;) of lurkers
who fully support EFF et al., but I suspect a sizable chunk of the list
population disagrees that there are many people really fighting invasive govt.
action.

-L. Futplex McCarthy [seeking summer work, with a background in theoretical
                      computer science; private email inquiries welcomed]




From storm at marlin.ssnet.com  Fri Feb 10 14:59:09 1995
From: storm at marlin.ssnet.com (Don Melvin)
Date: Fri, 10 Feb 95 14:59:09 PST
Subject: S. 314 and existing situation
In-Reply-To: <Pine.LNX.3.91.950209140130.8757A-100000@chewy.wookie.net>
Message-ID: <AbxElKJXYzk0078yn@ssnet.com>



In article <Pine.LNX.3.91.950209140130.8757A-100000 at chewy.wookie.net>,
slowdog <slowdog at wookie.net> wrote:
> 
> Hard to tell from this bill what the deal is on this. Common carriers 
> aren;t completely immune from prosecution or lawsuit or whatnot to begin 
> with. But in addition, S.314 introduces "transmit or otherwise make 
> available" into the language of the law. Which makes the -carrier- of the 
> "offending" information responsible.

Interesting point, there.

Following from that:

        Telecoms have bucks.
        Telecoms have lawyers.
        Telecoms are the 'transmission' agents for pretty much all of
                the internet. Even high speed dedicated T1s are usually
                from a telecom or two.

Can we get them involved?

--
America - a country so rich and so strong we can reward the lazy 
          and punish the productive and still survive (so far)

Know your Constitution (void where prohibited)





From storm at marlin.ssnet.com  Fri Feb 10 14:59:11 1995
From: storm at marlin.ssnet.com (Don Melvin)
Date: Fri, 10 Feb 95 14:59:11 PST
Subject: Effects of S.314 (Communications Decency Act)
In-Reply-To: <Pine.3.89.9502081213.A7848-0100000@netcom10>
Message-ID: <qAxElKJXYb$E078yn@ssnet.com>



In article <Pine.3.89.9502081213.A7848-0100000 at netcom10>,
"James A. Donald" <jamesd at netcom.com> wrote:
>  (B) by striking out `makes any comment, request,
>         suggestion, or proposal' in subparagraph (A) and inserting
>         `makes, transmits, or otherwise makes available any comment, request,
>                 ^^^^^^^^^^
>          suggestion, proposal, image, or other communication'; 
> 
> This appears to make ISP's responsible for content.
> 
> It makes them responsible for something that they cannot 
> control without violating people privacy.

Plus the processing cost would place a tremendous burden on the 'net.
Transmision goes both ways, not just from the posting machine to the
rest of the world.  Every site 'transmits' every piece of news posted
to the newsgroups they carry.  Every intermediate site, especially
the backbones, 'transmits' email even in not generated from or
addressed to that site.

--
America - a country so rich and so strong we can reward the lazy 
          and punish the productive and still survive (so far)

Don Melvin                  storm at ssnet.com                finger for PGP key.





From erich at CSUA.Berkeley.EDU  Fri Feb 10 15:03:31 1995
From: erich at CSUA.Berkeley.EDU (Erich von Hollander)
Date: Fri, 10 Feb 95 15:03:31 PST
Subject: why pgp sucks
In-Reply-To: <9502102058.AA07955@josquin.media.mit.edu>
Message-ID: <199502102303.PAA24281@soda.CSUA.Berkeley.EDU>


In message <9502102058.AA07955 at josquin.media.mit.edu>, Derek Atkins writes:
>
>> if i use a command like
>> 
>> 	pgp filename
>
>The problem is that you are using the wrong command....

hal pointed out to me that

	pgp -F

will do exactly what i want.  it will work.  the behavior of pgp -F (given
keys, for instance) is not well-described in the docs, but it will do what i
want it to.

as hal said, i can catch the stdout for the data, and catch the stderr for
out-of-band info about the data, and this will work fine.

and the product of all this is going to be quite cool.  i'll post it when
it's finished.

e





From warrior at infinet.com  Fri Feb 10 15:22:12 1995
From: warrior at infinet.com (Dave Harvey)
Date: Fri, 10 Feb 95 15:22:12 PST
Subject: Laws, Feds, & the Internet
In-Reply-To: <199502102211.OAA22129@mail.igc.apc.org>
Message-ID: <Pine.3.89.9502101831.B22980-0100000@rigel>


On Fri, 10 Feb 1995, Richard F. Dutcher wrote:

> 
> The following was in today's San Francisco Chronicle.  BTW, quoting 
> the entire article as I have done is probably a violation of "fair 
> use" - but de minimis ...
> 
> All under *current* law, folks.
> 
> [hmmm -- encryption doesn't do much for exhibitionists and 
> braggarts, does it?  ;-]
> 
> ==============================
[Article Deleted for the sake of Brevity]

Now mind you, this kind of writing is demented, however, what ever
happened to fiction, free speech and such.  At this rate, Steven Spielberg
should be in jail as well.  I thought you had to prove intent, the saying
something or writing it is not bad as long as you didn't have the intent
or present capability to carry out such.  BTW, I like all of Steven
Spielberg's writings and movies, and now HB830 from Oregon rears its head
and fangs.  Did this guy intend to threaten or was it fiction?  How would
they even know? 

Next thing you know they will limit all free speech.

Bummer.

dh
___
            /\  PGP the Cutting Edge of Privacy.
/vvvvvvvvvvvv \-----------------------------------\
| WARRIOR   (  |     PGP Key Id 0XF4D9F5C5          > Magnus Frater Videt Tu
`^^^^^^^^^^^^ /===================================/
            \/  Finger for PGP 2.6.2 public Key.

      PGP Fingerprint 76 6F 4B 56 B1 AC 05 FE  BE 39 9D CC 18 E4 F6 68
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Dave M. Harvey                                       warrior at infinet.com|
| PO Box 151311              	            dharvey at freenet.columbus.oh.us|
| Columbus, OH 43215-8311    	               fm063 at cleveland.freenet.edu|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=








From greg at ideath.goldenbear.com  Fri Feb 10 15:54:49 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Fri, 10 Feb 95 15:54:49 PST
Subject: why pgp sucks
Message-ID: <199502102348.AA09436@ideath.goldenbear.com>


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


Matt Blaze, quoting Greg Morgan, wrote:

> >Doesn't having some kind of central record of keys go against
> >the principle of PGP?  

> The only "principle" of which I'm aware (and particularly interested
> in supporting) is that of having widely fielded, useful and strong
> privacy and authentication tools that work properly and transparently.

I think the centralization/decentralization confusion comes from PGP's
decentralized approach to key generation and authentication, which has
been hailed as a good thing. As long as folks can generate their own
keys, sign their friends' keys, and upload their keys to servers at 
their own discretion, I can't see what would make a centralized or
standardized distribution method harmful.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLzv7I33YhjZY3fMNAQGVbAP/Sm8rXLFDXU4te0mBEhmi6CaAbvHTPqRZ
kce6+auO1T/3ypEi0c0D2QCJ7mS3Xx/g/n42mHhJHzt5ClhuHlhDRyjOV2rGBpWX
OElxuVFpcSIlUnnQ2cvju9k8cDtHnXN+crmmjUXxvqmUB371eyOZ6E140nxfxo2/
JqWBXLFPvpI=
=AL3C
-----END PGP SIGNATURE-----




From hfinney at shell.portal.com  Fri Feb 10 16:29:58 1995
From: hfinney at shell.portal.com (Hal)
Date: Fri, 10 Feb 95 16:29:58 PST
Subject: why pgp sucks
In-Reply-To: <199502102233.RAA02974@crypto.com>
Message-ID: <199502110029.QAA21514@jobe.shell.portal.com>


Matt Blaze <mab at crypto.com> writes:
>More seriously, the problem that Perry brought up is that it's hard
>to deploy any kind of scaleable key distribution infrastructure
>that works with PGP (as it currently exists - and yes, I realize
>there are work-arounds for some specific situations).

Could you have a distributed database where you lookup by key ID and get
a key?  Or is there a constraint that the key distribution infrastructure has
to be part of the DNS?

I could see a set of key servers where one deals with all keys that start
with 0x00, the next has all keys which start with 0x01, etc.  This makes
it easy to know which server to go to in order to look up a given key ID.

Hal





From NSO at delphi.com  Fri Feb 10 17:02:53 1995
From: NSO at delphi.com (Network Security Observations)
Date: Fri, 10 Feb 95 17:02:53 PST
Subject: So, what's it all about?
Message-ID: <01HMWAETLTZ29C1MQQ@delphi.com>


In response to:

> In article <199502100151.RAA25844 at sleepy.retix.com>, you wrote:
> > 
> > >   I went to a UNIX trade show yesterday, and the main speaker was a 
> > >   security type. He talked about "the cypherpunks" among other things.
> > >   He said you are really scary and dangerous and ...
> > >   But of course he had to also project this adress (cypherpunks at toad.com)
> > >   on the screen.
> > can't imagine he is much of a security stud if he is that deluded.
> > what was his name?
> Lance or Vance something.  Rottweiler, maybe?

Can anybody tell me who this ignorant twit might be ? 
A correct name and an email address would help to educate him a bit.

Bertil







From mab at crypto.com  Fri Feb 10 17:11:41 1995
From: mab at crypto.com (Matt Blaze)
Date: Fri, 10 Feb 95 17:11:41 PST
Subject: why pgp sucks
In-Reply-To: <199502110029.QAA21514@jobe.shell.portal.com>
Message-ID: <199502110114.UAA07325@crypto.com>



>Matt Blaze <mab at crypto.com> writes:
>>More seriously, the problem that Perry brought up is that it's hard
>>to deploy any kind of scaleable key distribution infrastructure
>>that works with PGP (as it currently exists - and yes, I realize
>>there are work-arounds for some specific situations).
>
>Could you have a distributed database where you lookup by key ID and get
>a key?  Or is there a constraint that the key distribution infrastructure has
>to be part of the DNS?
>
>I could see a set of key servers where one deals with all keys that start
>with 0x00, the next has all keys which start with 0x01, etc.  This makes
>it easy to know which server to go to in order to look up a given key ID.
>
>Hal

Well, you could do that, but it has the disadvantage that you can't
or control what server a particular key would end up on.  One of the
nice things about DNS-like systems is that a domain is responsible for
providing the resources to provide lookups within it.  If I add a machine
to crypto.com, I add it to the crypto.com name server (plus the secondary
servers, but that's a detail that gets handled automatically).
Everyone knows to come here if they want to resolve a crypto.com name.

In the case of PGP key IDs, you could create an artificial hierarchy
of numbers for the purpose of offloading work among several servers,
but that doesn't solve the hard problem, which is letting _me_ (or my
designee) control (and be responsible for) the distribution of keys in
_my_ domain.  (When someone generates a new key it could end up anywhere
in the kind of hierarchy you described).

I don't think it's clear yet, by the way, that domain names are
the right model for personal key distribution (in particular, it
assumes that keys are being distributed on-line and deals only
awkwardly with semi- off-line clients, as anyone who travels with
a sometimes-networked laptop knows.  It also assumes that the
distribution hierarchy can be mapped atop the lookup keys namespace,
which makes it hard to use for anything that isn't hierarchically
formed).  It's probably one of the important options, though, since
it scales so well and has a successfully fielded history in DNS.

-matt





From jamesd at netcom.com  Fri Feb 10 18:08:13 1995
From: jamesd at netcom.com (James A. Donald)
Date: Fri, 10 Feb 95 18:08:13 PST
Subject: why pgp sucks
In-Reply-To: <9502102110.AA07984@josquin.media.mit.edu>
Message-ID: <Pine.3.89.9502101709.A4566-0100000@netcom10>


On Fri, 10 Feb 1995, Derek Atkins wrote:
> The point is to have a centralized, distributed key distribution
> mechanism, similar in concept to the PGP Public Keyservers, but which
> scale much much better.i

We already have a centralized, for profit, key distribution system.

http://ww.four11.com/InfoServices.html


If they make money off it, there will be more of them, they
will provide better service, and it will in due course
become a distributed key distribution system.

Digression:

I notice that it is possible to have thread titled 
"Why PGP sucks" without Holy Warriors leaping into 
the fray.

This is a marked contrast with certain other topics. 

Possibly the level of heat is inversely proportional
to the level of knowledge.  (I.e. it is safe to have
such a thread title because in this list we have
many people with considerable knowledge of several
different crypto systems, and who have spent 
considerable thought on the various possibilities.)


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From perry at imsi.com  Fri Feb 10 19:10:18 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Fri, 10 Feb 95 19:10:18 PST
Subject: why pgp sucks
In-Reply-To: <199502110029.QAA21514@jobe.shell.portal.com>
Message-ID: <9502110307.AA16138@snark.imsi.com>



Hal says:
> Matt Blaze <mab at crypto.com> writes:
> >More seriously, the problem that Perry brought up is that it's hard
> >to deploy any kind of scaleable key distribution infrastructure
> >that works with PGP (as it currently exists - and yes, I realize
> >there are work-arounds for some specific situations).
> 
> Could you have a distributed database where you lookup by key ID and get
> a key?  Or is there a constraint that the key distribution infrastructure has
> to be part of the DNS?
> 
> I could see a set of key servers where one deals with all keys that start
> with 0x00, the next has all keys which start with 0x01, etc.  This makes
> it easy to know which server to go to in order to look up a given key ID.

Theis will not work, Hal, because it would mean that administrative
control over keys would have to be held by people far removed
organizationally and spacially from those who own them. Things work
much better when the administrators and users are close
together. Futhermore, the DNS style solution scales -- it
automatically aquires servers to meet demand as the space expands,
unlike a pseudo-distributed system such as the one you
propose. Furthermore, DNS is one of the few really large scale
distributed databases that has been well proven, and piggybacking off
the technology has real advantages.

Perry





From warlord at MIT.EDU  Fri Feb 10 19:16:52 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 10 Feb 95 19:16:52 PST
Subject: why pgp sucks
In-Reply-To: <199502110114.UAA07325@crypto.com>
Message-ID: <9502110316.AA29939@toxicwaste.media.mit.edu>


Matt Blaze:
> I don't think it's clear yet, by the way, that domain names are
> the right model for personal key distribution (in particular, it
> assumes that keys are being distributed on-line and deals only
> awkwardly with semi- off-line clients, as anyone who travels with
> a sometimes-networked laptop knows.  It also assumes that the
> distribution hierarchy can be mapped atop the lookup keys namespace,
> which makes it hard to use for anything that isn't hierarchically
> formed).  It's probably one of the important options, though, since
> it scales so well and has a successfully fielded history in DNS.

The idea I've had, and have floated to a few people, is not to
base a distributed keyserver on DNS, but to use DNS as a model
for a distributed key database.  

Hal, yes, you could have a keyID->userID mapping, but that doesn't
scale well.  Let me give you a concrete example (using DNS): I want
the host information for TOXICWASTE.MIT.EDU.  From the root servers I
get to EDU->MIT->TOXICWASTE, and find its IP address (18.85.0.40).
This would be like asking for a key by UserID (warlord at MIT.EDU would
go to the MIT.EDU keyserver).  Now, lets work in reverse, you have
18.85.0.40 and want to get the hostinfo.  In DNS there is a 1-to-1
mapping of Domain to Network.  You _know_ that any machine that is in
18.* will be at MIT, so again you can go to the MIT nameserver for
help.

This doesn't work with PGP KeyID, since the keyID is a random string
of bits.  As a result, you have no way to know that keyID 0xC1B06AF1
should be obtained on the MIT keyserver.  This is the major problem
that Perry is trying to address.  I just don't know of a good way of
doing this, other than maintaining a keyID->userID mapping table
somewhere, but that can become a HUGE flat lookup table!

James said:
> We already have a centralized, for profit, key distribution system.
> 
> http://ww.four11.com/InfoServices.html
> 
> If they make money off it, there will be more of them, they
> will provide better service, and it will in due course
> become a distributed key distribution system.

No offense, James, but this needs to be a free infrastructure.  When
you get your shell account/IP address/PPP drop/etc., you should also
automagically be allocated space in a keyserver.  It shouldn't cost
you anything to be put in it (just like it doesn't cost you anything
to be put in the Telephone White Pages.

The keyservers have to be distributed so that there is a single method
for everyone in the world to connect to the white-page server of their
choice.  I'm sorry, but the WWW is not it.  The WWW does not scale,
and personally if I had to pay to be put on your server, I would
ignore it; I'm perfectly happy using the Public Keyservers.

Just as sites currently provide DNS service for names, they will, in
some time, provide KeyService as well.  It's just a matter of time.

As for the "centralized" part...  I think the distributed part is much
more important.  The public keyserver keyrings are currently over 3MB
and growing.  We need to be able to split that keyring across multiple
servers and have requests go to the appropriate locations.  Yes, there
will be a centralized authority delegator, but the keys themselves, as
well as the means to obtain them, will be distributed.

Enjoy!

-derek





From warlord at MIT.EDU  Fri Feb 10 19:21:16 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Fri, 10 Feb 95 19:21:16 PST
Subject: why pgp sucks
In-Reply-To: <9502110307.AA16138@snark.imsi.com>
Message-ID: <9502110321.AA29986@toxicwaste.media.mit.edu>


The only problem with piggybacking off the current DNS implementation
is that DNS was designed for SMALL pieces of data (read: hostnames and
IP addresses).  PGP keys are HUGE pieces of data, in respect, and DNS
just wont handle the sizes.  For example, my PGP key is about 8k of
data (approximately).  DNS would never be able to handle that!

It its bigger than a single UDP packet DNS has trouble.

No, while DNS is a perfect model for a distributed keyserver,
it is by no means the implementation infrastructure that we want
to use.

-derek





From rfdutcher at igc.apc.org  Fri Feb 10 20:02:39 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Fri, 10 Feb 95 20:02:39 PST
Subject: Laws, Feds, & the Internet
Message-ID: <199502110403.UAA12629@mail.igc.apc.org>


> Date:          Fri, 10 Feb 1995 18:17:55 -0500 (EST)
> From:          Dave Harvey <warrior at infinet.com>
> Subject:       Re: Laws, Feds, & the Internet
> To:            "Richard F. Dutcher" <rfdutcher at igc.apc.org>
> Cc:            cypherpunks at toad.com

> On Fri, 10 Feb 1995, Richard F. Dutcher wrote:
> 
> > 
> > The following was in today's San Francisco Chronicle.  BTW, quoting 
> > the entire article as I have done is probably a violation of "fair 
> > use" - but de minimis ...
> > 
> > All under *current* law, folks.
> > 
> > [hmmm -- encryption doesn't do much for exhibitionists and 
> > braggarts, does it?  ;-]
> > 
> > ==============================
> [Article Deleted for the sake of Brevity]
> 

And David Harvey wrote:

> Now mind you, this kind of writing is demented, however, what ever
> happened to fiction, free speech and such.  At this rate, Steven Spielberg
> should be in jail as well.  I thought you had to prove intent, the saying
> something or writing it is not bad as long as you didn't have the intent
> or present capability to carry out such.  BTW, I like all of Steven
> Spielberg's writings and movies, and now HB830 from Oregon rears its head
> and fangs.  Did this guy intend to threaten or was it fiction?  How would
> they even know? 
> 
> Next thing you know they will limit all free speech.
> 

They *do* have to prove intent -- as to how, that's what juries are 
for.  BTW, he used her real name in the post, with no disclaimers 
about fiction.  From what I have heard, if he had said the same thing 
in her presence, he could have been arrested for assault.

So is saying something that would be actionable in a public space
also actionable in a public cyberspace?  I dunno, and neither does
anyone else.  But it's a well-established principle that a threat is 
a shout of "Fire!" in a crowded theater.

The "Law" is very conservative.  Not like Newt the Grinch, but like 
the Catholic Church -- make the least change necessary to accomodate 
the pressures.  If you've got laws to cover telephones and cybercomm 
looks like telephones, get out the shoehorn.

"Free" speech has always been a balancing act.  The founders
certainly didn't intend to provide "free" speech for blacks and
women.  Our current case law structure is, in large part, the results
of the ACLU's 80-year struggle to prevent a repetition of the
wholesale imprisonment of dissidents during WWI.  Previously, people
were *commonly* tossed in local hoosegows [sp?] at the whim of the
local authorities for speaking out on anything [Quakers, Methodists,
Baptists, temperance, free love, abolition, suffrage, pacifists, 
Romanists, Masons, anti-masons, anarchists, populists, free silver, 
etc. ad nauseum].

"They" have never liked "free" speech ... :-(

Wei Dai has the right idea -- be a specialist, support other 
specialists.  [But keep those cards and letters coming ... ;-]



===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From rsalz at osf.org  Fri Feb 10 21:21:24 1995
From: rsalz at osf.org (Rich Salz)
Date: Fri, 10 Feb 95 21:21:24 PST
Subject: MIME based remailing commands
Message-ID: <9502110516.AA15719@sulphur.osf.org>


>	It doesn't matter if they disagree. If you don't have a To:
>line in the header then "Apparently-To:" gets tacked on using the "To"
>from the envelope.

... And all CC recipient and all BCC recipients as well.
	/r$





From rsalz at osf.org  Fri Feb 10 21:38:27 1995
From: rsalz at osf.org (Rich Salz)
Date: Fri, 10 Feb 95 21:38:27 PST
Subject: Bernstein
Message-ID: <9502110534.AA15867@sulphur.osf.org>


djb at silverton wrote a few crypto thinks, including a cute modification
of the snefru hash that turned it into a crypto scheme called shuffle.

my guess is that he put it out on the net for ftp...  but i guess
we'll all find out when the articles gets published.

djb would make a fun addition to this list.
	/r$





From pcassidy at world.std.com  Fri Feb 10 21:47:10 1995
From: pcassidy at world.std.com (Peter F Cassidy)
Date: Fri, 10 Feb 95 21:47:10 PST
Subject: Bernstein
In-Reply-To: <9502110534.AA15867@sulphur.osf.org>
Message-ID: <Pine.3.89.9502110059.B17884-0100000@world.std.com>


-	I've E-mailed this guy and he has not answered. He may, just by 
some wild twist of fate, have a life and not spend his Friday evenings 
lunging at his terminal every five minutes to check his E-mail.






From dls at mcs.com  Fri Feb 10 22:44:16 1995
From: dls at mcs.com (David Sallach)
Date: Fri, 10 Feb 95 22:44:16 PST
Subject: Laws, Feds, & the Internet
Message-ID: <m0rdBe4-000k50C@mailbox.mcs.com>


>
>"Free" speech has always been a balancing act.  The founders
>certainly didn't intend to provide "free" speech for blacks and
>women.  

        The Founders created a larger space for free speech than had ever
existed.  Slaves were deprived of many freedoms including speech, of course,
but women and free blacks were included in the Bill of Rights and exercised
free speech, frequently compellingly.  

        Check out Frederick Douglass' practicing oration while still a
slave, and then winning his freedom to become one of the greatest
abolitionist orators.  Consider the appreciation of diversity of thought and
speech manifested by Jefferson, Lincoln and many other American political
leaders.
>
> . . . "They" have never liked "free" speech ... :-(

        Invoking poitically 'correct' stereotypes does not strengthen your
argument.

David Sallach
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAy8kkMQAAAEEALKOD1O8IVPKHX2qZa+iRz1gqI+uc5lnPAfGYzBSkKDGDdDO
CpZEsblWUkVNdRq/ac5elFFvLAtege+pgWmIFdtPnDtJRhHRjXUjB+aYwzue5+Xb
C+FoT0j5jwl356gdNiOgUxTYx1dDMcA+VotjDNDvsai3AQaJZU6BpjnLW0KBAAUR
tB5EYXZpZCBMLiBTYWxsYWNoIDxkbHNAbWNzLmNvbT4=
=g/d6
-----END PGP PUBLIC KEY BLOCK-----






From NSO at delphi.com  Fri Feb 10 23:20:30 1995
From: NSO at delphi.com (Network Security Observations)
Date: Fri, 10 Feb 95 23:20:30 PST
Subject: new book pre announcement
Message-ID: <01HMWNKSYO6091RZVR@delphi.com>



ISM/NSO received the manuscript of 'Cryptography: Theory and Practice'
Author is Doug Stinson (Comp. Science/Eng. dept. University of Nebraska).
Publisher is CRC Press Inc.
Pages: 434
Chapters: 13
Format: Hardbound trimmed book 8,5 x 5,5
ISBN: not available yet
Expected release: within 3 months
Price: not available yet

Preliminary review (a full review will be published in Internet Security
Monthly)

The book starts - obvious - with classical cryptography. Hopping from shift
cipher, to substitution, to affine, to vigenere, to hill, to permutation, and
ending in the range of simple cryptosystems with stream ciphers.  A mature
subchapter is devoted to cryptanalysis, covering the affine, the substitution
and the vigenere. And providing a known plaintext attack on the hill cipher. 
The subchapter ends with the cryptanalysis of the LFSR-based stream cipher.  A 
next chapter discusses in depth Shannon's theory. This is followed by the
inevitable discussion of the DES, its modes of operation and includes an
attack on a 3 round DES, and an attack on a 6 round DES.  Chapter 4 discusses
RSA and factoring. Touching also the not much discussed Chinese Remainder
theorem.. The Rabin scheme is reviewed. And within factoring Doug pays
attention to Dixon's Algorithm and the quadratic sieve.  Of course other
public key cryptosystems, as El Gamal, finite field, Merkle Hellman and
McEliece are discussed.  Doug explains signature schemes, as El Gamal and DSS
and touches undeniable and fail-stop. In Hash functions, after the basics,
among others MD4 and timestamping are issues of interest. In key distribution
and key agreement Blom's scheme, D-H, Kerberos, station to station, MIT key
agreement are noteworthy stops.  Another chapter goes into identification
scheme's discussing Schnorr, Okamoto, Guillou-Quisquater, and a general
overview of conversion processes from identification to signature.   In
authentication codes a good discussion on computing deception probabilities,
and combinatorial bounds. In the latter orthogonal arrays are a topic of
interest. Doug also views the entropy bounds on deception probabilities.  A
next chapter introduces the Shamir treshold, the monotone circuit construction 
and Ernie Brickell's vector space, among others.  A separate chapter is
devoted to pseudo-random numbers, giving examples. The indistinguishable
probability distributions and the Blum/Blum/Shub generator are noteworthy.
Extra attention for probabilistic encryption.  As common fur the subject,
close to the end of the book, zero-knowledge proofs are discussed in depth. 

The book is basically organized in three parts: private key cryptography,
public key cryptography and the introduction to four active research area's.
It's comprehensive in the 'core' area's of cryptography. Although
Cryptography: Theory and Practice is a text book, it certainly provides
researchers and practitioners in the field with material on less discussed
topics, and certainly invites for the development of new idea's.  The work
contains also a comprehensive reference section and the good workable index. 
Each chapter ends with exercise material. 

For the reader:
It is necessary to have at least some familiarity with basic linear algebra
and modular arithmetic. 

Compliments to Doug Stinson who sat many hours behind his terminal to get it
all straightened out, and to a professional publisher that is up to the job of 
putting it all 
in print in such a layout that student, researcher and professional are
encouraged. 

11 February 1995
Internet Security Monthly
Network Security Observations
Editorial Office

------
Note: if you want to copy this short review, distribute it on the net, please 
do so at will. This review is not copyrighted.  If you want more information
on the book, consider sending us an email. 
------






From alt at iquest.net  Fri Feb 10 23:27:57 1995
From: alt at iquest.net (Al Thompson)
Date: Fri, 10 Feb 95 23:27:57 PST
Subject: why pgp sucks
Message-ID: <m0rdCF4-000E2cC@dorite.use.com>


>"Perry E. Metzger" <perry at imsi.com> writes:
>>I'll also note, yet again, that unless PGP quits this bad practice of
>>identifying counterparties only by a number, it is NOT going to be
>>universally deployed. Counterparties need to be identified by a name
>>that can be looked up in the DNS -- meaning "joe at foo.com" rather than
>>some key ident number.
>
>PGP of course looks up keys by strings in addition to numbers.  A widely
>accepted practice is to use <joe at foo.com> in the user ID which allows the
>lookups to be by internet address.  PGP was intended for use beyond the
>internet, such as in bbs's, fidonet, corporate networks, etc., where DNS
>style addresses may not be useful.
 
I would prefer that PGP would not give out ANY info about addressees.  It 
would seem to me that it is quite a security breach to have PGP dutifully 
tell you to whom it is addressed.  
 
************************************************************
*           Just your basic signature block                *
*                                                          *
*  Al Thompson                                             *
*  Fidonet 1:231/110                                       *
*  alt at iquest.net                                          *
************************************************************






From rfdutcher at igc.apc.org  Sat Feb 11 01:39:54 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Sat, 11 Feb 95 01:39:54 PST
Subject: Laws, Feds, & the Internet
Message-ID: <199502110940.BAA11278@mail.igc.apc.org>


> Date:          Sat, 11 Feb 1995 01:41:09 -0600
> To:            cypherpunks at toad.com
> From:          dls at mcs.com (David Sallach)
> >
> >"Free" speech has always been a balancing act.  The founders
> >certainly didn't intend to provide "free" speech for blacks and
> >women.  
> 
>  The Founders created a larger space for free speech than had ever
> existed.  Slaves were deprived of many freedoms including speech, of course,
> but women and free blacks were included in the Bill of Rights and exercised
> free speech, frequently compellingly.  
> 
And were frequently thrown in jail for their pains - note especially 
the experiences of the early feminists [anachronistic label alert].  
And let us not forget what happened to the Mormons ...

> Check out Frederick Douglass' practicing oration while still a
> slave, and then winning his freedom to become one of the greatest
> abolitionist orators.  Consider the appreciation of diversity of thought and
> speech manifested by Jefferson, Lincoln and many other American political
> leaders.
> >

And Douglass spent a good portion of his life as a refugee in a 
protected enclave [Boston] where he had powerful friends to keep him 
from being arrested.

I'm not dissing the Founders, or the Bill of Rights -- just the 
simplified pap their invocation in most discourse has become.  I was 
trained in high school as a scientist, and in college as an 
historian, and in both instances to value the messy contingent 
realities over the tempting simplicities of ideology and theory.

And there are few contingent realities messier than the law ...

> > . . . "They" have never liked "free" speech ... :-(
> 
> Invoking poitically 'correct' stereotypes does not strengthen your
> argument.
> 
> David Sallach

Irony-impaired, are we?

There's a Polish word, used by most of the populace after the 1979
coup to refer to the army and apparat, that is usually translated as
"them."  I [probably incorrectly] recall it as "Oni" -- would you
prefer it?

My own first encounter with the term "politically [in]correct" was
among 70's feminists, who used it ironically, to tell people they
needed a vacation/to get laid/to get a grip.  Would that Newt used it 
that way ...


===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From craig at passport.ca  Sat Feb 11 02:49:54 1995
From: craig at passport.ca (Craig Hubley)
Date: Sat, 11 Feb 95 02:49:54 PST
Subject: West (just a minute)
In-Reply-To: <9502102042.AA20803@toad.com>
Message-ID: <m0rdFOe-0002IhC@forged.passport.ca>


Hmm, 
how hard could it be to eliminate West page numbers?

There couldn't be more than a couple of cases on each page, 
if each page number were replaced by links to each case, a
lawyer could tell on the first glance which of the three was
right and mark it, assuming a reasonable HTML/SGML editor or
something.  Seems like it could be done as a part of daily work
and the results accreted somewhere.
-- 
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the Web
craig at passport.ca   416-778-6136  416-778-1965 FAX





From barrett at daisy.ee.und.ac.za  Sat Feb 11 03:16:37 1995
From: barrett at daisy.ee.und.ac.za (Alan Barrett)
Date: Sat, 11 Feb 95 03:16:37 PST
Subject: Bernstein
In-Reply-To: <9502110534.AA15867@sulphur.osf.org>
Message-ID: <Pine.NEB.3.91.950211130522.23367d-100000@daisy.ee.und.ac.za>


> djb at silverton wrote a few crypto thinks, including a cute modification
> of the snefru hash that turned it into a crypto scheme called shuffle.
> my guess is that he put it out on the net for ftp...

I don't think Dan Bernstein made shuffle available, but he did get into a
fight with various branches/departments/agencies of the US government
about his right to publish it.

--apb (Alan Barrett)





From news at visionware.co.uk  Sat Feb 11 03:46:02 1995
From: news at visionware.co.uk (Visionware News)
Date: Sat, 11 Feb 95 03:46:02 PST
Subject: automatic reply to test posting (lwall)
Message-ID: <9502111145.AA16693@wol.visionware.co.uk>



STOP!  Before you panic, read this message through to the end.

This message has been sent to you because you have posted an article to
one of the Usenet test groups (eg alt.test), and it arrived here at
Visionware (visionware.co.uk) on Sat 11 Feb, 11:44 GMT.

If you have not posted an article to one of these groups, then it is
possible that someone else did so while pretending to be you.  If you
are sure that this is the case then ask your Local Help Desk to help
you track down the perpertrator.  It is not possible to track down
forgeries from this site.

Many people like to see copies of the articles that they post, so that
they can see how far (and how quickly) their message has been
transmitted.  Accordingly, you will get at most one email message from
Visionware for each article you post to a *.test newsgroup.  You have
*not* been added to a subscription list.

It is not possible to stop the replies to other messages you may have
already posted, but in FUTURE POSTINGS you can prevent this
autoresponder from replying to you by including a phrase like "don't
reply" or "ignore this message".

This site, visionware.co.uk, is located at Visionware Ltd., which is in
lovely Leeds, West Yorkshire, England (53 48 34 N / 01 34 51 W).

In case you want to know, we're running INN 1.4sec.

We deliberately receive the 'ba' (Bay Area) distribution; this is for
our staff working from Menlo Park CA.


Feel free to send your comments, suggestions, and questions regarding
this auto-reply daemon to the administrator,
postmaster at visionware.co.uk (telephone +44 113 251-2000 and ask for the
System Administrator).  You should get a response to email within a day
or so; if not, then your message has probably not arrived.


Your article, as received here, follows:
> Path: visionware.co.uk!pipex!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
> Subject: lwall
> Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
> NNTP-Posting-Host: ack.berkeley.edu
> Organization: cypherpunks
> Lines: 2
> From: cypherpunks at toad.com
> Distribution: world
> Newsgroups: alt.test
> Date: 6 Feb 1995 19:34:19 GMT
> 
> test
> test
-- 





From perry at imsi.com  Sat Feb 11 05:31:40 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sat, 11 Feb 95 05:31:40 PST
Subject: why pgp sucks
In-Reply-To: <9502110321.AA29986@toxicwaste.media.mit.edu>
Message-ID: <9502111331.AA16528@snark.imsi.com>



Derek Atkins says:
> The only problem with piggybacking off the current DNS implementation
> is that DNS was designed for SMALL pieces of data (read: hostnames and
> IP addresses).  PGP keys are HUGE pieces of data, in respect, and DNS
> just wont handle the sizes.  For example, my PGP key is about 8k of
> data (approximately).  DNS would never be able to handle that!

Well, its already been modified to do it. Read the drafts by Eastlake
and Kaufman on DNS security, which basically means keys in the DNS and
signed DNS records.

> It its bigger than a single UDP packet DNS has trouble.

So you use TCP -- DNS already supports that. In any case, however, the
reassembly size and lowest common denominator MTUs are being jacked
way up for IPv6.

> No, while DNS is a perfect model for a distributed keyserver,
> it is by no means the implementation infrastructure that we want
> to use.

I very strongly disagree. Even today, we find more and more bugs in
DNS. If we had to start from scratch, we'd have to build an
infrastructure like DNS all over again, only to find that we suffer
from all the same old bugs and end up with a parallel implementation
that looks almost exactly like DNS only less reliable.

Perry





From rah at shipwright.com  Sat Feb 11 05:38:43 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Sat, 11 Feb 95 05:38:43 PST
Subject: Privacy vs. Ubiquitous Video: NetCam; Wearable WebCam, etc
Message-ID: <v01510100ab622813b24d@[199.0.65.105]>


Saw this in technomads. Not necessarily crypto, but certainly privacy related...

Cheers,
Bob Hettinga


>Date: Fri, 10 Feb 95 19:11:08 -0500
>From: Steve Mann <steve at media.mit.edu>
>To: technomads at ucsd.edu
>Subject: NetCam; Wearable WebCam, etc
>Cc: steve at media.mit.edu
>
>
>I am an amateur television (ATV) hobbyist, interested in things like
>driving radio-controlled cars using a head mounted display (HMD)
>(which involves putting myself into the ``usual'' perspective
>of the car), or playing tennis with an HMD linked to a stand
>mounted camera (which is exactly the opposite: the radiocar is
>like a flight simulator from the cockpit, while the tennis example
>is like switching to the ``control tower'').  I've also been
>interested in wearable photographic equipment (such as a wearable
>2400J flashlamp I use for ``lightpainting'').
>
>More recently, I've become interested in sending and receiving
>video (and digital stills) over the WWW (e.g. Wearable WebCam,
>and WebCar -- radiocar on the WWW).
>
>I would like to hear from any other ATV hobbyists, people into
>packet radio, and those interested in wearable cameras, and
>combining wearable cameras with wearable computing.  Another
>application I was interested in was wearable vision (e.g. for
>the visually impaired, or simply to augment the regular human
>visual system).
>
>Therefore, I've started a new mailing list, ``netcam at media.mit.edu'',
>to discuss issues related to wearable cameras, as well as communications
>and computation issues associated with wearable cameras.  I am also
>interested in some of the privacy issues associated with wearable
>cameras (as I touch on in http://www-white.media.mit.edu/~steve),
>and the social implications of a society in which there are
>ubiquitous cameras (both wearable and fixed) connected to various
>high speed communications networks.
>
>If you would like to be added to netcam at media.mit.edu, please
>email netcam-request at media.mit.edu
>
>--steve

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From jya at pipeline.com  Sat Feb 11 06:36:15 1995
From: jya at pipeline.com (John Young)
Date: Sat, 11 Feb 95 06:36:15 PST
Subject: NYT on Cybertheft and Sex Writer
Message-ID: <199502111435.JAA26507@pipe1.pipeline.com>


Ralph Blumenthal writes on NYC conference on "cyberthieves" of 
ideas and intellectual property.


For email copy send blank message to <jya at pipeline.com> with 
subject:  TEF_ida


Peter Lewis writes on the U Mich student arrested for posting 
fictional rough sex story.


For email copy, same, with subject:  RIT_xxx



----------

Also, for the famished, these not very fresh tomatoes:


Negroponte writes OpEd piece supporting Newt's idea for a 
laptop in every cave, arguing that it will help with 
international economic competition, especially against those 
countries with the youngest population.  NEG_poo


Peter Lewis writes on PSI's buy of Pipeline.  PSI_pip





From rrothenb at ic.sunysb.edu  Sat Feb 11 07:41:00 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Sat, 11 Feb 95 07:41:00 PST
Subject: Four Horsemen of the Infopocalypse?
Message-ID: <199502111540.KAA05206@libws4.ic.sunysb.edu>



Terrorists, Drug Dealers, Pornography and Piracy (copyright, patent & trademarks)
					  ^^^^^^
That's been left out... and likely it's the one some of the authorities
fear most. Money can be made off of terrorists, drug dealers and pornograpy
by allowing them to exist as a "threat" rather than actually stopping them.

Piracy is a whole different matter (though some would argue that it applies
to allow it as well...)

Off the subject of crypto, though....


Rob




From lee.noon at mgmtsys.com  Sat Feb 11 07:48:51 1995
From: lee.noon at mgmtsys.com (Lee Noon)
Date: Sat, 11 Feb 95 07:48:51 PST
Subject: Not necessarily crypt
Message-ID: <90.84391.1@mgmtsys.com>


  
in message-ID: 
<Pine.LNX.3.91.950209105922.8309A-100000 at chewy.wookie.net> 
slowdog at wookie.net wrote:

SG>On Thu, 9 Feb 1995, Robert Rothenburg Walking-Owl wrote:

SG>> I heard yesterday that someone in the House of Representatives proposed an
  >> amendment to the new crime bill which was soundly defeated it. Turns out t
  >> Amendment was worded exactly as the Fourht Amendment in the Bill 'o Rights
  >> Apparently many a congressman/woman has egg on their face...

SG>Yes indeed, in response to the H666 bill. The Dems placed up for vote the 
  >text of the 4th Amendment without attributing it to be such. It was 
  >defeated. Dems then immediately took to the floor of the House accusing 
  >the Repubs of tryingto dismantle the Constitution.

     Almost all right.  The Dems did acknowledge it was the fourth 
amendment, they drummed on that fact during the debate.  What they 
failed to explain was that the amendment was not offered TO the bill 
but IN PLACE OF the bill.  Even the Republicans failed to properly 
explain this, instead saying it would "gut the bill."
     This bill is not new, people.  It codifies what has been the 
practice in two federal district courts for several years.  The boogie 
man raised most often it the "confidential informant."  The use of a 
bogus CI is illegal.  It is still illegal under this bill.
     The major problem with this bill is it does not add the penalty to 
law enforcement officers for "bad faith actions." This was proposed by 
the republicans last year and ignored by the democrats.  Tis year the 
republicans had the power to push it through and they ignored it.  
Shows how really different they are.
     The "bad faith actions" provision would have made a LEO who 
knowingly generated a search warrant, searched without one without 
probable cause, liable for criminal charges at the federal level.  In 
other words when cop A uses cop B as his evidence for a warrant, and 
cop B lies, cop B goes to jail.  If cop A knew it was a lie, cop A goes 
to jail.  If it results in a shoot out like Waco and lives are lost, he 
goes to jail on murder one charges.  This carries the death penalty for 
a federal offense.  Naturally the one outfit which opposed this the 
most was the BATF, who violates this provision as the preferred way to 
do business.
     It is now up to the senate.  Hopefully Senator Byrd can stop 
taking about his dog long enough to bring these points to the fore.

Lee

                              Lee Noon (lee.noon at mgmtsys.com)

 * 1st 2.00b #3833 * A government can't give back anything it hasn't taken first.





From bdolan at use.usit.net  Sat Feb 11 08:05:24 1995
From: bdolan at use.usit.net (Brad Dolan)
Date: Sat, 11 Feb 95 08:05:24 PST
Subject: Forwarded mail....
Message-ID: <Pine.SOL.3.90.950211105504.18090A-100000@use.usit.net>


Linda does a good job but I frankly didn't believe this when I got it.
So I checked.  Unfortunately, this is true.

Herr Klinton has, by executive order, suspended part of the constitution 
which gives him his powers.  This is not logical, but if he has 
enough guys with guns backing him up, that doesn't matter.

Good luck to you all.  I may occasionally read my mail but from now
on my efforts are going to be focused on getting moved out of this 
hellhole before they "seal the borders." (another project of 
Janet Reno's)

Regards,
Brad Dolan

---------- Forwarded message ----------
Date: Sat, 11 Feb 95 05:06 EST
From: lindat at iquest.net
To: caji at aol.com

Please excuse any duplication to you.  I have not finished sorting out my
lists and only recently figured out the difference between individuals and
newsgroups (and have not yet gotten the names that are already in
newsgroups).  This was too important to wait on me to finish sorting.

***********************  ALERT   ALERT  ************************

WARRENTLESS SEARCHES CAN NOW BE APPROVED BY FREEH, RENO, DOD, ET.
AL. AND CONDUCTED BY ANY FED AGENCY.  DUE TO THE CRIME BILL, THE FED
AGENCIES ARE NOW ALL OPERATING IN CONSOLIDATED "TASK FORCES."

   THIS EXECUTIVE ORDER ***SPECIFICALLY*** APPLIES TO ANYONE USING
            COMPUTER COMMUNICATIONS TO GATHER INFORMATION
              (SEE THE UNDERLYING LAW AT 50 USC 1801.)
              IT MAY ALSO BE USED TO APPLY TO MILITIAS BY THE
              AMBIGUOUS WORDING IN 50 USC 1801 and PL 103-359



                            THE WHITE HOUSE
                     Office of the Press Secretary
___________________________________________________________________
For Immediate Release                              February 9, 1995


                           EXECUTIVE ORDER

                            - - - - - - -
               FOREIGN INTELLIGENCE PHYSICAL SEARCHES


       By the authority vested in me as President by the
Constitution and the laws of the United States, including sections
302 and 303 of the Foreign Intelligence Surveillance Act of 1978
("Act") (50 U.S.C. 1801, et seq.), as amended by Public Law 103-
359, and in order to provide for the authorization of physical
searches for foreign intelligence purposes as set forth in the Act,
it is hereby ordered as follows:

       Section 1.  Pursuant to section 302(a)(1) of the Act, the
Attorney General is authorized to approve physical searches, without
a court order, to acquire foreign intelligence information for
periods of up to one year, if the Attorney General makes the
certifications required by that section.

       Sec. 2.  Pursuant to section 302(b) of the Act, the Attorney
General is authorized to approve applications to the Foreign
Intelligence Surveillance Court under section 303 of the Act to
obtain orders for physical searches for the purpose of collecting
foreign intelligence information.

       Sec. 3.  Pursuant to section 303(a)(7) of the Act, the
following officials, each of whom is employed in the area of
national security or defense, is designated to make the
certifications required by section 303(a)(7) of the Act in support
of applications to conduct physical searches:

       (a) Secretary of State;

       (b) Secretary of Defense;

       (c) Director of Central Intelligence;

       (d) Director of the Federal Bureau of
           Investigation;

       (e) Deputy Secretary of State;

       (f) Deputy Secretary of Defense; and

       (g) Deputy Director of Central Intelligence.

       None of the above officials, nor anyone officially acting in
that capacity, may exercise the authority to make the above
certifications, unless that official has been appointed by the
President, by and with the advice and consent of the Senate.


                         WILLIAM J. CLINTON


  THE WHITE HOUSE,
      February 9, 1995.


******************************************************************************
*  Dr. Linda D. Thompson                  NO JUSTICE, NO PEACE.            *
*  American Justice Federation
*
*  3850 S. Emerson Avenue, Suite E,  Indianapolis, IN 46203             * 
*  Telephone: (317) 780-5203      AEN News BBS: (317) 780-5211      *
*  Fax: (317) 780-5209                 Orders (Visa/MC) 1-800-749-9939   *    
*  Internet:  Lindat at iquest.net
*
*******************************************************************************







From hfinney at shell.portal.com  Sat Feb 11 09:10:27 1995
From: hfinney at shell.portal.com (Hal)
Date: Sat, 11 Feb 95 09:10:27 PST
Subject: why pgp sucks
In-Reply-To: <m0rdCF4-000E2cC@dorite.use.com>
Message-ID: <199502111709.JAA19315@jobe.shell.portal.com>


alt at iquest.net (Al Thompson) writes:
>I would prefer that PGP would not give out ANY info about addressees.  It 
>would seem to me that it is quite a security breach to have PGP dutifully 
>tell you to whom it is addressed.  

PGP could be hacked fairly easily to do this (in fact there is a
program around called stealth that does this to some extent), however
in the context of this discussion we were discussing more the issue of
checking the signature on a file.  For that we do need a hint about
whose signature purports to be there.  PGP presently provides this in
the form of the low-order 64 bits of the key modulus, and this provides
problems in implementing the key database in distributed form.

Hal





From tc at phantom.com  Sat Feb 11 09:14:07 1995
From: tc at phantom.com (Dave Banisar)
Date: Sat, 11 Feb 95 09:14:07 PST
Subject: S314 and potential hell-raising
In-Reply-To: <v0151011cab5f38526c94@[152.97.12.101]>
Message-ID: <Pine.3.89.9502111208.C13529-0100000@mindvox>



 
The ACLU (aslong with us and numerous other groups) are all very aware of 
S. 314. I briefed the Telecommunications policy Roundtable, which is over 
100 public interest groups interested in telecom policy, about it last 
week and we are all gearing up to nail this sucker to the wall before it 
is included in  the telecom bill. If you havent called and screamed at 
your senator and congresscritter, do so now already (202) 224-3121.

-d






From jtender at telerama.lm.com  Sat Feb 11 11:12:23 1995
From: jtender at telerama.lm.com (John Tender)
Date: Sat, 11 Feb 95 11:12:23 PST
Subject: Laws, Feds, & the Internet
Message-ID: <3hj262$32m@africa.lm.com>


"Richard F. Dutcher" <rfdutcher at igc.apc.org> writes:

> They *do* have to prove intent -- as to how, that's what juries are 
> for.  BTW, he used her real name in the post, with no disclaimers 
> about fiction.  From what I have heard, if he had said the same thing 
> in her presence, he could have been arrested for assault.
> 
> So is saying something that would be actionable in a public space
> also actionable in a public cyberspace?  I dunno, and neither does
> anyone else.  But it's a well-established principle that a threat is 
> a shout of "Fire!" in a crowded theater.

How do you know what was in the original post?
Can you post a copy here?


-- 
JT                            "From the purlieus of Pittsburgh"      
jtender at telerama.lm.com      
"Everything must GO"
   





From jtender at telerama.lm.com  Sat Feb 11 11:12:33 1995
From: jtender at telerama.lm.com (John Tender)
Date: Sat, 11 Feb 95 11:12:33 PST
Subject: Laws, Feds, & the Internet
Message-ID: <3hj26d$32o@africa.lm.com>


"Richard F. Dutcher" <rfdutcher at igc.apc.org> writes:

> They *do* have to prove intent -- as to how, that's what juries are 
> for.  BTW, he used her real name in the post, with no disclaimers 
> about fiction.  From what I have heard, if he had said the same thing 
> in her presence, he could have been arrested for assault.

How do yopu know the content of the original post?
Can you post it here?




-- 
JT                            "From the purlieus of Pittsburgh"      
jtender at telerama.lm.com      
"Everything must GO"
   





From lmccarth at ducie.cs.umass.edu  Sat Feb 11 13:41:12 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Sat, 11 Feb 95 13:41:12 PST
Subject: UMich student arrested for rape story
In-Reply-To: <199502110403.UAA12629@mail.igc.apc.org>
Message-ID: <199502112143.QAA12769@ducie.cs.umass.edu>


Rich Dutcher writes:
> They *do* have to prove intent -- as to how, that's what juries are 
> for.  BTW, he used her real name in the post, with no disclaimers 
> about fiction.  From what I have heard, if he had said the same thing 
> in her presence, he could have been arrested for assault.

Based on the NY Times article I've read, you're omitting some important
extenuating circumstances here. For one thing, it was apparently posted to
alt.sex.stories, which seems to obviate the use of "fictional" disclaimers.
Furthermore, he did _not_ identify her as a UMich student.

I don't see the relevance of "if he had said the same thing in her presence".
He *didn't* !  There's an enormous difference between making a comment about
a person to third parties, and making the comment to that person.

According to the NY Times story, the woman mentioned in the story only heard
about it because reporters asked her about it !  I find a great deal of irony
in the report that the controversy started because an alt.sex.stories reader
in _Moscow_ tipped off the UMich authorities.

It appears that the Russians are allowed to read erotic fiction, while the
Americans are forbidden to read it, and get tossed in jail for writing it.
We've come a long way, baby. Yeah.

 -L. Futplex McCarthy; PGP key by finger or server   "The objective is for us 
  to get those conversations whether they're by an alligator clip or ones and 
  zeroes. Wherever they are, whatever they are, I need them." -FBI Dir. Freeh




From lmccarth at ducie.cs.umass.edu  Sat Feb 11 13:47:32 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Sat, 11 Feb 95 13:47:32 PST
Subject: NYT on Cybertheft and Sex Writer
In-Reply-To: <199502111435.JAA26507@pipe1.pipeline.com>
Message-ID: <199502112149.QAA12793@ducie.cs.umass.edu>


John Young writes:
> Peter Lewis writes on the U Mich student arrested for posting 
> fictional rough sex story.

Thanks once again for making this material available, John.

I must object to your thumbnail sketch of this story, though. The story as
described in the NY Times article does not involve "rough sex" -- it involves
rape, and the distinction is crucial.





From wessorh at ar.com  Sat Feb 11 13:49:58 1995
From: wessorh at ar.com (Rick H. Wesson)
Date: Sat, 11 Feb 95 13:49:58 PST
Subject: "Being Digital" spinde
Message-ID: <199502112143.NAA03166@ar.com>


I thought you guy's would enjoy this...

I found out Nicholas Negroponte, the author of 
"being Digital" encoded a message in the spine of the book
all ones and zeros. It's a decent book, and not 
much about crypto except for the spine. 

I made a text file mof the 1260 bits on the spine.

a sample perl script is included to grab the bits.

Next mont's issue of wired is supposed to have 
a discussion about the spine and the encrypted messages.

the only hint I've got is:
   000 000 111

I know how you guys love this stuff, he says it's 
(the code) is unbreakable...

-Rick


========================= Cut Here ==========================
begin 644 bd.tar.gz
M'XL("%HL/2\``V)D+G1A<@#M5E%OVS80]FOX*VYQ at +9`9Y&6:6W(NCUM0X"A
M#WL;NJV0+#H6HDB"*,,-ANVWC^3=41Z&[LT9T/(+8H>ZTW=WW]T1J>IL<6G`
M1A9:PP(`U`:_0:WQ&R$!=*&*]7JKUKDSREQO%Z`OGIG#T4[E"+`X&6O[\?!1
M/^>VWS]'0L^+JLZJ>C6TEXRAY'_W?UW$_NLBWSJCR at NY`'G)I!B?>?^77V1'
M.V9MORO;K&JZ;#!C*X1OR\T/=S]]#V_ at V@U(74[7M^%I/YCNI;>\NA7BZJ:R
MWH-LIT/3FI??>.NWK_X05YWY,$&SA^SW97:+SJLW</,>O?_$*)[A+[#9KUV6
M/=ZC:=?VUG`4_P`S&L:FF_P;M^+_UNU3`>Z_:^\%8[C]WVXV']W_/-=KWO^\
MV$B__SHOTOX_!Y9B"?NQ?X3I8,`.36>@W[N5-TUW#W5SWTQE>PW5$[QM=H>^
M+2V\-?=C/_236;E7`9H)1E.V3S`TUAH+CYY@[ZX"T\$=',H:IA[JWO$W%J93
MLS.K%;[Y2W]T&]V755FYUT^E6VWGNCN8W4/P?@UWDP53VB?_?!K+S@[N6 at BV
M0&"GXWZ_ at A_'_CB8&IK.3U7E$^I/[FWMOZ%R5]N#.ZGU5GJCQ>!7[UQ1D\NW
M[KL7$YSZ\>&UTL5*X^/OX+?@]N7/S>Y!+/T/:"&5DFZ8PX=PO^Y/%1X)&4XR
M6-D2CB*X*#PZ$O^$'=TS@>\K-!,U4RI%)"JX<73/H at 4:Z0DE$CR$8G:%P2@$
MICQ3+F&-09`%BY@/S.\A,$>L2A!%^/(LFL)CF501%:%8(L6Z<,HLDL)<<BDD
MRR2Q8"*B\BA3;^$\HV(8SK-H,8=0F+>D0(*K42PHIR#4G*1GV9#XL[JLHI*Q
MB)D?_6;=)>JR";EPWF=2^"(XME+_5!=UX1A^Z*3@#N(XL6K>5_ZK+5@$L=#9
MLV at 115&2IH+JB(*&(KB5;(GSXUBV..<\%W&VL`A.9!X1*H*[JK!'6RVBV-1/
MCLZ=X$['),_+PWDI:(^H$C938G%;@M1Q5<Y&$',I-(@H&D9ADMA0/`EVB6--
M%I_,5SQ<M'3Q`I@/5#XUC,8Z*H\L6K":9(["D?#T(7@@%.TF#5`HZ6MYM@*2
M#UQ$7)=0'@^,I'6G9#R+GFM4?&?Q;<`33[EP'^39;JHP=DK&Q&E%J+5*\@J>
MC?(\A(H74A*-IHGE^L_O#LG7)(U!U.;\"E,B_<>8D)"0D)"0D)"0D)"0D)"0
3D)"0D)"0D/"9X&_^(G<;`"@``(U!
`
end





From A5113643667 at attpls.net  Sat Feb 11 13:53:51 1995
From: A5113643667 at attpls.net (Tom Jones)
Date: Sat, 11 Feb 95 13:53:51 PST
Subject: Does PGP scale well?
Message-ID: <9811968B>


Perry has repeated a litany here that I have been hearing for years on
the pem-dev list with never a hint of a justification.  That is that
PGP does not scale well.

One of the reasons that I consider this to be untrue is my empirical
experience with two groups that are constantly interested in exactly
who I am: the government and the credit bureaus.  They both chose to
use my SSN even though that has all the same attributes of a KeyID,
except that it is somewhat denser.  Now if this is what happens when
the real world tries to identify me, why is the KeyID such a bad way to
identify keys?

Please note that I do understand that identifying me and finding me are
separate issues.  I'm not sure that the pem-dev folk clearly
discriminate these.

Peace. Tom







From jrochkin at cs.oberlin.edu  Sat Feb 11 14:26:05 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Sat, 11 Feb 95 14:26:05 PST
Subject: Does PGP scale well?
Message-ID: <ab62e915050210045172@[132.162.201.201]>


At 4:53 PM 02/11/95, Tom Jones wrote:
>One of the reasons that I consider this to be untrue is my empirical
>experience with two groups that are constantly interested in exactly
>who I am: the government and the credit bureaus.  They both chose to
>use my SSN even though that has all the same attributes of a KeyID,
>except that it is somewhat denser.  Now if this is what happens when
>the real world tries to identify me, why is the KeyID such a bad way to
>identify keys?

It seems like it might be important to note, however, that the government
identification systems are definitely _centrazilized_ modes of information
storage and distribution.  Credit buearues are less obviously centralized,
but still perhaps centralized.  And it could be argued that credit bureaus
would never have used a system like social security numbers for
identification if it hadn't already been in widespread use in the
centralized governmental systems which created it.

This is in sharp contrast to the decentralized mode that we want our
encryption and authorization to function in.  This is for
anti-authoritarian reasons, as well as simply practical reasons.  When the
government is involved, it can mandate that everyone use the system they
are in control of, and they can get the neccesary manpower to actually
implement a centralized system too.  But we don't want to have to trust any
one authority, and we also want a system where everyone does their own work
(like DNS, where every domain has it's own server), if possible.

Conventional wisdom is that PGP is inherently decentralized, and it is, in
a sense, and in it's current web-of-trust model.  But a
social-security-number model of key distribution would definitely _not_ be
centralized.  You are assigned your social security number by a central
authority, and others can look up your social security number by consulting
with that central authority, or with other authorities that have themselves
consulted with the central authority.  That's not a model most of us think
desirable for PGP key distribution.

[It also could be noted that a SSN has some contained meaning, where a PGP
keyid doesn't.  The prefixes on your SSN say what state (and maybe even
what county, I'm not sure) you were born in.  But generally this isn't very
useful information, so this probably isn't an important point.]







From perry at imsi.com  Sat Feb 11 14:38:00 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sat, 11 Feb 95 14:38:00 PST
Subject: Does PGP scale well?
In-Reply-To: <9811968B>
Message-ID: <9502112237.AA17845@snark.imsi.com>



Tom Jones says:
> Perry has repeated a litany here that I have been hearing for years on
> the pem-dev list with never a hint of a justification.  That is that
> PGP does not scale well.

I've given plenty of justification. You can't reverse map keys. Isn't
that bad enough?

> One of the reasons that I consider this to be untrue is my empirical
> experience with two groups that are constantly interested in exactly
> who I am: the government and the credit bureaus.  They both chose to
> use my SSN even though that has all the same attributes of a KeyID,
> except that it is somewhat denser.

Ahem.

Next you'll tell us that the hosts.txt database was a great idea and
you see no reason why we should have built the DNS. After all, host
addresses are only 32 bits, so the problem of mapping them into
hostnames should be easy to do in a flat database, right?

If you'd like to volunteer to run the centralized databases containing
the (at least) five billion keys for the population of the planet,
including handling tens to hundreds of billions of hits against them
per day, and probably tens of millions of updates per day (perhaps
you'd like us to enter them by hand, too?) and you'd like to supply
this service for free, then we will certainly be willing to talk.

Until you volunteer, however, leave the engineering to the people with
some experience in building large scale systems?


Perry

(Sure, TRW can store 100 million records in a giant database and index
them purely by a single unstructured number. 'taint cheap or fast,
however, and it certainly isn't amenable to decentralized maintainance
of the data.)





From CCGARY at MIZZOU1.missouri.edu  Sat Feb 11 15:26:37 1995
From: CCGARY at MIZZOU1.missouri.edu (Gary Jeffers)
Date: Sat, 11 Feb 95 15:26:37 PST
Subject: Secure Drive ver. & loc. ?
Message-ID: <199502112322.SAA09620@bb.hks.net>


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

Dear Cypherpunks,
   Does anyone know where the latest version of SECURE DRIVE really is
& what the latest version is?
                                           Yours Truly,
                                           Gary Jeffers
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz1GuyoZzwIn1bdtAQFCrwF/ZH4w9VdubpZRH8JPRDm+N56aMNVg3riW
EcVCDcsWaTUUqFB8E1fazTfJSL2mAgEP
=eE7u
-----END PGP SIGNATURE-----





From abacard at well.sf.ca.us  Sat Feb 11 15:43:45 1995
From: abacard at well.sf.ca.us (Andre Bacard)
Date: Sat, 11 Feb 95 15:43:45 PST
Subject: Feb 15th Meeting About PGP
Message-ID: <199502112343.PAA13759@well.sf.ca.us>


-----BEGIN PGP SIGNED MESSAGE-----
 
The Electronic Frontier Foundation <info at eff.org> will meet on
Wednesday, February 15th at the WIRED magazine <info at wired.com>
office in San Francisco. John Gilmore and Cindy Cohn will discuss
the constitutional implications of export controls on cryptography.
This topic relates directly to PGP.
 
Attached you'll discover complete details about this meeting --
which I've borrowed from the EFFector, EFF's online newsletter. I
hope to see you Wednesday!
 
***************************************************************
Andre Bacard,              Bacard wrote "The Computer Privacy
Stanford, California       Handbook: A Practical Guide to E-Mail
abacard at well.com           Encryption, Data Protection, and PGP
                           Privacy Software" [for novices/experts].
 
Introduction by Mitchell Kapor, co-Founder of Electronic Frontier
Foundation and creator of Lotus 1-2-3.
 
          +++ Book forthcoming. Write for details. +++
*****************************************************************
 
 
Subject: EFF SF Bay Area Meetings Announced
- -------------------------------------------
 
EFF is pleased to introduce a series of monthly `BayFF' meetings in
the San Francisco Bay Area.  All EFF members, guests, and the
public are invited.
 
The first meeting will be in San Francisco on February 15, 1995, at
7:30PM.  The gracious donor of our first meeting place is:
 
        Wired Magazine
        520 Third Street, Fourth Floor
        San Francisco, CA
        +1 415 222 6200  voice
 
John Gilmore and Cindy Cohn will speak on the constitutional issues
around export controls on cryptography.  John is a co-founder of
EFF and Chair of the EFF Board's Crypto Committee.  Cindy is an
attorney in private practice at McGlashen and Sarrail in San Mateo. 
These controls inhibit free speech, publication of software and
papers, academic freedom of inquiry, and personal privacy, as well
as having a strong negative impact on computer security.  We'll
explore some of the implications and prospects for change.
 
Dave Farber will speak on "Living in the Global Information
Infrastructure -- some concerns".  Dave is an EFF Board member and
has more years of experience in computers and networking than the
total experience at many startup companies.  Vice President Gore
has proposed that the nations of the world undertake the building
of a Global Information Infrastructure -- the GII.  While most
leaders agree with the sprit of the Gore proposal -- namely to
provide a mechanism which could invigorate the world economy in the
forthcoming information age, many disagree with his belief that it
will bring democracy to the world.  They interpret such statements
as being another example of American colonialism.  It is this basic
lack of uniform global agreement on what terms mean, what rules
apply to electronic commerce and what impact a GII will have on
their nation that underlies the comments Dave will make.  These
raise questions about the universality of Cyberspace.  He will seek
to table a set of questions that may  stimulate your thinking in
this area.
 
There will also be plenty of time for general and specific
questions, issues, discussion, meeting people, and socializing with
frontier- minded folks.
 
 
-----BEGIN PGP SIGNATURE-----
Version: 2.7
 
iQCVAwUBLz04Y96pT6nCx/9/AQF4CQP9EsOJdzn75G+5mG73nX/URpina5K58rIW
marI385hS/66wqMDNlsRZ3d8VxCAFp7SPgO7XiajMMrNDTPEpAQjvqU233R2k3aP
Yk19xNnIKisL8rBTmNw0r8eoH8dI+4/XqnDP3GOmf2nTq9Y/P9hVwtVqH9vpCaVD
CjloHxczOwY=
=4imy
-----END PGP SIGNATURE-----





From nobody at nately.UCSD.EDU  Sat Feb 11 16:37:02 1995
From: nobody at nately.UCSD.EDU (Anonymous)
Date: Sat, 11 Feb 95 16:37:02 PST
Subject: TEMPEST Paper by Former Civilian (2/2)
Message-ID: <9502120040.AA14089@nately.UCSD.EDU>



                                IV. CANADIAN LAW
               Canada has taken direct steps to limit eavesdropping on
          computers.    The Canadian  Criminal  Amendment Act  of 1985

          _____________________              

          22.  Interception of Communications Act 1985    1, Prohibition on
          Interception:
               (1) Subject to the  following provisions of this section,  a
               person who  intentionally intercepts a communication  in the
               course of its  transmission by post or by  means of a public
               telecommunications system shall be guilty  of an offence and
               liable--
                    (a) on summary  conviction, to a fine not exceeding the
                    statutory maximum;
                    (b) on conviction on indictment,  to imprisonment for a
                    term not exceeding two years or to a fine or to both.
               ***

          23.  Tapping  (aka  trespassatory eavesdropping)  is  patently in
          violation  of the statute.  "The  offense created by section 1 of
          the Interception of Communications Act 1985 covers those forms of
          eavesdropping on computer communications  which involve "tapping"
          the wires along  which messages  are being passed.   One  problem
          which  may  arise,  however,  is  the  question  of  whether  the
          communication in question  was intercepted in  the course of  its
          transmission by  means of a public telecommunications system.  It
          is technically possible  to intercept a communication  at several
          stages in its transmission,  and it may be a question  of fact to
          decide the stage  at which it enters the "public" realm.  THE LAW
          COMMISSION,WORKING PAPER NO. 110: COMPUTER MISUSE,  3.30 (1988). 

          24.  "There are  also forms of  eavesdropping which the  Act does
          not cover.  For  example. eavesdropping on a V.D.U.  [referred to
          in  this text as a CRT] screen  by monitoring the radiation field
          which surrounds it  in order to  display whatever appears on  the
          legitimate  user's  screen on  the  eavesdropper's screen.   This
          activity would not  seem to  constitute any criminal  offence..."
          THE LAW COMMISSION, WORKING PAPER NO. 110: COMPUTER MISUSE,  3.31
          (1988).

<New Page>
          criminalized indirect access  to a computer service.[25]   The
          specific reference  to an  "electromagnetic device"  clearly
          shows the intent  of the legislature  to include the use  of
          TEMPEST ELINT equipment within the ambit of the legislation.
               The limitation of obtaining "any computer service" does
          lead to  some confusion.   The Canadian legislature  has not
          made  it  clear  whether  "computer  service"  refers  to  a
          computer  service  bureau  or  merely   the  services  of  a
          computer.    If  the  Canadians  had  meant  access  to  any
          computer,  why  did they  refer  to any  "computer service".
          This   is   especially   confusing   considering   the   al-
          encompassing language  of (b)  'any function  of a  computer
          system'.
               Even   if   the   Canadian   legislation   criminalizes
          eavesdropping  on  all  computers,  it  does not  solve  the
          problem  of  protecting  the privacy  of  information.   The
          purpose  of  criminal law  is  to control  crime.[26]   Merely
          making  TEMPEST  ELINT  illegal will  not  control  its use.
          First, because  it  is an  inherently  passive crime  it  is
          impossible to detect and hence punish.  Second, making  this
          form of  eavesdropping  illegal without  taking a  proactive
          stance  in  controlling  compromising emanations  gives  the
          public a false sense of security.   Third, criminalizing the
          possession of a TEMPEST ELINT  device prevents public sector
          research into countermeasures.   Finally,  the law will  not
          prevent eavesdropping on private information held in company
          computers unless  disincentives are given for companies that
          do not take sufficient precautions against eavesdropping and
          simple, more common, information crimes.[27]
          _____________________              

          25.   301.2(1) of the  Canadian criminal code states  that anyone
          who:

          ... without color of right,
          (a) obtains, directly or indirectly, any computer service,
          (b)  by  means  of  an  electromagnetic  ...   or  other  device,
          intercepts  or  causes  to  be  intercepted, either  directly  or
          indirectly, any function of  a computer system ... [is  guilty of
          an indictable offence].

          26.  UNITED   STATES   SENTENCING   COMM'N,  FEDERAL   SENTENCING
          GUIDELINES MANUAL (1988) (Principles  Governing the Redrafting of
          the Preliminary Guidelines "g." (at an unknown page)) 

          27.  There has been great debate over  what exactly is a computer
          crime.    There  are  several  schools  of  thought.    The  more
          articulate school, and the one to  which the author adheres holds
          that  the category  computer crime  should be  limited to  crimes
          directed against computers; for example, a terrorist destroying a
          computer  with explosives would fall into  this category.  Crimes
          such as  putting  ghost  employees  on  a  payroll  computer  and

<New Page>

                                  V. SOLUTIONS
               TEMPEST ELINT  is passive.   The  computer or  terminal
          emanates  compromising radiation which is intercepted by the
          TEMPEST device  and reconstructed  into useful  information.
          Unlike conventional  ELINT there  is no  need to  physically
          trespass or even come near the target.  Eavesdropping can be
          performed from a nearby office or even a van parked within a
          reasonable distance.   This means  that there is  no classic
          scene of the crime; and little or  no chance of the criminal
          being discovered in the act.[28]  
               If the crime is discovered it will be ancillary to some
          other  investigation.    For example,  if  an  individual is
          investigated for insider  trading a search of  his residence
          may yield a TEMPEST ELINT device.   The device would explain
          how the defendant was obtaining  insider information; but it
          was the insider trading, not the  device, that gave away the
          crime.
               This  is  especially  true  for illegal  TEMPEST  ELINT
          performed by the state.  Unless the perpetrators are  caught
          in the act  there is  little evidence  of their  spying.   A
          trespassatory bug can be detected and located; further, once
          found it provides tangible evidence that a crime took place.
          A TEMPEST ELINT device by its inherent passive nature leaves
          nothing to detect.   Since the government is less  likely to
          commit an ancillary crime which might be detected there is a
          very small chance  that the spying will  ever be discovered.
          The  only way to  prevent eavesdropping is  to encourage the
          use of  countermeasures: TEMPEST  Certified[29] computers  and
          _____________________              
                                                                           
          collecting their pay are merely  age-old accounting frauds; today
          the  fraud involves a computer because  the records are kept on a
          computer.  The  computer is merely ancillary to  the crime.  This
          has been mislabeled  computer crime and should merely be referred
          to as a fraud perpetrated with  the aid of a computer.   Finally,
          there are information  crimes.  These  are crimes related to  the
          purloining or  alteration of information.  These  crimes are more
          common and more profitable due to  the computer's ability to hold
          and access great amounts of information.   TEMPEST ELINT can best
          be categorized as a information crime.

          28.  Compare, for  example, the  Watergate breakin  in which  the
          burglars  were discovered  when they  returned to  move  a poorly
          placed spread spectrum bug.

          29.  TEMPEST Certified refers  to the  equipment having passed  a
          testing and  emanations regime specified  in NACSIM 5100A.   This
          classified document sets forth the emanations levels that the NSA
          believes digital equipment can give  off without compromising the
          information it  is processing.   TEMPEST  Certified equipment  is
          theoretically secure against TEMPEST eavesdropping.  

<New Page>
          terminals.
               In merely making  TEMPEST ELINT  illegal the public  is
          given the  false impression  of security;  they lulled  into
          believing  the  problem  has been  solved.    Making certain
          actions illegal does not prevent them  from occurring.  This
          is  especially  true  for  a  TEMPEST  ELINT  because it  is
          undetectable.  Punishment is an empty  threat if there is no
          chance of being  detected; without detection there can be no
          apprehension and conviction.   The only way  to prevent some
          entity  from eavesdropping  on  one's  computer or  computer
          terminal is  for the equipment not to  give off compromising
          emanation; it must be TEMPEST Certified.
               The United  States can solve  this problem by  taking a
          proactive  stance on compromising  emanations.  The National
          Institute of Standards and Technology  (NIST[30]) is in charge
          of  setting  forth standards  of  computer security  for the
          private  sector.   NIST  is  also charged  with  doing basic
          research to advance the art of computer security.  Currently
          NIST does not discuss TEMPEST with  the private sector.  For
          privacy's sake,  this policy must be changed  to a proactive
          one.  The NIST should publicize  the TEMPEST ELINT threat to
          computer  security and  should set  up a  rating system  for
          level  of  emanations  produced   by  computer  equipment.[31]
          Further,  legislation  should  be  enacted  to  require  the
          labeling  of  all computer  equipment    with  its level  of
          emanations and whether it is TEMPEST Certified.  Only if the
          public  knows of the  problem can it begin  to take steps to
          solve it.
               Title III makes  possession of a surveillance  device a
          crime,  unless  it   is  produced  under  contract   to  the
          government.  This means that  research into surveillance and
          counter-surveillance   equipment   is  monopolized   by  the
          government and a  few companies working under  contract with
          _____________________              
                                                                           
               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. 

          30.  Previously the Bureau of Standards.   The NIST is a division
          of the Commerce Department.

          31.  In this case computer equipment would include all peripheral
          computer equipment.  There is no use is using a TEMPEST Certified
          computer if the printer or the modem are not Certified.

<New Page>
          the government.   If TEMPEST eavesdropping  is criminalized,
          then possession of TEMPEST ELINT equipment will be criminal.
          Unfortunately,this  does  not  solve the  problem.    Simple
          TEMPEST ELINT  equipment is easy  to make.   For just  a few
          dollars  many  older  television  sets  can be  modified  to
          receive and  reconstruct  EMR.    For less  than  a  hundred
          dollars a more  sophisticated TEMPEST ELINT receiver  can be
          produced[32].  
               The  problem  with  criminalizing  the  possession   of
          TEMPEST ELINT equipment is  not just that the law  will have
          little effect on the use of such equipment, but that it will
          have a  negative effect  on counter-measures  research.   To
          successfully   design   counter-measures  to   a  particular
          surveillance  technique  it  is  vital  to have  a  complete
          empirical  understanding   of  how  that   technique  works.
          Without  the right  to  legally manufacture  a  surveillance
          device there is no possible way for a researcher to have the
          knowledge to  produce an effective  counter-measures device.
          It  is  axiomatic:  without  a  surveillance device,  it  is
          impossible to test a counter-measures device.  
               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
          _____________________              

          32.  The  NSA  has tried  to  limit the  availability  of TEMPEST
          information to prevent the spread of the devices.
               For a discussion of the  First Amendment and prior restraint
          See, e.g. The United  States of America v. Progressive,  Inc. 467
          F.Supp 990 (1979, WD Wis.)(magazine intended to publish plans for
          nuclear  weapon; prior  restraint injunction  issued),  reh. den.
          United States v. Progressive  Inc. 486 F.Supp 5 (1979,  WD Wis.),
          motion  den  Morland  v. Sprecher  443  US  709 (1979)(mandamus),
          motion denied  United States  v. Progressive,  Inc. 5  Media L  R
          (1979, 7th Cir.), dismd. without op. U.S. v. Progressive, Inc 610
          F.2d 819 (1979, 7th Cir.); New York Times, Co. v.  United States,
          403  U.S.  713 (1971)(per  curium)(Pentagon Papers  case: setting
          forth prior  restraint standard  which government  was unable  to
          meet); T.  EMERSON, THE SYSTEM  OF FREEDOM OF  EXPRESSION (1970);
          Balance  Between Scientific  Freedom  and  NAtional Security,  23
          JURIMETRICS  J. 1  (1982)(current  laws and  regulations limiting
          scientific and  technical expression exceed the  legitimate needs
          of national security); Hon. M.  Feldman, Why the First  Amendment
          is not Incompatible  with National Security, HERITAGE  FOUNDATION
          REPORTS (Jan.  14, 1987).  Compare Bork,  Neutral Principles  and
          Some First Amendment Problems,  47 IND. L. J. 1  (First Amendment
          applies only to  political speech); G.  Lewy, Can Democracy  Keep
          Secrets, 26  POLICY REVIEW 17  (1983)(endorsing draconian secrecy
          laws mirroring the English system).

<New Page>
          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.

               Even if the  laws allow ownership of  TEMPEST Certified
          equipment by the public, and even  if the public is informed
          of  TEMPEST's   threat  to  privacy,   individuals'  private
          information will not necessarily  by protected.  Individuals
          may  choose to  protect their  own information on  their own
          computers.  Companies  may choose  whether to protect  their
          own  private  information.    But  companies that  hold  the
          private information of  individuals must  be forced to  take
          steps to protect that information.
               In  England  the  Data  Protection  Act 1984[34]  imposes
          sanctions   against   anyone   who   stores   the   personal
          information[35] on  a computer  and fails  to take  reasonable
          _____________________              

          33.  For  example, the  NSA has  just recently  allowed the  Drug
          Enforcement Agency (DEA) to  purchase TEMPEST Certified  computer
          equipment.    The DEA  wanted  secure computer  equipment because
          wealthy  drug   lords  had   were  using   TEMPEST  eavesdropping
          equipment.

          34.  An  Act  to  regulate  the  use of  automatically  processed
          information relating to individuals and the provision of services
          in respect of such information.
               -Data Protection Act 1984, Long Title.

          35.  "Personal data"  means data consisting  of information which
          relates to a  living individual who  can be identified from  that

<New Page>
          measures to prevent disclosure of that information.  The act
          mandates  that  personal  data  may  not  be  stored  in any
          computer  unless  the  computer bureau  or  data  user[36] has
          registered under the  act.[37]    This provides for a  central
          registry  and  the tracking  of  which companies  or persons
          maintain databases of personal information.   Data users and
          bureaux must  demonstrate a  need and  purpose behind  their
          possession of personal data.
               The act  provides tort  remedies to  any person  who is
          damaged by disclosure  of the  personal data.[38]   Reasonable
          care to  prevent the  disclosure  is a  defense.[39]   English
          _____________________              
                                                                           
          information (or from that and other information in the possession
          of the data user), including any  expression of opinion about the
          individual but not any  indication of the intentions of  the data
          user in respect of that individual.
               -Data Protection Act 1984   1(3)

          36.  "Data user" means  a person  who holds data,  and a  persons
          "Holds" data if --
               (a) the data form part of a collection of  data processed or
               intended to be  processed by or on behalf  of that person as
               mentioned in  subsection (2) above; [subsection  (2) defines
               "data"] and
               (b) that person (either  alone or jointly or in  common with
               other persons)  controls the  contents and  use of  the data
               comprised in the collection; and
               (c) the data are in the form in which  they have been or are
               intended to be processed as mentioned in paragraph (a) above
               or (though not  for the time being  in that form) in  a form
               into which they have been converted after being so processed
               and  with  a  view  to  being  further  so  processed  on  a
               subsequent occasion.
               - Data Protection Act   1(5).

          37.  Data Protection Act 1984,   4,5.

          38.  An individual who is the subject of personal data held  by a
          data user... and who  suffers damage by reason of  (1)(c) ... the
          disclosure of the  data, or  access having been  obtained to  the
          data without  such authority as  aforesaid shall  be entitled  to
          compensation from  the data  user... for any  distress which  the
          individual has  suffered  by  reason of  the  ...  disclosure  or
          access.
               - Data Protection Act 1984   23.

          39.  ... it shall  be a defense to  prove that ... the  data user
          ...  had  taken  such  care  as  in  all  the  circumstances  was
          reasonably required  to prevent  the... disclosure  or access  in
          question.
               Data Protection Act 1984   23(3)

<New Page>
          courts  have not yet  ruled what level  of computer security
          measures  constitute  reasonable  care.     Considering  the
          magnitude of invasion possible with  TEMPEST ELINT it should
          be  clear  by now  that  failure  to use  TEMPEST  Certified
          equipment is prima facie unreasonable care.
               The Remedies section of the  act provides incentive for
          these  entities to provide  successful protection  of person
          data from disclosure  or illicit access.  Failure to protect
          the data will  result in monetary loss.  This  may be looked
          at from the economic efficiency  viewpoint as allocating the
          cost  of  disclosure the  persons  most able  to  bear those
          costs, and also most able to prevent disclosure.  Data users
          that  store   personal  data  would  use  TEMPEST  Certified
          equipment as part of their computer security plan, thwarting
          would-be eavesdroppers.  
               The Data Protection  Act 1984  allocates risk to  those
          who can  bear it best and provides  an incentive for them to
          keep other  individuals' data private.   This act  should be
          adopted by the United States as part of a full-spectrum plan
          to combat TEMPEST eavesdropping.  Data users are in the best
          position  to  prevent  disclosure  through  proper  computer
          security.    Only by  making  them  liable for  failures  in
          security can we begin to rein in TEMPEST ELINT.

                                       VII
                                 Recommendations
                 Do not  criminalize TEMPEST ELINT.   Most crimes that
          TEMPEST ELINT would aid, such a insider trading, are already
          illegal; the current laws are adequate.
                 The  National Institute of  Standards and  Technology
          should immediately begin  a program  to educate the  private
          sector about TEMPEST.  Only if  individuals are aware of the
          threat  can  they  take  appropriate precautions  or  decide
          whether any precautions are necessary.
                   Legislation  should  be   enacted  to  require  all
          electronic  equipment to  prominently display  its level  of
          emanations  and  whether  it  is   TEMPEST  Certified.    If
          individuals are to choose to protect themselves they must be
          able  to  make  a  informed   decision  regarding  how  much
          protection is enough.
                 TEMPEST  Certified equipment  should be available  to
          the private  sector.   The current  ban on  selling to  non-
          governmental  agencies  prevents  individuals  who  need  to
          protect information from having the technology to do so.
                 Possession of  TEMPEST ELINT equipment should  not be
          made  illegal.   The  inherently  passive nature  and simple
          design  of  TEMPEST ELINT  equipment  means that  making its
          possession illegal  will not deter  crime; the units  can be
          easily manufactured and are impossible  to detect.  Limiting
          their   availability   serves   only   to   monopolize   the
          countermeasures research, information, and equipment for the
          government;   this   prevents   the  testing,   design   and

<New Page>
          manufacture of counter-measures by the private sector.
                 Legislation mirroring  England's Data Protection  Act
          1984 should be  enacted.  Preventing disclosure  of personal
          data  can  only be  accomplished  by giving  those companies
          holding the data a reason to protect  it.  If data users are
          held liable for  their failure  to take reasonable  security
          precautions they  will  begin to  take  reasonable  security
          precautions,  including   the  use   of  TEMPEST   Certified
          equipment.

-------------------------------------------------------------------------
To find out more about the anon service, send mail to help at anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin at anon.penet.fi.







From nobody at nately.UCSD.EDU  Sat Feb 11 16:57:12 1995
From: nobody at nately.UCSD.EDU (Anonymous)
Date: Sat, 11 Feb 95 16:57:12 PST
Subject: TEMPEST Paper by Former Civilian (1/2)
Message-ID: <9502120100.AA14610@nately.UCSD.EDU>



For those interested in TEMPEST, below is a draft paper written 5 years ago
by Christopher Seline.  Mr Seline's new E-mail address ends with
"DOCKMASTER.NCSC.MIL",  so any attempts to query him about TEMPEST are
guaranteed to go unanswered.  I hope he still feels the same about TEMPEST
now that he has changed employers.  
 

Date: Fri, 19 Jan 90 19:13:44 -0500
From: cjs%cwru at cwjcc.ins.cwru.edu (Christopher J. Seline (CJS at CWRU.CWRU.EDU))

The following is a prepublication draft of an article on TEMPEST.  I am posting
it to this news group in the hope that it will:
        (1) stimulate discussion of this issue;
        (2) expose any technical errors in the document;
        (3) solicit new sources of information;
        (4) uncover anything I have forgotten to cover.

I will be unable to monitor the discussions of the article.  Therefore, PLEASE
post your comments to the news group BUT SEND ME A COPY AT THE ADDRESS LISTED
BELOW.

I have gotten a number of mail messages about the format of this
article.  Some explanation is in order:  The numbered paragraphs
following "____________________" on each page are footnotes.  I suggest
printing out the document rather than reading it on your CRT.

Thanks you in advance.

Christopher Seline
cjs at cwru.cwru.edu
cjs at cwru.bitnet

(c) 1990 Christopher J. Seline
=============================================================================
<Start Print Job>
<New Page>
                                Eavesdropping On 
                         the Electromagnetic Emanations 
                              of Digital Equipment:
                               The Laws of Canada,
                          England and the United States

                           This  document is  a rough
                           draft.        The    Legal
                           Sections  are   overviews.
                           T h e y    w i l l     b e
                           significantly expanded  in
                           the next version.

               We in this country, in this generation, are -- by
               destiny rather than choice -- the watchmen on the
               walls of world freedom.[1]
                                             -President John F.
          Kennedy

          _____________________              

          1.  Undelivered  speech  of  President  John  F.  Kennedy, Dallas
          Citizens Council (Nov. 22, 1963) 35-36.

<New Page>
                    In the novel 1984, George Orwell foretold a future
          where individuals had no expectation  of privacy because the
          state monopolized the technology of  spying.  The government
          watched the actions of its subjects from birth to death.  No
          one could protect himself because  surveillance and counter-
          surveillance technology was controlled by the government.
               This note explores  the legal status of  a surveillance
          technology  ruefully  known  as  TEMPEST[2].    Using  TEMPEST
          technology  the  information in  any  digital device  may be
          intercepted  and  reconstructed  into   useful  intelligence
          without the  operative ever having to come  near his target.
          The technology is  especially useful in the  interception of
          information  stored  in  digital computers  or  displayed on
          computer terminals.
               The use of TEMPEST is not illegal under the laws of the
          United  States[3],  or  England.    Canada has  specific  laws
          criminalizing TEMPEST eavesdropping but the  laws do more to
          hinder surveillance countermeasures than to prevent  TEMPEST
          surveillance.  In  the United  States it is  illegal for  an
          individual  to  take   effective  counter-measures   against
          TEMPEST surveillance.  This  leads to the conundrum that  it
          is legal  for individuals and  the government to  invade the
          privacy of others but illegal for  individuals to take steps
          to protect their privacy.
               The author would  like to suggest that the  solution to
          this   conundrum   is  straightforward.      Information  on
          _____________________              

          2.  TEMPEST  is an  acronym for  Transient Electromagnetic  Pulse
          Emanation Standard.   This standard sets forth the official views
          of the United  States on the amount  of electromagnetic radiation
          that a device may emit without compromising the information it is
          processing.   TEMPEST  is  a defensive  standard; a  device which
          conforms to this standard is referred to as TEMPEST Certified.
               The United States  government has refused to  declassify the
          acronym  for  devices  used   to  intercept  the  electromagnetic
          information of  non-TEMPEST Certified  devices.   For this  note,
          these  devices  and  the  technology  behind  them  will  also be
          referred  to as  TEMPEST;  in  which  case,  TEMPEST  stands  for
          Transient Electromagnetic Pulse Surveillance Technology.
               The  United  States  government refuses  to  release details
          regarding TEMPEST and continues an organized effort to censor the
          dissemination of  information  about it.    For example  the  NSA
          succeeded in shutting  down a  Wang Laboratories presentation  on
          TEMPEST Certified equipment  by classifying  the contents of  the
          speech and threatening  to prosecute  the speaker with  revealing
          classified information.  [cite coming].  

          3.  This  Note  will not  discuses  how  TEMPEST relates  to  the
          Warrant Requirement under  the United  States Constitution.   Nor
          will it discuss the Constitutional exclusion of foreign nationals
          from the Warrant Requirement. 

<New Page>
          protecting  privacy  under  TEMPEST should  be  made  freely
          available;  TEMPEST  Certified equipment  should  be legally
          available; and organizations possessing  private information
          should  be  required  by  law  to protect  that  information
          through  good  computer security  practices  and the  use of
          TEMPEST Certified equipment.

                            I. INTELLIGENCE GATHERING
               Spying is divided by professionals into two main types:
          human   intelligence   gathering  (HUMINT)   and  electronic
          intelligence gathering (ELINT).  As  the names imply, HUMINT
          relies   on   human   operatives,   and  ELINT   relies   on
          technological operatives.   In the past HUMINT  was the sole
          method  for collecting intelligence.[4]   The HUMINT operative
          would  steal  important  papers, observe  troop  and  weapon
          movements[5],  lure people  into  his confidences  to  extract
          secrets,  and   stand  under   the  eavesdrip[6]   of  houses,
          eavesdropping on the occupants.  
               As  technology  has progressed,  tasks that  once could
          only  be  performed  by  humans  have  been  taken  over  by
          machines.  So  it has  been with spying.   Modern  satellite
          technology allows troop and weapons movements to be observed
          with greater  precision and  from greater  distances than  a
          human  spy  could ever  hope to  accomplish.   The  theft of
          documents  and  eavesdropping on  conversations  may now  be
          performed electronically.  This means greater safety for the
          human operative, whose  only involvement may be  the placing
          of  the  initial  ELINT  devices.    This  has  led  to  the
          ascendancy of ELINT  over HUMINT  because the placement  and
          _____________________              

          4.  HUMINT  has  been  used  by  the   United  States  since  the
          Revolution.   "The necessity  of procuring  good intelligence  is
          apparent &  need not be further urged --  All that remains for me
          to add is, that you keep the  whole matter as secret as possible.
          For  upon Secrecy,  Success depends  in Most  Enterprises of  the
          kind, and for  want of it,  they are generally defeated,  however
          well planned &  promising a favorable  issue."  Letter of  George
          Washington (Jul. 26, 1777).

          5.  "... I wish  you to take every possible pains in your powers,
          by  sending  trusty persons  to  Staten  Island in  whom  you can
          confide,  to  obtain  Intelligence  of  the Enemy's  situation  &
          numbers --  what kind of  Troops they are,  and what  Guards they
          have -- their strength & where posted."  Id.

          6.  Eavesdrip is  an Anglo-Saxon  word,  and refers  to the  wide
          overhanging eaves used  to prevent rain  from falling close to  a
          house's foundation.   The eavesdrip  provided "a sheltered  place
          where  one  could hide  to  listen clandestinely  to conversation
          within the house."   W. MORRIS & M. MORRIS,  MORRIS DICTIONARY OF
          WORD AND PHRASE ORIGINS, 198 (1977).

<New Page>
          monitoring of ELINT devices may be performed by a technician
          who has  no training  in the  art of spying.   The  gathered
          intelligence  may be  processed by  an intelligence  expert,
          perhaps  thousands of  miles  away, with  no  need of  field
          experience.  
               ELINT has a number of other advantages over HUMINT.  If
          a  spy is caught his existence could embarrass his employing
          state and he could  be forced into giving up  the identities
          of his compatriots  or other important information.   By its
          very nature, a discovered ELINT device (bug)  cannot give up
          any information; and the ubiquitous  nature of bugs provides
          the  principle  state  with the  ability  to  plausibly deny
          ownership or involvement.
               ELINT   devices   fall  into   two   broad  categories:
          trespassatory  and  non-trespassatory.   Trespassatory  bugs
          require some type of trespass in order for them to function.
          A transmitter  might require  the physical  invasion of  the
          target  premises  for placement,  or  a microphone  might be
          surreptitiously attached  to  the outside  of a  window.   A
          telephone transmitter can  be placed  anywhere on the  phone
          line, including at the  central switch.  The trespass  comes
          either when it is physically attached  to the phone line, or
          if it is  inductive, when placed  in close proximity to  the
          phone line.   Even microwave  bugs require the  placement of
          the resonator cone within the target premises.[7]
               Non-trespassatory  ELINT  devices  work   by  receiving
          electromagnetic radiation (EMR) as  it radiates through  the
          aether, and do not  require the placement of bugs.   Methods
          include intercepting[8] information transmitted  by satellite,
          microwave, and  radio, including mobile  and cellular  phone
          transmissions.   This information was  purposely transmitted
          with the intent that  some intended person or  persons would
          receive it.  
               Non-trespassatory ELINT also includes  the interception
          of information that  was never  intended to be  transmitted.
          All electronic devices emit electromagnetic radiation.  Some
          of  the  radiation,  as  with radio  waves,  is  intended to
          transmit  information.    Much  of  this  radiation  is  not
          intended to transmit information and is merely incidental to

          _____________________              

          7.  Pursglove, How  Russian Spy  Radios Work,  RADIO ELECTRONICS,
          89-91 (Jan 1962).

          8.  Interception  is  an  espionage  term of  art  and  should be
          differentiated from  its more common usage.   When information is
          intercepted, the interceptor  as well  as the intended  recipient
          receive the information.  Interception when not used as a term of
          art refers to one person receiving something intended for someone
          else; the intended recipient never receives what he  was intended
          to receive.

<New Page>
          whatever  work  the  target  device  is performing.[9]    This
          information  can be  intercepted  and reconstructed  into  a
          coherent  form.    With  current  TEMPEST technology  it  is
          possible to  reconstruct  the  contents  of  computer  video
          display  terminal  (VDU)  screens  from  up to  a  kilometer
          distant[10];  reconstructing  the  contents  of  a  computer's
          _____________________              

          9.  There are  two types  of emissions,  conducted and  radiated.
          Radiated  emissions are formed  when components or  cables act as
          antennas for transmit the EMR; when radiation is conducted  along
          cables or other connections but not radiated it is referred to as
          "conducted".  Sources  include cables,  the ground loop,  printed
          circuit boards, internal  wires, the power  supply to power  line
          coupling, the cable to cable coupling, switching transistors, and
          high-power  amplifiers.    WHITE  &  M. MARDIGUIAN,  EMI  CONTROL
          METHODOLOGY AND PROCEDURES,   10.1 (1985).
               "[C]ables  may act  as an  antenna to  transmit the  signals
          directly  or  even  both  receive the  signals  and  re-emit them
          further away  from the  source equipment.   It  is possible  that
          cables acting as an  antenna in such a manner could  transmit the
          signals  much  more  efficiently than  the  equipment  itself...A
          similar  effect  may occur  with metal  pipes  such as  those for
          domestic water supplies. ...  If an earthing [(grounding)] system
          is  not installed  correctly such  that there  is a  path  in the
          circuit  with a  very high  resistance (for  example  where paint
          prevents  conduction and  is acting  as an  insulator), then  the
          whole earthing  system could well act in  a similar fashion to an
          antenna. ...   [For a  VDU] the strongest  signals, or  harmonics
          thereof, are  usually between  60-250 MHz  approximately.   There
          have  however  been  noticeable  exception  of  extremely  strong
          emissions  in  the  television bands  and  at  higher frequencies
          between 450-800  MHz.  Potts,  Emission Security, 3  COMPUTER LAW
          AND SECURITY REPORT 27 (1988).

          10.  The TEMPEST ELINT operator can distinguish between different
          VDUs  in   the   same  room   because   of  the   different   EMR
          characteristics of both  homo and heterogeneous units.   "[T]here
          is little comparison  between EMR characteristics  from otherwise
          comparable equipment.   Only if the  [VDU] was made with  exactly
          the  same components  is there  any similarity.   If some  of the
          components have come from a different batch, have been updated in
          some   way,  and  especially   if  they  are   from  a  different
          manufacturer, then completely different results are obtained.  In
          this way a  different mark or version of the same [VDU] will emit
          different  signals.   Additionally  because  of the  variation of
          manufacturing standards between counties, two  [VDUs] made by the
          same  company  but  sourced  from  different counties  will  have
          entirely different EMR signal characteristics...From this  it way
          be thought that there is such a jumble of emissions  around, that
          it would not be possible to isolate those from any one particular
          source.  Again, this is not the case.  Most received signals have

<New Page>
          memory or the contents  of its mass storage devices  is more
          complicated and must be performed  from a closer distance.[11]
          The reconstruction  of information  via EMR,  a process  for
          which the  United States  government  refuses to  declassify
          either  the  exact  technique or  even  its  name[12], is  not
          limited to computers  and digital devices but  is applicable
          to  all devices  that generate  electromagnetic radiation.[13]
          TEMPEST is  especially effective  against VDUs  because they
          produce a very high level of EMR.[14]
          _____________________              
                                                                           
          a  different  line synchronization,  due  to  design, reflection,
          interference or  variation of component  tolerances.  So  that if
          for  instance  there  are three  different  signals  on the  same
          frequency  ...  by  fine  tuning  of  the  RF  receiver,  antenna
          manipulation  and modification  of  line synchronization,  it  is
          possible to lock onto each of the three signals separately and so
          read  the  screen information.    By  similar techniques,  it  is
          entirely  possible  to discriminate  between individual  items of
          equipment in the same room."  Potts, supra note 9.
               For  a discussion  of  the TEMPEST  ELINT  threat See  e.g.,
          Memory Bank, AMERICAN BANKER 20 (Apr 1 1985); Emissions from Bank
          Computer Systems  Make Eavesdropping Easy,  Expert Says, AMERICAN
          BANKER  1  (Mar  26 1985);  CRT  spying:  a  threat to  corporate
          security, PC WEEK (Mar 10 1987).

          11.  TEMPEST is  concerned  with  the  transient  electromagnetic
          pulses formed  by digital  equipment.   All electronic  equipment
          radiates  EMR  which  may be  reconstructed.    Digital equipment
          processes information as 1's and 0's--on's  or off's.  Because of
          this, digital equipment  gives off pulses  of EMR.  These  pulses
          are easier to  reconstruct at a  distance than the non-pulse  EMR
          given off by  analog equipment.   For a  thorough discussion  the
          radiation  problems  of  broadband digital  information  see e.g.
          military standard MIL-STD-461   REO2; White supra note 9,   10.2.

          12.  See supra note 2.

          13.       Of special interest  to ELINT  collectors are EMR  from
          computers,  communications   centers  and  avionics.     Schultz,
          Defeating Ivan with TEMPEST, DEFENSE ELECTRONICS 64 (June 1983). 

          14.     The  picture on  a  CRT screen  is  built up  of  picture
          elements  (pixels) organized  in lines  across the  screen.   The
          pixels  are made  of material  that fluoresces  when struck  with
          energy.  The energy is produced by a beam of electrons fired from
          an electron gun  in the back of  the picture tube.   The electron
          beam scans the screen of the  CRT in a regular repetitive manner.
          When the voltage of the beam is high then the pixel it is focused
          upon  emits  photons and  appears as  a  dot on  the screen.   By
          selectively firing  the gun as  it scans across  the face of  the
          CRT, the pixels form characters on the CRT screen.
<New Page>
               ELINT is not limited to  governments.  It is  routinely
          used by  individuals for  their  own purposes.   Almost  all
          forms of ELINT are  available to the individual with  either
          the technological  expertise or  the money  to hire  someone
          with  the  expertise.     Governments   have  attempted   to
          criminalize all use  of ELINT by their  subjects--to protect
          the privacy of both the government and the population.

                              II. UNITED STATES LAW
               In the United States, Title III of  the Omnibus Streets
          and Crimes Act of 1968[15] criminalizes trespassatory ELINT as
          the intentional interception  of wire communications.[16]   As
          originally  passed,   Title  III   did  not  prohibit   non-

          _____________________              
                                                                           
               The pixels  glow for  only a  very  short time  and must  be
          routinely struck by the electron beam  to stay lit.  To  maintain
          the light output of  all the pixels that are supposed  to be lit,
          the electron beam traverses  the entire CRT screen sixty  times a
          second.   Every time the beam fires it  causes a high voltage EMR
          emission.  This EMR  can be used  to reconstruct the contents  of
          the  target CRT  screen.   TEMPEST  ELINT  equipment designed  to
          reconstruct the information synchronizes its  CRT with the target
          CRT.  First, it uses the EMR to synchronize its electron gun with
          the electron gun in the target CRT.  Then, when the TEMPEST ELINT
          unit detects EMR indicating that the target CRT fired on a pixel,
          the TEMPEST ELINT  unit fires the electron  gun of its CRT.   The
          ELINT CRT is in perfect synchronism with the target CRT; when the
          target lights a pixel, a corresponding pixel on the TEMPEST ELINT
          CRT  is lit.  The exact picture on  the target CRT will appear on
          the TEMPEST ELINT  CRT.  Any changes on the target screen will be
          instantly reflected in the TEMPEST ELINT screen. 
               TEMPEST Certified equipment gives off emissions  levels that
          are too faint to  be readily detected.  Certification  levels are
          set   out  in   National   Communications  Security   Information
          Memorandum  5100A   (NACSIM  5100A).    "[E]mission   levels  are
          expressed in the time  and frequency domain, broadband or  narrow
          band  in terms of the frequency domain, and in terms of conducted
          or radiated emissions."  White, supra, note 9,   10.1.
               For a  thorough  though purposely  misleading discussion  of
          TEMPEST ELINT see  Van Eck, Electromagnetic Radiation  from Video
          Display units: An Eavesdropping Risk?, 4 Computers & Security 269
          (1985).

          15.   Pub. L.  No. 90-351,  82 Stat. 197.   The Act  criminalizes
          trespassatory  ELINT  by  individuals  as  well  as  governmental
          agents.  cf.  Katz v. United States, 389 U.S. 347  (1967) (Fourth
          Amendment prohibits surveillance by government not individuals.) 

          16.  18 U.S.C.   2511(1)(a).

<New Page>
          trespassatory  ELINT,[17] because  courts found  that non-wire
          communication lacked any expectation of p2IIIrivacy.[18]   The
          Electronic Communications  Privacy  Act  of  1986[19]  amended
          Title  III  to  include non-wire  communication.    ECPA was
          specifically  designed  to include  electronic  mail, inter-
          computer  communications,  and  cellular  telephones.     To
          accomplish  this,  the  expectation  of  privacy   test  was
          eliminated.[20]
               As  amended, Title  III  still outlaws  the  electronic
          interception of  communications.  The  word "communications"
          indicates  that   someone  is   attempting  to   communicate
          something to someone; it  does not refer to the  inadvertent
          transmission   of   information.       The   reception   and
          reconstruction of emanated transient  electromagnetic pulses
          (ETEP), however, is based on  obtaining information that the
          target does  not  mean to  transmit.   If  the ETEP  is  not
          intended as communication, and  is therefore not transmitted
          in a form approaching current communications protocols, then
          it can not  be considered communications as  contemplated by
          Congress  when  it   amended  Title  III.     Reception,  or
          interception, of emanated  transient electromagnetic  pulses
          is not criminalized by Title III as amended.

                                III. ENGLISH LAW
               In  England  the  Interception  of  Communications  Act
          1985[21] criminalizes the tapping of  communications sent over

          _____________________              

          17.  United States v. Hall,  488 F.2d 193 (9th Cir.  1973) (found
          no legislative history  indicating Congress  intended the act  to
          include radio-telephone conversations).  Further,  Title III only
          criminalized  the interception  of  "aural" communications  which
          excluded all forms of computer communications.  

          18.  Willamette  Subscription Television  v.  Cawood, 580  F.Supp
          1164 (D. Or. 1984) (non-wire communications lacks any expectation
          of privacy).

          19.  Pub. L. No. 99-508, 100 Stat. 1848 (codified at 18 U.S.C.   
          2510-710) [hereinafter ECPA].

          20.  18 U.S.C.   2511(1)(a) criminalizes the interception of "any
          wire,  oral  or electronic  communication"  without regard  to an
          expectation of privacy.

          21.  Interception of Communications Act 1985,  Long Title, An Act
          to make new provision for and in connection with the interception
          of  communications  sent   by  post   or  by   means  of   public
          telecommunications  systems  and  to  amend  section  45  of  the
          Telecommunications Act 1984.

<New Page>
          public  telecommunications  lines.[22]   The  interception  of
          communications on  a telecommunication line  can take  place
          with a physical tap on the line, or the passive interception
          of microwave or  satellite links.[23]  These  forms of passive
          interception  differ  from TEMPEST  ELINT  because  they are
          intercepting   intended    communication;   TEMPEST    ELINT
          intercepts unintended  communication.  Eavesdropping  on the
          emanations  of  computers does  not  in any  way  comport to
          tapping a telecommunication line and therefore falls outside
          the scope of the statute.[24]

-------------------------------------------------------------------------
To find out more about the anon service, send mail to help at anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin at anon.penet.fi.







From hfinney at shell.portal.com  Sat Feb 11 17:06:32 1995
From: hfinney at shell.portal.com (Hal)
Date: Sat, 11 Feb 95 17:06:32 PST
Subject: Does PGP scale well?
In-Reply-To: <9502112237.AA17845@snark.imsi.com>
Message-ID: <199502120105.RAA20992@jobe.shell.portal.com>


I was just reading RFC1034 about DNS, and one thing I noted was that there is a
"reverse lookup" feature.  This allows you to go from, say, 156.151.1.101
to portal.com.  This problem seems similar in some ways to the key lookup
problem since you have a relatively unstructured number and you want to
use it as a lookup key.

According to the RFC, if you want to know what host machine is at
address 156.151.1.101, you do a lookup of 156.151.1.101.IN-ADDR.ARPA.
The RFC did not make it very clear how this is done.  Does this use a
"flat" database?    Is it distributed in some way?  Or has this method
perhaps been superceded by some other?

I can see that the key problem is worse than the reverse lookup problem
because there are many more users than hosts.  Although in the long run
won't everybody have a computer at home that has an IP address?  Will the
nameserver hierarchy run into problems then?  There is no obvious
hierarchical arrangement as we have now with our .edu and .com sites,
unless we go geographical.  This seems analogous to the PEM/RSA key
certificate hierarchy problem.  In any case the reverse lookup problem
seems like it will be difficult then.

Hal





From rrothenb at ic.sunysb.edu  Sat Feb 11 17:56:25 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Sat, 11 Feb 95 17:56:25 PST
Subject: law vs technology
In-Reply-To: <199502102253.RAA10658@ducie.cs.umass.edu>
Message-ID: <199502120156.UAA27335@libws4.ic.sunysb.edu>


L. Futplex McCarthy's reply to Wei Dei:

[ Snip! ]

> As a separate issue, there are quite a few vocal opponents of groups such as
> EFF on the list. I've no idea whether there's a silent majority ;) of lurkers
> who fully support EFF et al., but I suspect a sizable chunk of the list
> population disagrees that there are many people really fighting invasive govt.
> action.

There's an advantage of techies getting politically active, provided they
can explain the systems in an understandable way that is interesting, and
provided that these issues hit home to them (ie, that you're not talking
in technobabble and that they see the need for privacy technologies in
their own lives).

What I find harder to do is to get through to people who have given up on
the government not eroding what little rights remain, or who are already
afriad that the FBI/CIA/NSA/KGB/etc. are already watching their every move.

I'm working on a fax to send to congresspersons as a start. I'd like to
get local political action groups hip to the issues as well to get the ball
rolling in the right direction as well.






From mccoy at io.com  Sat Feb 11 19:18:29 1995
From: mccoy at io.com (Jim McCoy)
Date: Sat, 11 Feb 95 19:18:29 PST
Subject: Does PGP scale well?
In-Reply-To: <199502120105.RAA20992@jobe.shell.portal.com>
Message-ID: <199502120318.VAA27650@pentagon.io.com>


> From: Hal <hfinney at shell.portal.com>
> 
> I was just reading RFC1034 about DNS, and one thing I noted was that
> there is a "reverse lookup" feature.  This allows you to go from, say,
> 156.151.1.101 to portal.com.  This problem seems similar in some ways to
> the key lookup problem since you have a relatively unstructured number
> and you want to use it as a lookup key.
[...]
> According to the RFC, if you want to know what host machine is at
> address 156.151.1.101, you do a lookup of 156.151.1.101.IN-ADDR.ARPA.
> The RFC did not make it very clear how this is done. [...]

Actually you do a lookup on 101.1.151.156.in-addr.arpa, it is reversed
because of the way addresses are structured.  This is part of the
problem with PGP keys and DNS: PGP key IDs are unstructured and randomly
distributed, IP addresses are not really unstructured and thier
distribution is not random.  A reverse lookup (aka "pointer query") happens
the same way as a regular name lookup, it just reverses the order of the
bytes in the IP address and then resolves it in the same method as a
regular name, from the least specific to most specific parts of the
address. 

With a PGP key ID there is no order to the distribution of the IDs, so it
is not like one could delegate authority for bits in a key ID the same way
taht one can with bits/bytes in an IP address.  The inability to delgate
chunks of the key ID space is what will prevent lookups by keyID; no one
can run a single server that has all the IDs and the organizational
problems with delegating random chunks of the keyID-space are fairly obvious
(e.g. in the DNS model you are responsible for your own address space and
it is in your own self-interest to make sure that it works, the same cannot
be said of keyID-space)

jim




From perry at imsi.com  Sat Feb 11 22:16:29 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sat, 11 Feb 95 22:16:29 PST
Subject: Does PGP scale well?
In-Reply-To: <199502120105.RAA20992@jobe.shell.portal.com>
Message-ID: <9502120616.AA18409@snark.imsi.com>



Hal says:
> I was just reading RFC1034 about DNS, and one thing I noted was that
> there is a "reverse lookup" feature.  This allows you to go from,
> say, 156.151.1.101 to portal.com.  This problem seems similar in
> some ways to the key lookup problem since you have a relatively
> unstructured number and you want to use it as a lookup key.
> 
> According to the RFC, if you want to know what host machine is at
> address 156.151.1.101, you do a lookup of 156.151.1.101.IN-ADDR.ARPA.

No, you got that wrong. You do a lookup on 101.1.151.156.IN-ADDR.ARPA
-- note the component reversal. The reversal is very key.

> The RFC did not make it very clear how this is done.  Does this use a
> "flat" database?

No. Its fully distributed. The fact that networks are assigned in
heirarchical chunks should explain how its done, and why the bytes get
reversed for the lookup. As an example, MIT owns network 18, which is
to say that all MIT addresses are 18.XXX.XXX.XXX, and 18.IN-ADDR.ARPA
is a server at MIT. MIT may have sub-servers beyond that level, but
DNS makes us oblivious to this.

For IPv6, the reverse lookup is going to be segregated at the nybble
boundaries rather than at the byte boundaries because of CIDR style
classless allocation. The domain will be IP6.INT rather than IN-ADDR.ARPA

Perry





From 0003701548 at mcimail.com  Sun Feb 12 00:20:15 1995
From: 0003701548 at mcimail.com (Alan Pugh)
Date: Sun, 12 Feb 95 00:20:15 PST
Subject: Fwd: Re: West (just a minute)
Message-ID: <71950212081717/0003701548PJ2EM@MCIMAIL.COM>



the most reasonable and easiest to implement solution to eliminating the
need for west's page number system is to just number each paragraph.
anyone can do this.


-----------------
Forwarded Message

Date:     Sat Feb 11, 1995  5:57 am  EST
Source-Date: Sat, 11 Feb 1995 05:49:47 -0500 (EST)
From:     Craig Hubley
          EMS: INTERNET / MCI ID: 376-5414
          MBX: craig at passport.ca
 
TO:     * Alan Pugh / MCI ID: 370-1548
Subject:  Re: West (just a minute)
Message-Id: 81950211105718/0003765414DC2EM
Source-Msg-Id: <m0rdFOe-0002IhC at forged.passport.ca>
U-Mime-Version: 1.0
U-Content-Type: text/plain; charset=US-ASCII
 

Hmm, 
how hard could it be to eliminate West page numbers?

There couldn't be more than a couple of cases on each page, 
if each page number were replaced by links to each case, a
lawyer could tell on the first glance which of the three was
right and mark it, assuming a reasonable HTML/SGML editor or
something.  Seems like it could be done as a part of daily work
and the results accreted somewhere.
-- 
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the Web
craig at passport.ca   416-778-6136  416-778-1965 FAX







From rfdutcher at igc.apc.org  Sun Feb 12 02:25:38 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Sun, 12 Feb 95 02:25:38 PST
Subject: UMich student arrested for rape story
Message-ID: <199502121026.CAA19268@igc3.igc.apc.org>


> From:          "L. McCarthy" <lmccarth at ducie.cs.umass.edu>

> Rich Dutcher writes:
> > They *do* have to prove intent -- as to how, that's what juries are 
> > for.  BTW, he used her real name in the post, with no disclaimers 
> > about fiction.  From what I have heard, if he had said the same thing 
> > in her presence, he could have been arrested for assault.
> 
> Based on the NY Times article I've read, you're omitting some important
> extenuating circumstances here. For one thing, it was apparently posted to
> alt.sex.stories, which seems to obviate the use of "fictional" disclaimers.
> Furthermore, he did _not_ identify her as a UMich student.
> 
Well, I was quoting a small AP story in a paper notorious for
clipping articles short, so I knew that some [if not many]
circumstances would be missing.  In conversations today at
Potlatch 4 I learned of other circumstances, albeit not
necessarily what I would call "extenuating" ones.  And the
lawyers, of course, will be spin controlling from now until a
verdict.

> I don't see the relevance of "if he had said the same thing in her presence".
> He *didn't* !  There's an enormous difference between making a comment about
> a person to third parties, and making the comment to that person.
> 
Not necessarily -- there's lots of case law that the threatened
person need not be present to be threatened.  The people present
are still witnesses.  I agree there's a difference, but its nature
isn't obvious.  Precisely what that difference is is up to judges,
juries and [goddess help us!] legislators.

> According to the NY Times story, the woman mentioned in the story only heard
> about it because reporters asked her about it !  I find a great deal of irony
> in the report that the controversy started because an alt.sex.stories reader
> in _Moscow_ tipped off the UMich authorities.
> 
Irony noted and appreciated -- but it does illustrate the "public" 
nature of the forum.

> It appears that the Russians are allowed to read erotic fiction, while the
> Americans are forbidden to read it, and get tossed in jail for writing it.
> We've come a long way, baby. Yeah.
> 
>  -L. Futplex McCarthy

I was in high school while the Supremes [the real Supremes, with 
Earl Warren, not the bogus nostalgia group currently wearing the 
black robes] were doing the decisions that allowed Joyce and Lawrence 
to be sold in bookstores, and I was taught Shakespeare from a 
bowlderized edition of Romeo & Juliet.  Trust me, we aren't in a 
place remotely like that now [not that there aren't plenty of people 
trying to get back there].

Which is not to say I'm complacent -- when I have money to spare from 
Green work, it goes to the ACLU.  Eternal vigilance and all that.  
And this dude is entitled to presumption of innocence, a jury trial, 
and all the other paraphenalia of procedural liberty.

However, given the information available to date, I see no reason to 
believe that he's been busted for writing "erotic fiction"  rather than 
threatening a woman.  Violence against women is too real, and in 
other contexts courts have held to a standard of what a "reasonable 
woman" might fear.

BTW, does alt.sex.stories presume fiction, or is it pretend truth 
like the readers' sex stories in Penthouse?





From peace at BIX.com  Sun Feb 12 02:50:41 1995
From: peace at BIX.com (peace at BIX.com)
Date: Sun, 12 Feb 95 02:50:41 PST
Subject: the problem that destroyed PGP
Message-ID: <9502120550.memo.29017@BIX.com>


Return-path: <peace at BIX.com>
Received: by bix.com (CoSy3.31.1.50) id <9502112132.memo.28092 at BIX.com>;
 Sat, 11 Feb 1995 21:32:20 -0500 (EST)
From: peace at BIX.com
Date: Sat, 11 Feb 95 21:32:20 EST
To: cyperpunks at toad.com
Message-ID: <9502112132.memo.28092 at BIX.com>
Subject: the problem that destroyed PGP

So finding a KeyID is the problem that destroys PGP eh?

Well I would just take that as the problem to solve, not a
reason to throw the baby out with the bath water.

All we need to do is design a distributed, hashed database.
Should be a piece 'o cake, right?

Let's see, first of all the problem is the receiver of a message
who gets just the KeyID.  First of all, the trusted keys should
be expected to be local (in some webby sense).  But lets assume
that the key is new, not in our local cache.  Now my scheme would put
a net of keyservers that ALL know each other.  The local environment
puts in a request to its usual keyserver.  That is the keyserver
that typically has the keys that the receiver is likely to trust.
Now it is certainly possible to imagine a case where a key is not
in the receiver's expected server, so what's next.  Well the 
keyserver knows ALL the other servers, right, so just copy the
original receiver's request to all the other keyservers.  If that
gets to be too big, just build a real net where every keyserver is
at most two hops away from any other one, then the intermediate
servers that could not honor the request would forward it to all 
the servers it knew.  I purposely propose that only two steps would
ever be necessary to limit the explosion, but I see that as no
real limitation, the rule could even be modified if there was
really any need.

Hey look, the net supports archie and a host of other non-structured
search mechanisms.  Why create a search hierarchy where such things
are not natural.  Why create a naming hierarchy where such things are
not natural.

By the way, the dockmaster.ncsc.mil note is a good example of a naming
hierarchy that has nothing to do with the employment of the person.
Anyone working in the security field can get an address there.  And
any member can get acm.org or ieee.org. But I can post from any of
there different net addresses which do not even agree at the very
most basic level.  So why would my KeyID be naturally associated with
any one of .net, .org or .com?

Peace ..Tom





From perry at imsi.com  Sun Feb 12 06:50:56 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 12 Feb 95 06:50:56 PST
Subject: the problem that destroyed PGP
In-Reply-To: <9502120550.memo.29017@BIX.com>
Message-ID: <9502121449.AA18809@snark.imsi.com>



peace at bix.com says:
> So finding a KeyID is the problem that destroys PGP eh?

No, it doesn't "destroy" it. PGP just needs a redesign to pass along
DNSable tags (like joe at some.domain.org) with keyIDs.

> Well I would just take that as the problem to solve, not a
> reason to throw the baby out with the bath water.

No one is proposing throwing it away. People are proposing small
changes to the format.

> All we need to do is design a distributed, hashed database.
> Should be a piece 'o cake, right?

No, we aren't going to do that, because its an administrative
nightmare, and I can't imagine proposing such a thing with a straight
face at an IETF meeting.

> Hey look, the net supports archie and a host of other non-structured
> search mechanisms.

No, it doesn't. Archie is a piece of shit that can't find what I need
about two thirds of the time and is slow as molasses and cannot
scale. It was a nice idea but its at the breaking point.

Perry





From root at einstein.ssz.com  Sun Feb 12 08:27:13 1995
From: root at einstein.ssz.com (root)
Date: Sun, 12 Feb 95 08:27:13 PST
Subject: Q: ref. for DNA used to solve math. network prob. (fwd)
Message-ID: <199502121623.KAA00375@einstein.ssz.com>


Forwarded message:
 
> Message-Id: <m0rdRDS-0005iFa at hip-hop.hh.sbay.org>
> Date: Sat, 11 Feb 95 15:27 PST
> From: jwgruber at aol.com (JWGruber)
> Subject: Q: ref. for DNA used to solve math. network prob.
> Designated-To: Internet Amateur Mathematics Society
> 
> Hi - I am looking for a reference (newspaper or popular magazine) on a
> recent article that described the use of DNA and genetic expression to
> solve a complex mathematical problem (linear algebra-matrix systems I
> believe) regarding a network of paths or routes between cities. Does
> anyone have a reference on this work ? I would be greatly obliged if I
> could receive a note on this. Thank you !
> John W. Gruber
> Philadelhia College of Pharmacy & Science
> JWGruber at aol.com
>
Only peripheraly related to crypto but has anyone got any info on this?

 





From mab at crypto.com  Sun Feb 12 09:25:57 1995
From: mab at crypto.com (Matt Blaze)
Date: Sun, 12 Feb 95 09:25:57 PST
Subject: the problem that destroyed PGP
In-Reply-To: <9502120550.memo.29017@BIX.com>
Message-ID: <199502121727.MAA20000@crypto.com>



Peace at BIX.com writes:
>So finding a KeyID is the problem that destroys PGP eh?
>
...

I don't think anyone has suggested there's any one problem that
"destroys" PGP.  Several people have pointed out a number of problems
that limit PGP's scalability in various ways.  Its flat key ID
namespace is one.  Lack of functional modularity is another.  Its
fixed certification model is still another.  There are more, and
no doubt still others waiting to be discovered as the user base
grows.  Any secure communications system that aspires to large-scale
penetration, whether called "PGP" or something else, will have to
tackle these kinds of issues before it will be successful.  Some
of the issues are obvious, while others only become apparent after
some experience.  Scale, after all, has a way of turning easy
problems into surprisingly hard ones.

For whatever reason, PGP has attracted an almost cult-like following,
and this has so far helped the spread of secure email.  But this
cuts both ways; cult status or not, PGP has to continue to evolve
and adapt to large-scale, mainstream demands by applying the lessons
of other big systems.  If it doesn't, rest assured that companies
like Microsoft and AT&T will do just fine with whatever they decide
the market wants.

-matt





From kinney at bogart.Colorado.EDU  Sun Feb 12 09:57:47 1995
From: kinney at bogart.Colorado.EDU (W. Kinney)
Date: Sun, 12 Feb 95 09:57:47 PST
Subject: the problem that destroyed PGP
In-Reply-To: <199502121727.MAA20000@crypto.com>
Message-ID: <199502121757.KAA12098@bogart.Colorado.EDU>



Matt Blaze writes:

> I don't think anyone has suggested there's any one problem that
> "destroys" PGP.  Several people have pointed out a number of problems
> that limit PGP's scalability in various ways.  Its flat key ID
> namespace is one.  Lack of functional modularity is another.  Its
> fixed certification model is still another. 

Certification really does need to be added to the discussion on scaling.
In the sense that I want to be able to download a stranger's key from 
a key server and have some idea of its reliablility, web of trust has
turned out to be a real failure, IMO. There's no "web", rather a large
set of disconnected "islands" of signatures. I'm looking at the latest
keyring from MIT right now, and noticing that most of the keys are
either unsigned or self-signed. The majority of the rest have signatures,
but signatures that are unconnected to me via the web of trust, so that
they are entirely useless. I suspect that my situation is by far the
most common one: the only keys that I have any verifiable authentication
for are ones I've signed myself, or ones that are signed by people 
in my immediate circle. The chain of signatures dies very close to me.

This isn't a criticism of PGP's key certification paradigm -- PGP allows
centralized certification (I see a few keys signed by SLED, for instance),
and it also allows me the flexibility of having mutual certification within
the circle of people I mail regularly. But web of trust _in and of itself_
is not proving to be effective when applied to the problem of providing
reliable key certification on the scale of the internet as a whole. 


                                  -- Will




From perry at imsi.com  Sun Feb 12 10:03:08 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 12 Feb 95 10:03:08 PST
Subject: the problem that destroyed PGP
In-Reply-To: <199502121757.KAA12098@bogart.Colorado.EDU>
Message-ID: <9502121802.AA19017@snark.imsi.com>



"W. Kinney" says:
> This isn't a criticism of PGP's key certification paradigm -- PGP allows
> centralized certification (I see a few keys signed by SLED, for instance),
> and it also allows me the flexibility of having mutual certification within
> the circle of people I mail regularly. But web of trust _in and of itself_
> is not proving to be effective when applied to the problem of providing
> reliable key certification on the scale of the internet as a whole. 

I think the jury is still out on that. Web-of-trust is still really
untested because of the difficulties in widespread deployment of
PGP. As it stands, PGP is still a hacker's toy -- the lack of a
library or an easy to use global key distribution infrastructure mean
that we have yet to see what can be done. I think that mutually
authenticating organizations with small trust pyramids within the
organizations, but without a global key pyramid, may come to prove
very practical.

Perry





From kinney at bogart.Colorado.EDU  Sun Feb 12 10:10:30 1995
From: kinney at bogart.Colorado.EDU (W. Kinney)
Date: Sun, 12 Feb 95 10:10:30 PST
Subject: the problem that destroyed PGP
In-Reply-To: <9502121802.AA19017@snark.imsi.com>
Message-ID: <199502121810.LAA12147@bogart.Colorado.EDU>



Perry Metzger writes:

> I think the jury is still out on that. Web-of-trust is still really
> untested because of the difficulties in widespread deployment of
> PGP. As it stands, PGP is still a hacker's toy -- the lack of a

Perhaps you're right. Your argument here, as I see it, is that web-of-trust
becomes _more_ functional as it becomes adopted on a larger scale. This
might end up being true and it might not, although there seems to be
no evidence as of yet of increasing "connectivity" of signatures as PGP
becomes more widely used, which was the point I was trying to make. The
unresolved question is whether or not there will be a critical point at
which the web will become widely connected. The answer does not seem at
all clear to me.

                               -- Will





From hfinney at shell.portal.com  Sun Feb 12 10:20:57 1995
From: hfinney at shell.portal.com (Hal)
Date: Sun, 12 Feb 95 10:20:57 PST
Subject: the problem that destroyed PGP
In-Reply-To: <199502121757.KAA12098@bogart.Colorado.EDU>
Message-ID: <199502121820.KAA04736@jobe.shell.portal.com>


"W. Kinney" <kinney at bogart.Colorado.EDU> writes:

>But web of trust _in and of itself_
>is not proving to be effective when applied to the problem of providing
>reliable key certification on the scale of the internet as a whole. 

Here is something I posted on this topic last year:

> From owner-cypherpunks at toad.com  Wed Mar 30 09:19:30 1994
> Date: Wed, 30 Mar 1994 09:17:40 -0800
> From: Hal <hfinney at shell.portal.com>
> Message-Id: <199403301717.JAA14861 at jobe.shell.portal.com>
> To: cypherpunks at toad.com
> Subject: Web of Trust?
> Sender: owner-cypherpunks at toad.com
> Precedence: bulk
> Status: RO
> 
> One of the key concepts widely used to describe PGP is the "web of trust".
> This brings to mind a network of connections between people who know and
> communicate with each other.  Two people who want to communicate can do
> so securely if there is a path of connections in the form of signed keys
> that joins them.
> 
> But this is not quite right.  The fundamental fact about PGP key signatures,
> which is often misunderstood, is this:
> 
> You can only communicate securely with someone whose key is signed by a person
> you know, either personally or by reputation.
> 
> In other words, if I want to communicate with joe at abc.com, I can only do so
> if one of the signators of his key is a person I know.  If not, I have no way
> of judging the validity of his key.
>  
> This belies simple interpretations of the "web of trust".  I may have signed
> A's key, A has signed B's, B has signed C's, C has signed D's, and D has signed
> Joe's, but this is of no value unless I know D.  Only then can I trust Joe's
> key.
> 
> This means that, in the "web" picture, I can only communicate securely with
> people who are at most two hops away in the web of connections.  I can
> communicate with the people I know, and I can communicate with the people they
> know, and that is it.
> 
> This is unfortunate, because the simple web model ties into some famous
> research which suggests that any two people chosen at random are only about
> half a dozen steps apart in the web of who-knows-whom connections.  (This
> result is where the title of the movie "Six Degrees of Separation" comes from.)
> If you had a system which actually supported communications via such a web
> model, it actually would have hope of letting two people communicate who did
> not have a very long chain between them.  But PGP, with a maximum chain length
> of two, will not allow this.
> 
[Discussion of possible extensions elided]
> 
> Without this, I think we will continue to have problems with PGP being unable
> to validate keys of people we want to communicate with.  People will collect
> huge laundry lists of signatures in the hopes that whoever wants to commu-
> nicate with them will know one of those people.  Centralized key validators
> will appear (as in the case of the SLED service being started now, which will
> sign a key based on a signed check with your name on it).  The result may be
> a choice between using an unsigned key or using one signed by some faceless
> bureaucracy, which is no better than the original PEM conception.
> 
> (People may be confused by this essay because they thought PGP worked this
> way already.  PGP does have a follow-the-web model, but that is only for
> following signatures.  In the example above, where I wanted to talk to Joe
> and there was a chain to him through A, B, C, and D, we have to first sup-
> pose that I know and trust all of A, B, C, and D.  Given that, what PGP can
> do is to determine whether I have valid keys for all of those people.  It will
> notice that A has signed B's key, so it is valid.  I know B and told PGP he
> was trustworthy, and he signed C's key, so therefore that one is valid.  Sim-
> ilarly, I know C and I know D so PGP can follow the chain through them.  Fin-
> ally we come to Joe, whom I don't know, but because I know D and PGP followed
> the web to determine that D's key is valid, PGP can determine that Joe's key
> is valid.  But again, that was only because I knew D and everyone else in
> the chain.  The bottom line is still that I can only communicate with people
> who know someone I know.)
>  
> Hal





From rrothenb at ic.sunysb.edu  Sun Feb 12 10:23:14 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Sun, 12 Feb 95 10:23:14 PST
Subject: The question is moot: (Was: Not crypto, but scary.)
In-Reply-To: <Pine.SOL.3.90.950210075752.11373A-100000@use.usit.net>
Message-ID: <199502121822.NAA06249@libws3.ic.sunysb.edu>


Any punishment on the books for politce who knowingly violate the law seems
pointless, since they can technically be prosecuted for violating civil
rights anyway.  As it is, juries tend to believe police testimony no matter
what side they are on (prosecution or defense).

It's rare that police are prosecuted for brutaliy cases, and corruption
trials fizzle out because of the "blue wall" effect.






From samman at CS.YALE.EDU  Sun Feb 12 10:40:09 1995
From: samman at CS.YALE.EDU (Ben)
Date: Sun, 12 Feb 95 10:40:09 PST
Subject: Privacy digest an all
Message-ID: <Pine.SUN.3.91.950212133556.11884A-100000@jaguar.zoo.cs.yale.edu>


I found this on another list that I"m on.  I have no connection at all 
with the distributor, but I thought that it would be interesting to share 
it with the list.

Ben.

________


1.  New Publication: PRIVACY & GEMS: HOW TO AVOID THE PRIVACY INVADERS
We all have something to hide, right?  From nosy neighbors, burglars, our
spouses, private detectives, but most of all the government and business.
In this 38-page booklet, you will  learn how the government and business,
through the extensive use of super-computers, is compiling data on ever
facet of your life.  Discover exactly how they do it.  The amount of
information kept on you is astounding: bank statements, investments,
credit histories, medical records, school transcripts, driving histories,
videotape rentals, retail purchases, tax returns, legal records, and more!
This booklet explains who is collecting information on you and what they
are doing with it.  Your dossier is compiled and sold without your
permission or knowledge.  Find out what technologies are available today,
and their frightening implications for tomorrow.  We are on the verge of a
1984 Orwellian-type Police State!

How can you keep some of your life private?  After you read this booklet,
at least you will have some idea! Learn how to make untraceable telephone
calls.  Be prepared for the New Money . There are a few  low-profile
investments that do not generate reports to business or  government.  Learn
what they are and how to go about protecting yourself from the privacy
invaders.  Once you have shifted some of your assets from high -profile
assets to low-profile assets, learn how to store and conceal them so you
will not be discovered.  Subjects covered include:
Why Privacy?, Political Persecution, High-Risk Business, Divorce, Probate,
Protection from Robbery, Protection from Government Seizure, The Future:
The Total Surveillance State, "Smart Cars", "Smart Cards", "Video
Surveillance", "Satellite, Surveillance", "Clipper Chip", "Robot Spies", The
Future Workplace:  A Look At Electronic Banking System, Inc., How Profiles
Are Created, Damaging Dossiers, Privacy And The  Telephone, The New Be A
Private Investor, An Analysis Of Low-Profile Investments, Diamonds and
Precious Gems, Rare Coins, Foreign Currency, Collectibles, 
Cash, The Tangible Investment Philosophy, Recent DeBeers Diamond Price
Hikes, Long Term Investment Gem Performance, Low-Profile Strategies In A
High-Profile World, Confidential Model Portfolio For Privacy Clients, 10
Rules For Gem Investing, How To Safeguard Your Valuables.  This is an
excellent tool for anyone concerned with our vanishing privacy.  Here is how
you order:  Send $9.95 ppd (includes first class postage). Illinois
Residents add 6.5% sales tax.  to: Superior Broadcasting Company, Box 668,
Lindenhurst, IL 60046.  Request #119O  "Privacy & Gems: A Special Report by
Bob Genis"





From shamrock at netcom.com  Sun Feb 12 11:19:25 1995
From: shamrock at netcom.com (Lucky Green)
Date: Sun, 12 Feb 95 11:19:25 PST
Subject: Design my protocol
Message-ID: <v01510100ab640747eb76@[192.0.2.1]>


Here's a question for all the gurus out there: I work for a company that
manufactures a new concept in telephony hardware. The system we developed
essentially replaces PBXs with an off-the-shelf computer, some special
cards, and some software. Our system will offer all the features that you'd
expect from current PBXs, such as least cost routing, as well as other
features that can't be provided by a standard PBX.

When a customer sets up a site, the system connects via a modem to our
server, from which the system retrieves software, routing tables, etc. We
also offer periodic software updates, and software based add-on features
for an additional free. We would like to be able to upgrade, and in some
cases control, the sites by remote and we would like the customer to be
able to purchase extra software from us via modem or over the net. We use
TCP/IP and SNMP to comunicate with the sites. We want to include strong
crypto from the begining for several purposes:

-Link encryption between the customer sites and us.
-Authentication of the upgrade software.
-Secure purchases and transmision of software both via dial-up and the Internet.
-Optional encryption of the (telephony) data carried between sites.

I understand that the last issue is somewhat different from the others, I
just mentioned it to complete the picture. For now I need a solution for
the first two or three questions. We need something that can be delivered
to the customer six months from now, not something that may make it out of
a standard comittee years from now.

Thanks in advance,


-- Lucky Green <shamrock at netcom.com>
   PGP encrypted mail preferred.







From kinney at bogart.Colorado.EDU  Sun Feb 12 11:33:39 1995
From: kinney at bogart.Colorado.EDU (W. Kinney)
Date: Sun, 12 Feb 95 11:33:39 PST
Subject: the problem that destroyed PGP
In-Reply-To: <199502121820.KAA04736@jobe.shell.portal.com>
Message-ID: <199502121933.MAA12403@bogart.Colorado.EDU>



Hal Finney writes, in regard to web-of-trust:

> But this is not quite right.  The fundamental fact about PGP key signatures,
> which is often misunderstood, is this:
> 
> You can only communicate securely with someone whose key is signed by a person
> you know, either personally or by reputation.
> 
> In other words, if I want to communicate with joe at abc.com, I can only do so
> if one of the signators of his key is a person I know.  If not, I have no way
> of judging the validity of his key.

There are, however, degrees of certainty here. The only person I trust
implicitly to sign keys is myself. If I have a key which is separated from
me by more than one hop in the web of trust, but still connected to me
via a chain of signatures, I have more certainty that this key is valid
than I do for an unsigned key. Granted, if I don't know the actual signator
of a particular key, my level of trust in the key's validity is pretty
low, but it's nonzero as long as it's connected by a chain of signatures.
The ease of mounting of a man-in-the-middle attack decreases with increasing 
signature connectivity, no?

Of course, the reality is that use of totally unverified PGP keys is
widespread, even among people who are well educated on the subject. This
is not a good thing in the long run.


                                  -- Will






From rfb at lehman.com  Sun Feb 12 12:33:25 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Sun, 12 Feb 95 12:33:25 PST
Subject: MIME based remailing commands
In-Reply-To: <0jCxBn=0Eyt5AxShYL@nsb.fv.com>
Message-ID: <9502122031.AA23722@cfdevx1.lehman.com>


    Date: Fri, 10 Feb 1995 15:58:27 -0500 (EST)
    From: Nathaniel Borenstein <nsb at nsb.fv.com>
    
    Well, I have no idea why you think that MIME is an "atrocity" or
    "slime", but it is perfectly clear that you have no idea what it
    actually *is*, since "X-" headers have nothing whatsoever to do with
    MIME.  The "X-" headers are defined by RFC 822, which has been the
    standard for Internet mail formats since 1982.

You base a large conclusion on a small piece of data in combination
with some poor duduction.  Unless you are claiming that MIME violates
RFC 822 with respect to the handling of X- headers you have made a
number of false claims in the paragraph above.
    
    Perhaps you should learn what MIME is before you embarass yourself
    further.

Unless it has changed radically in the 6 months since I read all of
the RFCs that were then available (I believe that rtfm.mit.edu was my
source at the time), then I have already taken the step that you
suggest -- in fact, it is largely what caused me to form the opinions
that I have with respect to MIME.  It is possible for someone to find
ugliness where you find beauty without them necessarily being
uninformed.

I must admit that Perry's references to secure multi-parts make me
think that another review is in order.  I'm certainly not an expert,
but then nothing in what was readily available provided much
encouragement for further exploration.  However, I have learned enough
of what MIME is that I am not embarrased by your incorrect inferences.

			Rick





From cjl at welchlink.welch.jhu.edu  Sun Feb 12 12:55:43 1995
From: cjl at welchlink.welch.jhu.edu (cjl)
Date: Sun, 12 Feb 95 12:55:43 PST
Subject: Q: ref. for DNA used to solve math. network prob. (fwd)
In-Reply-To: <199502121623.KAA00375@einstein.ssz.com>
Message-ID: <Pine.SOL.3.91.950212154435.623A-100000@welchlink.welch.jhu.edu>


On Sun, 12 Feb 1995, root wrote:

[forwarded note from jwgruber deleted]

> >
> Only peripheraly related to crypto but has anyone got any info on this?
> 

Here is the reference, additionally there is a nice News & Views article 
on page 993-994 of the same issue..

Author   Adleman LM. 

Title    MOLECULAR COMPUTATION OF SOLUTIONS TO COMBINATORIAL PROBLEMS.
   
Source   Science.  266(5187):1021-1024, 1994 Nov 11.

Abstract
    The tools of molecular biology were used to solve an instance of 
the directed Hamiltonian path problem. A small graph was encoded in 
molecules of DNA, and the ''operations'' of the computation were performed 
with standard protocols and enzymes. This experiment demonstrates 
the feasibility of carrying out computations at the molecular 
level.  

C. J. Leonard                     (    /      "DNA is groovy"
                                   \ /                - Watson & Crick
<cjl at welchlink.welch.jhu.edu>      / \     <--  major groove
                                  (    \
Finger for public key               \   )
Strong-arm for secret key             /    <--  minor groove
Thumb-screws for pass-phrase        /   )





From rishab at dxm.ernet.in  Sun Feb 12 13:23:03 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Sun, 12 Feb 95 13:23:03 PST
Subject: Involve Telcos in activism?
Message-ID: <gate.c97F1c1w165w@dxm.ernet.in>


storm at marlin.ssnet.com (Don Melvin):
>        Telecoms have bucks.
>        Telecoms have lawyers.
>        Telecoms are the 'transmission' agents for pretty much all of
>                the internet. Even high speed dedicated T1s are usually
>                from a telecom or two.

That's a laugh! Yes, it would be a good idea to involve telcos in our cause, 
but it was my impression that most cypherpunks expressed derision for the EFF 
for 'compromising' (i.e. being realistic). Telcos do not necessarily share the 
interests of cypherpunks; they want to make money, that's all. They'd love to 
compromise, and provide funding for CDT, Jerry Berman's new lobbying outfit. 
A good example of their attitude is what they do in India, or China. Here none 
of them are too keen to say anything against some of our ancient and idiotic 
laws, and they're all happy to budget for huge and unjustified 'licence fees' 
because they want to lick state ass. They want to grab these huge markets 
before it's too late, free speech be damned.


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From rishab at dxm.ernet.in  Sun Feb 12 13:23:49 1995
From: rishab at dxm.ernet.in (rishab at dxm.ernet.in)
Date: Sun, 12 Feb 95 13:23:49 PST
Subject: Clinton's No Warrant decree, and insulting dogs
Message-ID: <gate.kq8F1c1w165w@dxm.ernet.in>


Brad Dolan <bdolan at use.usit.net>:
> WARRENTLESS SEARCHES CAN NOW BE APPROVED BY FREEH, RENO, DOD, ET.
> AL. AND CONDUCTED BY ANY FED AGENCY.  DUE TO THE CRIME BILL, THE FED
> AGENCIES ARE NOW ALL OPERATING IN CONSOLIDATED "TASK FORCES."

Clinton's recent high-profile resort to executive orders reminds me of 
Yeltsin's 'democracy by decree'. I await with interest an American Chechnya.

However with the latest one he seems not to be ordering anything new, he's
just pulled something out of the legislative hat, he's just using powers
he's been given under the cited subsections of the Foreign Intelligence Act.
He seems happy to follow whatever little safeguards it has. How that Act
was never ruled unconstitutional beats me. 

Why is Clinton kowtowing to the Notional Security Agency and the Federal
Bureau of Instigation all of a sudden? Is this a 'law-and-order' shift to
the right of a New New Democrat?

Can we all stop insulting dogs? Lawrence Detweiler can be safely refered to
as LD. Rottweilers, as a correspondent writes with "great umbrage" in last 
week's Time, are "handsome, noble, courageous and steadfastly loyal."


-----------------------------------------------------------------------------
For Electric Dreams subscriptions and back issues, send a mail to
rishab at arbornet.org with 'get help' as the message Subject.

Rishab Aiyer Ghosh          rishab at dxm.ernet.in           rishab at arbornet.org
Vox +91 11 6853410 Voxmail 3760335       H 34C Saket, New Delhi 110017, INDIA  





From jya at pipeline.com  Sun Feb 12 15:07:04 1995
From: jya at pipeline.com (John Young)
Date: Sun, 12 Feb 95 15:07:04 PST
Subject: Clinton's No Warrant decree, and insulting dogs
Message-ID: <199502122306.SAA27050@pipe2.pipeline.com>



Responding to msg by rishab at dxm.ernet.in () on Mon, 13 Feb  
1:26 AM


>Why is Clinton kowtowing to the Notional Security 
>Agency and the Federal  Bureau of Instigation all of a 
>sudden? Is this a 'law-and-order' shift to  the right 
>of a New New Democrat?



The NY Times report today on the near miss of "terrorist 
mastermind" Yousef in Manila after a kitchen blaze of 
cooking-up explosives, says that he was seen walking rapidly 
away talking on a cellular phone.


Allegedly left behind on a laptop was a disk "filled with 
details of his plots to kill Pope John Paul II, and to blow up 
American jets flying in the Far East."


Twenty (20) FBI agents were sent to pick him up in Islamabad, 
Pakistan for safe home in the New York.


A concerned citizen may ask:


What was picked up from the phone, or will be affidavited to 
have been picked up.


What was on the disk, or will be solemnly sworn to have been 
found on the disk.


And, finally, what armament and intergalatic technology 
accompanied the SWAT team -- over and back, to provide full 
cloak and security on land, sea and air?  And, with that show 
as spoof, how was he really imported?  How many other fake 
transports were set in motion?


When will we learn more of the lurid Clancy-juicy details of 
this black-op budget-busting crowd-pleaser?


Is this a laptop dog and pony?  No offense to Fifi and Holy 
Bull and Apple.






From schneier at chinet.chinet.com  Sun Feb 12 15:39:37 1995
From: schneier at chinet.chinet.com (schneier at chinet.chinet.com)
Date: Sun, 12 Feb 95 15:39:37 PST
Subject: Factoring - State of the Art and Predictions
Message-ID: <m0rdnqt-000k5xC@mailbox.mcs.com>


((Comments are appreciated.  -Bruce))


Factoring large numbers is hard.  Unfortunately for algorithm
designers, it is getting easier.  Even worse, it is getting
easier faster than mathematicians expected.  In 1976 Richard Guy
wrote: "I shall be surprised if anyone regularly factors numbers
of size 10^80 without special form during the present century." 
In 1977 Ron Rivest said that factoring a 125-digit number would
take 40 quadrillion years.  In 1994 a 129-digit number was
factored.  If there is any lesson in all this, it is that making
predictions is foolish.

Table 1 shows factoring records over the past dozen years.  The
fastest factoring algorithm during the time was the quadratic
sieve.

         Table 1:  Factoring Using the Quadratic Sieve

         year     # of decimal               how many times harder to
                  digits factored            factor a 512-bit number
         1983     71                         > 20 million
         1985     80                         > 2 million
         1988     90                         250,000
         1989     100                        30,000
         1993     120                        500
         1994     129                        100

These numbers are pretty frightening.  Today it is not uncommon
to see 512-bit numbers used in operational systems.  Factoring
them, and thereby completely compromising their security, is well
in the range of possibility: A weekend-long worm on the Internet
could do it.

Computing power is generally measured in mips-years: a one-
million-instruction-per-second computer running for one year, or
about 3*10^13 instructions.  By convention, a 1 mips machine is
equivalent to the DEC VAX 11/780.  Hence, a mips-year is a VAX
11/780 running for a year, or the equivalent.

The 1983 factorization of a 71-digit number required 0.1 mips-
years; the 1994 factorization of a 129-digit number required
5000.  This dramatic increase in computing power resulted largely
from the introduction of distributed computing, using the idle
time on a network of workstations.  The 1983 factorization used
9.5 CPU hours on a single Cray X-MP; the 1994 factorization used
the idle time on 1600 computers around the world for about 8
months.  Modern factoring methods lend themselves to this kind of
distributed implementation.

The picture gets even worse.  A new factoring algorithm has taken
over from the quadratic sieve: the general number field sieve. 
In 1989 mathematicians would have told you that the general
number field sieve would never be practical.  In 1992 they would
have told you that it was practical, but only faster than the
quadratic sieve for numbers greater than 130-150 digits or so. 
Today it is known to be faster than the quadratic sieve for
numbers well below 116 digits.  The general number field sieve
can factor a 512-bit number over 10 times faster than the
quadratic sieve.  The algorithm would require less than a year to
run on an 1800-node Intel Paragon.  Table 2 gives the number of
mips-years required to factor numbers of different sizes, given
current implementations of the general number field sieve.

         Table 2: Factoring Using the General Number Field Sieve

         # of bits         mips-years required to factor

         512               30,000
         768               2*10^8
         1024              3*10^11
         1280              1*10^14
         1536              3*10^16
         2048              3*10^20

And the general number field sieve is still getting faster. 
Mathematicians keep coming up with new tricks, new optimizations,
new techniques.  There's no reason to think this trend won't
continue.  A related algorithm, the special number field sieve,
can already factor numbers of a certain specialized form--numbers
not generally used for cryptography--must faster than the general
number field sieve can factor general numbers of the same size. 
It is not unreasonable to assume that the general number field
sieve can be optimized to run this fast; it is possible that the
NSA already knows how to do this.  Table 3 gives the number of
mips-years required for the special number field sieve to factor
numbers of different lengths.

         Table 3: Factoring Using the Special Number Field Sieve

         # of bits         mips-years required to factor

         512               < 200
         768               100,000
         1024              3*10^7
         1280              3*10^9
         1536              2*10^11
         2048              4*10^14

At a European Institute for System Security workshop in 1992, the
participants agreed that a 1024-bit modulus should be sufficient
for long-term secrets through 2002.  However, they warned: 
"Although the participants of this workshop feel best qualified
in their respective areas, this statement [with respect to
lasting security] should be taken with caution."  This is good
advice.

The wise cryptographer is ultra-conservative when choosing
public-key key lengths.  To determine how long a key you need
requires you to look at both the intended security and lifetime
of the key, and the current state-of-the-art of factoring.  Today
you need a 1024-bit number to get the level of security you got
from a 512-bit number in the early 1980s.  If you want your keys
to remain secure for 20 years, 1024 bits is likely too short.

Even if your particular secrets aren't worth the effort required
to factor your modulus, you may be at risk.  Imagine an automatic
banking system that uses RSA for security.  Mallory can stand up
in court and say: "Did you read in the newspaper in 1994 that
RSA-129 was broken, and that 512-bit numbers can be factored by
any organization willing to spend a few million dollars and wait
a few months?  My bank uses 512-bit numbers for security, and by
the way I didn't make these seven withdrawals."  Even if Mallory
is lying, the judge will probably put the onus on the bank to
prove it.

Earlier I called making predictions foolish.  Now I am about to
make some.  Table 4 gives my recommendations for public-key
lengths, depending on how long you require the key to be secure. 
There are three key lengths for each year, one secure against an
individual, one secure against a major corporation, and the third
secure against a major government.

Here are some assumptions from the mathematicians who factored
RSA-129:

         We believe that we could acquire 100 thousand machines
         without superhuman or unethical efforts.  That is, we would
         not set free an Internet worm or virus to find resources for
         us.  Many organizations have several thousand machines each
         on the net.  Making use of their facilities would require
         skillful diplomacy, but should not be impossible.  Assuming
         the 5 mips average power, and one year elapsed time, it is
         not too unreasonable to embark on a project which would
         require half a million mips years.

The project to factor the 129-digit number harnesses an estimated
0.03% of the total computing power of the Internet, and they
didn't even try very hard.  It isn't unreasonable to assume that
a well-publicized project can harness 0.1% of the world's
computing power for a year.

Assume a dedicated cryptanalyst can get his hands on 10,000 mips-
years, a large corporation can get 10^7 mips-years, and that a
large government can get 10^9 mips-years.  Also assume that
computing power will increase by a factor of ten every five
years.  And finally, assume that advances in factoring
mathematics allows us to factor general numbers at the speeds of
the special number field sieve.  Table 4 recommends different key
lengths for security during different years.

         Table 4: Recommended public-key key lengths (in bits)

         Year     vs. I             vs. C             vs. G
         1995      768              1280              1536
         2000     1024              1280              1536
         2005     1280              1536              2048
         2010     1280              1536              2048
         2015     1536              2048              2048

Remember to take the value of the key into account.  Public keys
are often used to secure things of great value for a long time:
the bank's master key for a digital cash system, the key the
government uses to certify its passports, a notary public's
digital signature key.  It probably isn't worth the effort to
spend months of computing time to break an individual's private
key, but if you can print your own money with a broken key the
idea becomes more attractive.  A 1024-bit key is long enough to
sign something that will be verified within the week, or month,
or even a few years.  But you don't want to stand up in court
twenty years from now with a digitally signed document, and have
the opposition demonstrate how to forge documents with the same
signature.

Making predictions beyond the near future is even more foolish. 
Who knows what kind of advances in computing, networking, and
mathematics are going to happen by 2020?  However, if you look at
the broad picture, in every decade we can factor numbers twice as
long as in the previous decade.  This leads to Table 5.

         Table 5:  Long-range factoring predictions 

         Year     Key length (in bits)
         1995     1024
         2005     2048
         2015     4096
         2025     8192
         2035     16,384
         2045     32,768

Not everyone will agree with my recommendations.  The NSA has
mandated 512-bit to 1024-bit keys for their Digital Signature
Standard--far less than I recommend for long-term security.  PGP
has a maximum RSA key length of 1280 bits.  Lenstra, the world's
most successful factorer, refuses to make predictions past ten
years.  And Table 6 gives Ron Rivest's key-length
recommendations, originally made in 1990, which I consider much
too optimistic.  While his analysis looks fine on paper, recent
history illustrates that surprises regularly happen.  It makes
sense to choose your keys to be resilient against future
surprises.

         Table 6: Rivest's Optimistic Key-Length Recommendations (In
         Bits)

         Year     Low      Avg      High
         1990     398      515      1289
         1995     405      542      1399
         2000     422      572      1512
         2005     439      602      1628
         2010     455      631      1754
         2015     472      661      1884
         2020     489      677      2017

         Low estimates assume a budget of $25,000, the quadratic
         sieve algorithm, and a technology advance of 20% per year. 
         Average estimates assume a budget of $25 million, the
         general number field sieve algorithm, and a technology
         advance of 33% per year.  High estimates assume a budget of
         $25 billion, a general quadratic sieve algorithm running at
         the speed of the special number field sieve, and a
         technology advance of 45% per year.

There is always the possibility that an advance in factoring will
surprise me as well, but I think that unlikely.  But why trust
me?  I just proved my own foolishness by making predictions.




From lmccarth at ducie.cs.umass.edu  Sun Feb 12 15:45:24 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Sun, 12 Feb 95 15:45:24 PST
Subject: UMich student arrested for rape story
In-Reply-To: <199502121026.CAA19268@igc3.igc.apc.org>
Message-ID: <199502122347.SAA15127@ducie.cs.umass.edu>


Rich Dutcher writes:
> However, given the information available to date, I see no reason to 
> believe that he's been busted for writing "erotic fiction"  rather than 
> threatening a woman.  

The July `94 issue of Harper's described the case of a Menlo Park city 
employee who claimed in 1993 to be harassed by some paintings of female nudes
hanging in a hallway. The city removed the paintings the following day. It
used to be that when the majority of people in some state/county/town 
disapproved of some instance of expression, they could suppress it. This was
bad. Nowadays, it takes just one zealot to suppress it. This is much worse.
As far as I can see, anyone can claim to be harassed/threatened/offended by
just about anything, and get away with it.  Just the other day, I heard that
in Vermont (or was it New Hampshire ?), they're still talking seriously about
an amendment to the state constitution against burning the U.S. flag. Between
the censors on the left and the censors on the right, there's precious little
room remaining for those of us in the middle who believe in tolerating
divergent views.

It appears to me that people on the left are choosing (wrongly, IMHO) to 
interpret a work of fiction as a threat, and proceed from there. I imagine
that people on the right don't see the work of fiction as a threat to her, but 
simply want to ban fictional works they dislike anyway.

> Violence against women is too real, 

Strongly agreed, but a newsgroup article is not an act of violence.

> and in other contexts courts have held to a standard of what a "reasonable 
> woman" might fear.

Well, we'll have to see how it goes. It's tough for me to see why a 
"reasonable woman" would fear an article of which she was totally unaware.

I get the impression that neither did he imply a threat, nor did she infer a
threat. 

> BTW, does alt.sex.stories presume fiction, or is it pretend truth 
> like the readers' sex stories in Penthouse?

I don't know for sure, though I expect alt.sex.wizards would be more likely
to fall in the latter category :] .

-L. Futplex McCarthy




From zachary at pentagon.io.com  Sun Feb 12 16:12:48 1995
From: zachary at pentagon.io.com (Zachary)
Date: Sun, 12 Feb 95 16:12:48 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <m0rdnqt-000k5xC@mailbox.mcs.com>
Message-ID: <199502130012.SAA17341@pentagon.io.com>



This touches on something I was thinking the other day:  Most
cryptosystems that we seem to use are based on the assumption that
factoring large numbers is a Hard Problem.  Isn't this putting all our
eggs in one basket?  Are there other Hard Problems crypto systems can be
based on?  In the ludicrous case, suppose Eve is visited by aliens and
given a black box that would instantly factor a number irrelevant of its
size... how much of current cryptography would this device invalidate? 
I'm no crypto-expert, so I don't know... but surely there are other hard
problems in the universe that we can base crypto on...

 --Zachary







From jrochkin at cs.oberlin.edu  Sun Feb 12 16:53:30 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Sun, 12 Feb 95 16:53:30 PST
Subject: Factoring - State of the Art and Predictions
Message-ID: <ab645cdf0102100421a7@[132.162.201.201]>


At 7:12 PM 02/12/95, Zachary wrote:
>This touches on something I was thinking the other day:  Most
>cryptosystems that we seem to use are based on the assumption that
>factoring large numbers is a Hard Problem.  Isn't this putting all our
>eggs in one basket?  Are there other Hard Problems crypto systems can be

Keep in mind that it's been mathematically proven that factoring is
NP-complete.  That is, it's in the set of problems including such things as
discrete logs and the travelling salesman problem, such that if a
polynomial time solution is found to _any_ of these problems, one can be
found for all of them.  Of course it hasn't been proven that none of the
problems in NP can be solved in polynomial time, so it hasn't been proven
that these are "hard problems".  But I suspect that most problems suspected
to be Hard Problems that one could base a crypto system off of, are also
NP-complete, so it wouldn't be any better to use them then to use
factoring.   Logarithms, for instance, are used in some crypto systems, and
are another suspected Hard Problem, but are also NP complete.  So if
factoring is solved,  discrete logarithms will be solved too.

At least that's how I understand it.







From jamesd at netcom.com  Sun Feb 12 17:09:06 1995
From: jamesd at netcom.com (James A. Donald)
Date: Sun, 12 Feb 95 17:09:06 PST
Subject: Factoring - State of the Art and Predictions
Message-ID: <Pine.3.89.9502121608.A20084-0100000@netcom10>


Zachary <zachary at pentagon.io.com> wrote:
 Most cryptosystems that we seem to use are based
on the assumption that factoring large numbers is a Hard Problem.  Isn't
this putting all our eggs in one basket?  Are there other Hard Problems
crypto systems can be based on?

There is of course the discrete log problem - DH and all that.

Unfortunately, although the discrete log problem has not been
shown to be equivalent to the factoring problem, every 
factoring advance immediately leads to a corresponding
discrete log advance and vice versa, and the two problems
take a very similar length of time to solve, suggesting
that the two problems have some deep equivalence.

So far no one has found a way of applying NP problems to
Crypto.

And that pretty much wraps it up.

There are of course a lot of hard problems that are not NP,
yet probably take exponential time, but obviously you
want a well understood problem that is part of conventional
mathematics.

This narrows the field rather drastically.

Discrete log and factoring pretty much covers it.

Of course you can do discrete log on weird fields -- there
is a lot of research in that which I do not understand at all.

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From jamesd at netcom.com  Sun Feb 12 17:13:08 1995
From: jamesd at netcom.com (James A. Donald)
Date: Sun, 12 Feb 95 17:13:08 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <ab645cdf0102100421a7@[132.162.201.201]>
Message-ID: <Pine.3.89.9502121727.A20084-0100000@netcom10>


On Sun, 12 Feb 1995, Jonathan Rochkind wrote:
> Keep in mind that it's been mathematically proven that factoring is
> NP-complete.  That is, it's in the set of problems including such things as
> discrete logs and the travelling salesman problem, such that if a
> polynomial time solution is found to _any_ of these problems, one can be
> found for all of them. i

This is news to me!

I am fairly sure that factoring and discrete log are *not*
NP complete, and indeed there is no known way to use
NP complete problems for crypto.


 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From mab at crypto.com  Sun Feb 12 17:17:01 1995
From: mab at crypto.com (Matt Blaze)
Date: Sun, 12 Feb 95 17:17:01 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <ab645cdf0102100421a7@[132.162.201.201]>
Message-ID: <199502130119.UAA03807@crypto.com>



Johnathan Rochkind writes:
>
>Keep in mind that it's been mathematically proven that factoring is
>NP-complete.
...

No it hasn't.  Factoring is believed to be hard, but no one has ever
shown it to be NP-hard (let alone NP complete).

...
>factoring.   Logarithms, for instance, are used in some crypto systems, and
>are another suspected Hard Problem, but are also NP complete.  So if
>factoring is solved,  discrete logarithms will be solved too.

Ditto for discrete log.

-matt





From perry at imsi.com  Sun Feb 12 17:21:31 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 12 Feb 95 17:21:31 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <Pine.3.89.9502121608.A20084-0100000@netcom10>
Message-ID: <9502130121.AA19540@snark.imsi.com>



"James A. Donald" says:
> So far no one has found a way of applying NP problems to
> Crypto.

Further than that, it has been shown that a large class of ways to
apply NP complete problems to crypto are insecure -- this being
generalizations of the break of the knapsack problem based
cryptosystems...

> Of course you can do discrete log on weird fields -- there
> is a lot of research in that which I do not understand at all.

Most of the eliptic curve stuff maps pretty straightforwardly into
the "normal" case and vice versa.

.pmm





From jrochkin at cs.oberlin.edu  Sun Feb 12 17:26:36 1995
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Sun, 12 Feb 95 17:26:36 PST
Subject: Factoring - State of the Art and Predictions
Message-ID: <ab64660a03021004491e@[132.162.201.201]>


At 8:19 PM 02/12/95, Matt Blaze wrote:
>No it hasn't.  Factoring is believed to be hard, but no one has ever
>shown it to be NP-hard (let alone NP complete).

Woops.  Thanks for the correction, and thanks to everyone else who managed
to correct me within only minutes after I made the mistake.  :)  You can
all stop sending me mail now.

[Moral of the story: don't make a math error on the cypherpunks list.]







From doug at OpenMind.com  Sun Feb 12 17:33:06 1995
From: doug at OpenMind.com (Doug Cutrell)
Date: Sun, 12 Feb 95 17:33:06 PST
Subject: Factoring - State of the Art and Predictions
Message-ID: <ab6456634e021003a86a@[198.232.141.2]>


Bruce Schneier gives us:

>         Table 4: Recommended public-key key lengths (in bits)
>
>         Year     vs. I             vs. C             vs. G
>         1995      768              1280              1536
>         2000     1024              1280              1536
>         2005     1280              1536              2048
>         2010     1280              1536              2048
>         2015     1536              2048              2048


I applaud Bruce for making this unpopular presentation of the somber facts.
If these figures are taken seriously, the conclusion is that 1024 bit keys
are not even good TODAY if one is concerned about the C or G level attack.
In fact, not even the 1280 bit key is good for G level attack today.

Pay attention, people.  Factoring is still a good cryptographic approach,
but the key lengths have to keep growing larger.  Factoring may be NP-hard
in the key length, but the rate of growth of our ability to factor is
actually going up exponentially as well.  The speed of encryption and
decryption for 2048 bit keys on my Pentium is quite reasonable today... and
my confidence in the long-term security of my encrypted files has increased
considerably with the advent of PGP 2.6.2, for just that reason.

Doug Cutrell

_____________________________________________________________
Doug Cutrell                    General Partner
doug at OpenMind.com               Open Mind, Santa Cruz
=============================================================







From perry at imsi.com  Sun Feb 12 17:45:56 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 12 Feb 95 17:45:56 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <m0rdnqt-000k5xC@mailbox.mcs.com>
Message-ID: <9502130145.AA19584@snark.imsi.com>



schneier at chinet.chinet.com says:
> Making predictions beyond the near future is even more foolish. 
> Who knows what kind of advances in computing, networking, and
> mathematics are going to happen by 2020?  However, if you look at
> the broad picture, in every decade we can factor numbers twice as
> long as in the previous decade.  This leads to Table 5.

I'm not sure I agree with this assumption. From current knowledge, it
seems that factoring is still exponential -- we've just progressed on
the algorithms a bit. That can't continue forever, though. Assuming
algorithms remain stable on your most optimistic estimate (which would
require some advances even so), we would assume that factoring would
remain exponential, and that adding a constant number of bits to a
number would add a constant factor to the increase in
complexity. Since computing speeds are also rising exponentially, but
not superexponentially, we would assume that the number of bits we
could factor would grow linearly with time -- that is, each decade
would see numbers about another 60-80 digits long factored. This would
mean that every doubling in key length would give us more than just a
constant increase in the safety factor.

Perry





From mpd at netcom.com  Sun Feb 12 18:19:13 1995
From: mpd at netcom.com (Mike Duvos)
Date: Sun, 12 Feb 95 18:19:13 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <m0rdnqt-000k5xC@mailbox.mcs.com>
Message-ID: <199502130218.SAA00223@netcom3.netcom.com>


schneier at chinet.chinet.com writes:

 > ((Comments are appreciated.  -Bruce))

Ok.

[Nice historical presentation of factoring snipped]

 > A new factoring algorithm has taken over from the quadratic
 > sieve: the general number field sieve. In 1989
 > mathematicians would have told you that the general number
 > field sieve would never be practical.

 > In 1992 they would have told you that it was practical, but
 > only faster than the quadratic sieve for numbers greater
 > than 130-150 digits or so. Today it is known to be faster
 > than the quadratic sieve for numbers well below 116 digits.

 > The general number field sieve can factor a 512-bit number
 > over 10 times faster than the quadratic sieve.

The GNFS situation is a little bit more complicated than that.
Today's factoring algorithms work by finding distinct square
roots of the same quadratic residue modulo the number to be
factored.  Each such discovery yields an approximately 50% chance
of factoring the number using Euclid's GCD algorithm.

Since searching directly for a congruence of squares would be
grossly inefficient, one sieves for relations involving arbitrary
powers of numbers from a set called the "factor base", and after
collecting an overdetermined number of such relations, finds
their null space modulo two in huge matrix operation.  This
yields a relation whose powers are all even, from which a
congruence of squares may be constructed in an obvious manner.

Most popular factoring methods including NFS, GNFS, and numerous
flavors of QS utilize this general scheme, and differ only in the
numbers to which they are applicable and in the methods that they
use to fish for relations in more densely populated mathematical
waters.

GNFS uses a particularly cute trick, which is to express the
number being factored as a polynomial with small coefficients,
evaluated at a small argument.  On can then construct a
homomorphism from a ring of algebraic integers into Z/nZ. This
permits sieving to be conducted in a particularly efficient
fashion.

Finding such a polynomial, unfortunately, is a far from
straightforward task.  Current state of the art is to start with
a guess, and flog it to death on a workstation for several days,
attempting some sort of stepwise refinement.  Although the
problem is mathematically rich, no systematic method currently
exists to pick the "best" polynomial, and the problem of doing so
may be of a difficulty comparable to factoring.

The speed with which GNFS runs and the degree to which it
outperforms QS is extremely sensitive to the polynomial chosen,
so the blanket statement that GNFS outperforms QS by a factor of
10 on 512 bit numbers is in my opinion, a bit of an
oversimplification.

GNFS is one of the most complicated computer algorithms to be
constructed, sieving and factoring simultaneously in both a ring
of algebraic integers and in Z/nZ. The algorithm has been known
to experience "cycle explosions" in which unexpectly large
amounts of raw data are produced from relatively small numbers.
It is certainly not something that can be regularly run in
"production mode" and it requires a skilled operator (currently
its creator) to help it coast smoothly through its various
stages.

I don't think GNFS is going to be available in shrink-wrapped
form for quite some time. :)

 > A related algorithm, the special number field sieve, can
 > already factor numbers of a certain specialized
 > form--numbers not generally used for cryptography--must
 > faster than the general number field sieve can factor
 > general numbers of the same size.

NFS and GNFS are essentially the same algorithm.  NFS is simply a
special case where a particularly simple polynomial is known,
Z[a] is a unique factorization domain, and some other nice
algebraic properties are present.  In the case of a general
integer, and a more complex polynomial, some things get messier.

 > It is not unreasonable to assume that the general number
 > field sieve can be optimized to run this fast; it is
 > possible that the NSA already knows how to do this.

I think this is unlikely.  The difference in speed is due to the
fact that NFS only factors specially chosen simple numbers, and
GNFS factors anything.  That is not something that is likely to
be optimized away.

Also, I think we make far to much of the magical ability of the
NSA to do things.  At the present point in time, most of the
cryptomathematical expertise in the world is external to the NSA.
The NSA didn't invent GNFS, or for that matter, public key
cryptography.

 > Making predictions beyond the near future is even more
 > foolish. Who knows what kind of advances in computing,
 > networking, and mathematics are going to happen by 2020?
 > However, if you look at the broad picture, in every decade
 > we can factor numbers twice as long as in the previous
 > decade.

GNFS probably represents the final step in the evolution of the
"combination of congruences" factoring methods.  Further
refinements would probably be such complicated algorithms as to
be inpractical to program.

Additional improvements in our ability to break RSA will probably
come via some new factoring scheme that we are presently unaware
of, or via a method of computing the inverse of the encryption
permutation used by RSA which does not require explicit formation
of the factors of the modulus.

 >          Table 5:  Long-range factoring predictions

 >          Year     Key length (in bits)
 >          1995     1024
 >          2005     2048
 >          2015     4096
 >          2025     8192
 >          2035     16,384
 >          2045     32,768

I think factoring technology may reach its "Omega Point" long
before 2045.  Twenty years from now, we might be able to factor
anything.  I think predictions past ten years are pure
speculation.

 > There is always the possibility that an advance in
 > factoring will surprise me as well, but I think that
 > unlikely.

I expect to be surprised by an advance in factoring momentarily.
You are far too pessimistic. :)

-- 
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd at netcom.com     $    via Finger.                      $




From perry at imsi.com  Sun Feb 12 18:31:17 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Sun, 12 Feb 95 18:31:17 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
In-Reply-To: <199502130218.SAA00223@netcom3.netcom.com>
Message-ID: <9502130231.AA19651@snark.imsi.com>



Mike Duvos says:
> Also, I think we make far to much of the magical ability of the
> NSA to do things.  At the present point in time, most of the
> cryptomathematical expertise in the world is external to the NSA.
> The NSA didn't invent GNFS, or for that matter, public key
> cryptography.

I'm on both sides of this issue. On the one hand, the people in the
open crypto community are now, or soon will, substantially exceed in
number the people in the black community, and the people in the open
community have certain advantages in the way that they do their
work. On the other hand, the people in the black community have the
advantage that they can read anything that the open community produces
but not vice versa, and they have at least a 15 year edge in knowledge
about the design of conventional systems, and who knows (we certainly
have no idea) how much of an edge in the modern cryptographic
arena. We don't know for sure if the NSA knew about Public Key before
the open community did. Certainly they knew of differential
cryptanalysis and similar techniques, and they must know quite a lot
that we don't.

The black community also has lots of day-to-day experience that we
don't have, and they understand both the threat model and the
practical side of things a lot better than we do.

Overall, I'd say that in the long run the open community is going to
catch up regardless of what the NSA likes. That does not mean,
however, that this is going to happen particularly soon, or that they
don't still know decades more than we do.

Perry





From lile at art.net  Sun Feb 12 21:22:34 1995
From: lile at art.net (Lile Elam)
Date: Sun, 12 Feb 95 21:22:34 PST
Subject: bill alert...
Message-ID: <199502130515.VAA14482@art.net>


Do you think this will force folks into using encryption?
If I was a sysop, I sure would have all my users using
encryption... :)

-lile



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lile Elam	    |  "a brush in hand, a wisp of wind, she sighs 
lile at art.net        |   knowing that this will be the great one..."	
http://www.art.net  |						    -lile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




                       -> EMA ALERT <-
            News For and About the Members of the
               ELECTRONIC MESSAGING ASSOCIATION
============================================================
                February 3, 1995 -- Number 18
<---------------------------------------------------------->
                  ***** SPECIAL ALERT *****
 - Congress to consider making all system operators liable
   for messaging content.  Bill would force employers to
   monitor message content.              ACTION NEEDED NOW!
<---------------------------------------------------------->

UNREASONABLE NETWORK POLICING PROPOSED
   Yesterday, Senator Jim Exon (D-NE) introduced S.314, the
Communications Decency Act of 1995, in the United States
Senate.  In an effort to stamp out digital pornography, it
makes all telecommunications providers doing business in the
United States (from the telephone companies all the way down
to offices that use LANs) liable for the content of anything
sent over their networks.  To avoid the possibility of tens
of thousands of dollars in fines and up to two years in
jail, business owners would be forced to police their
networks and monitor in advance all messages sent over them.

WITHOUT ACTION - COULD BE LAW IN MONTHS
   This bill is substantially the same as the one he put
forward last year.  He will offer it as an amendment to the
pending telecommunications deregulation legislation in the
U.S. Senate, which is expected to be enacted by July.  Last
year, his amendment was adopted even though many thought it
hastily drafted and poorly thought out.  Fortunately, the
telecommunications deregulation legislation died.  This
year, a more conservative U.S. Congress may be even more
reluctant to challenge a "morality" amendment; and its
legislative vehicle, the telecommunications deregulation
legislation, stands a much better chance of passage this
year.

ACTION NEEDED NOW
   Action by the business community is needed now.  Please
notify your corporate government affairs office and/or your
legal counsel.  This measure could be adopted as an
amendment to the telecommunications bill IN A MATTER OF
WEEKS (or potentially added to any legislation pending on
the U.S. Senate floor), if business does not mobilize
against it.  S.314 will not stop digital pornography, but it
could devastate the messaging business.  If you are
interested in further information or are able to participate
in lobbying efforts over the next few weeks, contact Sarah
Reardon at EMA (see below).

------------------------------------------------------------
EMA ALERT is published and copyrighted (1995) by the
Electronic Messaging Association.  Permission to reproduce
and/or redistribute with attribution is hereby given to all
EMA members.  For more information about anything in EMA
ALERT, contact EMA via e-mail - use either X.400 (S=info;
O=ema; A=mci; C=us) or Internet (info at ema.org) address,
facsimile (1-703-524-5558), or telephone (1-703-524-5550).
Any EMA staff member can be addressed directly via e-mail by
using, for X.400, G=<firstname>; S=<lastname>; O=ema; A=mci;
C=us, and, for Internet, <firstinitial><lastname>@ema.org.
EMA's postal address is 1655 N. Fort Myer Dr. #850,
Arlington, VA 22209 USA.


------ End of Forwarded Message








From adam at bwh.harvard.edu  Sun Feb 12 21:56:03 1995
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Sun, 12 Feb 95 21:56:03 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
In-Reply-To: <9502130231.AA19651@snark.imsi.com>
Message-ID: <199502130554.AAA23466@bwh.harvard.edu>



	A few weeks back Matt Blaze posted on top ten problems we
face.  I'll add two to that list.  First is our inability to
accurately assess the strength of various government agencies.  We
tend to make very pessimistic assumptions, which tends to be safe, but
having real data on which to base our assumptions would be better.

	The other problem we face is that people like Matt write solid
essays on various things, and no one responds.  People who write
essays, post solid mathematical results, etc, bemoan this pretty
regularly.  Fortunately, this problem is easier to address.  Try to
spend more time on the posts which people took longer on.  Its usually
obvious which those are.  The reason to spend more time on solid posts
is that someone took the time to write well on something.  If they get
solid feedback, they'll do more solid writing, and the quality of
discourse goes up.

Adam


Perry writes:
| The black community also has lots of day-to-day experience that we
| don't have, and they understand both the threat model and the
| practical side of things a lot better than we do.
| 
| Overall, I'd say that in the long run the open community is going to
| catch up regardless of what the NSA likes. That does not mean,
| however, that this is going to happen particularly soon, or that they
| don't still know decades more than we do.


-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume




From unicorn at access.digex.net  Sun Feb 12 22:09:52 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Sun, 12 Feb 95 22:09:52 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
In-Reply-To: <199502130554.AAA23466@bwh.harvard.edu>
Message-ID: <Pine.SUN.3.91.950213010531.26741B-100000@access3.digex.net>


On Mon, 13 Feb 1995, Adam Shostack wrote:

> Date: Mon, 13 Feb 1995 00:54:21 -0500 (EST)
> From: Adam Shostack <adam at bwh.harvard.edu>
> To: perry at imsi.com
> Cc: Cypherpunks Mailing List <cypherpunks at toad.com>
> Subject: Re: The NSA (Was Re: Factoring - State of the Art and Predictions )
> 
> 
> 	A few weeks back Matt Blaze posted on top ten problems we
> face.  I'll add two to that list.  First is our inability to
> accurately assess the strength of various government agencies.  We
> tend to make very pessimistic assumptions, which tends to be safe, but
> having real data on which to base our assumptions would be better.

What your talking about here is a cypherpunks intelligence capability.
If you think we are thought of as subversive and distasteful now, just 
wait to see what happens if anyone on the list outs the kind of 
information your talking about about e.g., the NSA or the Justice Department.

Were this a private, closely held group instead of a public mailing list, 
you might have a different story.


> 
> 	The other problem we face is that people like Matt write solid
> essays on various things, and no one responds.  People who write
> essays, post solid mathematical results, etc, bemoan this pretty
> regularly.  Fortunately, this problem is easier to address.  Try to
> spend more time on the posts which people took longer on.  Its usually
> obvious which those are.  The reason to spend more time on solid posts
> is that someone took the time to write well on something.  If they get
> solid feedback, they'll do more solid writing, and the quality of
> discourse goes up.

There is a internet lore that says the more valuable and insightful a 
given article is, the less response it gets.

I hope this is right, as most of mine tend to be ignored.


> 
> Adam
> 
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 						       -Hume
> 

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From M00012 at kanga.stcloud.msus.edu  Sun Feb 12 23:17:00 1995
From: M00012 at kanga.stcloud.msus.edu (M00012 at kanga.stcloud.msus.edu)
Date: Sun, 12 Feb 95 23:17:00 PST
Subject: standards...
Message-ID: <950213011700.34a5@kanga.stcloud.msus.edu>


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

Cypherpunks,

Secure encryption programs should be / have (imo):

1.  Dynamic, allowing the user to select types of encryption
    on a per session basis, and to allow them to add crypto
    modules as they are developed in the future.
2.  Easy to use.
3.  All source code availible--allowing users to fully
    compile (and examine) the source code.

Such programs should make use of encryption modules or
libraries, and should be able to easily adapt to new
modules as they become available.

An encryption module standard will help facilitate the
creation of the type of programs decsribed above.


Some feateres...

  I.  Public key encryption.
      A.  Uses slower public key encryption to encrypt one or
          more session keys for one or more block ciphers.
      B.  Be used alone on larger blocks of data.  (The future
          may hold public key encryption algorithms that
          make this practical.)
      C.  Not limited to one public encryption scheme.
      C.  Function/format standards that allow user
          interfaces to implement various public key
          crypto functions.
 II.  Block Ciphers
      A.  Each block cipher has a committee assigned
          identification number.
      B.  Uses of random session key for encrypton for
          non-public key encryption.
          1.)  Random session key is encrypted with
               hash of user supplied password.
          2.)  Encrypted session key is appended to
               ciphertext.
      C.  Functrion/format standards for easier chaining
          of multiple block ciphers in user interfaces
          that implement these functions.
          1.)  Minimize/mitigate/eliminate use of layer
               headers that would serve as known plaintext.
III.  Compression
      A.  Perhaps implemented in the same or similar format
          used for block ciphers.
      B.  Compression with a session key/random buffer
          source?  (Used to alter any tables and/or
          mitigate known plaintext attacks, e.g., if
          5 bits of a header are unused...fill these
          with unpredictible bits to be masked off
          latter during decompression.)
      C.  Function/format standards, even though this will
          be, if a compression function is selected, the
          first function called)
          1.)  Minimize/mitigate/eliminate use of layer
               headers that would serve as known plaintext.
 IV.  Hash functions...
  V.  Validation (password and sig.s)
 VI.  Unpredictible (true random) number generation/distribution.
VII.  Variable key lengths.

Of course, this requires _STANDARDS_.  The cypherpunks are
the ideal people to define these standards (and start writing
such modules).  If others are working on this, I'd like to get
a copy of the standards so that I can contribute some code,
otherwise I am willing to help draft the standards--although
the significance of my contributions might amount to an
occasional unoriginal idea.

Some of the qualities listed above, it seems to me, might call
for the use of C++, although C is preferable.

Mike


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

mQCRAi8v0bMAAAEEAPd2Gn0tnUbEpituh2XrgtHBzSWg7joLHIFXLIQ2vFOcAlE2
9MxS/XuX0sl+Mm6Ix8Vc7gg0Jutb35PvXHy+TaHk9OuOOGGIWMUspd0GmZFTEdhv
nE49BltVmJpEXOU4vVxtVEMZAeewndRCfypYDRYbG1TpCCtvVrwEeVpjJyiBACEB
AAAAAbQmTWljaGFlbCBTLiBNb3JnYW4gPG1tb3JnYW5AZGlnaWJkLmNvbT6JAJUC
BRAvL9SKvAR5WmMnKIEBATQ5A/9h14BcFvpMX2O98iBOlrNlXvppMdQ8KnOfruBH
usg2tvZmynlajFItfTtaVxHQrQNAeQ+P1Ju846wqx+Y/IYHegvS7u7LvPpXIbPHo
Ko8DOgQkH2I3ko2QcNwDsBQvDxGtmx6wVZa0TXt/mmgHTeU6blhsXmyWvIqkeiah
xLn897QYRE8gTk9UIFVTRSBBRlRFUiAzLTE1LTk1tBFFeHBpcmVzOiAgMy0xNS05
NbQaUGVyc29uYWwgVXNlIG9ubHksIHBsZWFzZS4=
=eO8G
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLy/ZbbwEeVpjJyiBAQGClQP9FK4Er+WzSe4uAZNxJdqciXlX3XTFGeh2
WDXHF8yAfyPEmKOxnbgdD50sWoTJXf+ZQqcxKiBASn8HNmegPHy7NUFqJnU5+/Ma
oV6TK27doKf06l8B7Q0hLywQgRIWBeRuJqjD2FVr7pynLBYRjnRhHZPt8fHSkGYq
KJ4ui9mBcOA=
=/37d
-----END PGP SIGNATURE-----





From rfdutcher at igc.apc.org  Sun Feb 12 23:20:24 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Sun, 12 Feb 95 23:20:24 PST
Subject: UMich student arrested for rape story
Message-ID: <199502130721.XAA24596@igc3.igc.apc.org>


> 
> The July `94 issue of Harper's described the case of a Menlo Park city 
> employee who claimed in 1993 to be harassed by some paintings of female nudes
> hanging in a hallway. The city removed the paintings the following day. It
> used to be that when the majority of people in some state/county/town 
> disapproved of some instance of expression, they could suppress it. This was
> bad. Nowadays, it takes just one zealot to suppress it. This is much worse.
> As far as I can see, anyone can claim to be harassed/threatened/offended by
> just about anything, and get away with it.  Just the other day, I heard that
> in Vermont (or was it New Hampshire ?), they're still talking seriously about
> an amendment to the state constitution against burning the U.S. flag. Between
> the censors on the left and the censors on the right, there's precious little
> room remaining for those of us in the middle who believe in tolerating
> divergent views.
> 
Toleration of divergent views is not one of those issues that breaks 
out well along left-right polarities.  E.g., Andrea Dworkin's closest 
aliies on porn are on the xtian right, not among her fellow radical 
feminists [contrary to the image promoted in some mass media].  
Threats to Catcher in the Rye in libraries are far more common than 
incidents like the one in Menlo Park.

> > Violence against women is too real, 
> 
> Strongly agreed, but a newsgroup article is not an act of violence.
> 
Legally, that's a question yet to be resolved.

In any case, this is hardly cyrpto-related.  I would far rather lurk 
as the mathematicians discuss factoring.  I learn more [even if I 
only get one word in three :-]


===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From lmccarth at ducie.cs.umass.edu  Sun Feb 12 23:21:41 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Sun, 12 Feb 95 23:21:41 PST
Subject: Our Ignorance of Govt. Capabilities
In-Reply-To: <Pine.SUN.3.91.950213010531.26741B-100000@access3.digex.net>
Message-ID: <199502130723.CAA15970@ducie.cs.umass.edu>


Black Unicorn writes:
> If you think we are thought of as subversive and distasteful now, just 
> wait to see what happens if anyone on the list outs the kind of 
> information your talking about about e.g., the NSA or the Justice Department.
> 
> Were this a private, closely held group instead of a public mailing list, 
> you might have a different story.

IMHO, people generally don't share that sort of 
information here because they don't possess it, not because they fear
potential repercussions. Plenty of list subscribers seem able to shed their
inhibitions quite easily when it comes to criticizing organizations and 
revealing information. Full utilization of the most advanced available
remailer features offers at least the appearance of sufficient anonymity
for most people, AFAI can tell.

[Perhaps we could run a short survey: please respond if you could dish dirt 
 on a government security agency, but do not plan to do so on this list   ;]

BTW, with an eye to avoiding rehashes of old flamewars, this does *not*
constitute an invitation to scour the subscriber list for *.gov and *.mil and
announce the results. Consult the archives if in doubt on this point.

-L. Futplex McCarthy




From roy at cybrspc.mn.org  Sun Feb 12 23:24:08 1995
From: roy at cybrspc.mn.org (Roy M. Silvernail)
Date: Sun, 12 Feb 95 23:24:08 PST
Subject: UMich student arrested for rape story
In-Reply-To: <199502122347.SAA15127@ducie.cs.umass.edu>
Message-ID: <950212.175322.2U7.rusnews.w165w@cybrspc.mn.org>


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

In list.cypherpunks, L. Futplex McCarthy writes:

> It appears to me that people on the left are choosing (wrongly, IMHO) to 
> interpret a work of fiction as a threat, and proceed from there. I imagine
> that people on the right don't see the work of fiction as a threat to her, 
> but simply want to ban fictional works they dislike anyway.

Given the current "regulate the Internet" frenzy we're seeing almost
everywhere, couldn't this be an example of grabbing a scapegoat?  I see
this whole deal as opportunistic, especially since the alleged victim of
the "threat" appeared unaware that the "threat" had even been made.
- -- 
Roy M. Silvernail --  roy at cybrspc.mn.org
  perl -e '$x = 1/20; print "Just my \$$x! (adjusted for inflation)\n"'
        "What do you mean, you've never been to Alpha Centauri?"
                                               -- Prostetnic Vogon Jeltz

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLz6g2hvikii9febJAQEi7AP+IuDcbHY/PjI7HC3j29jtHFiMbFIS5fdG
2c08NQgnjiA8ul3fsJUUcmQ/sdr0WxZrR0qIRTwzBoX1baVDr0POARn4DY/5TrbH
Qmav0KW/kJQEqaX2uvu2MvdF5NFWiYlXB06ZysOhgHuj7wcAsCGyTwTpA5hpKmFj
3ZAP0vHuLaM=
=iXE+
-----END PGP SIGNATURE-----





From mpd at netcom.com  Sun Feb 12 23:32:57 1995
From: mpd at netcom.com (Mike Duvos)
Date: Sun, 12 Feb 95 23:32:57 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
Message-ID: <199502130732.XAA28958@netcom14.netcom.com>


"Perry E. Metzger" <perry at imsi.com> writes:

 > On the other hand, the people in the black community have
 > the advantage that they can read anything that the open
 > community produces but not vice versa, and they have at
 > least a 15 year edge in knowledge about the design of
 > conventional systems, and who knows (we certainly have no
 > idea) how much of an edge in the modern cryptographic arena.

Such a situation does not apply solely to the NSA.  There are,
for instance, secret lodges of French mystics who devote
themselves to higher mathematics, absorb everything the open
community produces, and rarely publish anything or draw attention
to themselves.  They solve problems, write secret manuscripts,
put them on shelves, and have been doing this for centuries.
Perhaps the ultimate factoring algorithm already exists within
their walls.  We would never know if it did, unless they chose to
tell us.

The NSA is very good at solving problems that require "acres of
Crays".  They are crack numerical analysts and algorithm
designers. They also make nice block ciphers.  I do not think,
however, that they have deeply profound insights into the
complexity of computation that exceed those of the University
community, and certainly not by 15 years.

 > We don't know for sure if the NSA knew about Public Key
 > before the open community did. Certainly they knew of
 > differential cryptanalysis and similar techniques, and they
 > must know quite a lot that we don't.

Rumour has it that the NSA nearly had a collective epileptic fit
when they realized the implications of Public Key Cryptography.
Yes, they did invent differential cryptanalysis and some other
techniques before outsiders thought of them, but I'm unsure this
implies some great cabal of hidden knowlege on their part.  It is
more likely a case of throwing research dollars at a problem
which had not yet captured the interest of researchers outside
the intelligence community.

 > Overall, I'd say that in the long run the open community is
 > going to catch up regardless of what the NSA likes. That
 > does not mean, however, that this is going to happen
 > particularly soon, or that they don't still know decades
 > more than we do.

I think the NSA has lost its edge completely in the last decade,
as cryptographic research in the open community has taken off. It
is much the same sort of situation experienced by IBM, when they
were slow to catch on to the paradigm shift created by
distributed computing and workstations, and companies like Sun
rose from nowhere to become major players.

If the NSA were a corporation, they would be apologizing to their
shareholders, restructuring, and trying to identify a market
niche they could continue to be a player in.  Since they are
funded by government, we don't see them doing this, but it is
absurd to suggest that they are still decades ahead of the rest
of the world in basic research and technology.

-- 
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd at netcom.com     $    via Finger.                      $





From M00012 at kanga.stcloud.msus.edu  Sun Feb 12 23:41:00 1995
From: M00012 at kanga.stcloud.msus.edu (M00012 at kanga.stcloud.msus.edu)
Date: Sun, 12 Feb 95 23:41:00 PST
Subject: Our Ignorance....
Message-ID: <950213014102.34a5@kanga.stcloud.msus.edu>


> From: "L. McCarthy" <lmccarth at ducie.cs.umass.edu>
> ...
> BTW, with an eye to avoiding rehashes of old flamewars, this does *not*
> constitute an invitation to scour the subscriber list for *.gov and *.mil and
> announce the results. Consult the archives if in doubt on this point.
>
>  -L. Futplex McCarthy
 
Even so, my guess is that 1/4 to 1/3 of the subscribers to this list
are interested government employees--though the most interested are
not using addresses with .gov or .mil.
 
Mike
o





From cactus at seabsd.hks.net  Sun Feb 12 23:49:24 1995
From: cactus at seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Sun, 12 Feb 95 23:49:24 PST
Subject: Q: ref. for DNA used to solve math. network prob. (fwd)
Message-ID: <199502130745.CAA25356@bb.hks.net>


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

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


The Adleman paper is on the web (I put it up).  The url is:

	http://www.hks.net/~cactus/doc/science/molecule_comp.html

I never completed typing the perspectives article since an article
appeared in Science that implied that Science doesn't consider it kosher
to reprint their articles.  As a member of the AAAS, I'm a bit appalled
by this position but for the moment I've stopped any progress on
entering Science articles into the Web.

Enjoy,
- - --
Todd Masco     | "Let me get this straight.  You're making a crypto toolkit,
cactus at hks.net |  and you're worried about it being _obscure_?" - Eric Hughes
Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz7VORNhgovrPB7dAQHd3gQAgXnpCEQRIxzO6VQSarHhK7nH9j4kncbi
IlJawMbNnCf1RD9P3OD7art0w+180luFRJW9d93C5lq3Z36XhCOCgrcHrnGausCM
D87DWCEYECMxjuMa362NC1u79UGQ5MThwb4Tl6/kttYzLYyRfCiJLRwexJs5B6mX
6PaKGuNQDV4=
=Vgdm
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz8OFCoZzwIn1bdtAQFC3QGA39rHlZeQgpkQwtsTv0JUEK4UyftbMqSK
I8IHti1XiwbwSGgc6zzg5ga0ChRg0B8P
=pXZq
-----END PGP SIGNATURE-----





From lmccarth at ducie.cs.umass.edu  Mon Feb 13 00:12:59 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Mon, 13 Feb 95 00:12:59 PST
Subject: Does Anyone Even Read This Stuff ? (was Re: The NSA)
In-Reply-To: <Pine.SUN.3.91.950213010531.26741B-100000@access3.digex.net>
Message-ID: <199502130814.DAA16063@ducie.cs.umass.edu>


Adam Shostack writes:
> 	The other problem we face is that people like Matt write solid
> essays on various things, and no one responds.  People who write
> essays, post solid mathematical results, etc, bemoan this pretty
> regularly.

I agree that this is a problem, but perhaps not so much as we might think.
For one thing, communication sometimes develops in private. For instance, I
exchanged some mail with Matt about Caller ID after his Top 10 Problems list.
More importantly, it takes much more time, and in some cases expertise, to 
compose a good response to a long discourse than to reply to a short opinion
piece or news report. Relatively few people have the time and ability to
formulate a significant extension or rebuttal to a major work. This is
natural and inevitable. It's probably unrealistic to expect a much greater
frequency of such messages.

Black Unicorn writes:
# There is a internet lore that says the more valuable and insightful a 
# given article is, the less response it gets.
# I hope this is right, as most of mine tend to be ignored.

Lately, I've had the feeling that majordomo at toad echoes my epistles only back
to me. None of the longer pieces I've written has elicited so much as a flame 
from Eric, Perry, or even James in a while.

As they say, "opinions are like assholes", and it's easy to argue about them.
Netiquette strenously discourages people from simply agreeing. This can be
carried too far.

I've encountered an insidious hazard of high-volume lists (such as this) that
probably snares other people too. It's altogether too easy to sit at one's
mailer and merely react to whatever comes along. Obviously, if everyone did
this all the time, nothing of substance would ever be accomplished. It's
therapeutic, IMHO, to step back regularly, refocus on one's long term goals
w.r.t the group, and push new initiatives.

-L. Futplex McCarthy




From cactus at seabsd.hks.net  Mon Feb 13 00:22:11 1995
From: cactus at seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Mon, 13 Feb 95 00:22:11 PST
Subject: standards...
Message-ID: <199502130818.DAA25598@bb.hks.net>


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

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


>Such programs should make use of encryption modules or
>libraries, and should be able to easily adapt to new
>modules as they become available.

Hmmm.  Did you come in late, or have you seen my posts about the crypto
library I'm working on ("Hastur Crypto Toolkit," nee "GUCAPI")?

>  I.  Public key encryption.
>      C.  Not limited to one public encryption scheme.

AFAIK, RSA is the only feasible PK scheme available.  There's eliptic
curves, of course, but that's patented.

> II.  Block Ciphers

Needn't be block.  Stream cipher works perfectly well for the "fast crypto"
symetric cipher part.

>      A.  Each block cipher has a committee assigned
>          identification number.

Why a number?  When you can choose between a number and a human-readable
string (and space is not a big issue), choose human-readable.

>      B.  Uses of random session key for encrypton for
>          non-public key encryption.
>          1.)  Random session key is encrypted with
>               hash of user supplied password.
>          2.)  Encrypted session key is appended to
>               ciphertext.

Hmmm.   If the session key is a hash of a password, then why on Earth
would you include it?  

>      C.  Functrion/format standards for easier chaining
>          of multiple block ciphers in user interfaces
>          that implement these functions.
>          1.)  Minimize/mitigate/eliminate use of layer
>               headers that would serve as known plaintext.

We shouldn't be using ciphers that are vulnerable to "known plaintext"
attacks.  RSA is known to be vulnerable to "chosen plaintext" attacks
(see Schneier), but is useful enough that we work around this shortcoming
by RSA encrypting only hashes and session keys.

>III.  Compression
>      A.  Perhaps implemented in the same or similar format
>          used for block ciphers.

Naturally.  In fact, encoding, encryption, and compression are the same
thing: mapping one set of numbers into another.

>Of course, this requires _STANDARDS_.  The cypherpunks are
>the ideal people to define these standards (and start writing
>such modules).  If others are working on this, I'd like to get
>a copy of the standards so that I can contribute some code,
>otherwise I am willing to help draft the standards--although
>the significance of my contributions might amount to an
>occasional unoriginal idea.

As far I know, there are two standards: the PKCS #11 document from 
RSADSI, which I do not care to follow if I can avoid it.  The other
is the IETF GSSAPI, which should be accomodated.

In general, I very much agree with the thrust of what you're saying.
Which is why I'm folding the crypto work I already have to do for
my company into the larger "general solution" approach.

If you haven't read my postings on GUCAPI/Hastur, please go back and
take a look (send me mail if you'd like a copy).  It very much sounds
to me like you're addressing the same problem that I've been hacking
full-time for the last month or so.

If you're interested in helping, the best things that could possibly
be provided is code released to the public domain that implements:

	- Good random number generators for Macs and PCs, or
	- Implementations of the non-RSAREF symetric ciphers and hashes,
	 incl. IDEA, RC4, RC5, BLOWFISH, MD4, MD5, SAPPHIRE, GOST,
         SHA, LUC, and LOKI91.  Or any others that seem like a good idea.
	
I'll mention some miscellaneous features that will be in the library
that I haven't brought up yet:

	- It will be trivial to make the UNIX-style filter programs
	that Perry and Matt desire.
	- Specification of a format for outgoing and incoming messages
	will be trivial.  All known old formats (PGP 2.*, RIPEM, etc)
	will be supported by including format specs.

Key _management_ will *not* be supported, though public keys _will_
be imported from PGP and PEM key rings as well as X.509 certificates with
no judgement as to trust (see message from Eric Hughes from the middle
of last week).  Some key translation (x.509 --> PGP) services might be
provided.
- - --
Todd Masco     | "If we don't make utter fools of ourselves from time to time,
cactus at hks.net |  we grow smug - that is, we do not grow at all." - T. Peters
     Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz7c3hNhgovrPB7dAQHGdQP+Idvw/FxnPgR49z70DCMqgHV6w3UEds3f
vdm0E5P7+3evSB++iTuP/NzOP92CCnen9VTlFX+gAab61g8T9mfT5mYMu3B9iCvi
PWo3/+3XFinypShYJaYyZHWaHkYJtse7A7rFgLhoqQXNPFYdPeSh5XSJqugtfHIm
wK37TDUptS4=
=3wi6
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz8VwyoZzwIn1bdtAQHQDgGAgURmCoUB4Hop6nPRayXkK//DJ6muBORK
H8Vs6rEiDuYEezGPOT0oIxM4J1aJMuwa
=t78D
-----END PGP SIGNATURE-----





From aegis at netcom.com  Mon Feb 13 00:31:05 1995
From: aegis at netcom.com (Dale Harrison)
Date: Mon, 13 Feb 95 00:31:05 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
Message-ID: <199502130830.AAA02302@netcom.netcom.com>


>I think the NSA has lost its edge completely in the last decade,
>as cryptographic research in the open community has taken off. It
>is much the same sort of situation experienced by IBM, when they
>were slow to catch on to the paradigm shift created by
>distributed computing and workstations, and companies like Sun
>rose from nowhere to become major players.
>
>If the NSA were a corporation, they would be apologizing to their
>shareholders, restructuring, and trying to identify a market
>niche they could continue to be a player in.  Since they are
>funded by government, we don't see them doing this, but it is
>absurd to suggest that they are still decades ahead of the rest
>of the world in basic research and technology.

As a former civilian TS Clearance holder working for the government, I can 
tell you I was amazed at what a small percentage of classified material 
really deserves to be classified.  90% of what I saw could be categorized as 
1)trival, 2)in the public domain already, or 3)politically embarrassing.  
For example, look at the long classified human radiation experiments just 
coming to light. The government certainly wasn't hidding that info from the 
Russians, they were hiding it from the voters. I remember once fighting for 
months to get access to some classified papers on the fracture 
characteristics of ceramics only to find them to contain nothing that hadn't 
been available in the public domain for 20 years. This of course has a lot 
to do with the strange sociology of government bureacracies where the 
combination of classified information with need-to-know restrictions create 
powerful petty-fiefdoms that lead to increased perks and prestige.  The 
other thing to realize is that inside the bureacracies there's little in the 
way of the vigorous competion of ideas (primarily because of the 
manipulation of need-to-know restrictions) that characterizes academia.  
Bureaucracies tend to foster myopia and tunnel vision rather than risk 
taking and originality.  My guess (and it's only that) is that if all of 
NSA's secrets were laid bare, maybe 10% of what they have would be truely 
unique and the other 90% would be surprisingly pedestrian.

Dale H.

------------------------------------------------------------
  Dale W. Harrison, president       |  TEL: (713) 682-0501
  AEGIS Software Development, Inc.  |  FAX: (713) 623-0030
  12 Greenway Plaza, Suite 1100     |  aegis at netcom.com
  Houston, Texas 77046              |  daleh at ix.netcom.com
------------------------------------------------------------






From news at lucy.ee.und.ac.za  Mon Feb 13 00:59:18 1995
From: news at lucy.ee.und.ac.za (News auto-reply daemon)
Date: Mon, 13 Feb 95 00:59:18 PST
Subject: Automatic reply to your test message   (lwall)
In-Reply-To: <PINE4545-dhfsdkjc@ack.berkeley.edu>
Message-ID: <9502130858.AA27833@lucy.ee.und.ac.za>

This is an automatic reply, to let you know that a test message from you
(or listing your address in the Reply-To header) recently arrived here
at news system "ee.und.ac.za", which is in the Electronic Engineering
department at the University of Natal, Durban, South Africa.

A lot of people are confused by automatic reply messages, so this
message tries quite hard to explain what is going on.  If you have any
good suggestions for ways in which the wording of this message can be
improved, please send them to <news at ee.und.ac.za>.

Some of the reasons people post test messages is to check whether their
news system is correctly configured to let their messages get out, and
to check whether their mail system is correctly configured to let mail
get back to them.  Because of these uses of test messages, some news
administrators -- trying to be helpful -- configure their news systems
to send automatic responses.

It is possible that somebody tricked you into posting a test message, or
that somebody else forged a test message that either appeared to be from
you or directed replies to you.  If that is what happened to you, then
you may be able to use the information below to help you to track down
the perpetrator.

Each message in almost all of the *.test newsgroups is a considered
as a candidate for an automatic reply like this one.  If the message
header or the first few lines of the body contains any of the phrases
"ignore", "no reply", "do not reply" or a few other variants, then
the message is ignored.  If the message does not contain any of those
trigger phrases, then the auto-replier sends back a reply like this
one.  (If you get more than one copy of this reply, that might mean
that there is a problem in the mail system; please ask your local mail
administrator for help.)

It's too late to have any effect on this message, because this reply
has already been sent, but in future, if you do not want to receive
automatic replies like this, then you should either refrain from posting
messages to the *.test newsgroups, or ensure that your postings to the
*.test newsgroups contain the trigger phrases that will cause your
messages to be ignored by auto-repliers.  Please also note that name
has not been added to any kind of subscription list, so there's no need
to try to unsubscribe or to send "ignore" messages back via electronic
mail.

By the way, this site receives messages in certain newsgroups, or with
certain distributions, that some people might consider to be unusual for
a site in South Africa.  We do that deliberately, so please don't be too
surprised.

If you want to write to the human who administers the news system that
generated this auto-reply message, the address <news at ee.und.ac.za>
should work.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00001.bin
Type: application/octet-stream
Size: 623 bytes
Desc: "A copy of the header and the first few lines of   the body of your test message."
URL: <https://lists.cpunks.org/pipermail/cypherpunks-legacy/attachments/19950213/722f69f7/attachment.bin>

From lile at art.net  Mon Feb 13 01:00:13 1995
From: lile at art.net (Lile Elam)
Date: Mon, 13 Feb 95 01:00:13 PST
Subject: you are invited...
Message-ID: <199502130853.AAA16195@art.net>




		       Valentines & Hearts Party!
		         	   @
		             Bryant's Bend	
		

	Our wonderful house at Bryant's Bend in Palo Alto, is having 
it's annual Valentines Party on Valentines Day and we would love to have 
you join us in the celebrations. 

	We request that everyone who attends cum dressed in women's lingerie 
for this feastive occasion. Anyone showing up at the door "overdressed" 
will not be given entry to this event. I suggest visiting Victoria's Secret
as they are having sales on their silky lingerie... :)

	I realize the notice is short but hope you can make it
				anyways...  :)  


	When:   Tuesday Night (yes, that's this week)
	                  ((Feb 14, 1995))
	Time:   7:30 to late
	Where:	130 Bryant St.
		Palo Alto CA

	What to bring:  Yourselves, any veggie food items you enjoy
               (we're a veggie co-op :) and any drinks. We will
		be providing the atmosphere and some non-alcoholic 
		drinks and small munchies.... Drums and instruments
		are most welcome as well as games... 
		
	Activities for the evening:
		Be prepared to play "Spin the Heart" and "Truth or Dare"
		while you are there. We will also have dancing upstairs and 
		kissing in the famous "Kissin Corner"! So watch where 
		you walk... 


	Directions to this Awesome Party:

	From Highway 101 (North or south):  
	
		Take the University Exit that heads West. Follow
		University Street until you reach Bryant St.
		Make a right onto Bryant St. and follow it to the 
		end. We are the last house on the left hand side
		and are on the corner of Bryant St. and Palo Alto
		Way. It's a big tan house with brown trimmings.
	

Hope to see you there...

-lile

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lile Elam	    |  "a brush in hand, a wisp of wind, she sighs 
lile at art.net        |   knowing that this will be the great one..."	
http://www.art.net  |						    -lile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






From tcmay at netcom.com  Mon Feb 13 01:54:20 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 13 Feb 95 01:54:20 PST
Subject: Is Cyberspace Rich Enough?
In-Reply-To: <199502130814.DAA16063@ducie.cs.umass.edu>
Message-ID: <199502130954.BAA19852@netcom3.netcom.com>


L. McCarthy wrote:

> Lately, I've had the feeling that majordomo at toad echoes my epistles only back
> to me. None of the longer pieces I've written has elicited so much as a flame 
> from Eric, Perry, or even James in a while.

Should I feel left out by not being mentioned in this set? Or
relieved?

In any case, I agree that most responses are mostly reactive. Though
in defense of the Cypherpunks list, not nearly so reactive as are many
groups. Lots of lists and groups are dominated by in jokes, non
sequitors, and other ephemera. At least this group quite often gets
into meaty issues.

> I've encountered an insidious hazard of high-volume lists (such as this) that
> probably snares other people too. It's altogether too easy to sit at one's
> mailer and merely react to whatever comes along. Obviously, if everyone did
> this all the time, nothing of substance would ever be accomplished. It's
> therapeutic, IMHO, to step back regularly, refocus on one's long term goals
> w.r.t the group, and push new initiatives.

Like a lot of you, I try to do this regularly. If people are
interested, they'll follow up. If not, they won't. Think of it as
evolution in action.

It so happens that the latest theme I've been thinking about is ready
to spring on you folks. If you respond, so be it.

That theme is this: Is cyberspace, or the Net/Web/Etc., sufficiently
rich or complex to meet our needs?

By "rich" or "complex" I mean in terms of "places to go," of "degrees
of freedom." For example, the multiplicity of routing paths for
messages, via remailers explicitly and via the underlying routing
options the Internet itself offers implicitly, gives certain major
advantages that a centralized system vulnerable to "choke points"
would not have. (The Internet gurus will likely jump in at this point
and blather about how this is isn't so, how they could shut down the
Internet in several minutes with just their Leatherman tool and a few
O'Reilly books, but my point is not that it isn't _possible_, but that
the direction in which the Net has moved is generally one that makes
shut-down harder than more centralized alternatives.)

By our "needs" I mean roughly the Cypherpunks goals of privacy, free
choice, cybernetic free association, virtual communities,
anarcho-capitalism, etc. (Quibblers can dispute any of these, but
clearly most active posters on the list advocate some vector made up
of many of these diverse elements.)

So, what am I getting at?

Consider how the abstractions of the World Wide Web, URLs, HTML, HTTP,
and Web browsers have *increased the size of cyberspace* rather
dramatically in just the past two years. More places to visit, more
interconnectedness, more difficulties in controlling access to stuff,
etc. Home pages containing banned material are proliferating (a la the
Homolka-Teale ritualistic cannibalism trial in Canada, the Scientology
material, and so on--this is not the place for me to recap this).
Sure, ftp sites used to do this pretty well; in fact, I'm considering
ftp sites in this "evolution" toward greater complexity (in the
richness sense).

(Actually, cyberspace is partly getting "bigger" and partly
"increasing in dimensionality." Dimensionality of a space can be
related to how many neighbors one has....think of the two nearest
neighbors one has in a 1-D space, the 4 (or 8 if diagonals are
considered) neighbors in a 2-D space, the 6 in a 3-D space, and so on.
Arguably, if one has "100 close neighbors" in a space, it is roughly a
50 dimensional space. An equivalent formulation is in terms of the
radius of the n-sphere that everyone fits into. For example, the "six
degrees of separation," the 6 "handshakes" that separate nearly any
two people in America, suggests that American society is in some
important sense roughly a 15-17 dimensional space, because in some
sense all 250 million Americans "fit into" a hypersphere of radius 3
(diameter 6) when the dimensionality is around 17. (Or slightly lower,
as the slight corrections to V = r ^ n have to be included, which I'm
not bothering with). What "increased connectivity" does is to increase
dimensionality, about as one would expect from our usual metaphors
about "a multidimensional society" and "the world is
shrinking"...indeed it is shrinking, even as the absolute volume
increases.) 

What Cypherpunks should be pushing for, in my view, is this increased
dimensionality. More places to stick things, more places to escape
central control, and more degrees of freedom (which has a nice dual
meaning I once used as the working title for a novel I was working
on).

Is Cyberspace already rich enough (= high enough dimensionality) so
that central control cannot be reestablished (to the extent it ever
existed)?

Many of this think that it probably already is past this point, that
the "point of no return" has been reached. After all, the Soviets
couldn't stop samizdats, the Chinese couldn't stop fax machines, and
the Americans can't stop drug use, so what hope is there in
controlling modems, crypto, cellular phones, satellites, Web links,
stegonography, terabytes of data flowing unobstructed across borders,
and so on. Just to "stop the Net" would disrupt the entire financial
system, which not even Clinton or the next (Republican) President
would be tempted to do....they might as well launch a nuclear war as
try to shut down this "anarchic" ( = high dimensionality) system.

But can we do more? One of my own wishes is to see hundreds (nay,
thousands!) of remailers, as these act as "teleportation booths" which
can dramatically increase connectivity. (They can increase the
connectivity in a different way that just straight connections
can...they "stitch together" otherwise visibly-connected regions with
unobservable connections, a desirable thing.)

What else?

* Lots more remailers. Run out of accounts, not just "remailer
machines." Accounts allow trivial proliferation of more remailers.

* Web access remailers. Like the "anonymous anonymous ftp," why not
explore combining Web systems with remailers? (Not so great for
browsing, of course, but there should be some interesting
possibilities.)

* More offshore sites, members, etc. This increases connectivity and
increases the "regulatory arbitrage" we so often talk about.

* Local corporate computer nets are "extra rooms in cyberspace," and
thus are harder to search. The equivalents of "rat lines" (in which
drugs are kept in one apartment and retrieved through a hole in the
wall, thus delaying/foiling searches and kick-in-the-door
raids....think of how technology makes all this so much easier).

* digital cash is of course of central importance. It glues commerce
together, but also greases it (a dual metaphor, not a mixed one). In
terms of the "richness" I'm talking about, it incentivizes the
colonization of cyberspace, the expansion of this space, and the
general richness.

* Alternative Nets, like FIDONet, are often lost in the discussion of
"the Net," but perhaps we should take much greater interest in these
alternatives. They make a crackdown harder, they lessen the dangers of
a single-point attack, and they provide "genetic diversity" for
building future Nets. (I'm not saying Cypherpunks have the time,
expertise, or incentive to work on this, but just reminding folks that
the Internet is not the end all and be all...)

* More users, more education, more articles....all increase
dimensionality, by expanding the space (e.g., key software on more
machines, accessible by more people, more home pages, etc.).

And so on. Increase the richness of cyberspace. More places, more
avenues, more rooms, more more. Make sure there's a "there," there.

Well, I've written too much, and as folks have noted, long posts get
fewer responses that do short ones, especially flamish ones.

Personally, I think there are fewer long essays and analyses for the
same reason there are fewer large predators than grass-munching
herbivores.

--Tim May


-- 

..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From nsb at nsb.fv.com  Mon Feb 13 03:26:23 1995
From: nsb at nsb.fv.com (Nathaniel Borenstein)
Date: Mon, 13 Feb 95 03:26:23 PST
Subject: MIME based remailing commands
In-Reply-To: <17765.792621125.1@nsb.fv.com>
Message-ID: <ojDo69v0Eyt50xSXkP@nsb.fv.com>


Excerpts from mail: 12-Feb-95 Re: MIME based remailing co.. Rick
Busdiecker at lehman.c (1544)

>     Well, I have no idea why you think that MIME is an "atrocity" or
>     "slime", but it is perfectly clear that you have no idea what it
>     actually *is*, since "X-" headers have nothing whatsoever to do with
>     MIME.  The "X-" headers are defined by RFC 822, which has been the
>     standard for Internet mail formats since 1982.

> You base a large conclusion on a small piece of data in combination
> with some poor duduction.  Unless you are claiming that MIME violates
> RFC 822 with respect to the handling of X- headers you have made a
> number of false claims in the paragraph above.

A very interesting claim.  Care to tell me what my "false claims" are,
or is it a secret?

> It is possible for someone to find
> ugliness where you find beauty without them necessarily being
> uninformed.

Of course.  Let me tell you, though, what the real "beauty" of MIME is: 
It is that Internet mail was upgraded from ASCII-text-only to permit
multiple character sets, images, audio, video, and arbitrary extensions,
WITHOUT breaking any existing standards or software.  It is that
multimedia mail was defined in such a way that it can cross existing
ASCII-to-EBCDIC gateways and all manner of other bizarre mail-eating
paths and still be complete and comprehensible on the other end.  That's
the kind of "beauty" we were aiming at, so if your comments are geared
to any specific technical aspects of MIME, this may be the explanation. 
We considered practical functioning and interoperation to be the
operational definition of "beauty".  -- Nathaniel





From root at einstein.ssz.com  Mon Feb 13 04:38:53 1995
From: root at einstein.ssz.com (root)
Date: Mon, 13 Feb 95 04:38:53 PST
Subject: bill alert...
In-Reply-To: <199502130515.VAA14482@art.net>
Message-ID: <199502131235.GAA02452@einstein.ssz.com>


> 
> Do you think this will force folks into using encryption?
> If I was a sysop, I sure would have all my users using
> encryption... :)
> 
> -lile
> 
> 
Then you would have no users. Users resent being made to do anything they
don't want to do. If they decide it is worth it they will do it, otherwise
they go elsewhere.

Take care.






From jburrell at crl.com  Mon Feb 13 04:56:41 1995
From: jburrell at crl.com (Jason Burrell)
Date: Mon, 13 Feb 95 04:56:41 PST
Subject: Archives?
In-Reply-To: <199502130723.CAA15970@ducie.cs.umass.edu>
Message-ID: <199502131255.GAA00423@crl.com>


> BTW, with an eye to avoiding rehashes of old flamewars, this does *not*
> constitute an invitation to scour the subscriber list for *.gov and *.mil and
> announce the results. Consult the archives if in doubt on this point.

Where are these archives? I haven't seen them.

Thanks.






From perry at imsi.com  Mon Feb 13 05:23:43 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 13 Feb 95 05:23:43 PST
Subject: standards...
In-Reply-To: <199502130818.DAA25598@bb.hks.net>
Message-ID: <9502131323.AA20121@snark.imsi.com>



A Loose Affiliation of Millionaires and Billionaires and Babies says:
> >  I.  Public key encryption.
> >      C.  Not limited to one public encryption scheme.
> 
> AFAIK, RSA is the only feasible PK scheme available.  There's eliptic
> curves, of course, but that's patented.

There are plenty of others, like Rabin's scheme, that are quite
practical, but just not used because they are all collectively
patented. After that patent expires in '97 things may change.

Perry





From rah at shipwright.com  Mon Feb 13 05:42:43 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Mon, 13 Feb 95 05:42:43 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
Message-ID: <v01510102ab64cd4dbfed@[199.0.65.105]>


At 1:09 AM 2/13/95, Black Unicorn wrote:
>There is a internet lore that says the more valuable and insightful a
>given article is, the less response it gets.
>
>I hope this is right, as most of mine tend to be ignored.

On the other hand, they also get forwarded to people not on the list who
may be interested, which helps.  Bruce's went to 3 or 4 mathematically
aware people I know. The work of Mssrs 'corn, Froomkin, Hughes, Finney,
May, et.al. get re-zinged all over the place by yours truly.

Some of us don't have the chops to comment on the <mostly> excellent
content of this list. We still appreciate the work.

Thanks to all of you.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From jamesd at netcom.com  Mon Feb 13 06:30:54 1995
From: jamesd at netcom.com (James A. Donald)
Date: Mon, 13 Feb 95 06:30:54 PST
Subject: UMich student arrested for rape story
In-Reply-To: <199502130721.XAA24596@igc3.igc.apc.org>
Message-ID: <Pine.3.89.9502130650.A28579-0100000@netcom9>


On Sun, 12 Feb 1995, Richard F. Dutcher wrote:
 
> In any case, this is hardly cyrpto-related.  I would far rather lurk 
> as the mathematicians discuss factoring.  I learn more [even if I 
> only get one word in three :-]

I am sick to the back teeth of people writing "This is not cryto related,
so I should be allowed to have last word."

This is irritating, offensive, and hypocritical.

In addition the claims you make are entirely false, but I wont rebut
them because you have wandered considerably further from crypto and
privacy than did the post that you are replying to.

> 
> "That's libertarians for you - anarchists who want police protection from their slaves."
>                           Kim Stanley Robinson, "Green Mars"

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From raph at CS.Berkeley.EDU  Mon Feb 13 06:49:51 1995
From: raph at CS.Berkeley.EDU (Raph Levien)
Date: Mon, 13 Feb 95 06:49:51 PST
Subject: List of reliable remailers
Message-ID: <199502131450.GAA17137@kiwi.CS.Berkeley.EDU>


   I operate a remailer pinging service which collects detailed
information about remailer features and reliability.

   To use it, just finger remailer-list at kiwi.cs.berkeley.edu

   There is also a Web version of the same information, at:
http://www.cs.berkeley.edu/~raph/remailer-list.html

   This information is used by premail, a remailer chaining and PGP
encrypting client for outgoing mail, which is available at:
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.30.tar.gz

   For the PGP public keys of the remailers, as well as some help on
how to use them, finger remailer.help.all at 204.95.228.28

This is the current info:

                                 REMAILER LIST

   This is an automatically generated listing of remailers. The first
   part of the listing shows the remailers along with configuration
   options and special features for each of the remailers. The second
   part shows the 12-day history, and average latency and uptime for each
   remailer. You can also get this list by fingering
   remailer-list at kiwi.cs.berkeley.edu.

$remailer{"vox"} = "<remail at vox.xs4all.nl> cpunk pgp. post";
$remailer{"avox"} = "<anon at vox.hacktic.nl> cpunk pgp post";
$remailer{"extropia"} = "<remail at extropia.wimsey.com> cpunk pgp special";
$remailer{"portal"} = "<hfinney at shell.portal.com> cpunk pgp hash";
$remailer{"alumni"} = "<hal at alumni.caltech.edu> cpunk pgp hash";
$remailer{"bsu-cs"} = "<nowhere at bsu-cs.bsu.edu> cpunk hash ksub";
$remailer{"rebma"} = "<remailer at rebma.mn.org> cpunk pgp hash";
$remailer{"c2"} = "<remail at c2.org> eric pgp hash";
$remailer{"soda"} = "<remailer at csua.berkeley.edu> eric post";
$remailer{"penet"} = "<anon at anon.penet.fi> penet post";
$remailer{"ideath"} = "<remailer at ideath.goldenbear.com> cpunk hash ksub";
$remailer{"usura"} = "<usura at replay.com> cpunk pgp. hash latent cut post";
$remailer{"desert"} = "<remail at desert.xs4all.nl> cpunk pgp. post";
$remailer{"nately"} = "<remailer at nately.ucsd.edu> cpunk pgp hash latent cut";
$remailer{"myriad"} = "<remailer at myriad.pc.cc.cmu.edu> cpunk pgp hash latent cut ek";
$remailer{"xs4all"} = "<remailer at xs4all.nl> cpunk pgp hash latent cut post ek";
$remailer{"flame"} = "<tomaz at flame.sinet.org> cpunk pgp hash latent cut post ek";
$remailer{"rahul"} = "<homer at rahul.net> cpunk pgp hash";
$remailer{"mix"} = "<mixmaster at nately.ucsd.edu> cpunk pgp hash latent cut ek ksub";
$remailer{"q"} = "<q at c2.org> cpunk pgp hash latent cut ek ksub";
$remailer{"syrinx"} = "<syrinx at c2.org> cpunk pgp";
$remailer{"tower"} = "<remailer at tower.techwood.org> cpunk pgp";
$remailer{"eniac"} = "<vanklava at eniac.ac.siue.edu> cpunk pgp hash latent cut ek";
$remailer{"charon"} = "<charon at styx.jpunix.com> cpunk hash latent cut ek";
$remailer{"bonafide"} = "<remailer at bonafide.jpunix.com> cpunk hash latent cut ek";
$remailer{"ford"} = "<ford at prefect.jpunix.com> cpunk hash latent cut ek";
$remailer{"aegis"} = "<aegis at athena.jpunix.com> cpunk";
catalyst at netcom.com is _not_ a remailer.
lmccarth at ducie.cs.umass.edu is _not_ a remailer.

JPUNIX.COM offers a domain hiding service for remailers. Send email to 
perry at jpunix.com for more information. NOTE: JPUNIX.COM itself does not 
run a remailer. All subdomains of jpunix.com on this list are remailers 
that are not physically located on jpunix.com

Use "premail -getkeys pgpkeys at kiwi.cs.berkeley.edu" to get PGP keys
for the remailers. Fingering this address works too.

Last ping: Mon 13 Feb 95 6:00:02 PST
remailer  email address                        history  latency  uptime
-----------------------------------------------------------------------
tower    remailer at tower.techwood.org      *****#*#****     4:34  99.97%
mix      mixmaster at nately.ucsd.edu        ++++++++++++    36:13  99.96%
nately   remailer at nately.ucsd.edu         ++++++++-+++    33:48  99.96%
penet    anon at anon.penet.fi               +++-+++++---  3:28:32  99.99%
rahul    homer at rahul.net                  *#-*+**-***     13:52  99.97%
xs4all   remailer at xs4all.nl               +**+*+++****    11:02  99.94%
bonafide remailer at bonafide.jpunix.com     ##********.-  1:06:02  99.92%
myriad   remailer at myriad.pc.cc.cmu.edu    **********.-  1:07:06  99.84%
vox      remail at vox.xs4all.nl             ..---...--.  23:29:37  99.90%
alumni   hal at alumni.caltech.edu           *##* *+*****     6:35  99.62%
portal   hfinney at shell.portal.com         *##* *+#**#*     4:16  99.62%
c2       remail at c2.org                    ++-+++++++++    42:42  99.49%
q        q at c2.org                         ++-+++++++.+  1:09:16  99.45%
flame    tomaz at flame.sinet.org            **********.-  1:18:51  99.38%
usura    usura at replay.com                 *+ *** *****     8:21  99.22%
ford     ford at prefect.jpunix.com          ++-++++ ++.-  1:46:37  99.21%
bsu-cs   nowhere at bsu-cs.bsu.edu           --**--#*****    27:38  99.18%
soda     remailer at csua.berkeley.edu       ....._. .-.   9:40:51  98.93%
ideath   remailer at ideath.goldenbear.com   --- ------.-  2:40:41  98.55%
charon   charon at styx.jpunix.com           ++-*__****.-  3:38:09  98.24%
syrinx   syrinx at c2.org                    ++-*__******  2:39:40  97.78%
aegis    aegis at athena.jpunix.com              _ -+**.-  4:06:48  96.99%
eniac    vanklava at eniac.ac.siue.edu       +#****    *      5:31  52.27%
rebma    remailer at rebma.mn.org            -     *--    14:20:54  45.33%
desert   remail at desert.xs4all.nl          -_.-_..-     33:07:32  42.87%
extropia remail at extropia.wimsey.com                     5:04:09   1.17%

For more info: http://www.cs.berkeley.edu/~raph/remailer-list.html

   History key
     * # response in less than 5 minutes.
     * * response in less than 1 hour.
     * + response in less than 4 hours.
     * - response in less than 24 hours.
     * . response in more than 1 day.
     * _ response came back too late (more than 2 days).

   Options and features

   cpunk
          A major class of remailers. Supports Request-Remailing-To:
          field.

   eric
          A variant of the cpunk style. Uses Anon-Send-To: instead.

   penet
          The third class of remailers (at least for right now). Uses
          X-Anon-To: in the header.

   pgp
          Remailer supports encryption with PGP. A period after the
          keyword means that the short name, rather than the full email
          address, should be used as the encryption key ID.

   oldpgp
          Remailer does not like messages encoded with MIT PGP 2.6. Other
          versions of PGP, including 2.3a and 2.6ui, work fine.

   hash
          Supports ## pasting, so anything can be put into the headers of
          outgoing messages.

   ksub
          Remailer always kills subject header, even in non-pgp mode.

   nsub
          Remailer always preserves subject header, even in pgp mode.

   latent
          Supports Matt Ghio's Latent-Time: option.

   cut
          Supports Matt Ghio's Cutmarks: option.

   post
          Post to Usenet using Post-To: or Anon-Post-To: header.
          
   special
          Accepts only pgp encrypted messages.

   ek
          Encrypt responses in relpy blocks using Encrypt-Key:
          header.


Raph Levien





From syshtg at gsusgi2.gsu.edu  Mon Feb 13 06:51:10 1995
From: syshtg at gsusgi2.gsu.edu (Tom Gillman)
Date: Mon, 13 Feb 95 06:51:10 PST
Subject: UMich student arrested for rape story
In-Reply-To: <Pine.3.89.9502130650.A28579-0100000@netcom9>
Message-ID: <9502131450.AA26342@gsusgi2.gsu.edu>


On Mon, 13 Feb 1995, James A. Donald wrote:
> 
> On Sun, 12 Feb 1995, Richard F. Dutcher wrote:
> > In any case, this is hardly cyrpto-related.  I would far rather lurk 
> > as the mathematicians discuss factoring.  I learn more [even if I 
> > only get one word in three :-]
> 
> I am sick to the back teeth of people writing "This is not cryto related,
> so I should be allowed to have last word."
> 
> This is irritating, offensive, and hypocritical.
> 
> In addition the claims you make are entirely false, but I wont rebut
> them because you have wandered considerably further from crypto and
> privacy than did the post that you are replying to.
> 

And besides, you wanted the last word...

-- 
 Tom Gillman, Unix/AIX Systems Weenie  |"For a privacy advocate to determine
 Wells Computer Center-Ga. State Univ. |the best way to do key escrow is like
 (404) 651-4503 syshtg at gsusgi2.gsu.edu |a death penalty opponent choosing
 My opinions, not GSU's...             |between gas or electricity"-D.Banisar




From roy at cybrspc.mn.org  Mon Feb 13 08:34:28 1995
From: roy at cybrspc.mn.org (Roy M. Silvernail)
Date: Mon, 13 Feb 95 08:34:28 PST
Subject: bill alert...
In-Reply-To: <199502131235.GAA02452@einstein.ssz.com>
Message-ID: <950213.082427.4B5.rusnews.w165w@cybrspc.mn.org>


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

In list.cypherpunks, root at einstein.ssz.com writes, quoting lile:

>> Do you think this will force folks into using encryption?
>> If I was a sysop, I sure would have all my users using
>> encryption... :)

> Then you would have no users. Users resent being made to do anything they
> don't want to do. If they decide it is worth it they will do it, otherwise
> they go elsewhere.

Some will leave.  Some (one might argue the ones with any basic
intelligence) will stay.  Sure, many users resent being herded.  But the
ones that stick around will be of a higher calibre.

Think of it as evolution in action.
- -- 
Roy M. Silvernail, writing from roy at cybrspc.mn.org
"Ah, man.. you hit the nails right on the heads there.  However, I think
you drove them right into your own forehead."
        -- datsun at wasteland.spam.org (Datsun Q. Wanderer)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLz9u7Rvikii9febJAQFpSwQAta5dfzEET3pmNJYwIGZ2/xH25byGgww7
JB0q/eS/C3WOJQZiygNfqcbkAeY7g5F+1fMHzhKC3CVLLDqlQCSnwFZahEHrjwdO
Z4q+flHeRo7dmPOWsUATdjk/S44BA11SwhgTZeMXJx0HvhRoimMjl06WCkqRmXZl
vbx5SGes33s=
=3pzO
-----END PGP SIGNATURE-----





From rrothenb at ic.sunysb.edu  Mon Feb 13 09:52:55 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 13 Feb 95 09:52:55 PST
Subject: Factoring - State of the Art and Predictions
In-Reply-To: <m0rdnqt-000k5xC@mailbox.mcs.com>
Message-ID: <199502131750.MAA18574@libws4.ic.sunysb.edu>



My knowledge of number theory is negligable, but I've got this one obvious
comment: use algorithms where factoring is not a weakness.

Isn't LUC safe from factoring?





From rrothenb at ic.sunysb.edu  Mon Feb 13 10:14:21 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 13 Feb 95 10:14:21 PST
Subject: bill alert...
In-Reply-To: <199502130515.VAA14482@art.net>
Message-ID: <199502131813.NAA20427@libws4.ic.sunysb.edu>



> Do you think this will force folks into using encryption?
> If I was a sysop, I sure would have all my users using
> encryption... :)

Which bill do you mean (aside from the one in the whitehouse)?

Why force users to do anything. There are other measures, such as running
the system on a secure file/device/drive system.  Well, that would only
help prevent anyone who yeggs your physical system from looking at it--
could even put you in more legal doo-doo that if the users encrypted it.

Getting users to encrypt their mail is pointless as a defense against
this bill, since the authorities' usual way of 'busting' systems is to
call in, become just another user and download (or get a minor to download)
'evil' files or messages.

Rob





From weidai at eskimo.com  Mon Feb 13 11:10:02 1995
From: weidai at eskimo.com (Wei Dai)
Date: Mon, 13 Feb 95 11:10:02 PST
Subject: Is Cyberspace Rich Enough?
Message-ID: <199502131909.AA13622@mail.eskimo.com>


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

> [deleted]

> But can we do more? One of my own wishes is to see hundreds (nay,
> thousands!) of remailers, as these act as "teleportation booths" which
> can dramatically increase connectivity. (They can increase the
> connectivity in a different way that just straight connections
> can...they "stitch together" otherwise visibly-connected regions with
> unobservable connections, a desirable thing.)

I'm not sure that thousands of remailers will ever exist.  There will 
be little incentive for people to use small remailers, which, because 
of their low traffic, add little untracibility per additional unit of 
latency and monetary costs compared to larger remailers.  Larger 
remailers will also likely have better reputations for 
trustworthiness.  The economics seem to indicate that (if a market 
of remailers is ever established) there will be a small number (less than 
a hundred) of large remailers that are well used and profitable, and 
a larger number of small remailers that are nearly never used.

> [deleted]
 
> * Web access remailers. Like the "anonymous anonymous ftp," why not
> explore combining Web systems with remailers? (Not so great for
> browsing, of course, but there should be some interesting
> possibilities.)

Remailers don't seem to be a good way to access the WWW, which is 
much more efficient when done interactively.  On the other hand, my 
proposed Pipe-net would seem to be perfect for this, and other 
communications that need both untracibility and low latency.

Wei Dai

P.S. People are more likely to respond to things they don't agree 
with (as I did here).  If you write something and no one responds, 
it probably means that everyone except the lurkers agree with you, so 
take it as a good sign.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz+uDzl0sXKgdnV5AQFvkwP/XiKF5kYexZUje14rk2iyxlLpLke8EHCY
BbRMFQZFQPk0KFo/8iThSn1Xs0xgHrjud5hmpoBxkR+pKMTPfNx6rbTFoSF3HQtX
VzNacOYflcb/eSjHDS02IhMH5wYeUpmKzBE+K4ZgZ35i7sdx8yoHb8laYp1Trhq5
iQ4fbWNy+UA=
=DiM1
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From blancw at microsoft.com  Mon Feb 13 11:12:24 1995
From: blancw at microsoft.com (Blanc Weber)
Date: Mon, 13 Feb 95 11:12:24 PST
Subject: Is Cyberspace Rich Enough?
Message-ID: <9502131912.AA24488@netmail2.microsoft.com>


From: Timothy C. May

"(Actually, cyberspace is partly getting "bigger" and partly
"increasing in dimensionality." Dimensionality of a space can be
related to how many neighbors one has....think of the two nearest
neighbors one has in a 1-D space, the 4 (or 8 if diagonals are
considered) neighbors in a 2-D space, the 6 in a 3-D space, and so on.
Arguably, if one has "100 close neighbors" in a space, it is roughly a
50 dimensional space. An equivalent formulation is in terms of the
radius of the n-sphere that everyone fits into. For example, the "six
degrees of separation," the 6 "handshakes" that separate nearly any
two people in America, suggests that American society is in some
important sense roughly a 15-17 dimensional space, because in some
sense all 250 million Americans "fit into" a hypersphere of radius 3
(diameter 6) when the dimensionality is around 17. (Or slightly lower,
as the slight corrections to V = r ^ n have to be included, which I'm
not bothering with). What "increased connectivity" does is to increase
dimensionality, about as one would expect from our usual metaphors
about "a multidimensional society" and "the world is
shrinking"...indeed it is shrinking, even as the absolute volume
increases.)"

         Well, what I want to know about this, is:
          what are the symmetries involved in the product?

          (I learned that question this weekend)


"What Cypherpunks should be pushing for, in my view, is this increased
dimensionality. More places to stick things, more places to escape
central control, and more degrees of freedom (which has a nice dual
meaning I once used as the working title for a novel I was working
on)."

I think that this proliferation of places will increase as people find 
immediate, practical or entertaining uses for home pages and places to 
stash info, before they will seek to find places to hide, to evade 
detection, to escape notice, or to blend into the milieu as the aim of 
their cyberspatial activity.

And shouldn't there be some mention of the "hardware" involved in 
making cyberspace possible?  Wouldn't there some requirement for more 
cables underground to places which don't yet have them, and utility 
companies to manage the flow of electricity, etc?   I don't know a 
great deal about these things, but it's hardly ever mentioned here, as 
though electricity just flows by itself somewhere called 'cyberspace' 
and all one ever has to think about (besides crypto and software 
commands) are how to plug oneself in, like 3C-PO.    But somebody has 
to install the plugs in, first.

    ..
Blanc





From rah at shipwright.com  Mon Feb 13 11:26:14 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Mon, 13 Feb 95 11:26:14 PST
Subject: Fun with numbers: Payment Switches
Message-ID: <v01510100ab651dd4939c@[199.0.65.105]>


Saw this on buyinfo. At first blush it reminds me of the old CMU "Billing
Server" without the gopher...

>From: treese at OpenMarket.com
>To: www-buyinfo at allegra.att.com
>Subject: technical paper: Payment Switches for Open Networks
>Date: Mon, 13 Feb 1995 13:24:48 -0500
>Original-From: Win Treese <treese at OpenMarket.com>
>
>
>"Payment Switches for Open Networks" by David K. Gifford, Lawrence
>C. Stewart, Andrew C. Payne, and G. Winfield Treese is a technical
>paper describing Open Market's Internet payment switch.  It will be
>presented at IEEE COMPCON '95 (San Francisco, March 5-9). A preprint
>is available from http://www.openmarket.com/about/technical/.
>
>Here is the abstract from the paper:
>
>    We describe the first operational Internet payment switch that
>    provides real-time authorization suitable for direct use by merchant
>    servers.  A payment switch is a server that creates digital
>    representations of conventional financial instruments, and forwards
>    authentic payment orders on these instruments to their corresponding
>    conventional financial networks and institutions.  Our payment switch
>    provides support for time-based and item-based pricing, implements
>    switch based authorization and settlement aggregation for
>    micro-payments, and includes an extensive customer support system in
>    order to provide a high level of customer confidence in electronic
>    commerce.  Fraud control is based on a transaction-specific
>    multi-level security model that accommodates existing Internet
>    browsers.  Multiple authentication technologies are applied to every
>    transaction.
>
>More information about COMPCON '95 can be found at
> http://www.hal.com:80/compcon/
>
>Win Treese
>Open Market, Inc.
>treese at OpenMarket.com
>

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From usviszpz at ibmmail.com  Mon Feb 13 11:48:03 1995
From: usviszpz at ibmmail.com (usviszpz at ibmmail.com)
Date: Mon, 13 Feb 95 11:48:03 PST
Subject: WSJ article on Internet Telephony
Message-ID: <9502131947.AA17236@toad.com>


Friday's Wall Street Journel (Feb. 10, page B1, col 6) includes an article on
"Internet Phone," a new software program that supposedly offers intelligible
real-time voice communication over the net.

The article cites potential cost savings of this approach as the primary
benefit of this technology: long-distance voice calls in on-line time instead
of $$/minute over AT&T will be much, much cheaper. Since Internet accounts for
many of us are of low or negligable cost, that angle is indeed significant, but
for the readers of this list it seems to me that the more interesting
possibilities here lie in the potential for bypassing the phone network
and leveraging existing privacy/authentication/anonymity tools for use with
voice communications as well as data. I imagine any privacy buff would like the
option of routing his/her calls out of the (Federally-mandated-wiretap-
compatible) normal phone system. Can this represent a development path for that
option?

{The producers of Internet Phone are listed as VocalTec in Tel Aviv, with
offices in Northvale, NJ; the software is currently $49 (although a demo
version allowing unlimited 3-min calls is free) and currently requires a 14.4
kps modem with a Windows 486, sound card & microphone. No Email address for the
company was given.)

For those for whom this is already old news, I would like to ask: any idea if
this technology is related in any way to VoicePGP? If not, any thoughts on the
development ramifications of this for VoicePGP?

If anybody wants the full text of the article and does not have easy access to
the WSJ, I can get it onto an Email. It may take a little while, though; I do
not have OCR and I'm not the fastest typist.

Regards all,

C.Y.

 
 





From gnu  Mon Feb 13 12:43:06 1995
From: gnu (gnu)
Date: Mon, 13 Feb 95 12:43:06 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
Message-ID: <9502132043.AA17858@toad.com>


------------------------------------------------------------------------
   ******    ********    *************
  ********   *********   *************   
  **         **      **       ***               POLICY POST  
  **         **      **       ***               
  **         **      **       ***               February 13, 1995
  **         **      **       ***               Number 2
  ********    *********       ***              
   ******    ********         ***
                
  CENTER FOR DEMOCRACY AND TECHNOLOGY
------------------------------------------------------------------------
  A briefing on public policy issues affecting civil liberties online
------------------------------------------------------------------------
CDT POLICY POST 2/13/95                                     Number 2

CONTENTS: (1) X9 Committee Agrees to Develop 3x DES Encryption Standard
          (2) About the Center for Democracy and Technology

This document may be re-distributed freely providing it remains in its 
entirety.
------------------------------------------------------------------------

X9 COMMITTEE AGREES TO DEVELOP 3x DES ENCRYPTION STANDARD 

Major Setback for NSA

The NSA's efforts to push the adoption the Clipper/Skipjack 
government-escrowed encryption scheme encountered a major 
setback earlier this month with the decision by the 
Accredited Standards Committee X9 to proceed with the 
development of a data security standard based on triple-DES.    

The ASC X9 committee is responsible for setting data security 
standards for the US banking and financial services 
industries.   These industries are heavy users of commercial 
cryptography, and standards developed for this community tend 
to drive the development of applications for the entire 
market.  As a result, the committee's decision to proceed 
with a triple-DES standard has important implications for 
future cryptographic standards and US cryptography policy 
generally.

The NSA, a voting member of the X9 committee, had lobbied 
hard against the proposal.  In a November letter to committee 
members, the NSA threatened to prevent the export of triple-
DES, citing existing US law and potential threats to national 
security (see attached NSA letter).

The decision sets the stage for the development of a next 
generation of security standards based on publicly available, 
non-escrowed encryption schemes.   A battle over the 
exportability of triple-DES applications is also on the 
horizon.

Through export controls on cryptography, the proposed Clipper 
initiative, and interference in the standards setting 
processes, US government policies have consistently sought to 
make strong encryption and other privacy protecting 
technologies unavailable to the general public.  The X9 
decision and development of triple-DES and other alternitives 
to government-escrowed cryptography is an important victory 
in that it will increase the public's access to strong, 
privacy enhancing technologies.

BACKGROUND

Banks and other financial institutions use encryption to 
protect the billions of dollars in transactions and fund 
transfers which flow every day across the world's 
communications networks.  

The current encryption standard used by the banking industry 
is based on DES, which has been available since the early 
1970's.  DES is widely trusted because it has been repeatedly 
tested and is considered by experts to be unbreakable except 
by brute force (trying every possible key combination).  The 
US government has also allowed the limited export of DES.

Despite its popularity, DES is considered to be reaching the 
end of its useful life.   The increasing speed and 
sophistication of computer processing power has begun to 
render DES vulnerable to brute force attacks.  Cryptographers 
have recently demonstrated that DES codes can be cracked in 
as little as three hours with $1 million worth of currently 
available equipment.  As a result, the banking and financial 
services industries have begun to explore alternatives to 
DES.  

Although there are many potential alternatives to DES, 
triple-DES is widely seen as the most practical solution.  
Triple-DES is based on DES, but has been enhanced by 
increasing the key length and by encrypting through multiple 
iterations.   These enhancements make triple-DES less 
vulnerable to brute force attacks.  Triple-DES is also 
popular because it can be easily incorporated into existing 
DES systems and is based on standards and procedures familiar 
to most users.   

NSA SETBACK IS A VICTORY FOR CLIPPER OPPONENTS

In their November letter to X9 committee members, the NSA 
attempted to undermine the attractiveness of triple-DES by 
arguing that it is cryptographically unsound, a potential 
threat to national security, and would not be exportable 
under US law.   The NSA, while offering no specific 
alternative to triple-DES, seemed to be attempting to push 
the committee to adopt the only currently available option -- 
Clipper.

Privacy advocates also lobbied the X9 committee.  In a letter 
sent in advance of the December 1994 ballot, CDT Deputy 
Director Daniel Weitzner (then EFF Deputy Policy Director) 
and EFF board member John Gilmore, an expert in this field, 
sent a letter to X9 committee members urging them to adopt 
the triple-DES standard. A copy of the letter is appended at 
the end of this post.

By agreeing to develop a triple-DES standard, the X9 
committee has clearly and decisively rejected Clipper as a 
solution. This vote thus represents a further repudiation to 
Clipper and yet another victory for opponents of government 
efforts to establish Clipper or other government-escrowed 
solutions as a national standard.

NEXT STEPS

X9F, a subcommittee of the X9 committee, will now develop 
technical standards for implementing triple-DES based 
applications.  This process is expected to take one or two 
years to complete.  Once technical standards are developed, 
the full X9 committee will vote as to whether to implement 
the subcommittee's technical recommendations.

The availability of triple-DES applications received a 
further boost recently with the announcement by AT&T and VLSI 
Technologies that they were developing new data security 
products based on triple-DES. This will presumably provide 
additional options for X9 committee members, but the 
exportability of these products is still in doubt.

The stage is thus set for a further battle between the NSA 
and the X9 committee over the exportability of triple-DES and 
final approval of the X9 standard.  As a sitting member of 
the committee, NSA will presumably continue to lobby against 
efforts by the committee to develop triple-DES applications.  
Furthermore, the banking and financial services industries 
must still persuade the government to allow for the export of 
triple-DES.  

As an opponent of government-escrowed cryptography, CDT 
applauds the recent actions of the X9 committee.  While CDT 
supports the development of a variety of security standards 
and alternatives to DES, we recognize the need of the banking 
and financial services industries to develop temporary stop-
gap solution. CDT will continue to work towards the 
relaxation of export controls on cryptography and will 
support X9 committee members in their efforts to gain the 
ability to export triple-DES applications.  

For more information contact:

Daniel J. Weitzner, Deputy Director       <djw at cdt.org>
Jonah Seiger, Policy Analyst              <jseiger at cdt.org>

+1.202.637.9800

----------------------------------------------------------

GILMORE/WEITZNER LETTER TO X9 COMMITTEE MEMBERS

November 18, 1994

Dear Accredited Standards Committee-X9 Member:

The X9 Committee is currently voting as to whether to 
recommend the development of a standard for triple-DES (ballot number 
X9/94-LB#28).  The Electronic Frontier Foundation (EFF) strongly urges you to 
vote in favor of the triple-DES standard.

EFF supports the development of a variety of new data 
security standards and alternatives to DES.  We believe the triple-DES standard 
provides the best immediate short term alternative because:

        * The basic algorithm, DES, is strong and has been 
          tested repeatedly.

        * There are no known attacks that succeed against 
          triple-DES.

        * It is clearly no less secure than DES.

        * It eliminates the brute-force problem completely by 
          tripling the key length.

        * It runs at high speeds in easy-to-build chips.

        * It can be easily incorporated into existing systems.

NSA's opposition to triple-DES appears to be an indirect attempt to push
Clipper by eliminating credible alternatives. Clipper is not a viable
alternative to triple-DES, and carries substantial liabilities. There has
been no evidence of foreign acceptance of the standard and the skipjact
algorithm is classified. The likelihood of any government accepting secret
standards developed by a foreign security agency is slim. Clinton
Administration efforts, through the NSA, to push Clipper as a domestic
standard over the past two years have failed.  

We urge you to carefully consider the alternatives before you 
cast your ballot.  We believe that the triple-DES issue should be 
decided on its own merits.

Sincerely, 

John Gilmore                            
Board of Directors                      
Electronic Frontier Foundation  

Daniel J. Weitzner
Deputy Policy Director
Electronic Frontier Foundation

-------------------------------------------------------------

NSA LETTER TO X9 COMMITTEE MEMBERS

X9 Member:

I will be casting a NO vote on the NWI for triple-DES, Letter 
Ballot X9/94-LB#28.  The reasons are set forth below.  You 
may find these useful as you determine your position.

Jerry Rainville

                NSA REASONS FOR A NEGATIVE VOTE

While NSA supports the use of DES in the global financial 
sector, we believe that standardization of triple-DES is ill-
advised for a number of reasons.

The financial community should be planning to transition to a 
new generation of cryptographic algorithms.  When DES was 
first introduced, it represented the "only game in town".  It 
supported encryption, authentication, key management, and 
secure hashing applications.  With a broader interest in 
security, the market can now support optimized algorithms by 
application.  Going through the expense of installing a stop-
gap can only serve to delay progress in achieving 
interoperable universal appropriate solutions.

While we understand the appeal of a snap-in upgrade, our 
experience has been that any change is expensive, especially 
one where the requirements on the key management system 
change.  We do not agree that replacing DES with triple-DES 
is significantly less expensive than upgrading to more 
appropriate technology.

Tripling of any algorithm is cryptographically unsound.  
Notice that tripling DES, at best, only doubles the length of 
the cryptovariable (key).  Phrased another way, the DES was 
optimized for security at 56 bits.  We cannot vouch that any 
of the schemes for doubling the cryptovariable length of DES 
truly squares security.

We understand the financial community has concerns with 
current key escrow based encryption, however, we are 
committed to searching for answers to those concerns.  But 
the government is also committed to key escrow encryption, 
and we do not believe that the proposal for triple DES is 
consistent with this objective.

US export control policy does not allow for general export of 
DES for encryption, let alone triple-DES.  Proceeding with 
this NWI would place X9 at odds with this long standing 
policy.  It also violates the newly accepted X9 cryptographic 
policy.

The US government has not endorsed triple-DES; manufacturers 
and users may be reluctant to use triple-DES products for 
fear of possible liability.

Finally, further proliferation of triple-DES is counter to 
national security and economic objectives.  We would welcome 
the opportunity to discuss these concerns with an appropriate 
executive of your institution.

---------------------------------------------------------------------

ABOUT THE CENTER FOR DEMOCRACY AND TECHNOLOGY

The Center for Democracy and Technology is a non-profit public interest
organization. The Center's mission is to develop and advocate public
policies that advance constitutional civil liberties and democratic 
values in new computer and communications technologies. 

Contacting us:

General information on CDT can be obtained by sending mail to <info at cdt.org>

www/ftp/gopher archives are currently under construction, and should be up
and running by the middle of March. 

                                 ###
------------------------------------------------------------------------
   ******    ********    *************
  ********   *********   *************   
  **         **      **       ***               POLICY POST  
  **         **      **       ***               
  **         **      **       ***               February 13, 1995
  **         **      **       ***               Number 2
  ********    *********       ***              
   ******    ********         ***
                
  CENTER FOR DEMOCRACY AND TECHNOLOGY
------------------------------------------------------------------------
  A briefing on public policy issues affecting civil liberties online
------------------------------------------------------------------------
CDT POLICY POST 2/13/95                                     Number 2

CONTENTS: (1) X9 Committee Agrees to Develop 3x DES Encryption Standard
          (2) About the Center for Democracy and Technology

This document may be re-distributed freely providing it remains in its 
entirety.
------------------------------------------------------------------------

X9 COMMITTEE AGREES TO DEVELOP 3x DES ENCRYPTION STANDARD 

Major Setback for NSA

The NSA's efforts to push the adoption the Clipper/Skipjack 
government-escrowed encryption scheme encountered a major 
setback earlier this month with the decision by the 
Accredited Standards Committee X9 to proceed with the 
development of a data security standard based on triple-DES.    

The ASC X9 committee is responsible for setting data security 
standards for the US banking and financial services 
industries.   These industries are heavy users of commercial 
cryptography, and standards developed for this community tend 
to drive the development of applications for the entire 
market.  As a result, the committee's decision to proceed 
with a triple-DES standard has important implications for 
future cryptographic standards and US cryptography policy 
generally.

The NSA, a voting member of the X9 committee, had lobbied 
hard against the proposal.  In a November letter to committee 
members, the NSA threatened to prevent the export of triple-
DES, citing existing US law and potential threats to national 
security (see attached NSA letter).

The decision sets the stage for the development of a next 
generation of security standards based on publicly available, 
non-escrowed encryption schemes.   A battle over the 
exportability of triple-DES applications is also on the 
horizon.

Through export controls on cryptography, the proposed Clipper 
initiative, and interference in the standards setting 
processes, US government policies have consistently sought to 
make strong encryption and other privacy protecting 
technologies unavailable to the general public.  The X9 
decision and development of triple-DES and other alternitives 
to government-escrowed cryptography is an important victory 
in that it will increase the public's access to strong, 
privacy enhancing technologies.

BACKGROUND

Banks and other financial institutions use encryption to 
protect the billions of dollars in transactions and fund 
transfers which flow every day across the world's 
communications networks.  

The current encryption standard used by the banking industry 
is based on DES, which has been available since the early 
1970's.  DES is widely trusted because it has been repeatedly 
tested and is considered by experts to be unbreakable except 
by brute force (trying every possible key combination).  The 
US government has also allowed the limited export of DES.

Despite its popularity, DES is considered to be reaching the 
end of its useful life.   The increasing speed and 
sophistication of computer processing power has begun to 
render DES vulnerable to brute force attacks.  Cryptographers 
have recently demonstrated that DES codes can be cracked in 
as little as three hours with $1 million worth of currently 
available equipment.  As a result, the banking and financial 
services industries have begun to explore alternatives to 
DES.  

Although there are many potential alternatives to DES, 
triple-DES is widely seen as the most practical solution.  
Triple-DES is based on DES, but has been enhanced by 
increasing the key length and by encrypting through multiple 
iterations.   These enhancements make triple-DES less 
vulnerable to brute force attacks.  Triple-DES is also 
popular because it can be easily incorporated into existing 
DES systems and is based on standards and procedures familiar 
to most users.   

NSA SETBACK IS A VICTORY FOR CLIPPER OPPONENTS

In their November letter to X9 committee members, the NSA 
attempted to undermine the attractiveness of triple-DES by 
arguing that it is cryptographically unsound, a potential 
threat to national security, and would not be exportable 
under US law.   The NSA, while offering no specific 
alternative to triple-DES, seemed to be attempting to push 
the committee to adopt the only currently available option -- 
Clipper.

Privacy advocates also lobbied the X9 committee.  In a letter 
sent in advance of the December 1994 ballot, CDT Deputy 
Director Daniel Weitzner (then EFF Deputy Policy Director) 
and EFF board member John Gilmore, an expert in this field, 
sent a letter to X9 committee members urging them to adopt 
the triple-DES standard. A copy of the letter is appended at 
the end of this post.

By agreeing to develop a triple-DES standard, the X9 
committee has clearly and decisively rejected Clipper as a 
solution. This vote thus represents a further repudiation to 
Clipper and yet another victory for opponents of government 
efforts to establish Clipper or other government-escrowed 
solutions as a national standard.

NEXT STEPS

X9F, a subcommittee of the X9 committee, will now develop 
technical standards for implementing triple-DES based 
applications.  This process is expected to take one or two 
years to complete.  Once technical standards are developed, 
the full X9 committee will vote as to whether to implement 
the subcommittee's technical recommendations.

The availability of triple-DES applications received a 
further boost recently with the announcement by AT&T and VLSI 
Technologies that they were developing new data security 
products based on triple-DES. This will presumably provide 
additional options for X9 committee members, but the 
exportability of these products is still in doubt.

The stage is thus set for a further battle between the NSA 
and the X9 committee over the exportability of triple-DES and 
final approval of the X9 standard.  As a sitting member of 
the committee, NSA will presumably continue to lobby against 
efforts by the committee to develop triple-DES applications.  
Furthermore, the banking and financial services industries 
must still persuade the government to allow for the export of 
triple-DES.  

As an opponent of government-escrowed cryptography, CDT 
applauds the recent actions of the X9 committee.  While CDT 
supports the development of a variety of security standards 
and alternatives to DES, we recognize the need of the banking 
and financial services industries to develop temporary stop-
gap solution. CDT will continue to work towards the 
relaxation of export controls on cryptography and will 
support X9 committee members in their efforts to gain the 
ability to export triple-DES applications.  

For more information contact:

Daniel J. Weitzner, Deputy Director       <djw at cdt.org>
Jonah Seiger, Policy Analyst              <jseiger at cdt.org>

+1.202.637.9800

----------------------------------------------------------

GILMORE/WEITZNER LETTER TO X9 COMMITTEE MEMBERS

November 18, 1994

Dear Accredited Standards Committee-X9 Member:

The X9 Committee is currently voting as to whether to 
recommend the development of a standard for triple-DES (ballot number 
X9/94-LB#28).  The Electronic Frontier Foundation (EFF) strongly urges you to 
vote in favor of the triple-DES standard.

EFF supports the development of a variety of new data 
security standards and alternatives to DES.  We believe the triple-DES standard 
provides the best immediate short term alternative because:

        * The basic algorithm, DES, is strong and has been 
          tested repeatedly.

        * There are no known attacks that succeed against 
          triple-DES.

        * It is clearly no less secure than DES.

        * It eliminates the brute-force problem completely by 
          tripling the key length.

        * It runs at high speeds in easy-to-build chips.

        * It can be easily incorporated into existing systems.

NSA's opposition to triple-DES appears to be an indirect attempt to push
Clipper by eliminating credible alternatives. Clipper is not a viable
alternative to triple-DES, and carries substantial liabilities. There has
been no evidence of foreign acceptance of the standard and the skipjact
algorithm is classified. The likelihood of any government accepting secret
standards developed by a foreign security agency is slim. Clinton
Administration efforts, through the NSA, to push Clipper as a domestic
standard over the past two years have failed.  

We urge you to carefully consider the alternatives before you 
cast your ballot.  We believe that the triple-DES issue should be 
decided on its own merits.

Sincerely, 

John Gilmore                            
Board of Directors                      
Electronic Frontier Foundation  

Daniel J. Weitzner
Deputy Policy Director
Electronic Frontier Foundation

-------------------------------------------------------------

NSA LETTER TO X9 COMMITTEE MEMBERS

X9 Member:

I will be casting a NO vote on the NWI for triple-DES, Letter 
Ballot X9/94-LB#28.  The reasons are set forth below.  You 
may find these useful as you determine your position.

Jerry Rainville

                NSA REASONS FOR A NEGATIVE VOTE

While NSA supports the use of DES in the global financial 
sector, we believe that standardization of triple-DES is ill-
advised for a number of reasons.

The financial community should be planning to transition to a 
new generation of cryptographic algorithms.  When DES was 
first introduced, it represented the "only game in town".  It 
supported encryption, authentication, key management, and 
secure hashing applications.  With a broader interest in 
security, the market can now support optimized algorithms by 
application.  Going through the expense of installing a stop-
gap can only serve to delay progress in achieving 
interoperable universal appropriate solutions.

While we understand the appeal of a snap-in upgrade, our 
experience has been that any change is expensive, especially 
one where the requirements on the key management system 
change.  We do not agree that replacing DES with triple-DES 
is significantly less expensive than upgrading to more 
appropriate technology.

Tripling of any algorithm is cryptographically unsound.  
Notice that tripling DES, at best, only doubles the length of 
the cryptovariable (key).  Phrased another way, the DES was 
optimized for security at 56 bits.  We cannot vouch that any 
of the schemes for doubling the cryptovariable length of DES 
truly squares security.

We understand the financial community has concerns with 
current key escrow based encryption, however, we are 
committed to searching for answers to those concerns.  But 
the government is also committed to key escrow encryption, 
and we do not believe that the proposal for triple DES is 
consistent with this objective.

US export control policy does not allow for general export of 
DES for encryption, let alone triple-DES.  Proceeding with 
this NWI would place X9 at odds with this long standing 
policy.  It also violates the newly accepted X9 cryptographic 
policy.

The US government has not endorsed triple-DES; manufacturers 
and users may be reluctant to use triple-DES products for 
fear of possible liability.

Finally, further proliferation of triple-DES is counter to 
national security and economic objectives.  We would welcome 
the opportunity to discuss these concerns with an appropriate 
executive of your institution.

---------------------------------------------------------------------

ABOUT THE CENTER FOR DEMOCRACY AND TECHNOLOGY

The Center for Democracy and Technology is a non-profit public interest
organization. The Center's mission is to develop and advocate public
policies that advance constitutional civil liberties and democratic 
values in new computer and communications technologies. 

Contacting us:

General information on CDT can be obtained by sending mail to <info at cdt.org>

www/ftp/gopher archives are currently under construction, and should be up
and running by the middle of March. 

                                 ###





From wcs at anchor.ho.att.com  Mon Feb 13 12:46:28 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 12:46:28 PST
Subject: standards...
Message-ID: <9502132044.AA24186@anchor.ho.att.com>


> > AFAIK, RSA is the only feasible PK scheme available.  There's eliptic
> > curves, of course, but that's patented.
> There are plenty of others, like Rabin's scheme, that are quite
> practical, but just not used because they are all collectively
> patented. After that patent expires in '97 things may change.

There are different uses for public-key systems, and some systems
support some but not all of the uses.  For instance,
Diffie-Hellman is useful for key exchage (and patented till 1997),
and the NIST/NSA's DSS Digital Signature Standard is useful for signatures,
especially if you like subliminal channels in your signatures :-), 
though the patent status depends on whether you believe NIST or RSA ....





From weidai at eskimo.com  Mon Feb 13 13:07:01 1995
From: weidai at eskimo.com (Wei Dai)
Date: Mon, 13 Feb 95 13:07:01 PST
Subject: Is Cyberspace Rich Enough?
Message-ID: <199502132106.AA22391@mail.eskimo.com>


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

> That theme is this: Is cyberspace, or the Net/Web/Etc., sufficiently
> rich or complex to meet our needs?

 [deleted]

> Consider how the abstractions of the World Wide Web, URLs, HTML, HTTP,
> and Web browsers have *increased the size of cyberspace* rather
> dramatically in just the past two years. More places to visit, more
> interconnectedness, more difficulties in controlling access to stuff,
> etc. Home pages containing banned material are proliferating (a la the
> Homolka-Teale ritualistic cannibalism trial in Canada, the Scientology
> material, and so on--this is not the place for me to recap this).
> Sure, ftp sites used to do this pretty well; in fact, I'm considering
> ftp sites in this "evolution" toward greater complexity (in the
> richness sense).

I agree that cyberspace is certainly becoming more complex and
interconnected.  However, just as a complex ecosystem is not necessarily
more stable than a simple one, and a complex cipher is not necessarily
more secure than a simple one, greater complexity in cyberspace does not
necessarily imply that it is less vulnerable to to centralized control.

[more stuff deleted]

> What Cypherpunks should be pushing for, in my view, is this increased
> dimensionality. More places to stick things, more places to escape
> central control, and more degrees of freedom (which has a nice dual
> meaning I once used as the working title for a novel I was working
> on).

But if you wanted to exert greater control over others, you would also
be pushing for increased dimensionality, because that shrinks the world
and moves everyone closer to you.  If you look at history, increased
connectivity has always been necessary for increased central control.
What I am saying is that increased connectivity alone does not
necessarily favor decentralization.  What makes the difference is the
details -- the nature of the connectivity.

> Is Cyberspace already rich enough (= high enough dimensionality) so
> that central control cannot be reestablished (to the extent it ever
> existed)?
>
> Many of this think that it probably already is past this point, that
> the "point of no return" has been reached. After all, the Soviets
> couldn't stop samizdats, the Chinese couldn't stop fax machines, and
> the Americans can't stop drug use, so what hope is there in
> controlling modems, crypto, cellular phones, satellites, Web links,
> stegonography, terabytes of data flowing unobstructed across borders,
> and so on. Just to "stop the Net" would disrupt the entire financial
> system, which not even Clinton or the next (Republican) President
> would be tempted to do....they might as well launch a nuclear war as
> try to shut down this "anarchic" ( = high dimensionality) system.

I'm not quite so optimistic.  One way to control a distributed system
such as the Internet would be to use a distributed method.  I.e., use
something like the Internet Worm, but a thousand times subtler and more
powerful.  There is no need for them to "stop the Net", just to subvert
a substantial part of it.

Wei Dai

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz/I0Tl0sXKgdnV5AQGEewP7BGVcIdtKv5UIh8z3ydSoMdOdvLyBxww3
N3f4NKaXTwS6PPfdmRafcN7i3mKEDIlB6CKBBEL5qV2GkDpmTi9rehD2q5hZFzEX
vdHYg8k/YRo8ZNnLdaelZO7EPFpFwX3XCeyd2Ap6efzrr7djX98ckJWb5ZMnK/Xp
BOLeEwxTF6Y=
=hcI1
-----END PGP SIGNATURE-----

E-mail: Wei Dai <weidai at eskimo.com>   URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?





From wcs at anchor.ho.att.com  Mon Feb 13 13:14:18 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 13:14:18 PST
Subject: perry@imsi.comRe: Does PGP scale well?
Message-ID: <9502132105.AA24452@anchor.ho.att.com>


> > I was just reading RFC1034 about DNS, and one thing I noted was that
> > there is a "reverse lookup" feature.  [....]
> > The RFC did not make it very clear how this is done.  Does this use a
> > "flat" database?
> 
> No. Its fully distributed. The fact that networks are assigned in
> heirarchical chunks should explain how its done, and why the bytes get
> reversed for the lookup. As an example, MIT owns network 18, which is
> to say that all MIT addresses are 18.XXX.XXX.XXX, and 18.IN-ADDR.ARPA
> is a server at MIT. MIT may have sub-servers beyond that level, but
> DNS makes us oblivious to this.

Of course, that's more useful for MIT, which owns Network 18,
than for the thousands of people on networks 192.xxx.xxx;
reverse lookups don't seem as reliable for Class C.
On the site I run, I implement reverse lookups for my subnet,
and the folks who run our larger internal net have pointers that 
know how to find it.  But DNS would work for forward lookups
even if the reverse weren't maintained, or deliberately omitted 
some parts for security/predictability reasons.





From wcs at anchor.ho.att.com  Mon Feb 13 13:54:28 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 13:54:28 PST
Subject: TEMPEST Paper by Former Civilian (1/2)
Message-ID: <9502132110.AA24519@anchor.ho.att.com>


Sigh.  Some anonymous poster drags up "Christopher Seline"'s
wildly inaccurate article about TEMPEST.  Aside from having a reverse-
engineered deacronymization of TEMPEST (which isn't an acronym and
isn't about Transient Electromagnetic Pulses), misunderstanding 
TEMPEST certification, not getting its legalities right,
it's in general just plain confused and sensationalist.

			Bill





From banisar at epic.org  Mon Feb 13 13:57:36 1995
From: banisar at epic.org (Dave Banisar)
Date: Mon, 13 Feb 95 13:57:36 PST
Subject: EPIC to Debate Exon on CNN
Message-ID: <n1419433051.47954@epic.org>




CNN's 6:00 p.m. (EST) news broadcast tonight (2/13) will include a
segment on S. 314, "The Communications Decency Act," introduced by
Sen. James Exon (D-NE).  Judy Woodruff will moderate a discussion 
of the bill with Sen. Exon and Marc Rotenberg of the Electronic
Privacy Information Center (EPIC).



_________________________________________________________________________
Subject: EPIC to Debate Exon on CNN
_________________________________________________________________________
David Banisar (Banisar at epic.org)       * 202-544-9240 (tel)
Electronic Privacy Information Center * 202-547-5482 (fax)
666 Pennsylvania Ave, SE, Suite 301  * ftp/gopher/wais cpsr.org 
Washington, DC 20003                * HTTP://epic.digicash.com/epic





From root at einstein.ssz.com  Mon Feb 13 13:58:18 1995
From: root at einstein.ssz.com (root)
Date: Mon, 13 Feb 95 13:58:18 PST
Subject: bill alert...
In-Reply-To: <950213.082427.4B5.rusnews.w165w@cybrspc.mn.org>
Message-ID: <199502132155.PAA00114@einstein.ssz.com>


> 
> > Then you would have no users. Users resent being made to do anything they
> > don't want to do. If they decide it is worth it they will do it, otherwise
> > they go elsewhere.
> 
> Some will leave.  Some (one might argue the ones with any basic
> intelligence) will stay.  Sure, many users resent being herded.  But the
> ones that stick around will be of a higher calibre.
> 
> Think of it as evolution in action.
>
I see it as going broke in action...the majority of your users will leave.
Then exactly how do you pay the bills?

This singlemindedness is unworkable in the real world. One of the whole ideas
that I am concerned with regarding crypto is to have people STOP telling me
what to do. Why would I want to become what I hate?

Take care.

 





From anonymous-remailer at xs4all.nl  Mon Feb 13 13:59:27 1995
From: anonymous-remailer at xs4all.nl (Name withheld on request)
Date: Mon, 13 Feb 95 13:59:27 PST
Subject: The NSA (Was Re: Factoring - State of the Art and Predictions )
Message-ID: <199502132058.PAA01939@bb.hks.net>


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

- ----- BEGIN PGP SIGNED MESSAGE HERE ----
An entity purporting to be Mike Duvos writes:

> Such a situation does not apply solely to the NSA.  There are,
> for instance, secret lodges of French mystics who devote
> themselves to higher mathematics, absorb everything the open
> community produces, and rarely publish anything or draw attention
> to themselves.  They solve problems, write secret manuscripts,
> put them on shelves, and have been doing this for centuries.
> Perhaps the ultimate factoring algorithm already exists within
> their walls.  We would never know if it did, unless they chose to
> tell us.

Actually, the French group is a subsidiary of our Bavarian operation.
However, "centuries" is, well, somewhat inaccurate, though the 
mathematician who first mentioned our existence about that time has
since recanted after a visit from the Elders...

				A.W.

- ----- PGP SIGNATURE BLOCK ----
PGP-Version: 23.5
PGP-Signature: T!
- ----- END PGP SIGNED MESSAGE -----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz/HsCoZzwIn1bdtAQEU/wF/Rr/9NvFyxbdxadvn6fql1wjfy19/oXOV
87PHHcmP1OWOxE8HU1oaZ9ZwVcNhD3XX
=dIax
-----END PGP SIGNATURE-----





From cactus at seabsd.hks.net  Mon Feb 13 13:59:42 1995
From: cactus at seabsd.hks.net (A Loose Affiliation of Millionaires and Billionaires and Babies)
Date: Mon, 13 Feb 95 13:59:42 PST
Subject: Archives
Message-ID: <199502132102.QAA02019@bb.hks.net>


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

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

(Add to the list of things to do: make a recurring post describing cpunk
 services available at various places, incl. c2.org, ftp.csua.berkeley.edu,
 hks.net, Tim's Cyphernomicon, etc.

 Anybody else willing to put the whole burrito together, or should I add it
 to my TODO list?)

Somebody asked where the cypherpunks archives are.  Recent traffic is 
available via nntp from news://nntp.hks.net/hks.lists.cypherpunks;  Traffic
older than that, back to June 94 at
news://nntp.hks.net/hks.lists.cypherpunks-archive, and back to the beginning
of the list from

    ftp://ftp.hks.net/cypherpunks/All/cypherpunks.archive.[0-3].gz

The archives are extrememly difficult to navigate through right now, but
the raw material is there and available.  One of these days I will finish
the harvest and/or hypermail installation to facilitate access.
- - --
Todd Masco     | "No matter how peculiar the medium or incongruous the scale,
cactus at hks.net |   the instinct to build persists."   - Joy Of Cooking
     Cactus' Homepage

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLz+PFRNhgovrPB7dAQHc1gP/WSdhsJ7l0LpnEGm8wFBHrBcf4r9ujv7M
OpK6SrfV1/ail5eWZN3waZWgMRzxLxVIkxk7cIILMWo7rZgwM3j50UH6VULWX+8f
o8XBUsKqKxf2UYsm1Ew92HAXdgZgAHj+L2s3L38t2mFxuobK2JhB2+slFC4JEa1P
nBKVgd0O8P0=
=5DSV
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz/IrioZzwIn1bdtAQExxAGAptVJi2VmN3g+5zH21/GkBI4mft0Ww/S0
ufiqJkfGVSB50HPrKcvyCLmVPq+lcc9s
=vg0X
-----END PGP SIGNATURE-----





From wcs at anchor.ho.att.com  Mon Feb 13 13:59:56 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 13:59:56 PST
Subject: bill alert...
Message-ID: <199502132049.PAA01819@bb.hks.net>


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

> > Do you think this will force folks into using encryption?
> > If I was a sysop, I sure would have all my users using
> > encryption... :)
> > -lile
[ obscene government threats CENSORED ]

Well, a good start would be to use an encrypted filesystem for any
server that you're allowing the general public on, and to support
encryption on any remailers you might run...
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLz/FoCoZzwIn1bdtAQEANgGAipZg3vy7lkdA/WC9LnuCQspo2bXOxVOy
ktMyX8kDHpInuZx77TnCq7LwpyC5GkKa
=jQov
-----END PGP SIGNATURE-----





From tcmay at netcom.com  Mon Feb 13 14:22:33 1995
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 13 Feb 95 14:22:33 PST
Subject: Is Cyberspace Rich Enough?
In-Reply-To: <199502132106.AA22391@mail.eskimo.com>
Message-ID: <199502132123.NAA15909@netcom4.netcom.com>


Wei Dai wrote:

> I agree that cyberspace is certainly becoming more complex and
> interconnected.  However, just as a complex ecosystem is not necessarily
> more stable than a simple one, and a complex cipher is not necessarily
> more secure than a simple one, greater complexity in cyberspace does not
> necessarily imply that it is less vulnerable to to centralized control.

No, it doesn't ncecessarily imply less vulnerability, but the two are
empirically correlated. Monocultures are usually easier to control
than in systems where the citizen-units have rich connections and
diverse options.

> But if you wanted to exert greater control over others, you would also
> be pushing for increased dimensionality, because that shrinks the world
> and moves everyone closer to you.  If you look at history, increased

It's always dangerous reasoning from imprecise analogies, and all the
more dangerous reasoning about the mental images others have of such
analogies. Thus, I won't dispute Wei Dai's image of "moving closer" to
the government except to say that as the space shrinks, _many people_
move closer...and this means transactions not visible to the
government _also_ become more common.

In other words, one may be only "2 Internet handshakes from Al Gore,"
but this doesn't give Al Gore control over Joe User's encrypted
transactions with Ivan Hackerovich. 

> connectivity has always been necessary for increased central control.
> What I am saying is that increased connectivity alone does not
> necessarily favor decentralization.  What makes the difference is the
> details -- the nature of the connectivity.

Yes, of course. The nature is critical, and I would not claim
otherwise. (This is another reason long posts are often losers in the
Ratings Game: the longer the post the more nits can be picked. And so
threads often devolve into word games. And if I try to fix things by
writing even _more_, it just gets worse! :-} )

> I'm not quite so optimistic.  One way to control a distributed system
> such as the Internet would be to use a distributed method.  I.e., use
> something like the Internet Worm, but a thousand times subtler and more
> powerful.  There is no need for them to "stop the Net", just to subvert
> a substantial part of it.

In fact, I almost mentioned the Morris Worm, but held back. For one
thing, in a crypto-dominated, reputation-centered era, such rogue
programs are probably less likely. Safe computing, etc.

I'm less fearful that the Net will be attacked in this way than that
liability laws will be used to try to scare people into compliance. 

But these are other topics, which I'll treat separately.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay at netcom.com       | anonymous networks, digital pseudonyms, zero
                       | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo at toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay






From rrothenb at ic.sunysb.edu  Mon Feb 13 14:42:02 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 13 Feb 95 14:42:02 PST
Subject: CNN (fwd) Communications (In)Decency Act?
Message-ID: <199502132241.RAA14045@libws4.ic.sunysb.edu>


Forwarded message:

This was just sent to me.

> Date: Mon, 13 Feb 1995 14:31:08 -0800
> Subject: CNN
> Content-Type: text
> Content-Length: 309
> 
>  CNN's 6:00 p.m. (EST) news broadcast tonight (2/13) will include a
>  live segment on S. 314, "The Communications Decency Act," introduced by
>  Sen. James Exon (D-NE).  Judy Woodruff will moderate a discussion
>  of the bill with Sen. Exon and Marc Rotenberg of the Electronic
>  Privacy Information Center (EPIC).
> 





From perry at imsi.com  Mon Feb 13 14:50:01 1995
From: perry at imsi.com (Perry E. Metzger)
Date: Mon, 13 Feb 95 14:50:01 PST
Subject: perry@imsi.comRe: Does PGP scale well?
In-Reply-To: <9502132105.AA24452@anchor.ho.att.com>
Message-ID: <9502132122.AA01505@snark.imsi.com>



wcs at anchor.ho.att.com says:
> Of course, that's more useful for MIT, which owns Network 18,
> than for the thousands of people on networks 192.xxx.xxx;
> reverse lookups don't seem as reliable for Class C.

I've never had trouble with maintaining xxx.xxx.in-addr.arpa servers;
dunno what causes yours...

.pm





From m5 at vail.tivoli.com  Mon Feb 13 15:00:08 1995
From: m5 at vail.tivoli.com (Mike McNally)
Date: Mon, 13 Feb 95 15:00:08 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <9502132043.AA17858@toad.com>
Message-ID: <9502132259.AA14841@vail.tivoli.com>



gnu at toad.com writes:
 > In their November letter to X9 committee members, the NSA 
 > attempted to undermine the attractiveness of triple-DES by 
 > arguing that it is cryptographically unsound, a potential 
 > threat to national security, and would not be exportable 
 > under US law.

One is forced to wonder at the sort of person that can with a straight
face argue that on the one hand an algorithm is cryptographically
unsound, while at the same time posing a threat to national security.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5 at tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





From unicorn at access.digex.net  Mon Feb 13 15:21:09 1995
From: unicorn at access.digex.net (Black Unicorn)
Date: Mon, 13 Feb 95 15:21:09 PST
Subject: No Subject
Message-ID: <Pine.SUN.3.91.950213181829.14382C-100000@access3.digex.net>




Has anyone checked into the software package "CryptDisk" for the 
Macintosh?  It seems to be the Macintosh compliment to SecureDrive, but 
one must register and drop an extra $20 for the source code.

I don't want to get into the issue of copyright and such, only the 
question of how much public scrutiny the source code for this application 
has seen.

Anyone taken a peek?

-uni- (Dark)


--
073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!






From UseNet at news.bull.com  Mon Feb 13 15:37:56 1995
From: UseNet at news.bull.com ( (Bull Worldwide AutoResponder))
Date: Mon, 13 Feb 95 15:37:56 PST
Subject: lwall
Message-ID: <199502132337.AA59383@cass.ma02.bull.com>


DO NOT PANIC!  REMAIN CALM!  READ *ALL* OF THIS MESSAGE BEFORE GETTING UPSET!

Your Usenet test article was received here at the news gateway machine at
Bull Worldwide Information Systems, in Billerica, MA, USA.

If you want to suppress this message in the future, include the word "ignore" 
in the Subject: header of any subsequent articles posted to *.test.  You could
also post your test articles with a Distribution: header of "local" to prevent
them from leaving your local machine, or you could also ask your local 
newsadmin to create a local *.test group that will not propagate outside of 
your organization.

There are typically 5 possible reasons why you were sent this e-mail message:

1) You intentionally posted a Usenet news article to a *.test newsgroup.  
These newsgroups exist so you can verify that your articles are being 
propagated correctly.  When your article arrives here, we send you this message
as confirmation.  We will only send you ONE e-mail reply for each of your test
articles that we see.

2) You unintentionally posted a Usenet news article to a *.test newsgroup.  
This is a bit of net.childishness caused by a Followup-To: header directing all
replies into a *.test newsgroup.  This is done by somebody upset with the
content of a discussion thread who wants to "punish" anybody who replies to his
message.  Your reply will be sent to *.test instead of the original newsgroup,
and you will start receiving autoresponder messages similar to this one that
you didn't ask for.  To avoid this in the future, look for a Followup-To:
header and make sure it's appropriate before replying to any articles.

3) You were a victim of a Reply-To: header directing your e-mail into a *.test
newsgroup via a mail->news gateway.  Similar to 2) above.

4) Somebody has forged a posting in your name to one of the *.test newsgroups.
To avoid this in the future, use better net.etiquette and you will make fewer
net.enemies.  If you want to try and identify the forger, use the following
procedure.  Make a legitimate posting to the same *.test newsgroup that the
forger used.  We will send you an e-mail reply.  Compare the Path: header from
this legitimate reply with the Path: header from the forgery.  The front
part of the two headers will be the same or topologically similar path to
your site.  Where the forged header becomes substantially different can
provide clues to where the forger lives.  Note that if you receive multiple
newsfeeds you may need to repeat this process several times so you can discover
all legitimate paths between our site and yours.  Once you think you've
identified the forger's site, try sending POLITE e-mail to the newsadmin/
sysadmin/postmaster explaining the situation.

5) You issued a cancel control message to a *.test newsgroup.  Some users
dislike autoresponses for cancel messages, but the newsadmins here think it
can be a valuable diagnostic tool for verifying cancel propagation.  If you
don't like it, use the "delete" key in your mail client!

All headers plus at most 10 lines of user text from your original article are
reproduced below for your perusal:

Path: cass.ma02.bull.com!steamer.clam.com!newsie.dmc.com!grapevine.lcs.mit.edu!uhog.mit.edu!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!agate!overload.lbl.gov!emf.emf.net!hilbert.dnai.com!nbn!miwok!news.zeitgeist.net!ack.berkeley.edu!not-for-mail
Subject: lwall
Message-ID: <PINE4545-dhfsdkjc at ack.berkeley.edu>
NNTP-Posting-Host: ack.berkeley.edu
Organization: cypherpunks
Lines: 2
From: cypherpunks at toad.com
Distribution: world
Newsgroups: alt.test
Date: 6 Feb 1995 19:34:19 GMT

test
test





From SADLER_C at HOSP.STANFORD.EDU  Mon Feb 13 15:39:10 1995
From: SADLER_C at HOSP.STANFORD.EDU (Connie Sadler)
Date: Mon, 13 Feb 95 15:39:10 PST
Subject: EPIC to Debate Exon on CNN
Message-ID: <B128ZVPYMCNQB*SADLER_C@HOSP.STANFORD.EDU>



Subject: EPIC to Debate Exon on CNN
Date: Mon, 13 Feb 1995 15:36:11 PDT
A1-type: DOCUMENT
Importance: normal



>CNN's 6:00 p.m. (EST) news broadcast tonight (2/13) will include a
>segment on S. 314, "The Communications Decency Act," introduced by
>Sen. James Exon (D-NE).  Judy Woodruff will moderate a discussion 
>of the bill with Sen. Exon and Marc Rotenberg of the Electronic
>Privacy Information Center (EPIC).



>_________________________________________________________________________
>Subject: EPIC to Debate Exon on CNN
>_________________________________________________________________________
>David Banisar (Banisar at epic.org)       * 202-544-9240 (tel)
>Electronic Privacy Information Center * 202-547-5482 (fax)
>666 Pennsylvania Ave, SE, Suite 301  * ftp/gopher/wais cpsr.org 
>Washington, DC 20003                * HTTP://epic.digicash.com/epic

For those of us who can't see this, will the text be available
anywhere?

Connie





From mpd at netcom.com  Mon Feb 13 15:55:31 1995
From: mpd at netcom.com (Mike Duvos)
Date: Mon, 13 Feb 95 15:55:31 PST
Subject: Ignore Test
Message-ID: <199502132355.PAA19451@netcom18.netcom.com>


The list seems a tad slow today.  No new messages.

-- 
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd at netcom.com     $    via Finger.                      $





From skaplin at mirage.skypoint.com  Mon Feb 13 15:56:21 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Mon, 13 Feb 95 15:56:21 PST
Subject: EPIC to Debate Exon on CNN
In-Reply-To: <n1419433051.47954@epic.org>
Message-ID: <Pine.SV4.3.91.950213174509.24624A-100000@mirage.skypoint.com>




On 13 Feb 1995, Dave Banisar wrote:

> 
> 
> CNN's 6:00 p.m. (EST) news broadcast tonight (2/13) will include a
> segment on S. 314, "The Communications Decency Act," introduced by
> Sen. James Exon (D-NE).  Judy Woodruff will moderate a discussion 
> of the bill with Sen. Exon and Marc Rotenberg of the Electronic
> Privacy Information Center (EPIC).

Just got done watching it (and I have it on video tape.) In a nutshell, 
Senator Exon was much more convincing than Mr. Rotenberg. :( Why didn't
EPIC field someone with better debating skills? A sellout was offered a 
la EFF and DT. Mr. Rotenberg seemed ill prepared and not really 
interested in the issue. This is not a good omen. The perseption left in 
my non-internet literate wife was that the INTERNET=smut. :(

All in all, not a good showing IMHO,

Sam





From pcassidy at world.std.com  Mon Feb 13 16:12:14 1995
From: pcassidy at world.std.com (Peter F Cassidy)
Date: Mon, 13 Feb 95 16:12:14 PST
Subject: What *is* the power of the FIPS
Message-ID: <Pine.3.89.9502131927.B13826-0100000@world.std.com>



Friends,
-	My editor from the Covert Action Quarterly called with a question 
on a piece I've authored on the NSA's involvement in the development of 
the digital telephony bill. I animated the characters and campaign 
strategies in this narrative common to the clipper and DT initiatives. In 
that, taking about Clipper I mentioned its rise as a FIPS, etc. 
-	QUESTION: Just what is the power of the FIPS outside of the 
interop issues in sending stuff back and forth from federal agencies?






From bwern at jax.jaxnet.com  Mon Feb 13 16:19:24 1995
From: bwern at jax.jaxnet.com (Ben Wern)
Date: Mon, 13 Feb 95 16:19:24 PST
Subject: Excel 5 Encryption
Message-ID: <199502140019.TAA23023@jax.jaxnet.com>


Greetings one and all,

I was wondering if anyone out there has played with or 'broken' Microsloths
encryption, especially in it's Excel from?

The story goes like this: A good friend of mine has an executive who stored
a lot of data in excel, with his own password. He has died, and the
company would very much like to get ahold of that corporate data. Microsoft
has chuckled politely at helping them (they're a rather large company), and
my friend has approached me... I don't have any experience with Microsoft
encryption.. but I know that the likes of WP can be broken, so I was
wondering if something similar to the cracks of that. 

ANY thoughts, comments, annencdotes, etc, etc. would be greatly appriciated.
I'll post a summary to the list, if you send privatly. 

Danke,

Ben Wern
(Hopefully this satisfies enough of the Cypherpunks-related content to avoid
scorch marks... :) )

bwern at jax.jaxnet.com
bwern at pathtech.com 
bwern at unf6.cis.unf.edu

PGP Key Available by Request! 
PGP mail gets preferred treatment!
Ask for it by name!






From jackr at dblues.engr.sgi.com  Mon Feb 13 16:24:50 1995
From: jackr at dblues.engr.sgi.com (Jack Repenning)
Date: Mon, 13 Feb 95 16:24:50 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <9502132043.AA17858@toad.com>
Message-ID: <13876.792721476@dblues.engr.sgi.com>



        In a November letter to committee members, the NSA
        threatened to prevent the export of triple- DES, citing
        existing US law and potential threats to national
        security (see attached NSA letter).

Oh, no, surely not.  There must be some misunderstanding here -
they *promised* they wouldn't block export of non-Clipper
things.  They wouldn't lie!


Jack Repenning                M/S 1-875     jackr at engr.sgi.com
Silicon Graphics, Inc.         x3-3027      Off:(415) 390-3027
Visual Magic Division                       Fax:(415) 390-6056





From rah at shipwright.com  Mon Feb 13 16:31:45 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Mon, 13 Feb 95 16:31:45 PST
Subject: What *is* the power of the FIPS
Message-ID: <v01510101ab6566ac8d4d@[199.0.65.105]>


>-       QUESTION: Just what is the power of the FIPS outside of the
>interop issues in sending stuff back and forth from federal agencies?

Eh? Say again?

Cheers,
Bob Hettinga

-----------------
Robert Hettinga  (rah at shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923







From kinney at bogart.Colorado.EDU  Mon Feb 13 16:40:57 1995
From: kinney at bogart.Colorado.EDU (W. Kinney)
Date: Mon, 13 Feb 95 16:40:57 PST
Subject: your mail
In-Reply-To: <Pine.SUN.3.91.950213181829.14382C-100000@access3.digex.net>
Message-ID: <199502140040.RAA24255@bogart.Colorado.EDU>



Black Unicorn writes:

> Has anyone checked into the software package "CryptDisk" for the 
> Macintosh?  It seems to be the Macintosh compliment to SecureDrive, but 
> one must register and drop an extra $20 for the source code.
> 
> I don't want to get into the issue of copyright and such, only the 
> question of how much public scrutiny the source code for this application 
> has seen.
> 
> Anyone taken a peek?

I have a copy of it. I haven't reviewed it in detail yet, but the general
features look quite solid. I'll post a review of the methods when I've
had a better look, if people are interested.

                                 -- Will





From jim at acm.org  Mon Feb 13 17:11:09 1995
From: jim at acm.org (Jim Gillogly)
Date: Mon, 13 Feb 95 17:11:09 PST
Subject: Excel 5 Encryption
In-Reply-To: <199502140019.TAA23023@jax.jaxnet.com>
Message-ID: <199502140110.RAA17460@mycroft.rand.org>



> bwern at jax.jaxnet.com (Ben Wern) writes:
> I was wondering if anyone out there has played with or 'broken' Microsloths
> encryption, especially in it's Excel from?

Accessdata of Orem Utah (1-800-658-5199) sells cracks for many of them.
So does John Kuslich (602-863-9274); I think his prices are lower.
I don't personally known or endorse either of 'em.

I append a message with some code for doing 4.0 -- I haven't tried it, and
don't know if it works for 5.0.  It's in Basic, but I didn't perpetrate it.

	Jim Gillogly
	Mersday, 24 Solmath S.R. 1995, 01:05
___________________________________________________________________________

Newsgroups: alt.security
Path: rand.org!usc!news.service.uci.edu!ihnp4.ucsd.edu!agate!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!solaris.cc.vt.edu!swiss.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!news
From: agriffiths at vnet.ibm.com (Alan Griffiths)
Subject: Re: Excel pass crack
Sender: news at hawnews.watson.ibm.com (NNTP News Poster)
Message-Id: <CwH0Jo.15sv at hawnews.watson.ibm.com>
Approved: myself
Date: Wed, 21 Sep 1994 08:21:24 GMT
Lines: 103
Reply-To: agriffiths at vnet.ibm.com (Alan Griffiths)
Disclaimer: This posting represents the poster's views, not necessarily those of IBM.
References: <Rw+xX1t.cinepott at delphi.com>
Nntp-Posting-Host: nhbrp75.caanerc.uk.ibm.com
Organization: LORAL CAA NERC Project
X-Newsreader: IBM NewsReader/2 v1.01

In <Rw+xX1t.cinepott at delphi.com>, Bob <cinepott at delphi.com> writes:
>Someone was looking for a crack to excel's passwords, apparently they
>forgot their password ? Well I found these helpful tidbits posted
>previously.
> 
>|>Encryption of Ms Excel files
>|>    From: Fabio Ottolina <fabio at tdc.dircon.co.uk>
>|>   Date: 29 Jan 1994 12:51:18 GMT    (1 screen)
>|>
>|>    I have saved an Excel 4.0 for Windows file with password-protection, and
>|>I can't remember the password (how remarkably stupid! :-)).
>|>Is there any way to crack the password-protection of Excel files?

You may find the following program of help. I am sorry it's in QBasic but that's the
only free language I have at present. The program removes document protection from
Excel worksheets. I haven't tested it extensively so there are no guarantees or warranties.
Always keep a backup copy of your files etc...

The protection scheme does two things:

 1. When you protect your document, Excel hashes your password to a 16 bit value, stores
    it somewhere and sets a few flags to say that the document is protected.

 2. When Excel saves a protected document it encrypts the content of each block using 16
    different alphabetic substitutions. This allows Excel to read and display protected
    documents before knowing their password. The program below unscrambles a protected
    document, removes an extra 8 byte block at the beginning, and resets the flags and
    passwords to zero.

I don't know if it can cope with all combinations of protection available in Excel. It
works fine on the simple protect document option. Similarly, charts etc. will probably
get munged since I don't think the titles etc get scrambled.

Hope this stuff is of use to someone.       Alan.

PS. Ironically enough, I found Excel of great value in recovering the set of magic numbers
used in the program. It allowed me to very quickly generate and evaluate possible decryption
formulae!

-------------------cut here------------------------------
DECLARE FUNCTION decrypt$ (c$, adr&, blen%)
DEFINT A-Z
DIM SHARED magic(15)
FOR i = 0 TO 15
  READ magic(i)
NEXT
DATA 196, 115, 164, 32, 60, 91, 212, 23, 240, 31, 40, 19, 240, 75, 180, 3

COLOR 14, 1
CLS
INPUT "Enter input Cyphertext filename: ", cf$
INPUT "Enter output Plaintext filename: ", pf$
OPEN pf$ FOR BINARY ACCESS WRITE AS #1
OPEN cf$ FOR BINARY ACCESS READ AS #2

chdr$ = INPUT$(18, #2)
phdr$ = LEFT$(chdr$, 10)
PUT #1, , phdr$
fp& = 10
cbh$ = INPUT$(4, #2)
WHILE NOT EOF(2)
  PUT #1, , cbh$
  blen = ASC(MID$(cbh$, 3, 1)) + 256 * ASC(MID$(cbh$, 4, 1))
  btyp = ASC(MID$(cbh$, 1, 1)) + 256 * ASC(MID$(cbh$, 2, 1))
  fp& = fp& + 4
  IF blen > 0 THEN
    cblk$ = INPUT$(blen, #2)
    x$ = decrypt$(cblk$, fp& - 4, blen)
    IF blen = 2 THEN
      SELECT CASE btyp
        CASE 18, 19, 99
          x$ = STRING$(2, 0)
      END SELECT
    END IF
    PUT #1, , x$
  END IF
  fp& = fp& + blen
  cbh$ = INPUT$(4, #2)
WEND
CLOSE #1
CLOSE #2
END

FUNCTION decrypt$ (c$, adr&, blen)
  offset = (adr& + blen) AND 15
  d$ = STRING$(blen, 0)
  FOR i = 1 TO blen
    c = ASC(MID$(c$, i, 1))
    crot = ((c * 8) MOD 256) OR (c \ 32)
    ctst = magic(offset)
    clss = (2 * (crot AND ctst)) AND 255
    d = (256 + crot + ctst - clss) AND 255
    MID$(d$, i, 1) = CHR$(d)
    offset = (offset + 1) AND 15
  NEXT
  decrypt$ = d$
END FUNCTION
-------------------cut here------------------------------

Alan Griffiths        CAA NERC Project    agriffiths at vnet.ibm.com
Tel: +44-705-561325                       Fax: +44-705-214094

All opinions expressed are my own and do not represent IBM in any way
___________________________________________________________________________






From lmccarth at ducie.cs.umass.edu  Mon Feb 13 17:12:35 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Mon, 13 Feb 95 17:12:35 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <9502132043.AA17858@toad.com>
Message-ID: <199502140114.UAA17825@ducie.cs.umass.edu>


CDT writes:
> The NSA's efforts to push the adoption the Clipper/Skipjack 
> government-escrowed encryption scheme encountered a major 
> setback earlier this month with the decision by the 
> Accredited Standards Committee X9 to proceed with the 
> development of a data security standard based on triple-DES.    
> 
> The ASC X9 committee is responsible for setting data security 
> standards for the US banking and financial services 
> industries.

Are the minutes of the deliberations of X9, in complete or digest form,
available to the public anywhere ? It would be useful to get a sense of how
close the vote was, whose representatives voted which way, and the arguments
the members found most compelling in reaching their decision. We need to
gather as much feedback as possible, in order to determine which strategies
are liable to be effective in the future. The answers may not come as a
surprise, but confirmation of our suspicions would be nice.

-L. Futplex McCarthy




From jim at acm.org  Mon Feb 13 17:18:00 1995
From: jim at acm.org (Jim Gillogly)
Date: Mon, 13 Feb 95 17:18:00 PST
Subject: What *is* the power of the FIPS
In-Reply-To: <Pine.3.89.9502131927.B13826-0100000@world.std.com>
Message-ID: <199502140117.RAA17498@mycroft.rand.org>



> Peter F Cassidy <pcassidy at world.std.com> writes:
>...                          I animated the characters and campaign
> strategies in this narrative common to the clipper and DT initiatives. In 
> that, taking about Clipper I mentioned its rise as a FIPS, etc. 
> -        QUESTION: Just what is the power of the FIPS outside of the 
> interop issues in sending stuff back and forth from federal agencies?

Seems to me a FIPS is an important standard to the extent that it contains
important and useful information.  The DES FIPS 46-2 and 81 do, and
they've been widely influential.  The EES (Clipper) FIPS 185 doesn't --
it's mostly terminology to support GACK (Government Access to Crypto Keys)
-- and has been largely ignored outside of said federal agencies, so far
as I know.

	Jim Gillogly
	Mersday, 24 Solmath S.R. 1995, 01:16





From jim at rand.org  Mon Feb 13 17:31:07 1995
From: jim at rand.org (Jim Gillogly)
Date: Mon, 13 Feb 95 17:31:07 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <199502140114.UAA17825@ducie.cs.umass.edu>
Message-ID: <199502140131.RAA17561@mycroft.rand.org>



> "L. McCarthy" <lmccarth at ducie.cs.umass.edu> writes:
> Are the minutes of the deliberations of X9, in complete or digest form,
> available to the public anywhere ? It would be useful to get a sense of how
> close the vote was, whose representatives voted which way, and the arguments

I haven't seen that kind of detail, but here's a piece with some of the
players posted by one member in December.  I don't have the message from
voorhees that he responded to.

	Jim Gillogly
	Mersday, 24 Solmath S.R. 1995, 01:27
_________________________________________________________________

From: x9a3 at aol.com (X9a3)
Newsgroups: talk.politics.crypto
Subject: Re: Triple-DES
Date: 12 Dec 1994 20:50:26 -0500
Organization: America Online, Inc. (1-800-827-6364)
Lines: 29
Sender: news at newsbf01.news.aol.com
Message-ID: <3ciul2$hc8 at newsbf01.news.aol.com>
References: <3cg57o$hvq at interport.net>
NNTP-Posting-Host: newsbf01.news.aol.com

In article <3cg57o$hvq at interport.net>, voorhees at interport.net writes:

Rich has the 3DES ballot results correct. It is currently our for
reconsideration which happens when there are 'no' votes.  It is expected
to pass.  Marty Ferris (Treasury and chair of X9F) chaired the X9F meeting
in Austin - which I attended as well as the earlier meeting of X9F4 on
Home Banking - and reported that the 3DES WI would probably go to Blake
and X9F1.  There will probably be a subworking group chaired by Glenda
Barnes of Cylink to shepard the 3DES along. Several of us will be
participating in the action.  We don't intend to let Blake sit on it or
kill it.  His rantings over some of the DES stuff is based on pure
conjecture and perhaps visions delivered in the night by NSA.  There are
no short cuts to a properly implemented DES system - only exhaustion. Ask
Bihnam and Shamir. The majority of folks (read banks) interested in 3DES
wan to see a two key system and not the 3 key proposed by Cylink for a
variety of reasons.  2key EDE DES produces key strength of 112 and not
somewhere between 70 and 80 as claimed by Father Blake.  The 70-80 is
probably more disinformation from the NSA to make SKIPJACK appear more
acceptable.  Many of us are convinced that Blake is paid by the spooks but
he will not publicly admit that he is.     The 3DES WI originated in X9F3
chaired by Gary Chauklin of the FRB and the 3DES WI was moved from X9F3 to
X9F1 over the objections of the X9F3 members and Gary.  When Marty was
questioned how that decision was made it became clear it was arbitrary and
Marty probably made it himself.  The meeting will be in Feb in Balitmore -
should be interesting.....         watch this space!!!                    
          ... peace ... abe

Abraham & Associates, Inc.; Applications in Cryptography;  Concord, NC
_________________________________________________________________





From mpd at netcom.com  Mon Feb 13 17:36:40 1995
From: mpd at netcom.com (Mike Duvos)
Date: Mon, 13 Feb 95 17:36:40 PST
Subject: French Mystics, Martin Gardner, and Transcendentality
Message-ID: <199502140136.RAA11222@netcom13.netcom.com>


An anonymous traveler on the Path writes:

 > Actually, the French group is a subsidiary of our Bavarian
 > operation. However, "centuries" is, well, somewhat
 > inaccurate, though the mathematician who first mentioned our
 > existence about that time has since recanted after a visit
 > from the Elders...

"Centuries" was perhaps an exaggeration.  I first became aware of
the existance of the French group when Martin Gardner published
an extremely interesting April Fool's edition of "Mathematical
Games" in Scientific American a number of years back.

The thesis of his piece was that some very simple expressions
involving transcendental numbers such as Pi and E had been proven
to be integers. When you checked them on a calculator, they did
indeed appear to be exact integers, in spite of a well-known
theorem which claimed otherwise.

The clever trick was that they were of course transcendental, but
differed from integers by a small epsilon far beyond the 15 digit
range of most ordinary calculators.

A number of us were trying to figure out how Martin Gardner had
constructed the expressions he had published, and quickly found
that doing so was a non-trivial mathematical problem.  We were
about to give up when a young associate professor walked in,
picked up a piece of chalk, and demonstrated a really clever
trick involving rings which permitted one to crank out such
expressions with the greatest of ease.

When we inquired as to the origin of the work he was citing, we
were told that this really clever mystical order in France had
recently decided to release this particular discovery into the
public domain, where it had served as the source for Martin
Gardner's baffling column.

Perhaps they will give us a factoring algorithm if we ask them
nicely. :)

-- 
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd at netcom.com     $    via Finger.                      $





From jim at rand.org  Mon Feb 13 17:48:00 1995
From: jim at rand.org (Jim Gillogly)
Date: Mon, 13 Feb 95 17:48:00 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <199502140131.RAA17561@mycroft.rand.org>
Message-ID: <199502140147.RAA17640@mycroft.rand.org>



> Jim Gillogly <jim at rand.org> writes:
>...I don't have the message from voorhees that he responded to.

Woops, just found it.  This is the predecessor to my previous forward
from x9a3, relating to Triple DES (3DES), complete with votes.

	Jim Gillogly
	Mersday, 24 Solmath S.R. 1995, 01:46

_________________________________________________________________

From: voorhees at interport.net
Newsgroups: talk.politics.crypto
Subject: Triple-DES
Date: 12 Dec 1994 00:24:24 GMT
Organization: Interport Communications
Lines: 87
Message-ID: <3cg57o$hvq at interport.net>
Reply-To: voorhees at interport.net
NNTP-Posting-Host: voorhees.port.net
X-Newsreader: IBM NewsReader/2 v1.03

The following post is from Rich Ankeny, a member of
X9F1 and possibly F3, too.

He does not have easy access to newsgroups, so I am
posting it on his behalf.

--Mark



I have a few comments on triple DES:

1.  X9F1 to Develop the Standard?

I read with interest your recent Usenet post about triple DES. I was not
aware that Marty Ferris (X9F chair) had already (offically) decided to
give the work to Blake. We (various X9F1/3 members) had figured the way
to delay it the longest is to form a new working group (X9F5:-).

2.  Blake's Opinions

Blake's claim is that triple DES (with two keys) is not 112 bits strong;
in fact it is somewhere between 70 and 80 bits strong. He gives no
details to back this up, though.  His other objection is that, since there
are only 32 bits input to the DES S-boxes in each round, at some point in
the future (say 10 years or so) this can be "cryptanalyzed" using table
lookups rather than test encryptions or other means, even on a desktop
sized machine (with lots of memory).  This is actually a reasonable
prediction, but it applies to single DES.  As to two-key triple DES, the
only published attack I'm aware of is a paper by Paul van Oorschot and
Michael Wiener of BNR (cited in Applied Cryptography, among other places);
their attack uses *lots* of memory and running time of less than 2^100
steps. I guess it all depends on who you think is the better
cryptanalyst:-)  Anyway, the X9 proposal was to use three-key triple DES;
one would hope that's at least 112 bits strong.

3.  The X9 Vote

I got the voting record from X9 on the triple DES NWI:

YES:  Applied Communications, AT&T, Bank of America, Bank of Boston,
Chemical Bank, Deluxe Check Printers(!), Federal Reserve, Fidelity
Investments, Mastercard, Mellon Bank, VISA, Wells Fargo.

NO:  NSA, NationsBank (their rep is X9 chair).

ABSTAIN:  ABA, American Express, Canadian Bankers Assoc., Moore Business
Forms, NIST, Unisys, Xerox.

10 members didn't return their ballots, including Citibank, Chase
Manhattan, and IBM.  This is not unusual for larger organizations
where the ballots sit on someone's desk for three or four months.  I
imagine many will be voting on the reconsideration ballot.

NO votes must have reasons, and abstentions typically do as well:

NSA:  We've seen their reasons already in earlier postings.
NationsBank:  Too much controversy and too many open issues (based, I
   would think, on the NSA comments)
ABA:  Concerned about the NSA comments (esp. exportability) and that
   adopting triple DES now would affect the number of options available
   in the long term.  ABA is opposed to Clipper/Capstone as currently
   proposed.  In particular:  (a) it must have congressional support,
   (b) at least one escrow agent must be a private sector entity, (c) it
   must be exportable, (d) there must be a *demonstrable* mechanism
   whereby escrow keys used in wiretap equipment cannot be compromised
   and are destroyed at the end of the wiretap period, (e) the
   algorithm must be unclassified or made available for an acceptable
   evaluation procedure by the banking industry, and (f) analysis of other
   issues is needed, including possiblity of software implementation, and
   compatibility with installed DES infrastructure.
Federal Reserve:  Supports triple DES, as an immediate alternative to DES.
   Also offers some much less negative wording for the reconsideration
   ballot.  (The original ballot did everything but recommend a NO vote.)



I don't have Usenet access (without "borrowing" a friend's account), so
please feel free to repost any of this you feel might interest the
EFF and other newsgroups.



Regards,
Rich Ankney
(Fischer Int'l)
_________________________________________________________________





From jamesd at netcom.com  Mon Feb 13 17:53:17 1995
From: jamesd at netcom.com (James A. Donald)
Date: Mon, 13 Feb 95 17:53:17 PST
Subject: EPIC to Debate Exon on CNN
In-Reply-To: <Pine.SV4.3.91.950213174509.24624A-100000@mirage.skypoint.com>
Message-ID: <Pine.3.89.9502131742.A19443-0100000@netcom10>


On Mon, 13 Feb 1995, Samuel Kaplin wrote:
>  A sellout was offered a 
> la EFF and DT. Mr. Rotenberg seemed ill prepared and not really 
> interested in the issue.

You expected something different from "EPIC"?

Cypherpunks are supposed to be paranoid.  You are
not paranoid enough.

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd at netcom.com






From mac5tgm at hibbs.vcu.edu  Mon Feb 13 18:07:49 1995
From: mac5tgm at hibbs.vcu.edu (Greg Morgan)
Date: Mon, 13 Feb 95 18:07:49 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
In-Reply-To: <9502132259.AA14841@vail.tivoli.com>
Message-ID: <9502140207.AA22303@hibbs.vcu.edu>


Mike McNally originally said the following...
> 
> 
> gnu at toad.com writes:
>  > In their November letter to X9 committee members, the NSA 
>  > attempted to undermine the attractiveness of triple-DES by 
>  > arguing that it is cryptographically unsound, a potential 
>  > threat to national security, and would not be exportable 
>  > under US law.
> 
> One is forced to wonder at the sort of person that can with a straight
> face argue that on the one hand an algorithm is cryptographically
> unsound, while at the same time posing a threat to national security.
Just playing Devil's Advocate, but maybe he's saying that it's
so faulty that trusting banking communications to it would be a
threat to national security...  You know, it's so faulty it's
dangerous.. Kinda like Dan Qyale for president. *8)

-----------------------------------------------------------------------------
Greg Morgan <mac5tgm at hibbs.vcu.edu>    | "I dunno Brain, me and Pipi
Mail me for PGP Key: 0xE0D222A9        |  Longstocking?  I mean what would
Key Fingerprint : 2430 BAA4 1EE4 AA2F  |  the children look like?" - Pinki
                  3B76 3516 3DEF 5529  |
-----------------------------------------------------------------------------





From rrothenb at ic.sunysb.edu  Mon Feb 13 18:18:30 1995
From: rrothenb at ic.sunysb.edu (Robert Rothenburg Walking-Owl)
Date: Mon, 13 Feb 95 18:18:30 PST
Subject: EPIC to Debate Exon on CNN
In-Reply-To: <Pine.SV4.3.91.950213174509.24624A-100000@mirage.skypoint.com>
Message-ID: <199502140218.VAA03104@libws4.ic.sunysb.edu>


Are they (CNN) going to re-air the discussion? I wasn't able to see it.





From rfb at lehman.com  Mon Feb 13 18:28:51 1995
From: rfb at lehman.com (Rick Busdiecker)
Date: Mon, 13 Feb 95 18:28:51 PST
Subject: MIME based remailing commands
In-Reply-To: <ojDo69v0Eyt50xSXkP@nsb.fv.com>
Message-ID: <9502140226.AA11393@cfdevx1.lehman.com>


    Date: Mon, 13 Feb 1995 06:24:57 -0500 (EST)
    From: Nathaniel Borenstein <nsb at nsb.fv.com>
    
    Excerpts from mail: 12-Feb-95 Re: MIME based remailing co.. Rick
    Busdiecker at lehman.c (1544)
    
    >     Well, I have no idea why you think that MIME is an "atrocity" or
    >     "slime", but it is perfectly clear that you have no idea what it
    >     actually *is*, since "X-" headers have nothing whatsoever to do with
    >     MIME.  The "X-" headers are defined by RFC 822, which has been the
    >     standard for Internet mail formats since 1982.
    
    > You base a large conclusion on a small piece of data in combination
    > with some poor duduction.  Unless you are claiming that MIME violates
    > RFC 822 with respect to the handling of X- headers you have made a
    > number of false claims in the paragraph above.
    
    A very interesting claim.  Care to tell me what my "false claims" are,
    or is it a secret?

One is your claim that ``"X-" headers have nothing whatsoever to do
with MIME.''  This was in response to my suggestion that such headers
were MIME-compliant.  As I said previously, unless you are claiming
that MIME violates the RFC which you referenced, then these headers
are MIME compliant, as I suggested, rather than completely seperated
from MIME as you have suggested.

The other is that I ``have no idea what [MIME] is''.  I may not know
as much as I should, by your judgement, however your claim is still
incorrect -- presumably you were more interested in being
inflammatory than accurate.  Not completely out of place here . . . .

Really, there was nothing very secretive about my previous or current
presentation of the problems with your claims.  For example, you might
note that the first one that I list is simply a rewording of the
message to which you most recently replied.  What was it that was
unclear the first time?  Or *are* you suggesting the MIME violates RFC
822?  Or perhaps I'm just missing something subtle in your reasoning.
If so, could you elaborate?

			Rick





From wcs at anchor.ho.att.com  Mon Feb 13 18:53:11 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 18:53:11 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
Message-ID: <9502140251.AA28439@anchor.ho.att.com>


Yahoo!

> From: Jack Repenning <jackr at dblues.engr.sgi.com>
>         In a November letter to committee members, the NSA
>         threatened to prevent the export of triple- DES, citing
>         existing US law and potential threats to national
>         security (see attached NSA letter).
> Oh, no, surely not.  There must be some misunderstanding here -
> they *promised* they wouldn't block export of non-Clipper
> things.  They wouldn't lie!

There's already some extra slack in the law and the official policy
for exporting encryption for use in banking; the NSA could get around it
by asking the banking regulators to impose some sort of Key Forfeiture nonsense,
which wouldn't lose much privacy since most banks are already
pretty cooperative about such things.

On the other hand, banks are rich enough to hire some off-shore programmer 
to write triple-DES implementations, given the current protocols,
as well as to lobby CONgress or the administration to keep the NSA in line.





From frissell at panix.com  Mon Feb 13 18:57:54 1995
From: frissell at panix.com (Duncan Frissell)
Date: Mon, 13 Feb 95 18:57:54 PST
Subject: EPIC to Debate Exon on CNN
In-Reply-To: <Pine.SV4.3.91.950213174509.24624A-100000@mirage.skypoint.com>
Message-ID: <Pine.SUN.3.91.950213215125.2820B-100000@panix.com>




On Mon, 13 Feb 1995, Samuel Kaplin wrote:

> Senator Exon was much more convincing than Mr. Rotenberg. :( Why didn't
> EPIC field someone with better debating skills? A sellout was offered a 
> la EFF and DT. Mr. Rotenberg seemed ill prepared and not really 
> interested in the issue. This is not a good omen. The perseption left in 
> my non-internet literate wife was that the INTERNET=smut. :(
> 

I assume that Rotenberg was trying to do one thing only which was to try 
and get Exon to state that his bill did not cover ISPs.  He succeeded.  
He was not trying in 5 minutes to score debating points along the lines 
of "pornography, smut, indecency, sex, violence, rapine, and slaughter 
are perfectly legal so long as they do not rise to the level of legal 
obscenity."  That's just the sort of argument that gets the audience to 
think you're nuts and ignore you.  

If the bill doesn't cover ISPs, it is meaningless.  He never actually 
*said* he'd work with Exon.  You have to be very careful on these shows.  
He could, perhaps, have done a little better, but I detected no sellout.

DCF





From wcs at anchor.ho.att.com  Mon Feb 13 19:09:06 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 19:09:06 PST
Subject: What *is* the power of the FIPS
Message-ID: <9502140305.AA28564@anchor.ho.att.com>


> -	QUESTION: Just what is the power of the FIPS outside of the 
> interop issues in sending stuff back and forth from federal agencies?

The basic purpose of a FIPS is to instruct governemnt agencies
on what kinds of equipment/software they should buy.
Some FIPSs are mandatory, but most are pretty optional.
However, in this case, the purpose is basically propaganda -
the NIST can set standards, and can announce "Hey, this is standard",
and even try to get other government agencies to buy lots and
lots of Clipperphones.

The so-called FIPS for Clipper was a horrendous abuse of the FIPS process;
I took advantage of my 10 years as a defense contractor to flame out the
proposed spec in great detail.  I don't think I've still got my critique,
but essentially I contended than the proposed "Escrowed Encryption Standard"
didn't describe escrow, didn't specify encryption, and wasn't a standard....
It was fun, if you can do that sort of thing and not inhale :-)

It wasn't escrow, because the functions it describes aren't escrow,
and it doesn't mandate that they be used in a way that performs
escrow functions using the functions it does perform.
It didn't specify an encryption algorithm.
It wasn't an implementable standard, since it didn't contain enough
information for a user agency to specify an equipment design ("ask the NSA" 
just _doesn't_ rate), or for a vendor to validate whether an equipment design
is compliant, or for a user to tell if it's working properly.
>From the commentary around the final FIPS, which differed in some detail
from the draft FIPS, it looks like most of the public comments were about
the political issues, but a couple of changes appeared to be responses to
technical details from the public, including things I'd flamed them about.
I don't know how positive I feel about that .....

		Bill





From pierre at shell.portal.com  Mon Feb 13 19:11:24 1995
From: pierre at shell.portal.com (Pierre Uszynski)
Date: Mon, 13 Feb 95 19:11:24 PST
Subject: ref on crypto formalism
Message-ID: <199502140310.TAA23087@jobe.shell.portal.com>



Eric,

I dug out one of the references I was thinking of when you were
talking last saturday. A summary of the introduction would go:

"We describe a theory of authentication and a system that implements
it. Our theory is based on the notion of principal and a "speaks for"
relation between principals. A simple principal either has a name or is a
communication channel; a compound principal can express an adopted role
or delegation of authority. [...] We use the theory to explain
many existing and proposed mechanisms for security [...]"

So anyway, although I haven't read the whole thing in depth, it seems
to me a reasonnable way to reason about complex security setups
to make decisions about them (including automatically).

%A Butler Lampson
%A Martin Abadi
%A Michael Burrows
%A Edward Wobber
%T authentication in distributed systems: theory and practice
%J Operating Systems Review (ACM SIGOPS Review)
%J Proceedings of the 13th ACM symposium on operating systems principles
%C Pacific Grove, CA
%D Oct. 13-16 1991
%V 25
%N 5
%P 165-182
%K transitive authentication, operating systems, DES, RSA, security,
channel, RPC, remote procedure calls, public key encryption, name
lookup, groups, access control, delegation, revocation, principals

I'm pretty sure I saw somewhere a companion paper titled something
like "An algebra of authentication"... hmmm  maybe even in CACM...
[...15 minutes later...] Unfortunately some of my CACMs are in hiding
and not properly indexed... It was work done at DEC SRC in Palo Alto,
there must be some research reports too.

If somebody has refs for any of these, it would be great if you'd
post them.

Pierre.
pierre at shell.portal.com





From msattler at jungle.com  Mon Feb 13 19:11:53 1995
From: msattler at jungle.com (Michael Sattler)
Date: Mon, 13 Feb 95 19:11:53 PST
Subject: Zimmerphone, IPhone, NetPhone, Maven...
Message-ID: <v03001403ab65cd6a5876@[140.174.229.219]>


At 11:46 2/13/95, usviszpz at ibmmail.com wrote:

>For those for whom this is already old news, I would like to ask: any idea if
>this technology is related in any way to VoicePGP? If not, any thoughts on the
>development ramifications of this for VoicePGP?

This is not related in any way to VoicePGP (which PRZ calls PGPFone and I
call the Zimmerphone).  On the CU-SeeMe discussion mailing list we've been
hashing out the performance of the costware IPhone (Windoze) and NetPhone
(Mac), and the freeware Maven (Mac).  They all suck less over 14.4.

-----------------------------------------------------------------------+
Michael Sattler <msattler at jungle.com>       San Francisco, California  |
Digital Jungle Consulting Services     http://www.jungle.com/msattler/ |
                                                                       |
      You couldn't get a clue during the clue mating season in         |
 a field full of horny clues if you smeared your body with clue musk   |
           and did the clue mating dance. - Edward Flaherty            |







From rfdutcher at igc.apc.org  Mon Feb 13 19:21:29 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Mon, 13 Feb 95 19:21:29 PST
Subject: (Fwd) Returned mail
Message-ID: <199502140322.TAA14989@igc3.igc.apc.org>



> Date:          Sat, 11 Feb 1995 01:41:09 -0600
> To:            cypherpunks at toad.com
> From:          dls at mcs.com (David Sallach)
> >
> >"Free" speech has always been a balancing act.  The founders
> >certainly didn't intend to provide "free" speech for blacks and
> >women.  
> 
>  The Founders created a larger space for free speech than had ever
> existed.  Slaves were deprived of many freedoms including speech, of course,
> but women and free blacks were included in the Bill of Rights and exercised
> free speech, frequently compellingly.  
> 
And were frequently thrown in jail for their pains - note especially 
the experiences of the early feminists [anachronistic label alert].  
And let us not forget what happened to the Mormons ...

> Check out Frederick Douglass' practicing oration while still a
> slave, and then winning his freedom to become one of the greatest
> abolitionist orators.  Consider the appreciation of diversity of thought and
> speech manifested by Jefferson, Lincoln and many other American political
> leaders.
> >

And Douglass spent a good portion of his life as a refugee in a 
protected enclave [Boston] where he had powerful friends to keep him 
from being arrested.

I'm not dissing the Founders, or the Bill of Rights -- just the 
simplified pap their invocation in most discourse has become.  I was 
trained in high school as a scientist, and in college as an 
historian, and in both instances to value the messy contingent 
realities over the tempting simplicities of ideology and theory.

And there are few contingent realities messier than the law ...

> > . . . "They" have never liked "free" speech ... :-(
> 
> Invoking poitically 'correct' stereotypes does not strengthen your
> argument.
> 
> David Sallach

Irony-impaired, are we?

There's a Polish word, used by most of the populace after the 1979
coup to refer to the army and apparat, that is usually translated as
"them."  I [probably incorrectly] recall it as "Oni" -- would you
prefer it?

My own first encounter with the term "politically [in]correct" was
among 70's feminists, who used it ironically, to tell people they
needed a vacation/to get laid/to get a grip.  Would that Newt used it 
that way ...


===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================






From slowdog at wookie.net  Mon Feb 13 19:32:40 1995
From: slowdog at wookie.net (slowdog)
Date: Mon, 13 Feb 95 19:32:40 PST
Subject: EPIC to Debate Exon on CNN
In-Reply-To: <Pine.SUN.3.91.950213215125.2820B-100000@panix.com>
Message-ID: <Pine.LNX.3.91.950213223336.16909A-100000@chewy.wookie.net>


On Mon, 13 Feb 1995, Duncan Frissell wrote:

> If the bill doesn't cover ISPs, it is meaningless.  He never actually 
> *said* he'd work with Exon.  You have to be very careful on these shows.  
> He could, perhaps, have done a little better, but I detected no sellout.

Exon can say whatever he wants. Read the bill. There's no "except for 
ISPs" in there anywhere you know.


- dog







From werewolf at io.org  Mon Feb 13 19:35:13 1995
From: werewolf at io.org (Mark Terka)
Date: Mon, 13 Feb 95 19:35:13 PST
Subject: The NSA
In-Reply-To: <199502132058.PAA01939@bb.hks.net>
Message-ID: <qV1GlOwscsyI077yn@io.org>


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

In article <199502132058.PAA01939 at bb.hks.net>,
anonymous-remailer at xs4all.nl (Name withheld on request) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>- ----- BEGIN PGP SIGNED MESSAGE HERE ----
>An entity purporting to be Mike Duvos writes:
>
>> Such a situation does not apply solely to the NSA.  There are,
>> for instance, secret lodges of French mystics who devote
>> themselves to higher mathematics, absorb everything the open
>> community produces, and rarely publish anything or draw attention
>> to themselves.  They solve problems, write secret manuscripts,
>
>Actually, the French group is a subsidiary of our Bavarian operation.
>However, "centuries" is, well, somewhat inaccurate, though the 
>mathematician who first mentioned our existence about that time has
>since recanted after a visit from the Elders...
>
>				A.W.

Is that sort of thing like being paid a visit by "The Enforcers" of "Forever
Knight" fame? :>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBL0AYh3BFBj7pSNyhAQH0MAf/URevPL9zB8d40zwAozvOhsgwG5pU0eVv
QOizn1SXgc75MdiWCiyUk7SpDG+vCpDSsmuIi/zUFiyxAxEmNSatGjtDQ3oEHom3
i2D3cor1AlNw6vSEVk+l6u9JVIch1BLEU8aEjFKqmfcA1zHFGN8Tm3+fCqkCKE13
0fdjwNMtJMcAMRAzefeFNM1oWvcmW8f17YFPMaGmKdfUvFEOuX5t8OBsAaRl3jWe
cop+Tobh0IVsYYzyKJRecNKnVqx8Jtc0FpdrFAsvV59ad2mx9ltt9S5uT2r2Pivk
kTbhR0TQN3Tt5G7WQth0wXbEpfIx1TbRu/rj6ezNvG9pzh8pfufQSQ==
=ygze
-----END PGP SIGNATURE-----





From wcs at anchor.ho.att.com  Mon Feb 13 19:42:42 1995
From: wcs at anchor.ho.att.com (wcs at anchor.ho.att.com)
Date: Mon, 13 Feb 95 19:42:42 PST
Subject: Distributed Key Service for PGP (was: why pgp sucks)
Message-ID: <9502140340.AA28899@anchor.ho.att.com>


Matt Blaze writes:
> >Doesn't having some kind of central record of keys go against
> >the principle of PGP?  
> 
> The only "principle" of which I'm aware (and particularly interested
> in supporting) is that of having widely fielded, useful and strong
> privacy and authentication tools that work properly and transparently.
> That means, among a great many other things, flexible protocols
> and tools that support remote key distribution services.

Another main principle of PGP is that it _has_ to be able to work
in a decentralized fashion, so it's usable by
> the civilizing forces of Anarchy (PGP?)
even if the most common uses are in the centralized wired real-world.

Perry and other write:
[ lots of things about the need for distributed scalable key servers ]
[ particularly the numeric-only IDs. ]
There are two main times you need to get PGP keys -
encrypting a message to someone, and validating a signature from someone.

The former can be distributed easily enough - use something DNS-like
to serve keys for joe_user at foo.bar.com, and add them to your local
keyring if they're not there (possibly with temporary keyrings,
if that's easy enough on PGP version N.) 
Fetching keys needs to be a separate tool from PGP anyway,
since PGP should be general enough to work on wired and unwired systems,
with different protocols and APIs for using the available networks.
(And of course, the fetched keys need to be validated using web_of_trust
or whatever, adding yet another step.)  Sounds like a job for a shell...

The latter problem is more difficult - partly PGP's fault, but partly 
because the underlying problem is harder.  Signed documents _may_
arrive from keyids not on the keyservers, whether they're from
non-wired users, users who wish to remain pseudonymous,
one-or-two-use keys, etc....  What PGP can be blamed for, which will
hopefully be addressed in version 3.x, is that it's possible to have
collisions in the abbreviated key_ids, especially for the optional
short key_ids that have been requested as an added feature for people
who _very strongly_ want to remain anonymous.
(There have already been collisions in the 24-bit key_ids,
and it's been shown that it's possible to generate arbitrary key_ids
if you _want_ to cause a collision, as well as birthday-problem 
probabilities of random collisions.)

One way to address it is to make it easy to loop through a bunch
of keys with the same key_id, which is a bit tough given PGP's current
MS-DOS-like interface.  Another way is out-of-band attachment of the
user_id with the message, followed by DNS-like lookup, or attachment of
the signature key with the message, accompanied by a lookup to validate it.

As Matt said, there's a lot of policy-vs-mechanism issues here;
PGP version 3.0 will have some library support that makes it
easier to build some of these things.

		Bill





From david.lloyd-jones at canrem.com  Mon Feb 13 20:04:16 1995
From: david.lloyd-jones at canrem.com (David Lloyd-Jones)
Date: Mon, 13 Feb 95 20:04:16 PST
Subject: The NSA (Was Re: Factorin
In-Reply-To: <9502130231.AA19651@snark.imsi.com>
Message-ID: <60.20378.6525.0C1CFB64@canrem.com>


 "Perry E. Metzger" <perry at imsi.com> writes:
 
PM+The black community also has lots of day-to-day experience that we
  +don't have, and they understand both the threat model and the
  +practical side of things a lot better than we do.
 
Perry,
 
I don't see too much reason to suppose that this is true.  The CIA
has had almost everything wrong since 1960, and it routinely becomes 
clear a few weeks after the fact that smart bombs, air breathing 
missiles, SCUD hunts and the like are an almost total waste of good 
silicon.
 
When the Russians first landed stuff on the Moon it was semi-amateurs 
in England, not the vaunted NASA folks, who were tuned in. 
 
My guess would be that the folks at NSA spend most of their time 
worrying about getting a better parking spot, the same as everybody 
else in Washington.
 
PM+Overall, I'd say that in the long run the open community is going to
  +catch up regardless of what the NSA likes. That does not mean,
  +however, that this is going to happen particularly soon, or that they
  +don't still know decades more than we do.
 
I think you're right about the superiority of the open community, but 
it may not be out there in the future.  It may be accompli.
 
                                   -dlj.

david.lloyd-jones at canrem.com

 * 1st 1.11 #3818 *       Gingrich, n. abbrev. :  "Giving to the rich".





From lmccarth at ducie.cs.umass.edu  Mon Feb 13 20:44:56 1995
From: lmccarth at ducie.cs.umass.edu (L. McCarthy)
Date: Mon, 13 Feb 95 20:44:56 PST
Subject: ref on crypto formalism
In-Reply-To: <199502140310.TAA23087@jobe.shell.portal.com>
Message-ID: <199502140446.XAA18306@ducie.cs.umass.edu>


Pierre writes:
> I'm pretty sure I saw somewhere a companion paper titled something
> like "An algebra of authentication"... hmmm  maybe even in CACM...
> [...15 minutes later...] Unfortunately some of my CACMs are in hiding
> and not properly indexed... It was work done at DEC SRC in Palo Alto,
> there must be some research reports too.
> 
> If somebody has refs for any of these, it would be great if you'd
> post them.

http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-039.html
SRC Research Report 39	A Logic of Authentication
Michael Burrows, Martin Abadi, and Roger Needham
February 28, 1989	48 pages

http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-070.html
SRC Research Report 70	A Calculus for Access Control in Distributed Systems
M. Abadi, M. Burrows, B. Lampson, G. Plotkin
March 4, 1991	52 pages

http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083.html
SRC Research Report 83	Authentication in Distributed Systems: Theory and 
			Practice
Butler Lampson, Martin Abadi, Michael Burrows, Edward Wobber
February 4, 1992

http://ftp.digital.com/pub/DEC/SRC/research-reports/abstracts/src-rr-117.html
SRC Research Report 117	Authentication in the Taos Operating System
Edward Wobber, Martin Abadi, Mike Burrows, and Butler Lampson
December 10, 1993	38 pages





From erc at s116.slcslip.indirect.com  Mon Feb 13 21:11:56 1995
From: erc at s116.slcslip.indirect.com (Ed Carp [khijol Sysadmin])
Date: Mon, 13 Feb 95 21:11:56 PST
Subject: WSJ article on Internet Telephony
In-Reply-To: <9502131947.AA17236@toad.com>
Message-ID: <m0reFXx-0004IKC@s116.slcslip.indirect.com>


> {The producers of Internet Phone are listed as VocalTec in Tel Aviv, with
> offices in Northvale, NJ; the software is currently $49 (although a demo
> version allowing unlimited 3-min calls is free) and currently requires a 14.4
> kps modem with a Windows 486, sound card & microphone. No Email address for the
> company was given.)

If memory serves, there are several implementations of this technology for
Windows and UNIX - no need to pay $$$...

One implementation is called mtalk, another is called ifone - they are both
for linux.  I think I found them on sunsite.
-- 
Ed Carp, N7EKG    			Ed.Carp at linux.org, ecarp at netcom.com
801/534-8857 voicemail			801/460-1883 digital pager
Finger ecarp at netcom.com for PGP 2.5 public key		an88744 at anon.penet.fi
                       ** PGP encrypted email preferred! **

Cop: "How many beers have you had tonight, bro?"
Suspect: "Seventy."  -- from the TV show "Cops"




From rfdutcher at igc.apc.org  Mon Feb 13 21:17:41 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Mon, 13 Feb 95 21:17:41 PST
Subject: CDT POLICY POST No.2 -- X9 TO DEVELOP TRIPLE-DES STANDARDS
Message-ID: <199502140518.VAA22900@igc3.igc.apc.org>


> 
> One is forced to wonder at the sort of person that can with a straight
> face argue that on the one hand an algorithm is cryptographically
> unsound, while at the same time posing a threat to national security.
> 

A lawyer, of course ... ;-}


===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From rfdutcher at igc.apc.org  Mon Feb 13 21:17:47 1995
From: rfdutcher at igc.apc.org (Richard F. Dutcher)
Date: Mon, 13 Feb 95 21:17:47 PST
Subject: Is Cyberspace Rich Enough?
Message-ID: <199502140518.VAA22903@igc3.igc.apc.org>



One of the problems commenting on long thoughtful posts is the number 
of hooks, and limiting oneself to just a few.

	[delete lots of interesting stuff]

> 
> ... After all, the Soviets
> couldn't stop samizdats, the Chinese couldn't stop fax machines, and
> the Americans can't stop drug use, so what hope is there in
> controlling modems, crypto, cellular phones, satellites, Web links,
> stegonography, terabytes of data flowing unobstructed across borders,
> and so on. Just to "stop the Net" would disrupt the entire financial
> system, which not even Clinton or the next (Republican) President
> would be tempted to do....they might as well launch a nuclear war as
> try to shut down this "anarchic" ( = high dimensionality) system.
> 

Well, I certainly hope so.  But let's remember Poland in 1979, where 
"they" were desperate enough to shut down the entire phone system.  
It gained them only an extra 10 years of control, but it cost the 
Poles a *lot* of misery.

But "samizdat" raises an interesting economic issue around security.  
The Soviets paid just enough attention to the circulation of 
hand-written or typed copies to make sure people spent a lot of time 
and energy at it -- time and energy not spent on more obviously 
dangerous activity.   Compare the volume of Solzenhitsen's output 
before and after exile [let's not debate quality].  That didn't mean 
samizdat wasn't subversive and long-term dangerous -- but it was very 
expensive and absorbing to dissidents and potential dissidents.

But that's the situation cypherpunks [and friends :] want to put our 
hypothetical eavesdroppers [government or corporate] in.  Not exactly 
harmless, but spending a lot of time and energy being concerned with 
the chasing multiple carbon copies of samizdat novellas.


> 
> * Alternative Nets, like FIDONet, are often lost in the discussion of
> "the Net," but perhaps we should take much greater interest in these
> alternatives. They make a crackdown harder, they lessen the dangers of
> a single-point attack, and they provide "genetic diversity" for
> building future Nets. (I'm not saying Cypherpunks have the time,
> expertise, or incentive to work on this, but just reminding folks that
> the Internet is not the end all and be all...)
> 

I find that techno-illiterate Greens have very little trouble 
understanding FIDONet -- it's the kind of small-scale organizing 
within larger networks that a lot of progressive activity has always 
followed.  They find it very hard to believe that other kinds of 
techie nets are really secure in the long run.  It is, in fact, the 
level of activity that the Poles reverted to without the phone 
system ...

> Personally, I think there are fewer long essays and analyses for the
> same reason there are fewer large predators than grass-munching
> herbivores.
> 
> --Tim May
> 

Geez, I have enough trouble getting card-carrying Greens to use 
and/or develop good ecological metaphors without some 
crypto-anarcho-libber punk muscling into the territory!  ;-)


===================================
Rich Dutcher, San Francisco Greens
P.O. Box 77005, San Francisco, California 94107 USA

"That's libertarians for you - anarchists who want police protection from their slaves."
                          Kim Stanley Robinson, "Green Mars"

Greens, of course, only enslave plants - so weed-whackers work better than cops ...
====================================





From skaplin at mirage.skypoint.com  Mon Feb 13 21:33:13 1995
From: skaplin at mirage.skypoint.com (Samuel Kaplin)
Date: Mon, 13 Feb 95 21:33:13 PST
Subject: EPIC to Debate Exon on CNN
Message-ID: <m0reFsV-0001f7C@skypoint.com>


>On Mon, 13 Feb 1995, Samuel Kaplin wrote:
>>  A sellout was offered a 
>> la EFF and DT. Mr. Rotenberg seemed ill prepared and not really 
>> interested in the issue.
>
>You expected something different from "EPIC"?
>
>Cypherpunks are supposed to be paranoid.  You are
>not paranoid enough.
>

I don't think paranoia has anything to do with it. I just expect people to
do the job that they are supposed to do. IMHO Mr. Rotenberg didn't do his
job as well as he should have. I saw numerous opportunities to score salient
points and he didn't. What Senator Exon says and what the bill says are two
different things. I got the feeling that Senator Exon didn't even understand
the ramifications of the bill. The unfortunate part is Joe Blow on the
street isn't going to read the bill. He's going to rely on what he has
heard. In my opinion Mr. Rottenberg didn't correct Senator Exon forcefully
enough. The consumate politician triumphed.

Sam






From hfinney at shell.portal.com  Mon Feb 13 22:41:38 1995
From: hfinney at shell.portal.com (Hal)
Date: Mon, 13 Feb 95 22:41:38 PST
Subject: Internationalism no panacea
Message-ID: <199502140641.WAA18400@jobe.shell.portal.com>


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

Two recent news stories cast doubt on the principle that the international
aspects of the nets will prevent governments from enforcing their laws
"in cyberspace".

One is the possible trade war between the U.S. and China over that
country's continued support of intellectual property piracy, in video,
audio, and computer software.  Apparently the U.S. is very serious about
imposing sanctions because of this problem, while China is threatening
retaliation.  It is quite amazing to me to see these two big countries
going to the mat over "just bits" but as we know bits are big business
now.

Think of our recent discussions of putting data havens offshore.  If the
U.S. is willing to turn the screws on a nuclear power like China, how
much protection will some dinky Caribbean country offer when people make
Windows 96 and Jurassic II available for download for $5 ecash?  IMO the
trend is going to be toward international enforcement efforts, a general
movement towards uniform information laws.

The other story related to the idea that individuals can evade laws by
moving from country to country as tourists.  Apparently in the recent
budget bill was a little-publicized change in the tax treatement of
people who renounce their U.S. citizenship.  (The change would be retroactive
to last week and was kept quiet until then to prevent a surge of people
leaving.)  Since you earned all your assets as a citizen of the U.S.,
naturally when you leave the grasp of that country you will not longer
get to take it all with you.  Instead you will apparently have to pay
capital gain taxes on some substantial fraction of your assets.

The article I read went on to discuss the problems many countries are
having with people playing citizenship games.  The implication was that
this may be just one step in a crackdown to close many of the loopholes
that allow people to travel under one flag or another.

My take on this is that human ingenuity is sufficient that there will
always be new loopholes found, and that a sufficiently energetic and
motivated person will probably be able to stay one step ahead of the
enforcers.  However, this will not be a lifestyle that can be turned into
a cookbook; as soon as some trick became widely known, the loophole would
be closed.  So this is something which will be available to an elite but
not to the masses.  Hence I don't see "perpetual tourism" as something
which will be a serious threat to government power.

My views are somewhat iconoclastic for this list; I don't see
cryptography as bringing about a libertarian/anarchist state.  I continue
to believe that the best and only way to achieve freedom for the mass of
people is to convince them that it is a good idea.  A small elite can and
will continue to be able to avoid many laws, and crypto will no doubt be
useful to them.  But IMO it is not going to change the shape of society.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBL0BQchnMLJtOy9MBAQGJaAH/WTtd0bYeqKy89AUOSaSdraxN7YNZ2z42
+rJCQH0NS8x3ILT8VT8XtSIuYltBGsQkPagUqYtn3vM/rp3ssPhr/w==
=JFan
-----END PGP SIGNATURE-----





From M00012 at kanga.stcloud.msus.edu  Mon Feb 13 22:45:28 1995
From: M00012 at kanga.stcloud.msus.edu (M00012 at kanga.stcloud.msus.edu)
Date: Mon, 13 Feb 95 22:45:28 PST
Subject: Cypher_punks standards, again.
Message-ID: <950214004527.42ba@kanga.stcloud.msus.edu>


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

Cypherpunks,

Q.  What do I mean, standards?

A.  A set of specifications that will allow encryption modules
    to be incorperated into receptacle encryption interface
    programs easily.

    The advantages of programs that comply with the CP standard
    might be illustrated with an example.

    Suppose Alice wants to use an interface program, say,
    GENPGP.EXE, to encrypt a message to Bob.

    Suppose that GENPGP is an interface encryption receptacle
    program that allows users to add and use their own encryption
    modules of choice.  If Alice were a command line freak, she
    could type:

        GENPGP -RSA_encrypt_the_session_key \
        -random_session_key_source ISA_Johnson_Noise_ADC \
        -chainsession \
        -blowfish -rounds 18 -keylength 2048 \
        -idea \
        -3descfb \
        -compress pkzip \
        -plain_text_file topsec.doc
        -receipient bob

    Or, suppose Alice is a GUI freak.  In this case she could
    use her entcrypt_lab schematic interface to design and save
    her encryption scheme for topsec.doc, and simply drop the
    icon for the doc into her block diagram's input icon.

    Bob, in either case, is still able to use his own program
    of choise, GNU_safe_mail, to automatically decrypt Alice's
    message to him, so long as Bob has incorperated all of the
    latest modules availible.

Q.  What are some advantages?

A.  There are numerous advantages.  Some programmers are good at
    writing user interfaces, and others are better at implementing
    algorithms.  Currently, many programmers of the second type
    make all sorts of encryption algorithms available, but these
    are not always easily understood by programmers of the first
    type, and more importantly, coded algorithms are not easily
    incorperated into existing programs.

    Another problem that may arise is that existing programs,
    and programs that may come out in the next year or two,
    may gain widespread use (e.g. PGP.EXE), but may at some
    time in the future become practically worthless, for
    example, if widely used interface programs rely on
    encryption algorithms that are discovered or perceived
    to be weak.

    If a standard such as the one I am proposing is released
    and gains acceptance, more programmers will comply, and
    this will allow the users of their interfaces to painlessly
    adapt the interface programs.  More importantly, such
    interface programs that make use of CP complient
    encryption modules will allow users to encrypt as
    insecurely or securely as their parinoia dictates.

    Also, as new encryption algorithms are invented and coded,
    hackers who like to optimize may take the extra step and
    make their code CP complient.  And command line Alice will
    be able to type:

        GENPGP -add_module BlowFish.mod

Q.  What are the disadvantages?

A.  At first blush, one disadvantage is options, like PGP's -m,
   (for your eyes only) are not practical for a standard such
   as the one I am proposing.  But then again, even using the
   command:

        PGP -em susan.doc

    is little more than a suggestion to the recepient of
    the letter to not keep the plaintext around.

Q.  Why should we?

A.  If we don't, IEEE or some other organization is
    bound to, and IEEE seems to be getting more politically
    correct as the years pass, and this doesn't seem to
    be compatible with the purpose of an encryption module
    standard.

    Consequently, I believe that such a task should be initiated
    and taken to completion by a renegade group such as the
    cypherpunks, by committe if possible, with the hopes that
    government moles will not weaken our effort.

Mike Morgan


-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBMNBuvbwEeVpjJyiBAQEi5QP/T9FmRS2nwWq0lr9iT+cQWMEMV1++Hpf3
u0OWnYYFlRjgJPxTa5vT549tgGeRGV+CB+TI6N3Aj96+LTWb34qS5Y0W2x7R5FEg
+XnACQRs9G5qIK4Zn114KlWXyx7Mj0QQCeo4h86gISdrWkfSJiYkwEoGgzcf6ocF
gp45YZLznnk=
=cMFk
-----END PGP SIGNATURE-----





From abostick at netcom.com  Tue Feb 14 01:02:39 1995
From: abostick at netcom.com (Alan Bostick)
Date: Tue, 14 Feb 95 01:02:39 PST
Subject: Laws, Feds, & the Internet
In-Reply-To: <m0rdBe4-000k50C@mailbox.mcs.com>
Message-ID: <Ki4GlyczB8cA075yn@netcom.com>


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

In article <m0rdBe4-000k50C at mailbox.mcs.com>, 
dls at mcs.com (David Sallach) wrote:

[Rich Dutcher wrote:]

> >"Free" speech has always been a balancing act.  The founders
> >certainly didn't intend to provide "free" speech for blacks and
> >women.  
> 
>         The Founders created a larger space for free speech than had ever
> existed.  Slaves were deprived of many freedoms including speech, of course,
> but women and free blacks were included in the Bill of Rights and exercised
> free speech, frequently compellingly.  

And hard on the heels of the ratification of the Bill of Rights came the
Alien and Sedition Acts.  The Founders were so distressed by the size of
the space for free expresion they had allowed to be created that they
took immediate steps to limit it.

It is well to remember that the Bill of Rights was a bone thrown by the
Founders (that is, the Federalists) to sweeten the bitter pill of the
process of centralizing government power.  An afterthought, actually.

> > . . . "They" have never liked "free" speech ... :-(
> 
>         Invoking poitically 'correct' stereotypes does not strengthen your
> argument.

Arguing _ad_hominem_ doesn't strengthen yours.

   Alan Bostick           | The nice thing about quotes is that they give   
   abostick at netcom.com    | a nodding acquaintance with the originator
finger for PGP public key | which is often socially impressive.
Key fingerprint:          |         Kenneth Williams
50 22 FB 46 41 A3 17 9D F7 33 FF E1 4E 1C 89 79  +legal_kludge=off

-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQB1AgUBL0BNnuVevBgtmhnpAQEe7wL/aNjOHyflJHfcRrHdxa73Xt9Hu8eTD4kx
+gWQpMpeJHLhQk+Gey3epbqXDkjT0YOFI3xUtcjotGRnHhisIbhPztYOCZBxhSLE
WkozOBCZpz2t6a+Z3cPYRH/jBk7aCWBd
=XDZA
-----END PGP SIGNATURE-----