From wcs at anchor.ho.att.com  Tue Feb  1 00:30:29 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 1 Feb 94 00:30:29 PST
Subject: 2-way anonymous via SASE
Message-ID: <9402010825.AA26310@anchor.ho.att.com>


Hal Finney writes:
> From: "Jon 'Iain' Boone" <boone at psc.edu>
> >   So, you use a chain of anonymous-id's to set up your return-path?
> 
> Unfortunately, return-paths are not exactly the strong point of the
> current cypherpunks remailers :-).  That is what much of the discussion
> in this thread has discussed: how to best allow for convenient but secure
> return paths.

Yeah; the only solutions I've seen so far either give you some persistence,
like anon.penet.fi, or no replies, or have generally been pretty ugly,
requiring rapidly-increasing numbers of messages to set up chains
of anonymous IDs, or use broadcast, like the Blacknet "post to Usenet"
or DCnets.  AIR-MAIL may be a start.
It seems to need something that supports a small but >1 number of replies
to make a non-ugly system, which means either some kind of Time-To-Live or
destruct messages from one or both ends need to be supported.

		Bill





From wcs at anchor.ho.att.com  Tue Feb  1 00:45:25 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 1 Feb 94 00:45:25 PST
Subject: PGP keyid collisions?
Message-ID: <9402010844.AA26415@anchor.ho.att.com>


I had discussed the benefit of putting PGP keyID or fingerprint
in signatures to reduce spoofing for people who distribute by finger
or unreliable keyservers, though obviously signatures are what
gives you the confidence that a key is valid.

Hal points out that brute-forcing a 24-bit Key-ID isn't all that hard;
the usual formulas tell you what fraction of numbers are prime in the 
desired range, though without looking them up I'd expect it would take
around 2**30 - 2**35 tries to find a specific one; I suppose this 
means the NSA has already done it :-)

> I understand there is already at least one 24-bit collision on the
> public key servers, not unexpected given a few thousand keys.

I assume PGP does the right thing, except in cases of pilot error
(e.g. doing key lookup by KeyID) ?  Even if it does, this has
some design impact on systems using random public-private key generation
for meet-me remailer cutouts.
		Bill
		
# Bill Stewart  AT&T Global Information Systems, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465





From franz at cs.ucdavis.edu  Tue Feb  1 00:55:25 1994
From: franz at cs.ucdavis.edu (Roy Franz)
Date: Tue, 1 Feb 94 00:55:25 PST
Subject: BlackNet - what is it?
Message-ID: <Pine.3.89.9402010035.A18050-0100000@burks.cs.ucdavis.edu>



Hi,
   I have seen BlackNet referred to several times.  Could someone
say a few words about it?

Thanks,
Roy

-----------------------------------------------------------
Roy B. Franz				rbfranz at ucdavis.edu
Software Engineer
Viewgraphics, Inc







From wcs at anchor.ho.att.com  Tue Feb  1 01:20:29 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 1 Feb 94 01:20:29 PST
Subject: BlackNet - what is it?
Message-ID: <9402010919.AA26665@anchor.ho.att.com>


Blacknet wasn't real; it was a posting Tim May anonymously posted advertising
network support for various illegal services, including where to
send your digicash blackmail or ransom payments and the like.
Basically to try to get us to think about the implications of the
technologies we're developing and potential for abuse and paranoia.

On the other hand, maybe it wasn't *really* Tim May anonymously posting it,
and the Tentacles of Detweiler will be posting GIFs of you and your
friends talking to notorious politicians to alt.your.mother
and releasing that new virus with your name on the banner page unless
you help Eric start a digibank to deposit some ransom money in. :-)

		Bill,or someone like him





From wcs at anchor.ho.att.com  Tue Feb  1 02:00:29 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 1 Feb 94 02:00:29 PST
Subject: 4th ammendment and Cryptography
Message-ID: <9402010955.AA26853@anchor.ho.att.com>


I'll second Phil Karn's recommendation of Caroline Kennedy's book,
though I do remember it having somewhat of a liberal "Government is Good" bias.
Unless I'm mixing it up with another book I read around the same time,
it's also the one place where I've seen a recent 3rd Amendment case.
The case was interesting largely because 3rd Amendment cases are
very rare; the U.S. government hasn't quartered troops in people's homes
except during the War Between The States, when it was ignoring
the Constitution and Bill of Rights anyway.  The issue was a prison
guard strike, in which the National Guard was brought in to replace
striking guards until the contract dispute was settled.  Guards at the
prison had rooms there for sleeping and off-duty use, and the National
Guard, which is part of the military, used them during the strike.
The guards contended that this was quartering troops in their homes.
I think the government won the case rather than the prison guards,
since it was really stretching the point.

Phil's concerns about not freaking people out by emphasizing that the
Second Amendment is designed to make overthrowing governments possible
are well-placed (notwithstanding the fact that it's true.)
It may be good rhetoric to use at a pro-gun meeting, though a lot of
the NRA people I've met tend to get upset by the word "anarchy",
but the general public just barely tolerates duck hunting and
really has no desire for violent revolution, and frankly, neither do I.

We're trying to go for their hearts and minds here, and issues like
privacy, freedom of speech, and Big Brother tapping your phone
are a lot more attractive to most people.  Even the ideas that
private communications can make government obsolete and that obsolete
institutions can fail are pretty scary to people who've been educated
in government schools, and associating crypto-privacy with the
more extreme radically-correct side of the Gun Nuts will lose them -
especially when there *are* legitimate concerns about use of
anonymity and digicash for blackmail, ransom, and funding of real terrorists,
plus the government's favorite drug dealer scare.

Besides, walking around making unattributed quotations from the
writings of the Founding Fathers tends to get you treated like
David Koresh or at the very least Michael Milken....

			Bill
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465





From MILKA%PLSZUS11.BITNET at SEARN.SUNET.SE  Tue Feb  1 04:05:27 1994
From: MILKA%PLSZUS11.BITNET at SEARN.SUNET.SE (Doodeck)
Date: Tue, 1 Feb 94 04:05:27 PST
Subject: PGPkeys (ftp access)
Message-ID: <9402011203.AA14567@toad.com>


> Subject: PGPTools
> From: m at BlueRose.com (M Carling)
> I don't have ftp access here. Could some kind person please email it
> to me?

I don't have ftp (or Internet) access either. Try using
one of BITFTP (BITnet FTP I think) services. Automated info
response will be send to you upon sending mail with message body
containing word "help" (without quotes) to one of the following
addresses:
bitftp at pucc.princeton.edu or
bitftp at pucc.bitnet (located in USA)
bitftp at plearn.edu.pl  or
bitftp at plearn.bitnet (located in Central Europe)

Just before onset of twenty first century such ftp 'access'
may seem ridiculous but it really works as I have transferred
megabytes of data this way.

Good Luck !

Doodeck.





From m5 at vail.tivoli.com  Tue Feb  1 06:00:34 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Tue, 1 Feb 94 06:00:34 PST
Subject: Matsui-san Attack
In-Reply-To: <9401312111.AA15451@atlanta.wti.com>
Message-ID: <9402011356.AA06070@vail.tivoli.com>



Huh?  Two years of breathing space?  I don't think so.  Networks of
many fast workstations (snakes, SPARC-10's, Alphas, whatever) aren't
exactly rare; I'm sure I could equal that mflop horsepower here, and
I'm double sure I could have done it while at DEC.  I frequently ran a
home-grown distributed fractal image generator at DEC harnessing 75
workstations, about 20 of them Alphas.

The real question is whether this new attack is bogus.

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From dmandl at lehman.com  Tue Feb  1 06:45:28 1994
From: dmandl at lehman.com (David Mandl)
Date: Tue, 1 Feb 94 06:45:28 PST
Subject: Cypherpunk article in NY Newsday
Message-ID: <9402011442.AA09401@disvnm2.lehman.com>


There's a decent cypherpunk piece in today's New York Newsday.
It was written by Joshua Quittner, who apparently attended the
most recent meeting out in CA.  It's more or less the usual,
very upbeat and supportive, with some quotes from Eric H.
and remarks on digibanking basics, Clipper, etc.

   --Dave.





From boone at psc.edu  Tue Feb  1 07:10:34 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Tue, 1 Feb 94 07:10:34 PST
Subject: 2-way anonymous via SASE
In-Reply-To: <199402010131.RAA05280@jobe.shell.portal.com>
Message-ID: <9402011510.AA03122@igi.psc.edu>



Hal <hfinney at shell.portal.com>  writes:
>
> From: "Jon 'Iain' Boone" <boone at psc.edu>
> 
> >   What if you have a remailer that only assigns you an id for that message
> >   so that your id is equivalent to (say) the Message-ID (or some portion
> >   thereof)?  How do you return-path without specifying?
> 
> Your syntax is a bit hard to follow here, but I'm guessing that you are
> proposing such a remailer as a way of providing for return paths.  The
> remailer would remember the message-id's of outgoing messages, and would
> remember where those messages came from.  Then if a reply came back for
> one of those message-id's it could send it to that remembered address.
> 
> There were some proposals along these lines made last year, or maybe back
> in 1992.  This scheme doesn't seem to generalize well to multi-remailer
> paths.  Also, I think people would be nervous about having remailers keep
> this kind of out-to-in mapping information.

  I think that I am confused.  Please bear with me.  

  Jim Miller <jim at bilbo.suite.com> writes:
  >
  > The general idea is that each anonymous messages will include a SASE that
  > can be used to reply to the sender, without revealing the identity of the
  > sender to the message recipient.  To reply, the recipient will copy the
  > SASE from the original message and past it into a special section of the
  > reply message.  Remailers will examine this section of the reply message
  > and use its contents to route the message back to the sender of the
  > original message.

  Now, what is this SASE?  Apparently it is either a) a fully-specified
  return-path (presumably a chain of anonymous ids at various remailers),
  b) a next-hop address (anonymousid at the next remailer that "knows"
  where to send the message), or c) some combination of the previous two.

  Is there another possibility that I have missed?

  Let's assume that the SASE is of type-a.
  
  Let's assume three remailers (and my accounts on them) named:

  anon1+ at foo.bar.edu
  anon2+ at biff.bam.com
  anon3+ at fred.barney.org
  
  Then, if I want to anonymously send mail to you ( <hfinney at shell.protal.com> )
  , I need to specifiy your address as normal, but specifiy some optional 
  header (X-Anonymous-Sender-Path) like this:

  <anon3+"anon2+"anon1+ at foo.bar.edu"@biff.bam.com"@fred.barney.org> 
  
  which says to my mailer that, while the ultimate destination is 
  <hfinney at shell.portal.com>, it should first mail it to the 
  X-Anonymous-Sender-Path address.

  HOST: fred.barney.org  Account: anon3+

  This anon3+ at fred.barney.org account will accept the mail (it accepts anything
  like anon3+*@fred.barney.org, so it doesn't matter about the stuff in quotes)
  It then strips off the anon3+ at fred.barney.org section, and re-writes the
  X-Anonymous-Sender-Path to read like this:

  <anon2+"anon1+ at foo.bar.edu"@biff.bam.com>

  It would then instantiate another optional header (X-Anonymous-Return-Path)
  like this:

  <anon3+ at fred.barney.org>

  It would change the Sender: header to say "Anonymous User 3" or whatever 
  it would normally say, and mail it to biff.bam.com.

  HOST: biff.bam.com  Account: anon2+

  This account accepts the mail and re-writes the headers like this:

  X-A-S-P: <anon1+ at foo.bar.edu>

  X-A-R-P: <anon2+"anon3+ at fred.barney.org"@biff.bam.com>

  Sender: "Anonymous User 2"@biff.bam.com

  and mails the mail to anon1+ at foo.bar.edu

  HOST: foo.bar.edu  Account: anon1+

  This account accepts the mail and re-writes the headers like this:

  X-A-R-P: <anon1+"anon2+"anon3+ at fred.barney.org"@biff.bam.com"@foo.bar.edu>

  Sender: "Anonymous User 1"@foo.bar.edu

  Notice that it leaves off the X-Anonymous-Sender-Path: header since it is
  empty.

  It then mails it to hfinney at shell.portal.com.

  You receive the mail and read the message.  Now, the sender indicates that
  it is from "Anonymous User 1"@foo.bar.edu, but the X-A-R-P: indicates that
  it is really from anon3+ at fred.barney.org!  So, as long as fred.barney.org
  can be trusted, no one can tell who I am, right?  And, except for anon3,
  none of the others needs to be my account!  This requires changing the
  mail agent on my end, though, and possibly yours.

  Replying follows the same sort of path, except in reverse.

  Of course, you could also allow for a Return-Path header which was not
  re-writeable, to force a seperate path to get back to me.  And, you can
  also change the software so that I initially send to 
  hfinney%shell.portal.com at fred.barney.org, which would *not* require any
  rewriting of mail-agent software.

  Is this at all coherent?

  If the return-path is type B, I don't see how you can avoid having the
  ID-mapping which makes the overall scheme weaker.  I don't have a good
  handle of the type c.


> I understand there is already at least one 24-bit collision on the
> public key servers, not unexpected given a few thousand keys.

  Hmm... I'm not sure I followed all of the math, but how's this for
  a signature?


 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From f_griffith at ccsvax.sfasu.edu  Tue Feb  1 07:15:28 1994
From: f_griffith at ccsvax.sfasu.edu (Reynolds Griffith)
Date: Tue, 1 Feb 94 07:15:28 PST
Subject: Privacy As Roadkill
Message-ID: <9402011513.AA16876@toad.com>


>Date: Mon, 31 Jan 1994 12:37:12 -0800 (PST)
>From: Dave Wren <dwren at olympus.net>
>Subject: Privacy As Roadkill
>To: "libernet at Dartmouth.edu" <libernet at Dartmouth.EDU>
>Errors-To: owner-libernet at Dartmouth.EDU
>Sender: owner-libernet at Dartmouth.EDU
>Reply-To: libernet at Dartmouth.EDU
>Precedence: bulk
>X-Mailing-List: libernet at Dartmouth.EDU
>
>
>---------- Forwarded message ----------
>Date: Sun, 30 Jan 1994 21:00:50 -0800
>From: "Brock N. Meeks" <brock at well.sf.ca.us>
>To: com-priv at psi.com
>Subject: Privacy As Roadkill
>
>
> 
>Jacking in from a "Private No More" Port:
> 
>Washington, DC -- If privacy isn't already the first victim of
>roadkill along the information superhighway, then it's about to be.
> 
>A law enforcement panel addressing the Administration's Information
>Infrastructure Task Force Working Group on Privacy told a public
>meeting here last week that it wanted to "front load" the National
>Information Infrastructure with trap door technologies that would
>allow them to easy access to digital conversations;  eavesdropping
>on any conversation or capturing electronic communications
>midstream.
> 
>But only for "the bad guys."  Us honest, hard working, law abiding
>citizens have nothing to fear from these law enforcement agencies
>selling out our privacy rights to make their jobs easier.  Nope, we
>can rest easy, knowing that child pornographers, drug traffickers
>and organized crime families will be sufficiently thwarted by law
>enforcement's proposed built-in gadgetry for the national
>information infrastructure.
> 
>There's just a small problem:  Law enforcement agencies, any law
>enforcement agency, has yet to prove it needs all these proposed
>digital trap doors.  In fact, according to a U.S. Assistant
>Attorney appearing on the panel, "Right now most law enforcement
>personnel don't have any idea what the NII is."
> 
>Gore Gives Go Ahead
>===================
> 
>Panel members, representing the Justice Dept., FBI and U.S.
>Attorney's office, said that they took Vice President Gore's
>promise that the White House would work to ensure that the NII
>would "help law enforcement agencies thwart criminals and
>terrorists who might use advanced telecommunications to commit
>crimes," as tacit approval of their proposals to push for digital
>wiretap access and government mandated encryption policies.
> 
>Gore buried those remarks deep in a speech he made in Los Angeles
>earlier this month when the Administration first fleshed out how it
>planned to rewrite the rules for communications in a newer, perhaps
>more enlightened age.  Those remarks went unnoticed by the
>mainstream press.  But readers here were forewarned.
> 
>Fuck Ross Perot's NAFTA-induced "giant sucking sound."  That
>"thump" you just heard was Law Enforcement running over the privacy
>rights of the American public on its way to the information
>superhighway.  The real crime is that the collision barely dented
>the damn fender.
> 
>This cunning and calculated move by law enforcement to install
>interception technologies all along the information superhighway
>was blithely referred to as "proactive" law enforcement policy by
>Assistant U.S. Attorney, Northern Dist. of California Kent Walker. 
>Designing these technologies into future networks, which include
>all telephone systems, would ensure that law enforcement
>organizations "have the same capabilities that we all enjoy right
>now," Walker said.
> 
>With today's wiretap operations, the Feds must get a court to
>approve their request, but only after supplying enough evidence
>warrant one.  But Walker seemed to be lobbying for the opposite. 
>Giving the Feds the ability to listen in first and give
>justification later was "no big difference," he said. Besides, "it
>would save time and money."
> 
>It's Us vs. Them
>=================
> 
>For Walker privacy issues weighed against law enforcement needs are
>black and white, or rather "good guys" vs. "bad guys."   For
>example, he said the rapid rise of private (read: non-government
>controlled) encryption technologies didn't mean law enforcement
>would have to work harder.  On the contrary, "it only means we'll
>catch less criminals," he said.                    
> 
>But if law enforcement is merely concerned with the task of "just
>putting the bad guys in jail," as James Settle, head of the FBI's
>National Computer Crime Squad states, then why are we seeing an
>unprecedented move by government intelligence agencies into areas
>they have historically shied from?  Because law enforcement
>agencies know their window of opportunity for asserting their
>influence is right now, right at the time the government is about
>to take on a fundamental shift in how it deals privacy issues
>within the networks that make up the NII, says David Sobel, general
>counsel for Computer Professionals for Social Responsibility
>(CPSR), who also spoke as a panel member.
> 
>"Because of law enforcement's concerns (regarding digital
>technologies), we're seeing an unprecedented involvement by federal
>security agencies in the domestic law enforcement activities,"
>Sobel said.
> 
>Sobel dropped-kicked this chilling fact from behind the closed
>doors of the Clinton Administration into the IITF's lap:  For the
>first time in history, the National Security Agency (NSA) "is now
>deeply involved in the design of the public telecommunications
>network."
> 
>Go ahead.  Read it again.
> 
>Sobel backs up his claims with hundreds of pages of previously
>classified memos and reports obtained under the Freedom of
>Information Act.  The involvement of the NSA in the design of our
>telephone networks is, Sobel believes, a violation of federal
>statutes.
> 
>Sobel's also concerned that the public might soon be looking down
>the throat of a classified telecommunications standard being
>created.  Another move he calls "unprecedented," is that if the
>NSA, FBI and other law enforcement organizations have their way,
>the design of the national telecommunications network will end up
>classified and withheld from the public.
> 
>Sobel is dead bang on target with his warnings.
> 
>The telecommunications industry and FBI have set up an ad hoc
>working group to see if a technical fix for digital wiretapping can
>be found to make the Bureau happy.  That way, legislation doesn't
>need to be passed that might mandate such FBI access and stick the
>Baby Bells with eating the full cost of reengineering their
>networks.
> 
>This joint group was formed during a March 26, 1992 meeting at
>FBI's Quantico, Va., facilities, according previously classified
>FBI documents released under Freedom of Information Act. The group
>was only formalized late last year, working under the auspices of
>the Alliance for Telecommunications Industry Solutions (ATIS).  The
>joint industry-FBI group operates under the innocuous sounding name
>of the Electronic Communications Service Provider Committee
>(ECSPC).
> 
>The ECSPC meets monthly with intent of seeking a technological
>"solution" to the FBI's request for putting a trap door into
>digital switches that would allow them easy access to those
>conversations. To date, no industry solution has been found for the
>digital wiretap problem, according to Kenneth Raymond, a Nynex
>telephone company engineer, who is the industry co-chairman of the
>group.
> 
>Oh, there's also a small, but nagging problem:  The FBI hasn't
>provided a concrete basis that such solutions are needed, Raymond
>said.  CPSR's Sobel raised these same points during the panel
>discussion.
> 
>The telecommunications industry is focused on "trying to evaluate
>just what is the nature of the [digital access] problem and how we
>can best solve it in some reasonable way that is consistent with
>cost and demand," Raymond said.   One solution might be to write
>digital wiretap access into future switch specifications, he said.
> 
>If and when the industry does find that solution, do you think the
>FBI will put out a press release to tell us about it? "I doubt it
>very much," said FBI agent Barry Smith with the Bureau's
>Congressional Affairs office. "It will be done quietly, with no
>media fanfare."
> 
>Is it just me or are these headlights getting REALLY close?
> 
>The FBI's Settle is also adamant about trap door specifications
>being written into any blue prints for the National Information
>Infrastructure. But there's a catch.  Settle calls these "security
>measures," because they'll give his office a better chance at
>"catching bad guys."  He wants all networks "to be required to
>install some kind of standard for security."  And who's writing
>those standards?  You guessed it:  The NSA with input from the FBI
>and other assorted spook agencies.
> 
>Settle defends these standards saying that the "best we have going
>for us is that the criminal element hasn't yet figured out how to
>use this stuff [encryption and networks in general].  When they do,
>we'll be in trouble. We want to stay ahead of the curve."
> 
>In the meantime, his division has to hustle.  The FBI currently has
>only 25 "net literate" personnel, Settle admitted. "Most of these
>were recruited 2 years ago," he said.  Most have computer science
>degrees and were systems administrators at time, he said.
> 
>You think that's funny?  Hell, the Net is a still small community,
>relatively speaking.  One of your friends is probably an FBI Net
>Snitch, working for Settle.  Don't laugh.
> 
>Don't Look Now, Your Privacy Is Showing
>=======================================
> 
>The law enforcement establishment doesn't think you really know
>what you expect when it comes to privacy.
> 
>U.S. Attorney Walker says:  "If you ask the public, 'Is privacy
>more important than catching criminals?'  They'll tell you, 'No.'"
> 
>(Write him with your own thoughts, won't you?)
> 
>Because of views like Walker's, the Electronic Communications
>Privacy Act (ECPA) "needs to be broader," said Mike Godwin, legal
>services counsel, for Electronic Frontier Foundation, speaking as
>a panel member.  The ECPA protects transmitted data, but it also
>needs to protect stored data, he said.  "A person's expectation of
>privacy doesn't end when they store something on a hard disk."
> 
>But Walker brushed Godwin aside saying, "It's easy to get caught up
>in the rhetoric that privacy is the end all be all."
> 
>Do you have an expectation of privacy for things you store on your
>hard disk, in your own home?  Walker says that idea is up for
>debate:  "Part of this working group is to establish what is a
>reasonable expectation of privacy."
> 
>That's right.  Toss everything you know or thought you knew about
>privacy out the fucking window, as you cruise down the fast lane of
>the information superhighway.  Why?  Because for people like
>Walker, those guardians of justice, "There has to be a balance
>between privacy needs and law enforcement needs to catch
>criminals," he says.
> 
>Balance, yes.  Total abrogation of my rights?  Fat chance.
> 
> 
>Meeks out...
> 
>
>
>
>
>






From jazz at hal.com  Tue Feb  1 07:35:28 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 07:35:28 PST
Subject: Archiving mail-lists...
Message-ID: <9402011530.AA13741@jazz.hal.com>



   I would be interested in a discussion on the mail-list on this
   issue. Please refrain from sending personal mail. In particular do you
   think such a archive without every members permission is un-ethical?

Unethical, hell; illegal is closer to it. I retain the copyright to
everything I post; although implicit permission to redistribute to the
mailing list is granted when I send to cypherpunks at toad.com, I have granted
no permission to anyone else to use my intellectual property (i.e. my posts,
valuable or not) for any other purpose.
   
   Would a archivist necessarily need the permission of the mail-list
   sponser?

In an actively-moderated group (i.e. where the moderator chooses which
messages to forward, constructs digests, etc.) the moderator possesses a
copyright on the collection of material (but not on the material itself); if
you were republishing a substantial part of the collection (in your case,
all of it) you'd need rights to the collection copyright also.

Study copyright law (including the Berne Convention, to which most nations
having Usenet sites are signatories). Understand what you're getting
yourself into.

Jason





From frissell at panix.com  Tue Feb  1 07:55:27 1994
From: frissell at panix.com (Duncan Frissell)
Date: Tue, 1 Feb 94 07:55:27 PST
Subject: 4th ammendment and C
Message-ID: <199402011550.AA14431@panix.com>


W >it's also the one place where I've seen a recent 3rd Amendment case.

The Third Amendment.  Answer to the question "What Amendment of the Bill 
of Rights *doesn't* the US Government violate thousands of times a day?"

W >but the general public just barely tolerates duck hunting and
W >really has no desire for violent revolution, and frankly, neither do 
W >I.

Not violent revolution.  Just an alternative source of authority or 
defense.  A reality check on tyranny.  A badge of sovereignty.  You can't 
be sovereign without weapons.

W >We're trying to go for their hearts and minds here, and issues like
W >privacy, freedom of speech, and Big Brother tapping your phone
W >are a lot more attractive to most people.

The whole point of this list is that we can achieve a technological fix 
for the "problems of human interaction."  We can free ourselves and others 
without changing anyone's mind.  That changes of ideology can follow new 
technologies and the social institutions they spawn.

W >Even the ideas that private communications can make government obsolete
W >and that obsolete institutions can fail are pretty scary to people
W >who've been educated in government schools, and associating
W >crypto-privacy with the more extreme radically-correct side of the Gun
W >Nuts will lose them.

Then the bulk of the population has a lot of frights coming and we are 
providing a public service by letting them confront their fears early in 
the game.  

What we are doing is predicting not advocating.  If social changes 
increase people's personal liberties, their liberties are increased 
whether we point them out or not.  

In any case, our sort of analysis is creeping into the straight business 
press (particularly Forbes) and when C. Wright Wriston (former Citibank 
CEO) writes a book like "The Twilight of Sovereignty" how off the wall can 
we be?

W >especially when there *are* legitimate concerns about use of
W >anonymity and digicash for blackmail, ransom, and funding of real 
W >terrorists, plus the government's favorite drug dealer scare.

These people could use existing techniques but mostly don't.  Can you 
*believe* the WTC bombers getting their dough by an open wire transfer 
from the BRD?

W >Besides, walking around making unattributed quotations from the
W >writings of the Founding Fathers tends to get you treated like
W >David Koresh or at the very least Michael Milken....

I don't remember Mike quoting the Founding Parents.  His only mistake was 
copping a plea.

DCF

Western Civilization didn't invent tyranny, slavery, racism, or the
oppression of women.  What it did do is eliminate those evils (to the 
extent they have been eliminated).  The rest of the world should be damn 
grateful and if they're not we should return them to the ancient tyrannies 
from which we so recently rescued them.  Would serve them right.

--- WinQwk 2.0b#1165                                                    





From jazz at hal.com  Tue Feb  1 08:05:27 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 08:05:27 PST
Subject: archiving on inet
Message-ID: <9402011601.AA13762@jazz.hal.com>


   So if I sell (at a profit) a netnews feed to subscribers via modem, it
   is not copyright infringement, but if I sell the same data on a CDROM,
   you cliam copyright infringement.

Yep. When you're providing a netnews feed, you're acting as a node in a
store-and-forward network. A CD-ROM is not a part of a store-and-forward
network; it is a permanently fixed repository of information. You can't hold
up a netnews feed in a courtroom and point at it saying "there it is"; you
*can* do so with a CD-ROM.

   So I suppose you want to give some
   kind of list of what types of media are acceptable for transmitting
   netnews feeds, and which are not?

A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently
fixed copy of the contents of such a feed. Static versus dynamic; permanent,
ephemeral. Is this hard to understand?

   The plain and simple fact is: When you post a message to usenet, you do
   so with the expectation that others will receive it.  You can have no
   way of knowing or limiting who may get it; that is given by the nature
   of the network.  Usenet news is, and is intended to be, publicly
   accessable information.  If there is something you don't want
   distributed, then DON'T POST IT!

Learn a little about law; while you're at it, learn a little about usenet.
When you post a message to usenet, you have tossed it into a flood-routed
store-and-forward network. You implicitly give permission for copying
appropriate to the propagation of messages in that network. You neither
grant permission nor withhold permission for Fair Use. Everything else,
though, is not granted unless explicitly granted.

If I post a message, under the terms of the Berne Convention and current US
copyright law, a recipient was not granted the right to print a copy and
publish it in a book. What makes you think I granted them permission to
publish a copy in a CD-ROM? The only permission I granted was that they
could (a) read it and (b) forward it via usenet protocols.

Jason





From hfinney at shell.portal.com  Tue Feb  1 08:10:34 1994
From: hfinney at shell.portal.com (Hal)
Date: Tue, 1 Feb 94 08:10:34 PST
Subject: PGP keyid collisions?
Message-ID: <199402011607.IAA22359@jobe.shell.portal.com>


From: wcs at anchor.ho.att.com (bill.stewart at pleasantonca.ncr.com +1-510-484-6204)
> Hal points out that brute-forcing a 24-bit Key-ID isn't all that hard;
> the usual formulas tell you what fraction of numbers are prime in the 
> desired range, though without looking them up I'd expect it would take
> around 2**30 - 2**35 tries to find a specific one; I suppose this 
> means the NSA has already done it :-)

Right, but the point is that you have to search for a prime q anyway;
PGP's algorithm is basically to repeat q += 2 until you find a q which
is prime.  It uses a sieve to speed this up a lot.  I was pointing out
that you can basically change the 2 to a 2^24, still use a sieve, and
find a key just about as fast.  So matching an existing key ID should not
take much if any longer than just generating a PGP key in the first place.

> > I understand there is already at least one 24-bit collision on the
> > public key servers, not unexpected given a few thousand keys.
> 
> I assume PGP does the right thing, except in cases of pilot error
> (e.g. doing key lookup by KeyID) ?  Even if it does, this has
> some design impact on systems using random public-private key generation
> for meet-me remailer cutouts.
> 		Bill

PGP actually uses a 64-bit key ID internally, only displaying the lower
24 bits for conciseness.  It would be practically impossible to get a
64-bit key ID collision by accident (well, almost impossible, anyway).
However, the technique I mentioned could easily generate such collisions.
PGP does check for the case of matching key ID and does something, but I
forget what.  24-bit key ID matches shouldn't have any effect except for,
as Bill says, extracting/deleting keys based on key ID.

Hal






From wex at media.mit.edu  Tue Feb  1 08:45:27 1994
From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat)
Date: Tue, 1 Feb 94 08:45:27 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011530.AA13741@jazz.hal.com>
Message-ID: <9402011645.AA04676@media.mit.edu>


Ah, the old I'm-not-a-lawyer-but-I-play-one-on-the-net.

Problem with Jason Zions' position:
	- Not at all clear that Berne applies to electronic mail, even of a
personal nature
	- Not at all clear that postings to a publicly-read list like this
are not equivalent to speech in a public place (ie not necessarily
copyrighted)
	- Not at all clear what the status of private communications is vis
a vis publication.  The courts in the US seem to be flip-flopping all over
the place in a couple of recent cases involving correspondence used to write
biographies (one of L Ron Hubbard sticks in my mind and I forget who the
other was about).

You can't just wave your hand and say the magic word "Berne" and thereby
prevent someone from archiving, reposting etc your messages to this list.

--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group	wex at media.mit.edu
Voice: 617-258-9168 Page: 617-945-1842		an53607 at anon.penet.fi
All the world's a stage and most of us are desperately unrehearsed.





From mnemonic at eff.org  Tue Feb  1 09:05:27 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 09:05:27 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011645.AA04676@media.mit.edu>
Message-ID: <199402011701.MAA08013@eff.org>


 
Alan Wexelblat writesK

> Ah, the old I'm-not-a-lawyer-but-I-play-one-on-the-net.
> 
> Problem with Jason Zions' position:
> 	- Not at all clear that Berne applies to electronic mail, even of a
> personal nature

Hey, it's clear to me.

> 	- Not at all clear that postings to a publicly-read list like this
> are not equivalent to speech in a public place (ie not necessarily
> copyrighted)

That's not the measure of copyright. It's whether the expression has been
instantiated in a tangible medium.

> 	- Not at all clear what the status of private communications is vis
> a vis publication.  The courts in the US seem to be flip-flopping all over
> the place in a couple of recent cases involving correspondence used to write
> biographies (one of L Ron Hubbard sticks in my mind and I forget who the
> other was about).
 
They flipflop because of the trickiness of Fair Use--there's no
hard-and-fast rule as to what qualifies.

> You can't just wave your hand and say the magic word "Berne" and thereby
> prevent someone from archiving, reposting etc your messages to this list.
 
True, but you can say "Berne" and settle the issue of copyright.



--Mike







From jazz at hal.com  Tue Feb  1 09:05:34 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 09:05:34 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011645.AA04676@media.mit.edu>
Message-ID: <9402011704.AA13796@jazz.hal.com>


Alan -

  - Not at all clear that Berne applies to electronic mail, even of a
    personal nature

Copyright exists from the moment the work is set down in concrete form. Are
you arguing that email is not concrete?

   - Not at all clear that postings to a publicly-read list like this
     are not equivalent to speech in a public place (ie not necessarily
     copyrighted)

Ah. The old "if the NFL has to remind us that its broadcast of the superbowl
is copyrighted, so do you" argument.

Okay, let's try this on for size.

Copyright 1994 Jason Zions. Permission to copy and transmit for the purpose
of propagation of the Cypherpunks mailing list in email or local-newsgroup
(usenet) forms is granted; all other rights are reserved.

   - Not at all clear what the status of private communications is vis
     a vis publication.

But this isn't private communication.

   You can't just wave your hand and say the magic word "Berne" and thereby
   prevent someone from archiving, reposting etc your messages to this list.

Law is a complex thing, isn't it. I'd better go back and reread the code and
current decisions. I'm spending more of my time tracking the CompuServe MIDI
copyright actions, though.

Jason





From kshep at netcom.com  Tue Feb  1 09:10:34 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 09:10:34 PST
Subject: archiving on inet
In-Reply-To: <9402011601.AA13762@jazz.hal.com>
Message-ID: <Pine.3.85.9402011100.A29594-0100000@netcom8>


Dear Jason,

I don't think you are neccissarily correct about making an archive of the 
usenet. You may be correct, but I don't believe this point has been 
litigated yet. Furthermore, just because something is forwarded and 
something is archived I don't believe is expressly covered in copyright 
law. Others could argue that postings by their very nature, when posted 
become "public domain", and thus not copyrightable. I practice law, but 
am not a copyright/trademark specialist. Also, as was posted earlier 
someone is already making an archive of the usenet. See earlier postings. 
Finally what is the tangible difference between storing usenet postings 
on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
re-writable, or tape or any other storage device? Not very much I would 
argue.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Jason Zions wrote:

>    So if I sell (at a profit) a netnews feed to subscribers via modem, it
>    is not copyright infringement, but if I sell the same data on a CDROM,
>    you cliam copyright infringement.
> 
> Yep. When you're providing a netnews feed, you're acting as a node in a
> store-and-forward network. A CD-ROM is not a part of a store-and-forward
> network; it is a permanently fixed repository of information. You can't hold
> up a netnews feed in a courtroom and point at it saying "there it is"; you
> *can* do so with a CD-ROM.
> 
>    So I suppose you want to give some
>    kind of list of what types of media are acceptable for transmitting
>    netnews feeds, and which are not?
> 
> A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently
> fixed copy of the contents of such a feed. Static versus dynamic; permanent,
> ephemeral. Is this hard to understand?
> 
>    The plain and simple fact is: When you post a message to usenet, you do
>    so with the expectation that others will receive it.  You can have no
>    way of knowing or limiting who may get it; that is given by the nature
>    of the network.  Usenet news is, and is intended to be, publicly
>    accessable information.  If there is something you don't want
>    distributed, then DON'T POST IT!
> 
> Learn a little about law; while you're at it, learn a little about usenet.
> When you post a message to usenet, you have tossed it into a flood-routed
> store-and-forward network. You implicitly give permission for copying
> appropriate to the propagation of messages in that network. You neither
> grant permission nor withhold permission for Fair Use. Everything else,
> though, is not granted unless explicitly granted.
> 
> If I post a message, under the terms of the Berne Convention and current US
> copyright law, a recipient was not granted the right to print a copy and
> publish it in a book. What makes you think I granted them permission to
> publish a copy in a CD-ROM? The only permission I granted was that they
> could (a) read it and (b) forward it via usenet protocols.
> 
> Jason
> 






From wex at media.mit.edu  Tue Feb  1 09:35:27 1994
From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat)
Date: Tue, 1 Feb 94 09:35:27 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011704.AA13796@jazz.hal.com>
Message-ID: <9402011731.AA09417@media.mit.edu>


> Are you arguing that email is not concrete?

Ayup.  If it was, we wouldn't need digital signatures on clear-text msgs,
no?

Mike Godwin says it's clear to him; I'd say that he represents a vanguard of
progressive thinkers applying the law to new areas.  I'd also bet that
vanguard is about a 10% minority at the moment.

--Alan






From ravage at wixer.bga.com  Tue Feb  1 09:40:35 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Tue, 1 Feb 94 09:40:35 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011530.AA13741@jazz.hal.com>
Message-ID: <9402011727.AA04285@wixer>


>
>
>    I would be interested in a discussion on the mail-list on this
>    issue. Please refrain from sending personal mail. In particular do you
>    think such a archive without every members permission is un-ethical?
>
> Unethical, hell; illegal is closer to it. I retain the copyright to
> everything I post; although implicit permission to redistribute to the
> mailing list is granted when I send to cypherpunks at toad.com, I have granted
> no permission to anyone else to use my intellectual property (i.e. my posts,
> valuable or not) for any other purpose.
>
>    Would a archivist necessarily need the permission of the mail-list
>    sponser?
>
> In an actively-moderated group (i.e. where the moderator chooses which
> messages to forward, constructs digests, etc.) the moderator possesses a
> copyright on the collection of material (but not on the material itself); if
> you were republishing a substantial part of the collection (in your case,
> all of it) you'd need rights to the collection copyright also.
>
> Study copyright law (including the Berne Convention, to which most nations
> having Usenet sites are signatories). Understand what you're getting
> yourself into.
>
> Jason
>

It is no more illegal (at the present time) for me to store your posting to
every usenet or inet service that I have access to on my hard-drive or a CD-
Rom for re-sale than it is for you to store my posting on your drive or print
it out to the printer.

When I got my account I did not sign any kind of agreement relating to me
retaining my rights to any material I chose to place on the net for
dissimenation to others. There IS an implied motivation to put that material
in the public domain so that others may use it for the betterment of all.

If you are serious about your view then please forward a money order for
$1000 dollars for having my original post stored on whatever medium you used
to reply to it.

There is no legal precedence at this time that would necessarily and
automaticaly copyright every entry I (or you) made, Berne not withstanding,
to inet or usenet. If that position is valid then each and every one of us is
commiting copyright infringement for storing the material on a hard drive.
When discussing copyright there is no involvment in medium of transmission
other than what the original author limits it to prior to release of that
material.

The motivation for bringing this topic up is that it provides a perfect way
to make the commen wide-spread usage of encryption a commen and everyday
occurance. Namely, authors who wish to retain all rights should do one of two
things. They should either encrypt the file and require potential users to
contact the author or distributor for keys to unlock it or else it should be
mandator for a author to put some sort of fair-use statement in their
releases that specificly delineates what the fair-use of that material is.
Users of usenet/inet do not read minds and can't necessarily imply what the
original motivation was, this means (to me anyway) that the responsibility of
enlightening potential users falls solely on the shoulders of the author.






From jazz at hal.com  Tue Feb  1 09:45:28 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 09:45:28 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011731.AA09417@media.mit.edu>
Message-ID: <9402011742.AA00212@jazz.hal.com>


>> Are you arguing that email is not concrete?
>
>Ayup.  If it was, we wouldn't need digital signatures on clear-text msgs,
>no?

Not the point; "concrete" does not mean immutable. If it did, then things
written in pencil, or eraseable ink, or created in mutable media (videotape,
audio tape, ...) would not be copyrightable either.

Jason





From pdn at dwroll.dw.att.com  Tue Feb  1 09:50:35 1994
From: pdn at dwroll.dw.att.com (Philippe Nave)
Date: Tue, 1 Feb 94 09:50:35 PST
Subject: Matsui-san Attack
In-Reply-To: <9401312111.AA15451@atlanta.wti.com>
Message-ID: <9402011745.AA19697@toad.com>


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

buckley at wti.com writes :
> 
> [continuing thread on ease of cracking DES/PEM]
> 
> Using a comparable breaker on the average machine, it is going
> to take two years to "break the scheme".
> That leaves two years to create stronger/tighter strategies.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Concerns about the validity about the 'two years' figure aside, does this
really 'leave you two years?' The technology to store messages (even ones
currently uncrackable) has been online for years already- unless your 
encrypted data is such that you don't mind having it examined by anybody
with a DES cracker, you are already at risk. In terms of careers, legal
action, and politics, a two-year event horizon is negligible. As advances
in computer power continue, the 'two-year' figure will continue to shrink.

Taking the long view, I view the PEM/DES debate as virtually identical to
the Clipper debate; Clipper's 'trap door' mindset is more overt, but getting
everbody involved in PEM/DES when the cracking technology is clearly in 
sight is no better.

- -- 
........................................................................
Philippe D. Nave, Jr.   | The person who does not use message encryption
pdn at dwroll.dw.att.com   | will soon be at the mercy of those who DO...
Denver, Colorado USA    | PGP public key: by arrangement.

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU6UHwvlW1K2YdE1AQGG4gQAqM+LthMCzEo3T2O+fLhKih8uNYUoHhvK
6zvDWjW2PW/t/N7TdWpA2oJ2dVmpABa3ENeNvju0qrEW91CVoU5JwBMHiCxSTrOn
wtK4fcQ7m+GBvvoLO6WW5tr+FZcVluzZbJrIcnaLQVWqP/P5Bmfjspd/GfROAduX
/oR4u9pFSvk=
=O5HV
-----END PGP SIGNATURE-----




From jazz at hal.com  Tue Feb  1 09:55:27 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 09:55:27 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011100.A29594-0100000@netcom8>
Message-ID: <9402011752.AA00225@jazz.hal.com>



> Furthermore, just because something is forwarded and something is archived
>I don't believe is expressly covered in copyright law.

It's not the forwarding or the archiving that makes anything covered by
copyright law; it is the setting down, in concrete form, the expression of
an idea.

> Others could argue that postings by their very nature, when posted 
>become "public domain", and thus not copyrightable.

Not successfully in court, I should think. How is a posting any different
than the production of a radio program which is distributed by
store-and-forward satellite distribution and then played through the radio
station and received at your home radio? The mechanisms are close to
identical in their attributes; tapes at the stations have some lifetime,
timeshifting can occur, special equipment is needed to perceive the work,
etc.

>Finally what is the tangible difference between storing usenet postings 
>on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
>re-writable, or tape or any other storage device? Not very much I would 
>argue.

If you were a ligitimate recipient of the work in the first place (i.e. got
it in a newsfeed) and you store those postings for your own use or for the
use of others on that node in the store-and-forward network, then you can
keep the work 'til the bits rot. Infringement occurs when you copy those
bits onto some medium for some purpose other than store-and-forward
propagation or the allowed fair-use exceptions; stuffing articles on a
CD-ROM and selling them falls into neither category and hence is an
infringement.

Jason





From ravage at wixer.bga.com  Tue Feb  1 10:00:34 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Tue, 1 Feb 94 10:00:34 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011704.AA13796@jazz.hal.com>
Message-ID: <9402011744.AA06092@wixer>


>
> Alan -
>
>   - Not at all clear that Berne applies to electronic mail, even of a
>     personal nature
>
> Copyright exists from the moment the work is set down in concrete form. Are
> you arguing that email is not concrete?
>
>    - Not at all clear that postings to a publicly-read list like this
>      are not equivalent to speech in a public place (ie not necessarily
>      copyrighted)
>
> Ah. The old "if the NFL has to remind us that its broadcast of the superbowl
> is copyrighted, so do you" argument.
>
> Okay, let's try this on for size.
>
> Copyright 1994 Jason Zions. Permission to copy and transmit for the purpose
> of propagation of the Cypherpunks mailing list in email or local-newsgroup
> (usenet) forms is granted; all other rights are reserved.
>
>    - Not at all clear what the status of private communications is vis
>      a vis publication.
>
> But this isn't private communication.
>
>    You can't just wave your hand and say the magic word "Berne" and thereby
>    prevent someone from archiving, reposting etc your messages to this list.
>
> Law is a complex thing, isn't it. I'd better go back and reread the code and
> current decisions. I'm spending more of my time tracking the CompuServe MIDI
> copyright actions, though.
>
> Jason
>

I have to admit that I have broken your fair use copyright notice
inadvertantly.

I have stored an image of your message in the ram on my system which is not a
part of inet or usenet nor involved in any way with the transmission to other
nodes of such stored material.

Berne works great for paper, audio recordings, movies, etc. It does not work
for networked information transmission.






From ravage at wixer.bga.com  Tue Feb  1 10:00:36 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Tue, 1 Feb 94 10:00:36 PST
Subject: archiving on inet
In-Reply-To: <9402011734.AA00188@jazz.hal.com>
Message-ID: <9402011745.AA06230@wixer>


>
> Jim -
>
> >Where is this agreement that it is ok to distribute material through a 'stor
e-
> >and-forward' network stated in the copyright law? I would be very interested

> >in the proviso that exempts such networks from liability.
>
> It's not embedded in the law; as I said, it's an implicit permission I grant
> when I post a message to such a network. Just as, when you buy a program on
> a floppy disk, you are implicitly granted the right to copy it from the disk
> into your computer's memory in order to run it: the nature of the work
> requires that specific type of copying. There's nothing new there.
>
> >The bottem line is that when I got my feed I was not asked to sign any kinjd

> >of waiver releasing any material that I generate from copyright infringement

> >as long as it was on a hard drive (or any other media). I did not sign any
> >kind of contract at all as a matter of fact. Legaly I still retain my right
> >of copyright on every bit on every drive (whether magnetic or otherwise) in
> >the internet and even your personal drive if you transfer the mail and other

> >material to it for offline processing.
>
> One more time. The nature of the work and your chosen distribution medium
> (netnews) requires a variety of copying for it to work: store-and-forward
> for propagation, copying into the memory of my system and onto my screen so
> I can read it. You grant permission to do that implicitly when you make the
> work available by that mechanism.
>
> Once I have received the copy you have implicitly authorized me to have,
> what I can *do* with that copy is governed by the Copyright Act and its fair
> use exemptions. I can use it for purposes of scholarship (i.e. I can keep it
> in an online or paper folder and refer to it later) and I can excerpt pieces
> for critique, among other things.  What I *cannot* do is redistribute it by
> any other mechanisms and for any purpose other than your initial netnews
> distribution.
>
> I have spent a lot of time studying this part of the law. Really. I already
> heeded my glib advice about reading the damn copyright act. Have you?
>
> Jason
>

when I buy a software program the copyright notice specificaly states that I
am allowed to make copies for backup purposes. Some of them notices on high-
dollar packages even tell me how many I can keep and whether I can keep them
on a network or not.






From jimn8 at netcom.com  Tue Feb  1 10:05:28 1994
From: jimn8 at netcom.com (Jim Nitchals)
Date: Tue, 1 Feb 94 10:05:28 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011100.A29594-0100000@netcom8>
Message-ID: <199402011803.KAA11756@mail.netcom.com>


Kirk writes,

> 
> Dear Jason,
> 
> I don't think you are neccissarily correct about making an archive of the 
> usenet. You may be correct, but I don't believe this point has been 
> litigated yet. Furthermore, just because something is forwarded and 
> something is archived I don't believe is expressly covered in copyright 
> law. Others could argue that postings by their very nature, when posted 
> become "public domain", and thus not copyrightable. I practice law, but 
> am not a copyright/trademark specialist. Also, as was posted earlier 
> someone is already making an archive of the usenet. See earlier postings. 
> Finally what is the tangible difference between storing usenet postings 
> on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
> re-writable, or tape or any other storage device? Not very much I would 
> argue.

Let me argue against Usenet archiving on a different point.  Archiving
violates the poster's implicit right to cancel or provide an expiration
date for his posting.

Do Usenet archivers provide a revised CD-ROM with the cancelled posts
removed on a regular basis, and ensure the original disks are returned?
Without such a guarantee, the owners of those messages aren't able to
exercise reasonable control over the messages.

There's a clear harm done when a cancel message isn't honored in this
situation: a potential employer may see a message written in anger or
the author was in an exceptionally bad state of mind, yet the author
(responsibly) sent out a cancel message just after the CD-ROM happened
to be pressed.

A second-hand copy of such an incriminating message is hearsay, and
should rightfully be considered with suspicion by a potential employer,
but a Usenet CD-ROM carries considerably more weight.

I'm not a lawyer, but it *seems* to me that when you publish a message
from a set of newsgroups containing a 'control' group that allows
retraction of messages, you're agreeing to honor those retractions when
they're issued by the original poster.  If that's not obvious enough,
when a message contains an expiration date, the author CLEARLY has a
reasonable expectation of having it honored.  I'd go further and say
there's a strongly implied agreement that says, "if you want to use
and republish this information, you must honor my expiration date."

Most of us have special words for someone who refuses to honor such
an implied agreement, even if it's made void by the message being
considered "in the public domain."

> 
> Kirk Sheppard
> 
> kshep at netcom.com
> 




From jazz at hal.com  Tue Feb  1 10:10:36 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 10:10:36 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011727.AA04285@wixer>
Message-ID: <9402011809.AA00254@jazz.hal.com>


>If you are serious about your view then please forward a money order for
>$1000 dollars for having my original post stored on whatever medium you used
>to reply to it.

Sigh. One more time.

The courts have recognized that permission to make copies which are
essential for the perception of the work is implicitly granted by the
copyright owner when the work is distributed. In order to perceive your
copyrighted works my system *must* make a copy or three to get it to me (as
would intervening systems if we both lived on uucp links instead of
internet). This is relatively old ground that was plowed by computer cases;
the exact issue of having to load a copy of a program into ram in order to
execute it has indeed been the subject of litigation.

The quote from your message I include above falls under the Fair Use
exceptions, under both Scholarship and Criticism.

>There is no legal precedence at this time that would necessarily and
>automaticaly copyright every entry I (or you) made, Berne not withstanding,
>to inet or usenet. [...] When discussing copyright there is no involvment in
>medium of transmission other than what the original author limits it to
>prior to release of that material.

But this is *precisely* what the current law says. From the moment the work
exists in concrete form, and a posting *is* concrete form, copyright exists.
Usenet and Internet are merely distribution mechanisms, the use of which may
cause the copyright holder to implicitly grant certain rights (as described
above).

>From another message:

>when I buy a software program the copyright notice specificaly states that I
>am allowed to make copies for backup purposes. Some of them notices on high-
>dollar packages even tell me how many I can keep and whether I can keep them
>on a network or not.

Yep. Backups are separate from implicit rights granted due to the medium of
expression; I'm not sure what this has to do with anything, except that
there is a recognized right for you to make a backup of your usenet news
archives. But you can't distribute that backup.

>From yet another message:

>I have to admit that I have broken your fair use copyright notice
>inadvertantly.
>
>I have stored an image of your message in the ram on my system which is not a
>part of inet or usenet nor involved in any way with the transmission to other
>nodes of such stored material.

You can't perceive the work without loading it into some device that can
turn electrical signals into something perceivable by a human; ram on a
computer is as good as anything else. As I stated above, this has been
covered by case law; it's a copy necessary to the perception of the work.
(The identical case arises with CDs - the bits are copied into a buffer in
your CD-player before they're fed through the D/A converters. This copy is
necessary to perceiving the work and hence permission is implicitly
granted.)

Jason





From kshep at netcom.com  Tue Feb  1 10:20:35 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 10:20:35 PST
Subject: archiving on inet
In-Reply-To: <9402011752.AA00225@jazz.hal.com>
Message-ID: <Pine.3.85.9402011327.A13472-0100000@netcom8>


Usenet copyrightable? I still doubt it. Of course, the only way to 
find out is to file a very expensive lawsuit. Most posters would not find 
their postings worth the expense to sue on copyright. Only a very rich 
dilletante, or someone less rich who is a fanatic on the subject is 
likely to do so.  Also, you would have a hard time answering the 
difference between charging for a usenet feed and charging for a cd-rom, 
again I see little difference except that one is more prompt in time than 
the other. But, again, my newsfeed from a BBS which might be 24 hrs 
delayed, and my netcom account which is much faster and a cd-rom differs 
only as to time removed from the original posting. 

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Jason Zions wrote:

> 
> > Furthermore, just because something is forwarded and something is archived
> >I don't believe is expressly covered in copyright law.
> 
> It's not the forwarding or the archiving that makes anything covered by
> copyright law; it is the setting down, in concrete form, the expression of
> an idea.
> 
> > Others could argue that postings by their very nature, when posted 
> >become "public domain", and thus not copyrightable.
> 
> Not successfully in court, I should think. How is a posting any different
> than the production of a radio program which is distributed by
> store-and-forward satellite distribution and then played through the radio
> station and received at your home radio? The mechanisms are close to
> identical in their attributes; tapes at the stations have some lifetime,
> timeshifting can occur, special equipment is needed to perceive the work,
> etc.
> 
> >Finally what is the tangible difference between storing usenet postings 
> >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
> >re-writable, or tape or any other storage device? Not very much I would 
> >argue.
> 
> If you were a ligitimate recipient of the work in the first place (i.e. got
> it in a newsfeed) and you store those postings for your own use or for the
> use of others on that node in the store-and-forward network, then you can
> keep the work 'til the bits rot. Infringement occurs when you copy those
> bits onto some medium for some purpose other than store-and-forward
> propagation or the allowed fair-use exceptions; stuffing articles on a
> CD-ROM and selling them falls into neither category and hence is an
> infringement.
> 
> Jason
> 






From lefty at apple.com  Tue Feb  1 10:45:27 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 10:45:27 PST
Subject: archiving on inet
Message-ID: <9402011838.AA12820@federal-excess.apple.com>


Kirk Sheppard asks
>
>Finally what is the tangible difference between storing usenet postings 
>on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
>re-writable, or tape or any other storage device? Not very much I would 
>argue.

I don't believe that _storage_ is the issue at all.  If I purchase a copy
of a book, I don't believe that I'm violating copyright by making an
archival copy of it _for_ _my_ _own_ _use_.

If I start distributing or selling copies to other people, however, that's
a different matter.

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From m5 at vail.tivoli.com  Tue Feb  1 11:00:37 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Tue, 1 Feb 94 11:00:37 PST
Subject: archiving on inet
In-Reply-To: <199402011803.KAA11756@mail.netcom.com>
Message-ID: <9402011857.AA07465@vail.tivoli.com>



Jim Nitchals writes:
 > Let me argue against Usenet archiving on a different point.  Archiving
 > violates the poster's implicit right to cancel or provide an expiration
 > date for his posting.

"Implicit right to cancel"?  Where'd that come from?

 >         a potential employer may see a message written in anger or
 > the author was in an exceptionally bad state of mind...

There's a poem by Carl Sandburg with some relevance to this.  I don't
see why the feature of cancel messages (which aren't guaranteed to
work anyway) carries with it a new right.

 > I'm not a lawyer, but it *seems* to me that when you publish a message
 > from a set of newsgroups containing a 'control' group that allows
 > retraction of messages, you're agreeing to honor those retractions when
 > they're issued by the original poster.  

I am perfectly free to implement my own news system and mailer that
does not honor cancel messages.  What authority would force me to do
so if I don't want to?

 > when a message contains an expiration date, the author CLEARLY has a
 > reasonable expectation of having it honored.  

Why?  Does he have an equally clear right to expect that the message
does not get deleted before then?

 > I'd go further and say
 > there's a strongly implied agreement that says, "if you want to use
 > and republish this information, you must honor my expiration date."

This seems pretty specious to me.

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From mnemonic at eff.org  Tue Feb  1 11:10:37 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 11:10:37 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011327.A13472-0100000@netcom8>
Message-ID: <199402011902.OAA09623@eff.org>


 
Kirk Sheppard writes:

> Usenet copyrightable? I still doubt it.

You shouldn't. Usenet postings are copyrighted the moment they are
instantiated in a tangible medium.


--Mike







From cknight at crl.com  Tue Feb  1 11:15:29 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 11:15:29 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011100.A29594-0100000@netcom8>
Message-ID: <Pine.3.87.9402011111.A18730-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> law. Others could argue that postings by their very nature, when posted 
> become "public domain", and thus not copyrightable. I practice law, but 

If I use your logic, a published article in a magazine becomes public domain 
because it has become available to a large number of subscribers.


> Finally what is the tangible difference between storing usenet postings 
> on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
> re-writable, or tape or any other storage device? Not very much I would 
> argue.

Tangible difference...  Lets see...  A CD-ROM can be duplicated and sold 
for profit, and doing so with net archives violates the copyrights of any 
message author who cares to file class action or personal...  Who did you 
say had that archive, and were they selling it?

-ck







From cknight at crl.com  Tue Feb  1 11:25:29 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 11:25:29 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011727.AA04285@wixer>
Message-ID: <Pine.3.87.9402011155.A18730-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Jim choate wrote:

> It is no more illegal (at the present time) for me to store your posting to
> every usenet or inet service that I have access to on my hard-drive or a CD-
> Rom for re-sale than it is for you to store my posting on your drive or print
> it out to the printer.

I think the question of storage goes beyond copyright law.  I have yet to 
find someone who lost a suit for owning a copy of a magazine.  But since 
you feel the way you do about CDs, why don't you scan in a couple of 
issues of Life magazine, master it, and try to sell it?  Do they supply 
Inet feeds in prison?

> 
> When I got my account I did not sign any kind of agreement relating to me
> retaining my rights to any material I chose to place on the net for
> dissimenation to others. 

Have you ever published an article in say a not-for profit journal?  Just 
because you don't sine a contract guaranteeing your rights DOES NOT mean 
you have given them up!

There IS an implied motivation to put that material

> If you are serious about your view then please forward a money order for
> $1000 dollars for having my original post stored on whatever medium you used
> to reply to it.

Now that you have set your rate, I set mine.  Please remit your check of 
$10,000....  I think this is getting a bit carried away.  Copyright cases 
generally relate to the sale or use of material belonging to an author.  
As I said above, I have never heard of a case where someone lost a suit 
for posessing a 1942 issue of Life magazine.



-ck


The material in this message composed by me, lines NOT preceeded by the 
">", is expressly copyrighted as the posession of Chris Knight.  You may 
reply to this message, forward this message, and store it for PRIVATE 
use.  Any attempt to sell this material either alone, or as part of an 
archive will be met by me, at you backdoor, late at night, with a chaninsaw.
I have the DOOM cheats!  I am invincible!   ;>

p.s.  The above bit of humor is copyrighted 1994, cmk.






From cknight at crl.com  Tue Feb  1 11:30:37 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 11:30:37 PST
Subject: Archiving mail-lists...
In-Reply-To: <9402011744.AA06092@wixer>
Message-ID: <Pine.3.87.9402011116.A18730-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Jim choate wrote:

> I have to admit that I have broken your fair use copyright notice
> inadvertantly.
> 
> I have stored an image of your message in the ram on my system which is not a
> part of inet or usenet nor involved in any way with the transmission to other
> nodes of such stored material.

Are you claiming to have sold your RAM, while still powered, for a 
profit?  Knowing that it contained copyrighted work?  Shame on you.


> Berne works great for paper, audio recordings, movies, etc. It does not work
> for networked information transmission.

I'm sorry, I didn not realize I was talking to a supreme court justice.  
Had I known you had the ultimate authority on this subject, I would not 
have been wasting your time, or mine.

Perhaps we should try this.  You sell archives of the net, and we'll file 
a class action suit...  I'll back up my beliefs with actions, how about you?


-ck







From kshep at netcom.com  Tue Feb  1 11:30:39 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 11:30:39 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.87.9402011111.A18730-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011400.A27297-0100000@netcom9>


Regarding the archive I believe it was some company in Canada, I'm not 
sure. There was a thread about this archiving question on another group I 
suppose in the last three weeks. I can't remember where I saw it, if it 
wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the 
usenet feed, and none of us who post are getting royalty payments from 
any of the internet providers. So answer the question again, what is the 
difference in paying an internet provider for access to usenet, and 
paying a cd-rom provider for access to usenet? None materially, except 
that the cd is not interactive, and some providers are (not all as in 
bbs' that don't send e-mail to the internet, but have some usenet 
groups.) There is no material difference that I can determine.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Kirk Sheppard wrote:
> 
> > law. Others could argue that postings by their very nature, when posted 
> > become "public domain", and thus not copyrightable. I practice law, but 
> 
> If I use your logic, a published article in a magazine becomes public domain 
> because it has become available to a large number of subscribers.
> 
> 
> > Finally what is the tangible difference between storing usenet postings 
> > on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
> > re-writable, or tape or any other storage device? Not very much I would 
> > argue.
> 
> Tangible difference...  Lets see...  A CD-ROM can be duplicated and sold 
> for profit, and doing so with net archives violates the copyrights of any 
> message author who cares to file class action or personal...  Who did you 
> say had that archive, and were they selling it?
> 
> -ck
> 
> 
> 






From kshep at netcom.com  Tue Feb  1 11:35:36 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 11:35:36 PST
Subject: archiving on inet
In-Reply-To: <9402011838.AA12820@federal-excess.apple.com>
Message-ID: <Pine.3.85.9402011445.A27297-0100000@netcom9>


This book analogy is not accurate. It is my contention that usenet 
postings are not copyrighted. Our postings are not disseminated like a 
book, we are paid nothing for the use of our postings on the multitude 
of machines that our postings appear. Or, in the alternative, if 
copyrighted, by posting them in the electronic ether, we give up most of 
our rights regarding dissemination, copying etc. Perhaps we may still 
have some residual rights regarding accuracy and the like. Also the 
posting regarding the legal blurbs on software, really was off point, 
since what they they were refering to was a "license", and again there is 
some doubt about how enforceable the individual licenses that the 
software companies give. That is, some of these licenses may have 
provisions that are not enforceable.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Lefty wrote:

> Kirk Sheppard asks
> >
> >Finally what is the tangible difference between storing usenet postings 
> >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is 
> >re-writable, or tape or any other storage device? Not very much I would 
> >argue.
> 
> I don't believe that _storage_ is the issue at all.  If I purchase a copy
> of a book, I don't believe that I'm violating copyright by making an
> archival copy of it _for_ _my_ _own_ _use_.
> 
> If I start distributing or selling copies to other people, however, that's
> a different matter.
> 
> --
> Lefty (lefty at apple.com)
> C:.M:.C:., D:.O:.D:.
> 
> 
> 






From lefty at apple.com  Tue Feb  1 11:45:27 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 11:45:27 PST
Subject: archiving on inet
Message-ID: <9402011948.AB17603@federal-excess.apple.com>


>Usenet copyrightable? I still doubt it. Of course, the only way to 
>find out is to file a very expensive lawsuit. Most posters would not find 
>their postings worth the expense to sue on copyright. Only a very rich 
>dilletante, or someone less rich who is a fanatic on the subject is 
>likely to do so.  Also, you would have a hard time answering the 
>difference between charging for a usenet feed and charging for a cd-rom, 
>again I see little difference except that one is more prompt in time than 
>the other. But, again, my newsfeed from a BBS which might be 24 hrs 
>delayed, and my netcom account which is much faster and a cd-rom differs 
>only as to time removed from the original posting. 

So, would you argue, on the same grounds, that you didn't believe that a
movie delivered into your home via a cable feed could be copyrighted?

How about a movie on a laser disk?

Do you understand that there's is a difference between personal use, which
does not infringe copyright, and redistribution, which does?

Are you _sure_ you're an attorney?

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From dwomack at runner.utsa.edu  Tue Feb  1 11:50:36 1994
From: dwomack at runner.utsa.edu (David L Womack)
Date: Tue, 1 Feb 94 11:50:36 PST
Subject: PGP
Message-ID: <9402011949.AA18718@runner.utsa.edu>


I was wondering if anyone has an answer to
a question on PGP....

About how many calculations does it take
to crack a 1024 bit key?  If someone
has limitless time, money, etc., they
can break it...but how many calculations
does it take?

Also, there is a password used to protect
the keyrings.  Assuming a strong password
how many calculations does that take to
break?

If there isn't some special method, an
assumption that leads nowhere, just how
much "brute force" effort is really required?

Thanks, Dave




From cknight at crl.com  Tue Feb  1 11:55:28 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 11:55:28 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011400.A27297-0100000@netcom9>
Message-ID: <Pine.3.87.9402011113.A18730-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> Regarding the archive I believe it was some company in Canada, I'm not 
> sure. There was a thread about this archiving question on another group I 
> suppose in the last three weeks. I can't remember where I saw it, if it 
> wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the 
> usenet feed, and none of us who post are getting royalty payments from 
> any of the internet providers. So answer the question again, what is the 
> difference in paying an internet provider for access to usenet, and 
> paying a cd-rom provider for access to usenet? None materially, except 
> that the cd is not interactive, and some providers are (not all as in 
> bbs' that don't send e-mail to the internet, but have some usenet 
> groups.) There is no material difference that I can determine.

I'm just glad you are not a politician.

If all you are concerned with is "Material differnce", then you think 
it's perfectly ok for me to sell you a good copy of a magazine?  By your 
"logic" (loosely used), you had to pay for the copy, and you had to pay 
for the original, so what's the difference?  The difference is the WILL 
AND PERMISSION of the author!  As the author of this message, I willingly 
placed it within the net.  I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION 
TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK.

The basis of copyright law is the protection of the author's rights.  One 
of these rights is the choice of distribution.

Perhaps you should try writing for money sometime.  You might actually 
appreciate what you seem to be trying to tear apart.


-ck






From talon57 at well.sf.ca.us  Tue Feb  1 11:55:38 1994
From: talon57 at well.sf.ca.us (Brian D Williams)
Date: Tue, 1 Feb 94 11:55:38 PST
Subject: clipper petition
Message-ID: <199402011952.LAA01629@well.sf.ca.us>



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

CPSR sends:

                Electronic Petition to Oppose Clipper  
                      Please Distribute Widely

>On January 24, many of the nation's leading experts in
>cryptography and computer security wrote President Clinton and
>asked him to withdraw the Clipper proposal.
  
>The public response to the letter has been extremely favorable,
>including coverage in the New York Times and numerous computer and
>security trade magazines.

>Many people have expressed interest in adding their names to the
>letter.  In  response to these requests, CPSR is organizing an
>Internet petition drive to oppose the Clipper proposal.  We will
>deliver the signed petition to the White House, complete with the
>names of all the people who oppose Clipper.

>To sign on to the letter, send a message to:

     Clipper.petition at cpsr.org

>with the message "I oppose Clipper" (no quotes)

>You will receive a return message confirming your vote.


- From noclipr at snyside.sunnyside.com Tue Feb  1 08:39:20 1994
Date: Tue, 1 Feb 1994 08:39:14 -0800
From: clipper.petition at snyside.sunnyside.com (via CPSR automation)
Subject: Your petition regarding opposition to Clipper
Apparently-To: Brian D Williams <talon57 at well.sf.ca.us>

Your name has been added to the petition asking President Clinton
to withdraw the Clipper proposal.

We will deliver the signed petition to the White House at the end
of the project. If you have any comments or questions, please email
us at clipper at washofc.cpsr.org.



  "We have not yet begun to Encrypt!!"



Brian Williams
Extropian
Cypherpatriot

"Cryptocosmology: Sufficently advanced comunication is
                  indistinguishable from noise." --Steve Witham
 
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU6xXtCcBnAsu2t1AQHs8wP/cpftWyNnUtvEBcp5SuY/YR9h45DO/W7H
VlgiVXf/aiOULr0dCMgJdu5BhoeV/C6MXEP0xfPNPSsk4JbpO2bn0yfcDLT69heU
9dGPE1ygVZsX4bOesk8s9eTaE+vSGpQcHXaotGrTWXo5Zsi7SFqdhraJEXFx9wnb
g6lln31WF1A=
=O1C5
-----END PGP SIGNATURE-----






From kshep at netcom.com  Tue Feb  1 12:05:27 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 12:05:27 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.87.9402011113.A18730-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011412.A29897-0100000@netcom9>


Dear Mr. Knight,

I am not interested in "tearing apart" anything, I was just participating 
in a discussion. Ad hominem attacks are really unjustified. Even though 
you have a hard time understanding my arguments, I have refrained from 
calling you stupid, until now. You are not only stupid, but silly. "I'm 
glad your're not a politician" is a non-sequitur, and is certainly 
irrelevant to the discussion. Further, this whole discussion is entirely 
"academic", since there is absolutely no case law on this particular 
subject. So if you are so excited about it, collect your pennies and hire 
an attorney to enforce your copyright, I'm sure my brethern could use the 
business.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Kirk Sheppard wrote:
> 
> > Regarding the archive I believe it was some company in Canada, I'm not 
> > sure. There was a thread about this archiving question on another group I 
> > suppose in the last three weeks. I can't remember where I saw it, if it 
> > wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the 
> > usenet feed, and none of us who post are getting royalty payments from 
> > any of the internet providers. So answer the question again, what is the 
> > difference in paying an internet provider for access to usenet, and 
> > paying a cd-rom provider for access to usenet? None materially, except 
> > that the cd is not interactive, and some providers are (not all as in 
> > bbs' that don't send e-mail to the internet, but have some usenet 
> > groups.) There is no material difference that I can determine.
> 
> I'm just glad you are not a politician.
> 
> If all you are concerned with is "Material differnce", then you think 
> it's perfectly ok for me to sell you a good copy of a magazine?  By your 
> "logic" (loosely used), you had to pay for the copy, and you had to pay 
> for the original, so what's the difference?  The difference is the WILL 
> AND PERMISSION of the author!  As the author of this message, I willingly 
> placed it within the net.  I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION 
> TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK.
> 
> The basis of copyright law is the protection of the author's rights.  One 
> of these rights is the choice of distribution.
> 
> Perhaps you should try writing for money sometime.  You might actually 
> appreciate what you seem to be trying to tear apart.
> 
> 
> -ck
> 
> 






From kshep at netcom.com  Tue Feb  1 12:15:29 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 12:15:29 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.87.9402011116.A18730-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011524.A29897-0100000@netcom9>


Master Knight does seem a bit intolerant, doesn't he?

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Jim choate wrote:
> 
> > I have to admit that I have broken your fair use copyright notice
> > inadvertantly.
> > 
> > I have stored an image of your message in the ram on my system which is not a
> > part of inet or usenet nor involved in any way with the transmission to other
> > nodes of such stored material.
> 
> Are you claiming to have sold your RAM, while still powered, for a 
> profit?  Knowing that it contained copyrighted work?  Shame on you.
> 
> 
> > Berne works great for paper, audio recordings, movies, etc. It does not work
> > for networked information transmission.
> 
> I'm sorry, I didn not realize I was talking to a supreme court justice.  
> Had I known you had the ultimate authority on this subject, I would not 
> have been wasting your time, or mine.
> 
> Perhaps we should try this.  You sell archives of the net, and we'll file 
> a class action suit...  I'll back up my beliefs with actions, how about you?
> 
> 
> -ck
> 
> 
> 






From jazz at hal.com  Tue Feb  1 12:25:27 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 12:25:27 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011400.A27297-0100000@netcom9>
Message-ID: <9402012021.AA01756@jazz.hal.com>


> So answer the question again, what is the 
>difference in paying an internet provider for access to usenet, and 
>paying a cd-rom provider for access to usenet?

It's the difference between listening to the radio yourself and buying a
home-made tape of the radio program from someone else. The first is legal;
the second is, generally, not.

Better yet, it's the difference between watching a program on HBO when you
are getting that service legally (i.e. paying for it) and buying a tape of
the same program from a friend who has HBO. Whether or not you also have
legal access to HBO, the sale of the tape infringes on the copyright of the
program.

Jason





From mccoy at ccwf.cc.utexas.edu  Tue Feb  1 12:25:40 1994
From: mccoy at ccwf.cc.utexas.edu (Jim McCoy)
Date: Tue, 1 Feb 94 12:25:40 PST
Subject: archiving on inet
In-Reply-To: <9402011752.AA00225@jazz.hal.com>
Message-ID: <199402012023.AA26109@tramp.cc.utexas.edu>


Jason Zions <jazz at hal.com> writes:
> 
> > Others could argue that postings by their very nature, when posted 
> >become "public domain", and thus not copyrightable.
> 
> Not successfully in court, I should think. How is a posting any different
> than the production of a radio program which is distributed by
> store-and-forward satellite distribution and then played through the radio
> station and received at your home radio? [...]

It is the difference between "broadcast" and "interactive communication."
Tell me, if I call in to the talk show you are distribute as part of your
radio program, do _I_ now own the copyright to a portion of your show?

> >Finally what is the tangible difference between storing usenet postings 
> >on [any particular storage media]
>
> If you were a ligitimate recipient of the work in the first place (i.e. got
> it in a newsfeed) and you store those postings for your own use or for the
> use of others on that node in the store-and-forward network, then you can
> keep the work 'til the bits rot. Infringement occurs when you copy those
> bits onto some medium for some purpose other than store-and-forward
> propagation or the allowed fair-use exceptions; stuffing articles on a
> CD-ROM and selling them falls into neither category and hence is an
> infringement.

Buzzz.  According to your logic all that one needs to do is to change the
label on the order from from "Usenet articles on CD-ROM" to "Quarterly
Usenet Feed distributed on CD-ROM" and I am in the clear.  I am not selling
a collectoin containing your articles, I am providing a low-bandwidth
newsfeed to those who do not have the same level of connectivity you have
or that want the excitement of seeing thier newsfeed delivered over the
"original information superhighway" (aka postal services.)  It is still
store-and-forward, it is just store-forever-and-forward-not-so-often.

But under all the smoke and mirrors nothing changes the fact that I am
selling archives of the Usenet.  No amount of puffed up indignation is
going to change the fact that your Usenet posting or message to a mailing
list is of no real value to you and is honestly as free as a bird once it
hits the wire.

jim




From pmetzger at lehman.com  Tue Feb  1 12:30:38 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 12:30:38 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.87.9402011113.A18730-0100000@crl.crl.com>
Message-ID: <199402012029.PAA03234@snark>



Chris Knight says:
> If all you are concerned with is "Material differnce", then you think 
> it's perfectly ok for me to sell you a good copy of a magazine?  By your 
> "logic" (loosely used), you had to pay for the copy, and you had to pay 
> for the original, so what's the difference?  The difference is the WILL 
> AND PERMISSION of the author!  As the author of this message, I willingly 
> placed it within the net.  I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION 
> TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK.

Try to sue for damages when your work is available for free to
millions of people. The judge will laugh in your face, copyright or
no. Damages are, after all, related to lost revenue -- if you allow
anyone who wants to see something for free in one medium, you will
have a fucking hard time to keep them from examining it in another
equivalent medium. Usenet is NOT a magazine. Failing to put a
copyright notice in your work destroys whats left of your ability to
do anything. I'm sure you can pay a lawyer to sue for you, but this
isn't exactly one anyone is going to take on contingency.

.pm





From nate at VIS.ColoState.EDU  Tue Feb  1 12:35:27 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Tue, 1 Feb 94 12:35:27 PST
Subject: new, improved remailer GUI
Message-ID: <9402012034.AA04618@vangogh.VIS.ColoState.EDU>


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



I have added some features to the remailer GUI I built in Mosaic.

It now has a radio button for choosing to use the CP remailers,
and toggle switches for selecting remailers.  It's also been moved,
and the old one is no longer there, so don't use it.

it's new location is:

http://monet.vis.colostate.edu/~nate/mailer.html

Give it a try, and tell me what you think.  BTW, this one is
fully open for business, so use it as much as you like!

- -nate

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From kshep at netcom.com  Tue Feb  1 12:35:39 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 12:35:39 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.87.9402011116.A18730-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011507.A5791-0100000@netcom9>


On Tue, 1 Feb 1994, Chris Knight wrote:

<Perhaps we should try this.  You sell archives of the net, and we'll file
<a class action suit...  I'll back up my beliefs with actions, how about you?
 

This appears to be merely hot air, since despite all his talk Master 
Knight hasn't taken any "action" and it is doubtful that he has the money 
or other "necessities" requisite for doing so. Also, notice the term 
"beliefs", which explains a lot. I thought were were having a discussion 
on a legal or academic basis, not one involving religeous or 
philosophical "beliefs" or faith.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Jim choate wrote:
> 
> > I have to admit that I have broken your fair use copyright notice
> > inadvertantly.
> > 
> > I have stored an image of your message in the ram on my system which is not a
> > part of inet or usenet nor involved in any way with the transmission to other
> > nodes of such stored material.
> 
> Are you claiming to have sold your RAM, while still powered, for a 
> profit?  Knowing that it contained copyrighted work?  Shame on you.
> 
> 
> > Berne works great for paper, audio recordings, movies, etc. It does not work
> > for networked information transmission.
> 
> I'm sorry, I didn not realize I was talking to a supreme court justice.  
> Had I known you had the ultimate authority on this subject, I would not 
> have been wasting your time, or mine.
> 
> Perhaps we should try this.  You sell archives of the net, and we'll file 
> a class action suit...  I'll back up my beliefs with actions, how about you?
> 
> 
> -ck
> 
> 






From jazz at hal.com  Tue Feb  1 12:35:41 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 12:35:41 PST
Subject: archiving on inet
In-Reply-To: <199402012023.AA26109@tramp.cc.utexas.edu>
Message-ID: <9402012033.AA01805@jazz.hal.com>


>It is the difference between "broadcast" and "interactive communication."
>Tell me, if I call in to the talk show you are distribute as part of your
>radio program, do _I_ now own the copyright to a portion of your show?

This is an interesting point of discussion. The question becomes one of
determining what the protected work is. Given that it is a call-in show, the
entire show would be a protected work and its copyright would belong to the
show's creator. I do not know if you retain copyright in the small part of
the work which represents your own intellectual property (i.e. what you
say), but I suspect it could be argued that you gave your permission to
broadcast your work when you called in to begin with. It gets murkier to me
with respect to compensation from the sale of transcripts or recordings.
Mike, is there case law here?

>But under all the smoke and mirrors nothing changes the fact that I am
>selling archives of the Usenet.  No amount of puffed up indignation is
>going to change the fact that your Usenet posting or message to a mailing
>list is of no real value to you and is honestly as free as a bird once it
>hits the wire.

We differ on the use of the word "honestly". In practice, enforcement is
well-nigh impossible; nonetheless, according to the letter of the law, my
words are my property to do with as I see fit. If I state that they may not
be recorded on optical media, the law requires you to honor that.

Jason

Copyright 1994 Jason Zions. Copying for the purpose of propagation of the
Cypherpunks mailing list in email or usenet news form is permitted, except
no copy shall be made in permanent optical storage media without the express
permission of the author. All other rights reserved.





From warlord at MIT.EDU  Tue Feb  1 12:45:27 1994
From: warlord at MIT.EDU (Derek Atkins)
Date: Tue, 1 Feb 94 12:45:27 PST
Subject: PGP
In-Reply-To: <9402011949.AA18718@runner.utsa.edu>
Message-ID: <9402012041.AA12750@toxicwaste.media.mit.edu>


Well, I don't know exactly how many calculations are necessary,
but I've seen some posts that have given general numbers...

Let me give some examples to try to answer your question.
Currently, we estimate about 2500 MIP-years have gone into
trying to factor RSA129 (about 425 bits).  We estimate we
are about 60% through... The whole project taking about 5000 
MIP-years.

Figure that every ten decimal digits adds one order of magnitude. 
So, a 512-bit (~155-digit) key would require about 5e7 MIP-years.  
And a 1024-bit key would require approximately 5e22 MIP-years.  
(These are approximations -- please do not quote these numbers).

Brute-forcing IDEA takes about as much computation as factoring
something between a 1200 and 3000 bit RSA key (I've heard both
numbers, but I don't know the numbers).  So, in the current
implementation, RSA is the weak link!

Since the passphrase is just a hash to an IDEA key, breaking the
secret ring is as hard as either dictionary attacking the key, or
breaking IDEA, which is harder than factoring the RSA key, given
current knowledge about the algorithms.

I hope this answers your questions.  If someone has real numbers
to put in here, please update mine!

-derek






From kshep at netcom.com  Tue Feb  1 12:45:39 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 12:45:39 PST
Subject: archiving on inet
In-Reply-To: <9402012021.AA01756@jazz.hal.com>
Message-ID: <Pine.3.85.9402011548.A5791-0100000@netcom9>


This is not an accurate comparison. A posting on usenet is not the same 
item as a program on HBO or the radio. In what way does my internet provider 
(netcom) have a "legal" distribution of usenet news, while a cd-rom 
provider does not? HBO has paid for the use of the programs it broadcasts 
that are produced by others, hence they have a contract between 
themselves and the owners of the copyright. No providers of usenet news 
have any agreements between themselves and the posters regarding 
copyrights. Netcom and all the other internet providers receive postings 
"free" and a cd-rom manufacturer has the same "right" to use postings as 
any other internet provider.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Jason Zions wrote:

> > So answer the question again, what is the 
> >difference in paying an internet provider for access to usenet, and 
> >paying a cd-rom provider for access to usenet?
> 
> It's the difference between listening to the radio yourself and buying a
> home-made tape of the radio program from someone else. The first is legal;
> the second is, generally, not.
> 
> Better yet, it's the difference between watching a program on HBO when you
> are getting that service legally (i.e. paying for it) and buying a tape of
> the same program from a friend who has HBO. Whether or not you also have
> legal access to HBO, the sale of the tape infringes on the copyright of the
> program.
> 
> Jason
> 






From cknight at crl.com  Tue Feb  1 13:05:28 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 13:05:28 PST
Subject: Why is Chris Knight a Twerp?
In-Reply-To: <Pine.3.85.9402011507.A29897-0100000@netcom9>
Message-ID: <Pine.3.87.9402011257.A2238-0100000@crl.crl.com>



It sure was short trip for you to go from person to prick.

My "attacks" have been on your logic.  Something that has always been a 
prime goal of a debate.  Lacking anything intellignet to say, you resort 
to the text quoted below, and your attempted personal slight of refering 
to me as "Master Knight" in your current posts.

Is there any chance that this will get back to the discussion at hand, or 
are you tired of this toy and trying to find something else to play with?

If all you have left is attacks, name calling, and rudeness, perhaps you 
should find other toys and leave the discussions to adults.

-ck

On 
Tue, 1 Feb 1994, Kirk Sheppard wrote:

> Dear Stupid,
> 
> Why you are intent on attacking me for no reason is beyond me. I didn't 
> attack you personally, what is the matter with you? Also I am not 
> interested in gratuitous advice regarding "trying to write sometime". I 
> can see why you might be bitter as you obviously lack the intelligence 
> and education to make much money writing. 
> 
> Kirk Sheppard
> 
> kshep at netcom.com
> 
> P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
> Bethesda, MD 20824-0911      Live On Your Knees."
> U.S.A.
> 			    			     - Emiliano Zapata
> 
> 
> 






From pmetzger at lehman.com  Tue Feb  1 13:05:39 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 13:05:39 PST
Subject: archiving on inet
In-Reply-To: <9402012021.AA01756@jazz.hal.com>
Message-ID: <199402012103.QAA03285@snark>



Jason Zions says:
> > So answer the question again, what is the 
> >difference in paying an internet provider for access to usenet, and 
> >paying a cd-rom provider for access to usenet?
> 
> It's the difference between listening to the radio yourself and buying a
> home-made tape of the radio program from someone else. The first is legal;
> the second is, generally, not.

The reason selling a tape of a radio show isn't legal is because then
you can play it as often as you like. On the other hand, usenet is
already distributed in a form that lets you read the messages as often
as you like. You can archive them forever, and in fact thats part of
the news software.

.pm





From kshep at netcom.com  Tue Feb  1 13:05:43 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 13:05:43 PST
Subject: archiving on inet
In-Reply-To: <9402011948.AB17603@federal-excess.apple.com>
Message-ID: <Pine.3.85.9402011555.A9978-0100000@netcom9>


Dear Master Lefty,

You too, have fallen into the same trap, as Master Knight, i.e.,  ad hominem 
attacks, unprovoked, launched merely because I disagree with you. As to 
your arguments, no I don't think you have followed my logic at all, and I 
certainly cannot follow or agree with your assertions. My point is that 
the redistribution of usenet postings by  Netcom, my local bbs, me on my 
hard disk to others for pay or not, or by cd-rom are not different and it 
is just as legal for Netcom to charge me for providing me a usenet feed 
as it is legal for a cd-rom manufacturer to do the same, neither is 
paying us a dime nor are they obligated to do so. Personal use is not at 
all relevant. Netcom, Delphi are copying and providing usenet newsfeeds 
as a commercial service, without paying any royalties to the authors of 
the usenet postings. And we can all do the same and use any medium we 
want to  whether you or Master Knight like it or understand it.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Lefty wrote:

> >Usenet copyrightable? I still doubt it. Of course, the only way to 
> >find out is to file a very expensive lawsuit. Most posters would not find 
> >their postings worth the expense to sue on copyright. Only a very rich 
> >dilletante, or someone less rich who is a fanatic on the subject is 
> >likely to do so.  Also, you would have a hard time answering the 
> >difference between charging for a usenet feed and charging for a cd-rom, 
> >again I see little difference except that one is more prompt in time than 
> >the other. But, again, my newsfeed from a BBS which might be 24 hrs 
> >delayed, and my netcom account which is much faster and a cd-rom differs 
> >only as to time removed from the original posting. 
> 
> So, would you argue, on the same grounds, that you didn't believe that a
> movie delivered into your home via a cable feed could be copyrighted?
> 
> How about a movie on a laser disk?
> 
> Do you understand that there's is a difference between personal use, which
> does not infringe copyright, and redistribution, which does?
> 
> Are you _sure_ you're an attorney?
> 
> --
> Lefty (lefty at apple.com)
> C:.M:.C:., D:.O:.D:.
> 
> 
> 






From mnemonic at eff.org  Tue Feb  1 13:10:40 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 13:10:40 PST
Subject: archiving on inet
In-Reply-To: <9402012033.AA01805@jazz.hal.com>
Message-ID: <199402012105.QAA11615@eff.org>


 
Jim writes:

> I do not know if you retain copyright in the small part of
> the work which represents your own intellectual property (i.e. what you
> say), but I suspect it could be argued that you gave your permission to
> broadcast your work when you called in to begin with. It gets murkier to me
> with respect to compensation from the sale of transcripts or recordings.
> Mike, is there case law here?

Not to my knowledge. But there's no disputing among lawyers that copyright
law applies.


--Mike







From kshep at netcom.com  Tue Feb  1 13:15:29 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 13:15:29 PST
Subject: archiving on inet
In-Reply-To: <199402012023.AA26109@tramp.cc.utexas.edu>
Message-ID: <Pine.3.85.9402011602.A9978-0100000@netcom9>


Well said, Jim.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Jim McCoy wrote:

> Jason Zions <jazz at hal.com> writes:
> > 
> > > Others could argue that postings by their very nature, when posted 
> > >become "public domain", and thus not copyrightable.
> > 
> > Not successfully in court, I should think. How is a posting any different
> > than the production of a radio program which is distributed by
> > store-and-forward satellite distribution and then played through the radio
> > station and received at your home radio? [...]
> 
> It is the difference between "broadcast" and "interactive communication."
> Tell me, if I call in to the talk show you are distribute as part of your
> radio program, do _I_ now own the copyright to a portion of your show?
> 
> > >Finally what is the tangible difference between storing usenet postings 
> > >on [any particular storage media]
> >
> > If you were a ligitimate recipient of the work in the first place (i.e. got
> > it in a newsfeed) and you store those postings for your own use or for the
> > use of others on that node in the store-and-forward network, then you can
> > keep the work 'til the bits rot. Infringement occurs when you copy those
> > bits onto some medium for some purpose other than store-and-forward
> > propagation or the allowed fair-use exceptions; stuffing articles on a
> > CD-ROM and selling them falls into neither category and hence is an
> > infringement.
> 
> Buzzz.  According to your logic all that one needs to do is to change the
> label on the order from from "Usenet articles on CD-ROM" to "Quarterly
> Usenet Feed distributed on CD-ROM" and I am in the clear.  I am not selling
> a collectoin containing your articles, I am providing a low-bandwidth
> newsfeed to those who do not have the same level of connectivity you have
> or that want the excitement of seeing thier newsfeed delivered over the
> "original information superhighway" (aka postal services.)  It is still
> store-and-forward, it is just store-forever-and-forward-not-so-often.
> 
> But under all the smoke and mirrors nothing changes the fact that I am
> selling archives of the Usenet.  No amount of puffed up indignation is
> going to change the fact that your Usenet posting or message to a mailing
> list is of no real value to you and is honestly as free as a bird once it
> hits the wire.
> 
> jim
> 






From mnemonic at eff.org  Tue Feb  1 13:25:28 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 13:25:28 PST
Subject: archiving on inet
In-Reply-To: <199402012029.PAA03234@snark>
Message-ID: <199402012121.QAA11869@eff.org>


> 
 
> Try to sue for damages when your work is available for free to
> millions of people. The judge will laugh in your face, copyright or
> no. Damages are, after all, related to lost revenue -- if you allow
> anyone who wants to see something for free in one medium, you will
> have a fucking hard time to keep them from examining it in another
> equivalent medium.

One can register the work and sue for statutory damages and attorneys'
fees. No need to prove damages in such a case.

If the Copyright Act is amended this year, it may be that one need not
even register the work.


--Mike


 





From cknight at crl.com  Tue Feb  1 13:25:41 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 13:25:41 PST
Subject: Why is Chris Knight a Twerp and an Idiot?
In-Reply-To: <Pine.3.85.9402011618.A9978-0100000@netcom9>
Message-ID: <Pine.3.87.9402011317.A2238-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> Dear Master Knight,
> 
> You have a double standard, or a bad memory. Saying "I'm glad your'e not 
> a politician" is most definitly a personal attack on me, not my 
> arguments. 

An incorrect jump of conclusions.  This was a comment on your arguments.  
I would not sleep well at night if the arguemnts you use were helping to 
write the laws regarding copyright and intelectual property.

> You became a prick first, and I am happy to join in. 

Happy?  Perhaps "At Home" is a better turn of phrase.  If fact, it seems 
you were looking for an excuse to switch to flame mode.

> If you look at the thread carefully you will see that you made the ad hominem 
> attack first, I do admit in joining you in the gutter however. Also, I 
> really don't care what you're thoughts are? Why should I. 

Why should you care?  I would like to end this useless chatter and go 
back to the discussion.  It appears that you do not.


> Just stop calling names when it hasn't been done to you. Or didn't your're 
mother and father teach you that, Master Knight?

It hadn't?  OOPS!  I guess I misread the subject of this message...  
Seems you have the thread confused.


-ck






From jazz at hal.com  Tue Feb  1 13:25:45 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 13:25:45 PST
Subject: archiving on inet
In-Reply-To: <199402012103.QAA03285@snark>
Message-ID: <9402012121.AA01984@jazz.hal.com>


>The reason selling a tape of a radio show isn't legal is because then
>you can play it as often as you like.

Even if you made play-once-and-then-self-destruct tapes like on Mission
Impossible, selling them would still be illegal. You've made an unauthorized
copy, plain and simple.

>You can archive them forever, and in fact thats part of the news software.

Yes, you, a recipient, can archive them forever. You *cannot* distribute
that archive in any form whatsoever.

I'm struggling with drawing an appropriate distinction between CD-ROM as
newsfeed medium and CD-ROM as archive medium. If a newsfeed provider sent
you a quarterly newsfeed on CD-ROM which you then fed into your normal news
system as if it were a live feed, after which you broke the CD-ROM; that
looks like a high-bandwidth-delay-product newsfeed. If a provider sent you a
quarterly newsfeed in Cnews directory form which you then mounted onto your
news system, I'd buy that as a newsfeed. If the provider sent to a newsfeed
in Cnews form which you mounted someplace other than as a part of the news
system - now an archive has been created and sold. But if you mounted it as
part of Cnews and then copied it via news onto your own CD-ROM drive, then
it seems like it'd be a personal archive.

No one said this was gonna be easy. It seems like I'm swallowing camels and
straining out flies, but these flies are camel-sized.

Jason

Copyright 1994 Jason Zions. Copying or retransmission for the purpose of
propagation of the Cypherpunks mailing list in email or newsfeed form is
permitted, except that no copy may be made on any permanent digital optical
storage medium.





From pmetzger at lehman.com  Tue Feb  1 13:25:46 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 13:25:46 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.85.9402011507.A5791-0100000@netcom9>
Message-ID: <199402012121.QAA03308@snark>



Kirk Sheppard says:
> On Tue, 1 Feb 1994, Chris Knight wrote:
> 
> <Perhaps we should try this.  You sell archives of the net, and we'll file
> <a class action suit...  I'll back up my beliefs with actions, how about you?
> 
> This appears to be merely hot air, since despite all his talk Master 
> Knight hasn't taken any "action" and it is doubtful that he has the money 
> or other "necessities" requisite for doing so. Also, notice the term 
> "beliefs", which explains a lot. I thought were were having a discussion 
> on a legal or academic basis, not one involving religeous or 
> philosophical "beliefs" or faith.

Archives of the net are already being sold. Furthermore, some folks at
the FBI got a newsfeed from uunet years ago by magtape when they
didn't have a direct uucp link. I'd say that anyone who thinks they
can actually succeed at such a suit is welcome to try, but I wouldn't
break a sweat worrying about it.

Yes, you have a copyright over your work -- however, once you've
posted it to the net it is likely practically impossible to restrict
distribution. Since you've already allowed it to be distributed on
demand to anyone for free it is hard to claim damages if it is
distributed to anyone via some medium you don't like.

Archives of all of usenet already exist. I was talking with Eric Fair
at Usenix about using a Cray at Apple to produce an index of all
usenet traffic thus far -- it likely won't happen, but those worried
about such possibilities are welcome to have their lawyers send me
nasty letters.

If you want your stuff to have limited distribution, you have to make
a conscious effort to limit distribution or you have likely lost all
cause of action. Posting to the net is likely implicit concent to
unlimited distribution, since it is in fact what will happen and you
have no reasonable expectation of anything else.

Perry





From pmetzger at lehman.com  Tue Feb  1 13:30:41 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 13:30:41 PST
Subject: archiving on inet
In-Reply-To: <199402012121.QAA11869@eff.org>
Message-ID: <199402012126.QAA03329@snark>



Mike Godwin says:
> > Try to sue for damages when your work is available for free to
> > millions of people. The judge will laugh in your face, copyright or
> > no. Damages are, after all, related to lost revenue -- if you allow
> > anyone who wants to see something for free in one medium, you will
> > have a fucking hard time to keep them from examining it in another
> > equivalent medium.
> 
> One can register the work and sue for statutory damages and attorneys'
> fees. No need to prove damages in such a case.

Absolutely true, but one has to say "Copyright" in the work in such a
case. Virtually no usenet work has that magic word in it. From what I
understand, if you don't say "Copyright" they can stop you in court
but there is a presumption going for the defendant.

Perry





From lefty at apple.com  Tue Feb  1 13:30:44 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 13:30:44 PST
Subject: archiving on inet
Message-ID: <9402012115.AA22993@internal.apple.com>


Kirk "I Can't Believe It's a Law Firm!" Sheppard astounds me by posting
>
>This book analogy is not accurate. It is my contention that usenet 
>postings are not copyrighted.  Our postings are not disseminated like a book...

Immaterial.  What on earth does "like a book" mean?  Do you contend that
only works printed on paper can have copyright protection, or only works
which are sold in bookstores, or only works which are bound in signatures?

As a trivial counterexample, movies broadcast over cable and songs played
on the radio retain copyright, without any question or doubt.  They aren't
"disseminated like a book", either.

>we are paid nothing for the use of our postings on the multitude 
>of machines that our postings appear.

Are you suggesting that there is any connection whatsoever between the
ability to copyright a given work and some third party's willingness to pay
for it?

Are you claiming that if I write a book and decide to give copies away
rather than sell them that my work is thereby not copyrighted?  If so,
you're clearly and without any doubt whatsoever in error.

Are you _positive_ you're a lawyer?

>Or, in the alternative, if copyrighted, by posting them in the electronic
>>ether, we give up most of our rights regarding dissemination, copying etc.

Aha.  This would explain why there's no legal problem with my recording the
complete works of the Beatles off the radio and then reselling them, no
doubt.

>Perhaps we may still 
>have some residual rights regarding accuracy and the like. Also the 
>posting regarding the legal blurbs on software, really was off point, 
>since what they they were refering to was a "license", and again there is 
>some doubt about how enforceable the individual licenses that the 
>software companies give. That is, some of these licenses may have 
>provisions that are not enforceable.

So, let's see here.

Let's say, for the sake of argument, that I'm Stephen King.

I write a book, using a word processing program on my computer, and saving
the results to a magmeto-optical disk.  Is it copyrighted?  Clearly, it is.

I sell the book to a publisher, who prints it onto paper, sews the paper
into signatures, binds it between covers, and sells several million
instantiations of this book to B. Dalton's.  Is it still copyrighted? 
Clearly, it is.

THe publisher takes a copy of my magneto-optical disk, adds some support
software licensed from Voyager, Inc., and presses a CD-ROM version of my
book.  Is it still copyrighted?  Clearly, it is.

At the same time, I distribute several long sections of the book, via
email, to a private mailing list of friends.  Is the book still
copyrighted?  Clearly, it is.

OK, now, here's the tough one.  I give one of my friend's permission to
post a long (i.e. clearly too long to constitute "fair use") section of
this book to rec.arts.books, with a copyright notice prominently displayed
at the very beginning of the posting, i.e.

          Copyright (c) 1994 by Stephen King.  All rights reserved.

You claim that this posting, suddenly and magically, no longer enjoys
copyright protection.  On what basis?

To approach this issue in another way, I wonder whether you're familiar
with "Internet Talk Radio", a scheme wherein voice broadcasts can be done
over the Internet.  If I were to pay the appropriate fees to ASCAP to allow
me to broadcast a song by Pearl Jam over Internet Talk Radio, are you
claiming that Pearl Jam's copyright to _their_ _own_ _music_ would be
destroyed by _my_ having played it back over this medium?  This would
clearly seem to be your contention.

I think you need to give this a wee bit more thought, Kirk.

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From pmetzger at lehman.com  Tue Feb  1 13:35:29 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 13:35:29 PST
Subject: archiving on inet
In-Reply-To: <9402012121.AA01984@jazz.hal.com>
Message-ID: <199402012131.QAA03337@snark>



Jason Zions says:
> >You can archive them forever, and in fact thats part of the news software.
> 
> Yes, you, a recipient, can archive them forever. You *cannot* distribute
> that archive in any form whatsoever.

The news software is explicitly designed to allow remote hosts to
request articles from each other.  Article numbers are never reused --
I can just use a nasty hierarchical storage system to keep all the
news articles I ever receive online.  So, how can you reconcile the
existance of the news software with your quaint notions? Are you
claiming that CNews and INN break the law? Are you claiming usenet is
illegal or something?

> I'm struggling with drawing an appropriate distinction between CD-ROM as
> newsfeed medium and CD-ROM as archive medium.

Maybe you are struggling because there is no reasonable way to make
the distinction?

> Copyright 1994 Jason Zions. Copying or retransmission for the purpose of
> propagation of the Cypherpunks mailing list in email or newsfeed form is
> permitted, except that no copy may be made on any permanent digital optical
> storage medium.

Well, you can now sue all the people who back up their home
directories nightly to optical disk. I believe all the folks at Bell
Labs who use Plan-9 are now in violation of your "copyright".

Perry





From lefty at apple.com  Tue Feb  1 13:35:40 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 13:35:40 PST
Subject: archiving on inet
Message-ID: <9402012127.AA23182@internal.apple.com>


>You too, have fallen into the same trap, as Master Knight, i.e.,  ad hominem 
>attacks, unprovoked, launched merely because I disagree with you.

Please feel free to identify the "ad hominem attack" to which you're
referring.  I _have_ questioned your claim to be an attorney, largely
because I do not believe that anyone could manage to pass a bar exam while
being so utterly ignorant of the basest rudiments of copyright law.

>As to 
>your arguments, no I don't think you have followed my logic at all, and I 
>certainly cannot follow or agree with your assertions.

I found no logic in your postings.  This explains, I think, my inability to
follow it.  I suspect that there are other explanations for _your_
inability to follow, or respond to, _my_ assertions.

>My point is that 
>the redistribution of usenet postings by  Netcom, my local bbs, me on my 
>hard disk to others for pay or not, or by cd-rom are not different and it 
>is just as legal for Netcom to charge me for providing me a usenet feed 
>as it is legal for a cd-rom manufacturer to do the same, neither is 
>paying us a dime nor are they obligated to do so.
>
>Personal use is not at all relevant.

No!?  How is it, then, that _I_ can copy a movie legally from HBO but I
can't legally sell the tape to you, eh?

>Netcom, Delphi are copying and providing usenet newsfeeds 
>as a commercial service, without paying any royalties to the authors of 
>the usenet postings. And we can all do the same and use any medium we 
>want to  whether you or Master Knight like it or understand it.

None of which has anything, specifically, to do with copyright.

Do you understand the concept of "intellectual property" in the least?

Are you absolutely, positively, thoroughly _certain_ you're a lawyer?

(Hey, can I repost that private email you sent me?  I'm sure the list would
_love_ to see so deeply reasoned and clearly thought out an argument. 
Besides, you don't believe that it's copyrighted, do you?)

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From cknight at crl.com  Tue Feb  1 13:40:41 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 13:40:41 PST
Subject: archiving on inet
In-Reply-To: <199402012029.PAA03234@snark>
Message-ID: <Pine.3.87.9402011355.A2238-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Perry E. Metzger wrote:

> Try to sue for damages when your work is available for free to
> millions of people. The judge will laugh in your face, copyright or
> no. Damages are, after all, related to lost revenue 

Lost revenue can be measured in more than one way.  Besides estimated 
loss of sales, it can be measured in profit earned by the defendant.  If 
an author published a story in a magazine once, and never intends to 
publish it again, this does not give you the right to sell his story 
because he wasn't going to be making money on it anywhay.


> anyone who wants to see something for free in one medium, you will 
> have a fucking hard time to keep them from examining it in another
> equivalent medium. 

Profanity aside, that's not an entirely logical arguemnt.  There are 
plenty of free publications in the US that contain copyrighted work.  
Publishing in a "free medium" does not strip your rights.


-ck






From mnemonic at eff.org  Tue Feb  1 13:40:44 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 13:40:44 PST
Subject: archiving on inet
In-Reply-To: <199402012126.QAA03329@snark>
Message-ID: <199402012139.QAA12055@eff.org>


 
Perry writes:

> Mike Godwin says:
> > > Try to sue for damages when your work is available for free to
> > > millions of people. The judge will laugh in your face, copyright or
> > > no. Damages are, after all, related to lost revenue -- if you allow
> > > anyone who wants to see something for free in one medium, you will
> > > have a fucking hard time to keep them from examining it in another
> > > equivalent medium.
> > 
> > One can register the work and sue for statutory damages and attorneys'
> > fees. No need to prove damages in such a case.
> 
> Absolutely true, but one has to say "Copyright" in the work in such a
> case.

This is not true.

> Virtually no usenet work has that magic word in it. From what I
> understand, if you don't say "Copyright" they can stop you in court
> but there is a presumption going for the defendant.

May have been true in the old days, but it isn't true now.


--Mike







From cknight at crl.com  Tue Feb  1 13:50:41 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 13:50:41 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.85.9402011507.A5791-0100000@netcom9>
Message-ID: <Pine.3.87.9402011307.A2238-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> On Tue, 1 Feb 1994, Chris Knight wrote:
> 
> <Perhaps we should try this.  You sell archives of the net, and we'll file
> <a class action suit...  I'll back up my beliefs with actions, how about you?
>  
> 
> This appears to be merely hot air, since despite all his talk Master 
> Knight hasn't taken any "action" and it is doubtful that he has the money 
> or other "necessities" requisite for doing so. 

And what sort of action am I supposed to take?  This was, to my knowledge a 
discussion.  And who is this "Master Knight"?


> Also, notice the term 
> "beliefs", which explains a lot. I thought were were having a discussion 
> on a legal or academic basis, not one involving religeous or 
> philosophical "beliefs" or faith.

All of us, including yourself Mr. Sheppard, have been discussing 
theoretical law and rights.  Until it is tried in court, we are all 
stating how we BELIEVE it will go.  This has nothing to do with religion, 
or philosophy; merely interpretation of law.


-ck






From kshep at netcom.com  Tue Feb  1 14:10:41 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 14:10:41 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.87.9402011307.A2238-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011739.A14632-0100000@netcom9>


"Master" is the term one uses in place of "Mister" or "Mr." when politely 
addressing a male, under the age of majority.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Kirk Sheppard wrote:
> 
> > On Tue, 1 Feb 1994, Chris Knight wrote:
> > 
> > <Perhaps we should try this.  You sell archives of the net, and we'll file
> > <a class action suit...  I'll back up my beliefs with actions, how about you?
> >  
> > 
> > This appears to be merely hot air, since despite all his talk Master 
> > Knight hasn't taken any "action" and it is doubtful that he has the money 
> > or other "necessities" requisite for doing so. 
> 
> And what sort of action am I supposed to take?  This was, to my knowledge a 
> discussion.  And who is this "Master Knight"?
> 
> 
> > Also, notice the term 
> > "beliefs", which explains a lot. I thought were were having a discussion 
> > on a legal or academic basis, not one involving religeous or 
> > philosophical "beliefs" or faith.
> 
> All of us, including yourself Mr. Sheppard, have been discussing 
> theoretical law and rights.  Until it is tried in court, we are all 
> stating how we BELIEVE it will go.  This has nothing to do with religion, 
> or philosophy; merely interpretation of law.
> 
> 
> -ck
> 
> 






From mcb at net.bio.net  Tue Feb  1 14:10:45 1994
From: mcb at net.bio.net (Michael C. Berch)
Date: Tue, 1 Feb 94 14:10:45 PST
Subject: archiving on inet
Message-ID: <9402012207.AA29009@net.bio.net>


Jason Zion writes:
> Yep. When you're providing a netnews feed, you're acting as a node in a
> store-and-forward network. A CD-ROM is not a part of a store-and-forward
> network; it is a permanently fixed repository of information. You can't hold
> up a netnews feed in a courtroom and point at it saying "there it is"; you
> *can* do so with a CD-ROM.
> 
>    So I suppose you want to give some
>    kind of list of what types of media are acceptable for transmitting
>    netnews feeds, and which are not?

You seem awfully confident about something that has never, to my
knowledge, been litigated at the appellate level.  The difference you
posit between a netnews feed and a CD-ROM seems very tenuous to me --
not the kind of thing I would feel supreme confidence in trying to
convince a judge of.  As far as "holding something up" and saying
"there it is", I could do the same thing in court with a hard disk
containing a news spool and a CD-ROM drive containing a CD with a copy
of a news feed.  Set up two windows side-by side and they have the
same article in them, right down to the Message-ID, byte count, even a
CRC or SNEFRU checksum.  *Now* try to convince the court they are
different animals for copyright purposes...

> A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently
> fixed copy of the contents of such a feed. Static versus dynamic; permanent,
> ephemeral. Is this hard to understand?

Yes, very.  And I have been in computing since 1975 and a licensed
attorney since 1981.  So I think it is fair to say that if I find this
murky and confusing, and believe that copyright law does not divide these
types of cases into neat little boxes, then others may as well.

>    The plain and simple fact is: When you post a message to usenet, you do
>    so with the expectation that others will receive it.  You can have no
>    way of knowing or limiting who may get it; that is given by the nature
>    of the network.  Usenet news is, and is intended to be, publicly
>    accessable information.  If there is something you don't want
>    distributed, then DON'T POST IT!
> 
> Learn a little about law; while you're at it, learn a little about usenet.
> When you post a message to usenet, you have tossed it into a flood-routed
> store-and-forward network. You implicitly give permission for copying
> appropriate to the propagation of messages in that network. You neither
> grant permission nor withhold permission for Fair Use. Everything else,
> though, is not granted unless explicitly granted.
> 
> If I post a message, under the terms of the Berne Convention and current US
> copyright law, a recipient was not granted the right to print a copy and
> publish it in a book. What makes you think I granted them permission to
> publish a copy in a CD-ROM? The only permission I granted was that they
> could (a) read it and (b) forward it via usenet protocols.

Except that it is extremely difficult to put one's finger on "Usenet
protocols".  *Most* people are using (for example) RFC1036-compliant
Netnews article formats and either NNTP or UUCP for transport.  BUT,
this certainly does not apply to everybody -- some people read
newsgroups as e-mail (SMTP, UUCP, QuickMail, cc:mail, Lotus Notes,
etc.).  Some people receive netnews feeds in the form of magnetic
tape; some as large batched file transmissions on IBM mainframe
networks.  Some get news articles via friends who operate informal
"clipping services" and save and print articles of interest and send
them via snail-mail.  Some people archive newsgroups and put them on
FTP/gopher/WWW/WAIS server where they may be indexed and  retrieved 
years later.  

I would not want to have the burden of convincing a court that any of
these are beyond the purview of "Usenet" and thus, in your scheme,
implicitly copyright infringements.

It is not that I vehemently disagree with any of the points made
above -- who knows what will eventually evolve as a legal standard? --
I just think that it is a wildly unsettled area and pronouncements
of bright-line criteria in the absence of relevant legislation *or*
jurisprudence is fatuous at best.

--
Michael C. Berch
mcb at net.bio.net / mcb at postmodern.com






From lefty at apple.com  Tue Feb  1 14:15:28 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 14:15:28 PST
Subject: archiving on inet
Message-ID: <9402012201.AA23756@internal.apple.com>


>This is not an accurate comparison. A posting on usenet is not the same 
>item as a program on HBO or the radio.

So you claim.  How does it differ, though?

>In what way does my internet provider 
>(netcom) have a "legal" distribution of usenet news, while a cd-rom 
>provider does not?

I have "provided" my postings to Usenet, for the personal use of Usenet
subscribers.  By providing my postings to a particular distribution
mechanism, I implicitly give permission for them to be redistributed _via_
_that_ _mechanism_.  I _do_ _not_ give permission for them to be repackaged
and resold via another medium, any more than David Byrne has given me
permission to resell cassettes of his music by allowing it to be broadcast
on the radio.

>HBO has paid for the use of the programs it broadcasts 
>that are produced by others, hence they have a contract between 
>themselves and the owners of the copyright.

And, hence, they have permission to distribute it over the medium of cable
televison transmission.  This does not, in and of itself, give them the
right to, for instance, resell laser disks of the movies they broadcast.

>No providers of usenet news 
>have any agreements between themselves and the posters regarding 
>copyrights.

An author doesn't _need_ an agreement to assert copyright.  Were you,
somehow, ignorant of that?

>Netcom and all the other internet providers receive postings 
>"free" and a cd-rom manufacturer has the same "right" to use postings as 
>any other internet provider.

Quite correct.  The CD-ROM manufacture may _read_ them.  Period.

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From cknight at crl.com  Tue Feb  1 14:20:41 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 14:20:41 PST
Subject: Archiving mail-lists...
In-Reply-To: <Pine.3.85.9402011739.A14632-0100000@netcom9>
Message-ID: <Pine.3.87.9402011409.A11290-0100000@crl.crl.com>




On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> "Master" is the term one uses in place of "Mister" or "Mr." when politely 
> addressing a male, under the age of majority.
> 

I confess to some doubts as to your intentions of politeness.  But, being 
of open mind I will put it to the test:  Mr Sheppard, I am above the "age 
of majority", and request that you refrain from using an incorrect form of 
title.

-ck







From sfi at verity.com  Tue Feb  1 14:20:48 1994
From: sfi at verity.com (Stefan Fielding-Isaacs)
Date: Tue, 1 Feb 94 14:20:48 PST
Subject: archiving on inet
Message-ID: <9402012220.AA24439@verity.com>



	>From: "Perry E. Metzger" <pmetzger at lehman.com>
>	>
>	>
>	>Chris Knight says:
>	>> If all you are concerned with is "Material differnce", then you think 
>	>> it's perfectly ok for me to sell you a good copy of a magazine?  By your 
>	>> "logic" (loosely used), you had to pay for the copy, and you had to pay 
>	>> for the original, so what's the difference?  The difference is the WILL 
>	>> AND PERMISSION of the author!  As the author of this message, I willingly 
>	>> placed it within the net.  I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION 
>	>> TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK.
>	>
>	>Try to sue for damages when your work is available for free to
>	>millions of people. The judge will laugh in your face, copyright or
>	>no. Damages are, after all, related to lost revenue -- if you allow
>	>anyone who wants to see something for free in one medium, you will
>	>have a fucking hard time to keep them from examining it in another
>	>equivalent medium. Usenet is NOT a magazine. Failing to put a
>	>copyright notice in your work destroys whats left of your ability to
>	>do anything. I'm sure you can pay a lawyer to sue for you, but this
>	>isn't exactly one anyone is going to take on contingency.

 I believe this is completely fallacious. Simply because I don't include
 a copyright statement _does not_ mean that my material is not copyrighted
 (look it up).

 Secondly, the issue at hand is not so much redistribution (I think that
 can be resolved by attribution) but rather that the redistribution was
 done for profit. I think that is where you can be hanged (metaphorically
 speaking).

 I do not think it wise to defend such an indefensible (morally and legally)
 position. Perhaps you should reconsider.

 Stef





From lefty at apple.com  Tue Feb  1 14:45:29 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 14:45:29 PST
Subject: Why is Kirk Sheppard Wasting Our Time? (was Re: Why is Chris Knight aTwerp?)
Message-ID: <9402012230.AA24339@internal.apple.com>


I have in fact myself received _two_ such _billets doux_ from Kirk "I claim
without evidence to be a lawyer, but so far I only play one badly on the
net" Sheppard.

I've asked his permission three times whether I can repost them, but have
gotten no specific response, other than further insults, silliness and
blathering.

I can't help but wonder why, given his strongly negative reaction to people
who try to argue with him, why on earth he might be inclined to pursue the
law as a profession.

Nor can I help but wonder how seriously I need to take someone who
addresses mail to me with the subjects "Why is Lefty a Twerp?" and "Why is
Lefty a Twerp and an Idiot?", wherein he complains about ad hominem
attacks.

I also wonder, given his tendency to call those who _do_ argue with him
"twerp" and "idiot", whether he receives many citations for contempt of
court.

>Is there any chance that this will get back to the discussion at hand, or 
>are you tired of this toy and trying to find something else to play with?

Highly doubtful.  I enjoy a battle of wits as much as the next person, but
I'm afraid I have to draw the line at an unarmed opponent.

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From kshep at netcom.com  Tue Feb  1 14:50:41 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 14:50:41 PST
Subject: Master v. Mister
In-Reply-To: <Pine.3.87.9402011409.A11290-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011759.A14632-0100000@netcom9>


Dear Master Knight,

Normally, I would be happy to oblige in using one's requested term of 
address, however I may make an exception in this case as you want fair 
play to be one sided. According to Master Knight, it is OK to start with 
ad hominem attacks, but not to answer them. Also, Master Knight has this 
devious habit of posting "private mail" on this list. Twice, now I have 
answered Master Knight's personal insults with a "private" reply so as to 
ease the burden on the other members of this  very active list, and twice 
Master Knight, shamelessly  posts follow-ups to the list. Not very 
honorable, Master Knight. So no, if I ever have the need to address you 
again it will be "Master" for you.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> 
> On Tue, 1 Feb 1994, Kirk Sheppard wrote:
> 
> > "Master" is the term one uses in place of "Mister" or "Mr." when politely 
> > addressing a male, under the age of majority.
> > 
> 
> I confess to some doubts as to your intentions of politeness.  But, being 
> of open mind I will put it to the test:  Mr Sheppard, I am above the "age 
> of majority", and request that you refrain from using an incorrect form of 
> title.
> 
> -ck
> 
> 
> 






From pmetzger at lehman.com  Tue Feb  1 15:05:29 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 1 Feb 94 15:05:29 PST
Subject: archiving on inet
In-Reply-To: <9402012220.AA24439@verity.com>
Message-ID: <199402012303.SAA03443@snark>



Stefan Fielding-Isaacs says:
>  I believe this is completely fallacious. Simply because I don't include
>  a copyright statement _does not_ mean that my material is not copyrighted
>  (look it up).

It does change the nature of the damages you can claim and the nature
of the process by which you prove copyright, as does registration of
the material.

>  Secondly, the issue at hand is not so much redistribution (I think that
>  can be resolved by attribution) but rather that the redistribution was
>  done for profit. I think that is where you can be hanged (metaphorically
>  speaking).

Redistribution of netnews is already done for profit, or haven't you
heard of uunet?

Perry





From kshep at netcom.com  Tue Feb  1 15:05:42 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Tue, 1 Feb 94 15:05:42 PST
Subject: Why is Chris Knight a Twerp?
In-Reply-To: <Pine.3.87.9402011257.A2238-0100000@crl.crl.com>
Message-ID: <Pine.3.85.9402011721.A14632-0100000@netcom9>


This is a prime example of Master Knight posting "private" e-mail to the 
list as a method of retaliation and ad hominem attack. Notice that he 
defames himself by being too lazy to change the "Subject" line. My sincere 
apology to the readers of this very active list. I will not reply 
publically to Master Knight any further as this entire thread is not 
within the list subject. 

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata


On Tue, 1 Feb 1994, Chris Knight wrote:

> 
> It sure was short trip for you to go from person to prick.
> 
> My "attacks" have been on your logic.  Something that has always been a 
> prime goal of a debate.  Lacking anything intellignet to say, you resort 
> to the text quoted below, and your attempted personal slight of refering 
> to me as "Master Knight" in your current posts.
> 
> Is there any chance that this will get back to the discussion at hand, or 
> are you tired of this toy and trying to find something else to play with?
> 
> If all you have left is attacks, name calling, and rudeness, perhaps you 
> should find other toys and leave the discussions to adults.
> 
> -ck
> 
> On 
> Tue, 1 Feb 1994, Kirk Sheppard wrote:
> 
> > Dear Stupid,
> > 
> > Why you are intent on attacking me for no reason is beyond me. I didn't 
> > attack you personally, what is the matter with you? Also I am not 
> > interested in gratuitous advice regarding "trying to write sometime". I 
> > can see why you might be bitter as you obviously lack the intelligence 
> > and education to make much money writing. 
> > 
> > Kirk Sheppard
> > 
> > kshep at netcom.com
> > 
> > P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
> > Bethesda, MD 20824-0911      Live On Your Knees."
> > U.S.A.
> > 			    			     - Emiliano Zapata
> > 
> > 
> > 
> 
> 






From loki at nately.UCSD.EDU  Tue Feb  1 15:05:48 1994
From: loki at nately.UCSD.EDU (Lance Cottrell)
Date: Tue, 1 Feb 94 15:05:48 PST
Subject: SASE Suggestion
Message-ID: <9402012306.AA09568@nately.UCSD.EDU>


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

I have been meditating on this problem of return
addresses, and have a proposal. The remailers
can not be allowed to choose the return path,
as any corrupted remailer will corrupt the rest
of the path. I suggest the following SASE packet
format.

Notation:
A(foo) = foo encrypted to remailer A
P = some sort of one use postage token.
end is a flag indicating the final destination.
x,y,z,b are large random integers.
n is a large prime.

Packet:
This will rout reply from A -> B -> C -> Bob

A(P,x,B,B(P,y,C,C(P,z,Bob,end))),A(b,n,message)

Upon receiving the packet, A does the following:

A decrypts the packet (both parts separately).

A calculates a new b' = b^x mod n and encrypts
B(b',n,message)

So B receives B(P,y,C,C(P,z,Bob,end)),B(b',n,message)

C receives C(P,z,Bob,end),C(b'',n,message)

Analysis:
The message, which would normally be encrypted to Bob,
is never transmitted in the clear. Bob can easily
compute b'' to confirm that the message was correctly
routed, but this reveals no information about the path
the message has taken. The first remailer will refuse
to deliver the message twice, because of the expired
postage token, so the same path will not be reused.

So, what do you think? It does require some work from
the remailers, but not too much more than now.

- ----------------------------------------------------------
Lance Cottrell	who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.3 key available by finger or server.

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
			--Nietzsche
- ----------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU7fRFVkk3dax7hlAQH4MgP9HIQPR3esnHbJuELXtCmTGXvQoLHgoA+L
OeW1WOM6WczcOEwzFRsto8k2vrTsSMDPAqhTm+Ylgy83x8ez+yquoKmfFqiNQzWY
Vcoy7ng/Jgu9i9snIGlsVdq6cpKTS8YKiR3EmnQrbpXetL7cFBZRN4yJ+dadS77q
cT2rY82uzw4=
=YTIz
-----END PGP SIGNATURE-----





From cknight at crl.com  Tue Feb  1 15:05:49 1994
From: cknight at crl.com (Chris Knight)
Date: Tue, 1 Feb 94 15:05:49 PST
Subject: Capt'n Kirk and Major Tom...  Both lost in space...
In-Reply-To: <Pine.3.85.9402011708.A14632-0100000@netcom9>
Message-ID: <Pine.3.87.9402011444.A16567-0100000@crl.crl.com>



I did not consider that a flame war, it was just a bit of banter.

You seem to lack both a sense of humor, and the intelligence to discern 
it in others.

As for re-posting personal mail, there is nothing unethical about it.  
Your vehemence on this point just goes to prove how much you wanted to 
hide your true personality from those on the net.

Since you don't seem to want to end this, I will.  Post all you want, 
personal and private.  You have proven beyond a doubt that you have no 
points of view worth discussing, nothing to be learned, and nothing worth 
replying to.

-ck 


On Tue, 1 Feb 1994, Kirk Sheppard wrote:

> Dear Master Knight,
> 
> You have quickly forgotten the crap about sending valium etc. You started 
> the flame war then by reading my small post literally and started it 
> today by making personal insults. This is your habit. My habit is to 
> respond in kind. Also, the trick of reposting private mail to a list 
> shows the level of your personal ethics. Quite low from this  vantage point.
> 
> Kirk Sheppard
> 
> kshep at netcom.com
> 
> P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
> Bethesda, MD 20824-0911      Live On Your Knees."
> U.S.A.
> 			    			     - Emiliano Zapata
> 
> 
> On Tue, 1 Feb 1994, Chris Knight wrote:
> 
> > 
> > 
> > On Tue, 1 Feb 1994, Kirk Sheppard wrote:
> > 
> > > This is the second idiotic flame war you have started with me in the last 
> > > two weeks. 
> > 
> > Perhaps you have your mail lists confused.  Until only a week ago, I 
> > was not posting in this echo.  Secondly, you started this "war".
> > 
> > > I would never again apologize to you. 
> > 
> > There was a first?
> > 
> > > I do take some small pleasure in the fact that you are so lazy that you 
> > > don't change the subject line when you reply, so on each reply you republish
> > > the condition of your being. It gives me a small chuckle each time I read the 
> > > "truth" of your intellect.
> > 
> > It is truely sad that these are the pleasures in your life.
> > 
> > 
> > 
> 
> 
> 
> 






From mnemonic at eff.org  Tue Feb  1 15:20:42 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Tue, 1 Feb 94 15:20:42 PST
Subject: Archiving mail-lists...
In-Reply-To: <199402012121.QAA03308@snark>
Message-ID: <199402012316.SAA13735@eff.org>


 
> Yes, you have a copyright over your work -- however, once you've
> posted it to the net it is likely practically impossible to restrict
> distribution.

Practical impossibility != legal impossibility.

> Since you've already allowed it to be distributed on
> demand to anyone for free it is hard to claim damages if it is
> distributed to anyone via some medium you don't like.
 
Hard, yes, but not impossible. Most copyright actions involving works that
are not being sold resort to statutory damages. And you can register your
copyright *after* the infringement occurs.


--Mike







From klbarrus at owlnet.rice.edu  Tue Feb  1 15:25:29 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Tue, 1 Feb 94 15:25:29 PST
Subject: PGP
Message-ID: <9402012321.AA07980@wahoo.owlnet.rice.edu>


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

>About how many calculations does it take to crack a 1024 bit key?  If
>someone has limitless time, money, etc., they can break it...but how
>many calculations does it take?

I did some calculations on this a few months ago, and it works out to
be on the order of 4.42 10^29 steps.  So then you can figure out how
much real time it takes given machine speed.

I also made some calculations for other sizes - to get the rest of the
article gopher to chaos.bsu.edu and look at Misc/"Bits and Factoring
Difficulty" where I have been archiving various cypherpunks posts,
apparently flying the face of copyright laws blah blah blah blah.

Since I wrote that I give permission for it to be at the gopher site
;)

>Also, there is a password used to protect the keyrings.  Assuming a
>strong password how many calculations does that take to break?

Well, if it's an 128 bit IDEA password, and brute force is the fastest
way to "break" it, then 2^128 = 3.4 10^38.

Karl Barrus
klbarrus at owlnet.rice.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU7jtYOA7OpLWtYzAQFV8wQAjugItETGxmxMkXyGN798/9DwUnhpHU7g
A7NskB3jBRSFvFJYwp1B/0c80v2I14LjZg1FHU2zlUD2NPza91mSRc0hW4WcY3Sq
2RQjZIUBxz9Fu+4XPEQWT7iFOh+MhGbx60h5QktXDaJaS46QrrsPz2SXaMbdG7iu
BiyraoH3mu8=
=aMtI
-----END PGP SIGNATURE-----





From klbarrus at owlnet.rice.edu  Tue Feb  1 15:30:42 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Tue, 1 Feb 94 15:30:42 PST
Subject: PGP
Message-ID: <9402012329.AA08073@wahoo.owlnet.rice.edu>


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

>Brute-forcing IDEA takes about as much computation as factoring
>something between a 1200 and 3000 bit RSA key (I've heard both
>numbers, but I don't know the numbers).  So, in the current
>implementation, RSA is the weak link!

Yes, I think that the turnaround point is right around 1600 bits, at
which IDEA is "easier" than RSA.

Assuming of course brute force is the fastest way to break IDEA;
the fastest (known|published) factoring method runs in time
proportional to the formula I typed out, etc.

Karl Barrus
klbarrus at owlnet.rice.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU7l2IOA7OpLWtYzAQE7fwP6A6ENOTE7dUl0gbqEk17NRLPnExCHa2za
HEt3LTfbn/0gpTfrwnKUTCKP3TAvnVJJ/cDFxRR1RkaTyHxA0RvQR/b8SosFK2Uc
HEY5I5AqNVUKE9TceDXcBnYmmMbZAIMpdMMTknrn3Eyo1kcfLGTfOInH0wM35Rdl
/o/sPMmc23s=
=S2+w
-----END PGP SIGNATURE-----





From jthomas at access.digex.net  Tue Feb  1 15:35:29 1994
From: jthomas at access.digex.net (Joe Thomas)
Date: Tue, 1 Feb 94 15:35:29 PST
Subject: archiving on inet
In-Reply-To: <9402012021.AA01756@jazz.hal.com>
Message-ID: <Pine.3.05.9402011809.B17142-b100000@access1.digex.net>


On Tue, 1 Feb 1994, Jason Zions wrote:

> > So answer the question again, what is the 
> >difference in paying an internet provider for access to usenet, and 
> >paying a cd-rom provider for access to usenet?
> . . .
> Better yet, it's the difference between watching a program on HBO when you
> are getting that service legally (i.e. paying for it) and buying a tape of
> the same program from a friend who has HBO. Whether or not you also have
> legal access to HBO, the sale of the tape infringes on the copyright of the
> program.

Several variations on this analogy have been posted, but I still don't see
how it applies to Usenet.

If HBO allowed anyone who could receive its signal to pass it along to
anyone else, without a prior license agreement, I would say it would have
little grounds for trying to prevent the sale of programs taped off HBO.

But to attempt to bring this back from misc.legal to cypherpunks territory...
Have people here thought about what happens to the concept of intellectual
property in an environment of strong cryptography and cheap anonymity? 
When there's no way for the government to enforce Berne on movies and
electronic books, what hope is there for Usenet postings?

Joe







From nate at VIS.ColoState.EDU  Tue Feb  1 15:45:44 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Tue, 1 Feb 94 15:45:44 PST
Subject: new remailer online
Message-ID: <9402012345.AA05789@vangogh.VIS.ColoState.EDU>


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



There is a new anonymous remailer online at:

   nate at vis.colostate.edu

It does not yet support pgp encryption, but it does remail
fine.  This is also the standard remailer used by by WWW
remailer GUI (even if no mailers are checked).

I will be releasing a copy of my remailer GUI and software
in the next day or so.

- -nate sammons

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From hojunya at ecf.toronto.edu  Tue Feb  1 16:05:29 1994
From: hojunya at ecf.toronto.edu (HO JUNYA)
Date: Tue, 1 Feb 94 16:05:29 PST
Subject: "bio-radar"?
Message-ID: <94Feb1.190048edt.5810@cannon.ecf.toronto.edu>



In the current issue of Defense Electronics, the editor talks about
some "bio-radar" technology, in the hands of both the US and the
Soviet bloc..  Does anyone know more about this, or know where to
get more information?





From loki at nately.UCSD.EDU  Tue Feb  1 16:10:45 1994
From: loki at nately.UCSD.EDU (Lance Cottrell)
Date: Tue, 1 Feb 94 16:10:45 PST
Subject: archiving on inet
Message-ID: <9402020008.AA09772@nately.UCSD.EDU>


This thread seems way off topic.

		Lance





From jim at bilbo.suite.com  Tue Feb  1 16:25:29 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Tue, 1 Feb 94 16:25:29 PST
Subject: Why is Chris Knight a Twerp?
Message-ID: <9402020019.AA02559@bilbo.suite.com>




Please take the "archiving mail-list" thread to e-mail.

Thank you,

Jim_Miller at suite.com






From jimn8 at netcom.com  Tue Feb  1 16:30:45 1994
From: jimn8 at netcom.com (Jim Nitchals)
Date: Tue, 1 Feb 94 16:30:45 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.85.9402011548.A5791-0100000@netcom9>
Message-ID: <199402020030.QAA20097@mail.netcom.com>


> 
> This is not an accurate comparison. A posting on usenet is not the same 
> item as a program on HBO or the radio. In what way does my internet provider 
> (netcom) have a "legal" distribution of usenet news, while a cd-rom 
> provider does not?

I've already said it.  I own the copyright to my posts, and only permit
them to be distributed by Usenet because I can *cancel* and provide
expiration dates with my posts.  CD-ROMs do not provide these standard
Usenet message control features.

If I issue a cancel message, it's obvious that I'm asserting control
over the further distribution of my content (sites that ignore them
notwithstanding.)  Any time a CD-ROM is published with my message, and
it contains an expiration date or is later cancelled, the publication
violates my right as a copyright holder to retract my message.

[portions deleted]                         >  No providers of usenet news
> have any agreements between themselves and the posters regarding 
> copyrights. Netcom and all the other internet providers receive postings 
> "free" and a cd-rom manufacturer has the same "right" to use postings as 
> any other internet provider.

My expiration dates or cancel messages are perfectly reasonable ways
to communicate the way in which I'm exercising my copyright.  Netcom
and other service providers currently honor those communications, but
CD-ROM publishers of Usenet news do not.
> 
> Kirk Sheppard
> 
> kshep at netcom.com
> 
> P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
> Bethesda, MD 20824-0911      Live On Your Knees."
> U.S.A.
> 			    			     - Emiliano Zapata
> 




From ebrandt at jarthur.Claremont.EDU  Tue Feb  1 16:35:30 1994
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Tue, 1 Feb 94 16:35:30 PST
Subject: archiving on inet
In-Reply-To: <9402011752.AA00225@jazz.hal.com>
Message-ID: <9402020035.AA00478@toad.com>


> From: Jason Zions <jazz at hal.com>

> Infringement occurs when you copy those bits onto some medium for
> some purpose other than store-and-forward propagation or the allowed
> fair-use exceptions; stuffing articles on a CD-ROM and selling them
> falls into neither category and hence is an infringement.
 
This is hardly cut-and-dried.  Try the defense lawyer's
interpretation: recipients of the CD-ROM are leaf nodes; the CD-ROM
is a convenient transport medium.  Usenet has been propagated over
magtape, after all.  CD-ROM is the modern equivalent, cheaper to cut
than a tape.

You seem to be concerned that your words might be stored on a
`permanent' medium.  You should be.  Anything you post is propagated
to a vast and unknown number of systems worldwide.  *Somebody* is
going to archive it, maybe back it up to WORM.  You know this
already, so what's the big deal about a CD-ROM?

I agree with your basic contention that authors of Usenet postings
retain copyright minus some concession to the nature of the medium.
But your concessions are unrealistically limited.  In the real world,
you can't count on the destruction of every copy of your `ephemeral'
article.  You can't know or control the media of propagation.  You
can't expect the RFCs to be followed to the letter -- the bulk of
news systems these days are probably neighborhood BBSes who run their
gateway software out of the box.  This is Usenet; post if you can
accept it.

   Eli   ebrandt at jarthur.claremont.edu





From jimn8 at netcom.com  Tue Feb  1 16:40:47 1994
From: jimn8 at netcom.com (Jim Nitchals)
Date: Tue, 1 Feb 94 16:40:47 PST
Subject: archiving on inet
In-Reply-To: <199402012131.QAA03337@snark>
Message-ID: <199402020036.QAA20961@mail.netcom.com>


> 
> 
> Jason Zions says:
[portions deleted]
> 
> > I'm struggling with drawing an appropriate distinction between CD-ROM as
> > newsfeed medium and CD-ROM as archive medium.
> 
> Maybe you are struggling because there is no reasonable way to make
> the distinction?

There is.  Copyright 1994 James Nitchals.  Duplication and redistribution
rights permitted only until the expiration date or issuance of a cancel
message by the author.

CD-ROM publishers cannot honor the request except by reissuing the CD-ROM
without my content.  Anyone who backs up their home directory is safe,
but if they redistribute my article after it's expired or cancelled, they
are in violation of my copyright.






From jazz at hal.com  Tue Feb  1 16:40:53 1994
From: jazz at hal.com (Jason Zions)
Date: Tue, 1 Feb 94 16:40:53 PST
Subject: The Death of Statutory Compensation for Intellectual Property (was pissing contest)
In-Reply-To: <Pine.3.05.9402011809.B17142-b100000@access1.digex.net>
Message-ID: <9402020038.AA02579@jazz.hal.com>


>Have people here thought about what happens to the concept of intellectual
>property in an environment of strong cryptography and cheap anonymity? 
>When there's no way for the government to enforce Berne on movies and
>electronic books, what hope is there for Usenet postings?

I was wondering when it was going to come around to this.

Surprise. Within ten years, the entire concept of intellectual property will
be radically altered, if not completely gone. The whole thing will become so
completely unenforceable that something will give; I'm not sure what, but
something.

At the Austin Crypto Conference, John Perry Barlow was asked what he thought
would happen to copyright. As I recall, he said something along the lines of
this: that compensation for intellectual property would cease to be a thing
of law and become a thing of interpersonal relationships. That people would
pay the producers of stuff they liked as an incentive for them to produce
more. That the ability of the Internet and its services to make
widely-separated people into a community, with all the emotions and duties
humans tend to experience in communities, would ensure a kind of darwinism
amongst the "stuff" out there; the stuff people liked would get supported
out of that sense of community, and the stuff people didn't like would not.

Would you pay $895 for a CD-ROM version of the Oxford Unabridged Dictionary?
If you could get it for almost nothing on the net, would you be willing to
send a check for $10 to the Oxford folks who made it possible?

Shareware is the future of just about all intellectual property. Once a
movie is released on video, it will be cloned and copied to rapidly that
they'll sell, what, a few hundred? Everyone else will trade perfect copies
around. There are only a few ways the studios could get huge bucks:

1) Shareware. Ask each owner of a copy to send a few bucks. Personally, I'd
rather send it to the director and actors and crew than to the back-office
overhead, but what the hell.

2) Stick with theatrical release. It'll get swiped from there too; film is
so expensive that the first users of really high-quality digital video will
be the studios, at which point it's just a question of dubbing the digital
bits (no film involved anymore).

3) Charge out the wazoo for the video tapes. Doesn't matter; the
Blockbuster's of the world will pay for one copy, which will be rented and
cloned.

4) Serializing digital copies to track down the "leaker". All you need is
two copies from different sources to find steganographically-hidden bits or
to produce a combination of the two that has a unique fingerprint that
doesn't match anything already shipping.

Within ten years it's all over.

Until then, until societal changes occur to help creative people get paid
the money they deserve for the fruits of their labors, try and stay honest
with the law as it is, eh? It's not that expensive to do it by the book
(send your check to the copyright clearance center for printed matter, for
example) and it's the primary feedback mechanism you have to the creators of
the works you like.

Jason

Copyright 1994 Jason Zions. You can copy this to propagate cypherpunks
mailing list as email or local newsgroups; no permanent digital optical
copies allowed (except for backup purposes, which I can't restrict anyway;
see relevant case law).





From mg5n+ at andrew.cmu.edu  Tue Feb  1 16:50:47 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Tue, 1 Feb 94 16:50:47 PST
Subject: Archiving on inet
Message-ID: <YhHjSSC00awOERPEVd@andrew.cmu.edu>


Wow, this usenet copyright issue has touched off a pretty heated debate.  

Let me just make a few points:

In most usenet areas, there are no limitations on who may receive the
group.  By posting to such an area, you imply that you intend your post
to be received by an unrestricted audience.  This, of course, includes
the possibility that some readers of the newsfeed will be reading it in
a time-delayed manner, such as a dialup newsfeed over slip, uucp, or
other protocol.  A CD-ROM is just another form of delayed newsfeed.

There are many areas availiable where restrictions are placed upon who
may receive the feed.  Many mailing lists, such as extropians, have this
policy.  Anyone receiving that list agrees that they will not
redistribute the messages, and that includes selling CD-ROMs.  If you
have something which you would like to limit the distribution of, there
are many forums availiable where the readers consent that they will
abide by such a policy.  The general readers of usenet have not
consented to any such agreement.

What offends me is that some hypocritical people would send a message to
an area that they know is public domain, and then complain that they
didn't want their message distributed.  When you post, you should decide
weather or not you want it public domain.  But don't complain if you
change your mind after the fact.

I reccomend that everyone who is concerned about the distribution of
some document that you wrote, (ie research paper, commentary, etc) post
a message in a public forum giving a brief overview, and then state that
it is copyrighted, and that anyone who agrees to respect your terms of
non-distribution should send you email and that you will send them a
copy.  This also allows you to place an expiration time limit on it, so
that someone won't find it reading outdated usenet news.

To continue Lefty's cable TV analogy:  A cable TV company can charge you
a fee for assisting you in receiving a publicly availiable signal. 
However, they do not have copyright on that signal - they can't stop you
from buying your own antenna, nor can they stop a competing cable
company (if the municipality allows it).  The cable company is selling
you their assistance in receiving a publicly availiable signal.  They do
not own that signal or the copyright to it.  They are merely a common
carrier of the communication.  In the same way, internet service
companies like netcom are merely providing a service which aids you in
receiving a publicly availiable signal.  Selling the netnews feed either
on a CD-ROM is no different.  They are not selling the posts - they are
selling their communications services which allow you to receive it. 
They have no copyright on the posts.  They are NOT SELLING COPYRIGHTED
MATERIAL - they are SELLING A COMMUNICATIONS SERVICE.

If a TV station was to take the broadcast of a competing station, add
their own commercials etc, and rebroadcasts it, then we have copyright
infringement.  They are taking someone else's material and using it for
their own benefit - here we have copyright infringement.  The cable
company does not do this - they are simply distributing the signal
unaltered, commercial advertisements and all.  In the same way, if
someone is selling complete, unaltered archives of usenet, it is a
communication service.  If they're taking posts, modifying for their own
purposes, and selling at a profit, we have the possibility of copyright
infringement.  I hope you all understand the difference.





From frissell at panix.com  Tue Feb  1 17:00:49 1994
From: frissell at panix.com (Duncan Frissell)
Date: Tue, 1 Feb 94 17:00:49 PST
Subject: Cypherpunk article in NY
Message-ID: <199402020055.AA18359@panix.com>


Life in Cyberspace - Joshua Quittner
New York Newsday - Page 59
Tuesday, 01 February 1994

CODING UP A BIT OF PRIVACY

MOUNTAIN VIEW, Calif.

This must be how the Founding Fathers looked when they hacked out the 
Constitution :

A roomful of young men, mostly--frazzled hair, eager eyes, wild beards,
arms flailing and fingers jabbing in air, reaching for big ideas.  You
can't help but feel it; urgency tempers their voices.  The earnest men 
plan and argue in this corporate conference room as the last sun rays of
a winter Saturday afternoon fade in through a skylight.

Time is running out for the Cypherpunks.

There is much work to be done before the information highway arrives.
The information highway --- that 500-channel shopping mall/cineplex
championed by cable and telephone companies --- is a noxious concept to
the people in this room.  They are not technophobes or Luddites, these
Cypherpunks,  Instead, they are a collection of clever computer 
programmers, engineers and wire heads from some of the nation's best-known 
Silicon Valley software houses and hardware shops.

This is their central question:  In a future world where all information 
is centralized on a network, where all information is tracked by the bit, 
where every purchase you make and every communication can be monitored by 
corporate America, how does privacy survive?  If you go to the bookstore 
now and buy a book, you can pay in cash.  No one knows your name or what 
you purchased.  "What happens to cash transactions on the information 
highway?" they ask.

The Cypherpunks believe that they can preserve your privacy through good 
cyphers, or codes.  But they must hurry, must get their codes out and 
their networks up and running.

"The whole information highway thing is now part of the public eye," 
explain Eric Hughes, a founder of the Cypherpunk movement.  "If we don't 
change it now, it'll be impossible later."  The Cypherpunks know what 
technology is capable of.  We visit them today because they represent one 
edge of the national debate on the structure of the information highway.  
And as we all know, extreme positions help define the middle.

Many of the Cypherpunks have been heavy Internet users for years and hope 
to preserve the communal spirit of that freewheeling world of 
interconnected computer networks.  They dread the coming commercial 
network of televisions and computers, saying it will displace the 
Internet and destroy many of the freedoms they now enjoy.

So the Cypherpunks, with the kind of zeal they professionally bring to 
marathon, 72-hour sessions hacking computer code, are plotting to keep 
free networks alive.  That's "free" in the sense of unfettered, 
unmonitored, uncensored.

One way they're going about it is by spreading easy-to-use, cheap 
cryptography.  Cryptography is the science of keeping two-way 
communication private.  Computers, it turns out, are revolutionary 
cryptographic tools, able to encode and decode files quickly.  For the 
first time, virtually unbreakable codes are now possible, thanks to 
computers.

The Cypherpunks post cryptographic software on the Internet where anyone 
can access it, and can encode their communications, including electronic 
mail, pictures and video.

The the U.S. government is concerned, as governments always are, about 
the spread of powerful cryptography (terrorists could use it, kidnappers 
could use it, drug dealers could use it, all of them on cellular phones 
that encode conversations).  It currently is pushing its own commercial 
cryptographic standard, through a special chip known as the Clipper.  The 
chip is reviled by Cypherpunks and other civil libertarians because it 
provides a back door that law-enforcement agencies could enter, with the 
proper warrants, for surveillance.

By getting good, unbreakable cryptography out there now, the Cypherpunks 
hope, whatever the government finally decides will be moot.

Software has a wonderful property, the Cypherpunks are fond of saying:  
Once it's created, it can never be destroyed.  It can be copied 
infinitely, from computer to computer, spreading like a secret.  Come 
what may, unbreakable Cypherpunk code, and Cypherpunk networks, will be 
out there forever, they hope.  But just to be safe, the Cypherpunks are 
toying with different network-related plans to create an economy of 
"digicash" --- network money that, like the dollars in your pocket, isn't 
tied to a user's credit cards or other personal identification.  Digicash 
will help pay for Cypherpunk networks and will allow people to purchase 
goods without revealing their identity.

"I'm starting a bank, and it's not going to be a U.S. bank," Hughes 
says.  He standing at the whiteboard now.  A strawberry-blond ponytail 
dangles down his back and he grasps a magic marker in his hand.  "We have 
several long-term strategies, one of which is the elimination of central 
banks."  He tells the assembled crowd what they already know.  Heads 
nod.  Some people take notes.

Hughes is a self-employed programmer in Berkeley.  His hand flies across 
the whiteboard, sketching out a schematic diagram, showing how his bank 
will operate.  The bank will store depositors' money (he's thinking a 
$200 minimum deposit) and disburse payments to anyone --- all over the 
Internet.  It will be based abroad, maybe in Mexico.  A Cypherpunk 
network bank is one way to pay for a network of truly encrypted, private 
communications, you see.

"Is this going to lead the way to portable laptop ATM machines?" someone 
else asks.

"First Bank of Cyberspace!" yells one person.

"First Internet bank!" yells another.

"The Nth National Bank!"

Laughter.  Billy goat beards bob.
There is much work to be done.


*******************************
Net Tips

If you have e-mail access to the Internet, you can subscribe free to the 
Cypherpunks mailing list, which circulates to about 750 people daily.  
Send an e-mail message to:  cypherpunks-request at toad.com with the word "
Subscribe" and your name in body of message.  More information about 
cryptography, as well as cryptographic software, can be obtained over the
Internet by ftp'ing to: ftp.soda.berkeley.edu
********************************

Thanks to Lois for entering this article.
--- WinQwk 2.0b#1165                                                                                                                  





From jim at bilbo.suite.com  Tue Feb  1 17:20:48 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Tue, 1 Feb 94 17:20:48 PST
Subject: SASE Suggestion
Message-ID: <9402020114.AA03481@bilbo.suite.com>




Lance Cottrell writes:

> I have been meditating on this problem of return
> addresses, and have a proposal. The remailers
> can not be allowed to choose the return path,
> as any corrupted remailer will corrupt the rest
> of the path.

As I understand it, the remailers don't "chose" the return path, Bob (the  
sender of the original message) choses the return path when he creates the  
SASE.  All the remailers do is interpret the part of the SASE that becomes  
readable to them after decrypting the SASE portion sent to them from the  
previous hop.  If all is working, what becomes readable is the address of  
the next hop (closer to Bob) and some misc other stuff (postage, maybe,  
and perhaps another encryption key).

Am I not understanding something correctly?

Jim_Miller at suite.com






From lefty at apple.com  Tue Feb  1 17:25:31 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 17:25:31 PST
Subject: Another Request
Message-ID: <9402020106.AA27839@internal.apple.com>


Can anyone give me a pointer to where I might find information about Kerberos?

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From lefty at apple.com  Tue Feb  1 17:25:47 1994
From: lefty at apple.com (Lefty)
Date: Tue, 1 Feb 94 17:25:47 PST
Subject: A Request
Message-ID: <9402020106.AA27836@internal.apple.com>


A few weeks ago, an ad from Microsoft looking for a staff cryptographic
expert was posted.  If anyone saved a copy, can they please forward it to
me?

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From tcmay at netcom.com  Tue Feb  1 17:25:53 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Tue, 1 Feb 94 17:25:53 PST
Subject: archiving on inet
In-Reply-To: <Pine.3.05.9402011809.B17142-b100000@access1.digex.net>
Message-ID: <199402020123.RAA16841@mail.netcom.com>



Boy, this has been one of the most contentious, arguing-in-circles
thread I've seen in a long time. I was getting ready to delete all
these posts by lawyers, semi-lawyers, wannabee-lawyers, and
non-lawyers when I ran across this nice and concise post by Joe Thomas:

> But to attempt to bring this back from misc.legal to cypherpunks territory...
> Have people here thought about what happens to the concept of intellectual
> property in an environment of strong cryptography and cheap anonymity? 
> When there's no way for the government to enforce Berne on movies and
> electronic books, what hope is there for Usenet postings?
> 
> Joe

Exactly! The copyright laws, confusing as they may be, are basically
unenforceable for _private_ and _mostly private_ behaviors. Xeroxing
books, sheet music, and the like is done routinely--stand in a copy
shop for a while and watch what happens. And these things are
indisputably violations of copyright (there is a "grey zone" for short
copying jobs, under the "fair use" interpretatins, but certainly not
for copying entire chapters or books, or sheet music). Ditto for
copying software, as we all know. 

Copying CDs onto tapes is a murkier issue, because of the recent
revisions to the laws and the so-called "tape tax," which collects a
royalty on blank tape while allowing essentially unlimited copying for
_personal_ use (e.g., I can safely tape CDs onto DAT so long as I
don't then _sell_ them).

Where the rubber meets the road on all this stuff is when a visible,
public situation occurs--the college instructor who makes Xerox copies
of a textbook (not his own, but maybe even that is a violation) and
distributes or sells them to a class, the musician in a public concert
who is seen with piles of Xeroxed sheet music, the guy selling dubbed
videos at a flea market, the corporation buying one copy of a program
and then duplicating it for 30 employees, etc. In these cases, a
whistleblower can call in the Music Police (don't know their real
name), the Data Narcs (SPA), etc., and some action _may_ be taken.
(Rarely, for many reasons.)

The hair-splitting about whether making backup copies of Usenet
constitutes any kind of violation is not all that useful. The issue is
what happens when--as is inevitable--folks sell compilations of other
people's postings. Indeed, there was a raging debate on this several
years ago when Brad Templeton was planning to sell a book of the best
jokes he's seen in rec.humor.funny. Maybe the book even came out....I
never did hear the outcome. Anyone know?

With strong crypto and anonymous systems, few actions will be
publically visible enough to allow enforcement and sanctions. 

Copyrighted material may be sent through remailers to protect the
source (recall the "Information Liberation Front"). Ditto for other
kinds of "software."

A brave new world. My fear is that the NII will be structured so as to
limit crypto use with a public rationale of preventing these kinds of
abuse (the private rationale being the NSA/FBI/national security state
sorts of things).


--Tim May, who's not a lawyer and doesn't want to become one

(and who hates to see fine minds devoted to the credo "Cypherpunks
study law")


-- 
..........................................................................
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.




From klbarrus at owlnet.rice.edu  Tue Feb  1 17:40:48 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Tue, 1 Feb 94 17:40:48 PST
Subject: REMAIL: ping, script
Message-ID: <9402020140.AA07524@screech.owlnet.rice.edu>


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

I've been catching up on past messages; I see there was some interest
in scripts for pinging remailers, and some questions about how many
there are, etc.

Here is the data file and script I use to ping non-special remailers.
Note: remailer #12 will only remail if you attach "digital cash",
remailer #20 batches until midnight, remailer #21 requires encryption.

Save this as "remailer.data"

- ----------8< cut here >8----------
01:n:remailer at chaos.bsu.edu
02:n:nowhere at bsu-cs.bsu.edu
03:n:hh at cicada.berkeley.edu
04:n:hh at pmantis.berkeley.edu
05:n:hh at soda.berkeley.edu
06:n:00x at uclink.berkeley.edu
07:y:hal at alumni.caltech.edu
08:y:ebrandt at jarthur.claremont.edu
09:y:catalyst at netcom.com
10:y:sameer at netcom.com
11:y:remailer at rebma.mn.org
12:y:elee6ue at rosebud.ee.uh.edu
13:y:elee7h5 at rosebud.ee.uh.edu
14:y:hfinney at shell.portal.com
15:y:sameer at soda.berkeley.edu
16:y:remail at tamsun.tamu.edu
17:y:remail at tamaix.tamu.edu
18:y:remailer at utter.dis.org
19:y:remailer at entropy.linet.org
20:y:elee9sf at menudo.uh.edu
21:s:remail at extropia.wimsey.com
- ----------8< cut here >8----------

and then the script

- ----------8< cut here >8----------
#!/usr/local/bin/perl
#ping the anonymous remailers
#Karl L. Barrus <klbarrus at owlnet.rice.edu>

open (IN,  "remailer.data") || die "Can't open remailer.data\n";

while (<IN>) {
  ($num, $rest) = split(/:/, $_, 2);
  $remailers{$num} = $rest;
}
close (IN);

#ping all remailers except special ones
foreach $i (sort keys(%remailers)) {
  ($mode, $name) = split(/:/, $remailers{$i});
  print "remail via $name" if $mode ne "s";

  open (MAIL, "| /usr/lib/sendmail " . $name);
  print MAIL "To: " . $name;
  print MAIL "From: nobody\n";
  print MAIL "Subject: test " . $i . "\n";
  print MAIL "Request-Remailing-To: klbarrus at owlnet.rice.edu\n";
  print MAIL "\ntesting :-)\n";
  close (MAIL);
  sleep 5;
}
- ----------8< cut here >8----------

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU8EUIOA7OpLWtYzAQFbjAQAhMj765Rd7r4BgRkXnRKmSRuJRphyNz/6
3Q7N4v+rQME44ZtiufDkxEyxj/M7s+bMXRqP+2n+gXVSaAgXq/g2CFrVisyvL70P
6RS//XHaoThJHRPp9x0/p9fO2MMeqOct0YXtYWi2C9LlU8B9/smjm7/Qg6q65tgk
D3FgR6YAlZI=
=bl8B
-----END PGP SIGNATURE-----





From warlord at MIT.EDU  Tue Feb  1 18:35:28 1994
From: warlord at MIT.EDU (Derek Atkins)
Date: Tue, 1 Feb 94 18:35:28 PST
Subject: Another Request
In-Reply-To: <9402020106.AA27839@internal.apple.com>
Message-ID: <9402020234.AA14461@toxicwaste.media.mit.edu>


You can obtain a lot of documentation from the anonymous ftp site:
	ftp://athena-dist.mit.edu/pub/kerberos/doc

There are a lot of papers, docs, etc in that directory.

Hope this helps.

-derek





From jthomas at access.digex.net  Tue Feb  1 18:55:28 1994
From: jthomas at access.digex.net (Joe Thomas)
Date: Tue, 1 Feb 94 18:55:28 PST
Subject: The Death of Statutory Compensation for Intellectual Property (was pissing contest)
In-Reply-To: <9402020038.AA02579@jazz.hal.com>
Message-ID: <Pine.3.05.9402012025.C18786-c100000@access3.digex.net>


On Tue, 1 Feb 1994, Jason Zions wrote:

> Surprise. Within ten years, the entire concept of intellectual property will
> be radically altered, if not completely gone. The whole thing will become so
> completely unenforceable that something will give; I'm not sure what, but
> something.

Here's my slant on it:

Without government coercion, "intellectual property" is limited to its
only natural form -- a secret.  If you don't want everyone to have certain
information, don't tell anyone.  At the very least, don't tell anyone who
has no incentive to keep the information to himself.

> At the Austin Crypto Conference, John Perry Barlow was asked what he thought
> would happen to copyright. As I recall, he said something along the lines of
> this: that compensation for intellectual property would cease to be a thing
> of law and become a thing of interpersonal relationships. That people would
> pay the producers of stuff they liked as an incentive for them to produce
> more. That the ability of the Internet and its services to make
> widely-separated people into a community, with all the emotions and duties
> humans tend to experience in communities, would ensure a kind of darwinism
> amongst the "stuff" out there; the stuff people liked would get supported
> out of that sense of community, and the stuff people didn't like would not.


EFF Co-Founder Solves Prisoner's Dilemma
   Game Theorists Had Neglected
  "Community Spirit," Says Barlow

> Shareware is the future of just about all intellectual property.

Maybe.  I wouldn't expect to get rich on it, though...

>         There are only a few ways the studios could get huge bucks:

[most of list deleted]

> 4) Serializing digital copies to track down the "leaker". All you need is
> two copies from different sources to find steganographically-hidden bits or
> to produce a combination of the two that has a unique fingerprint that
> doesn't match anything already shipping.

Is this really a settled issue?  I'll bet I could devise a scheme for
tagging a large number of copies of an image, such that the information
available to a cheater from two images isn't enough to produce an
untraceable copy.  Such a scheme would entail some image degradation -- if
you didn't mess with some visible bits in each picture, a cheater would
only have to randomize all the "invisible" bits.

But of course this stuff is only useful if the work is distributed
non-anonymously in the first place.  It doesn't do QVC/Paramount much good
to know that an2538295 was the one responsible for redistributing 10,000
copies of Star Trek L.

Computer software and other interactive works should fare better, since
the publishers can restrict their distribution to secure machines on a
network.  Customers would pay to use the software, but never receive a copy of
their own.  Reverse-engineering even "Dragon's Lair"-type games would be
non-trivial and error-prone.  And after getting ripped off for a bad
interactive copy, most people would probably be happy to pay a premium for
the real thing.

Joe







From ebrandt at jarthur.Claremont.EDU  Tue Feb  1 19:30:49 1994
From: ebrandt at jarthur.Claremont.EDU (Eli Brandt)
Date: Tue, 1 Feb 94 19:30:49 PST
Subject: fwd: Canadian gov't eavesdropping
In-Reply-To: <94Feb1.201622est.83288(2)@ivory.educom.edu>
Message-ID: <9402020326.AA05527@toad.com>


> Date:	Tue, 1 Feb 1994 20:21:46 -0500
[...]
> HIGH-TECH SNOOP GADGET.  A super-secret branch of the Canadian Security
> Intelligence Service has awarded three contracts to a Montreal firm to make
> equipment that can quickly isolate key words and phrases from millions of
> airborne phone, fax, radio signals and other transmissions. The hardware
> has the "Orwellian potential to sweep through ... and keep records of all
> conversations," said one CSIS critic.  (CTV National News, 01/31/94 11:00
> pm).

Dunno how feasible this kind of keyword recognition presently is,
but here's another reason to encrypt.

> EDUPAGE. To subscribe to Edupage send e-mail to listproc at educom.edu,
> containing the following text: SUB EDUPAGE yourfirstname yourlastname. To

   Eli   ebrandt at jarthur.claremont.edu





From jim at bilbo.suite.com  Tue Feb  1 21:20:49 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Tue, 1 Feb 94 21:20:49 PST
Subject: 2-way anonymous via SASE
Message-ID: <9402020513.AA07003@bilbo.suite.com>



Jon Boone writes:

>  Now, what is this SASE?  Apparently it is either a) a
> fully-specified   return-path (presumably a chain of
> anonymous ids at various remailers),   b) a next-hop
> address (anonymousid at the next remailer that "knows"  

> where to send the message), or c) some combination of the
> previous two.
> 

>   Is there another possibility that I have missed? 

> 


The SASE's that I've been describing are not type a, b, or c.

"b" is closest, except the next-hop address is not an "anonymousid at the  
next remailer", rather, it is simply the e-mail address of the next  
remailer to send to.

The SASE is structured somewhat like a message enclosed in a bunch of  
nested digital envelopes.  If you don't understand "message enclosed in a  
bunch of nested digital envelopes" then you will have a hard time  
understanding SASE's (at least the type of SASE's I'm describing).


** Using Nested Envelopes for sending anonymous e-mail (simplified) **

Say Bob wants to send a message to Ted, routing the message through R1 and  
R2, and finally to Ted.  First of all, Bob needs to know the e-mail  
address of R1, R2, and Ted.  Bob also needs to know the public-key of R1,  
and R2.  He will probably also want to know the public-key of Ted, but  
that is not required.

[Notice that I did *not* say the Bob needed to have an anonymous account  
id at each of the remailers.  There are different types of remailers.   
Some provide anonymous accounts, others simple forward e-mail.  In the  
description below, I am referring to remailers that just forward e-mail.]


To send to Ted, Bob constructs the following: (not considering SASE's yet)

      R1_PK(R2-addr, R2_PK(Ted-addr, Ted_PK(message)))

where:
   XX_PK(stuff)     stuff encrypted with XX's public-key
   XX-addr          e-mail address of XX


Bob sends this mess to R1.

>From R1's point of view, R1 receives

      R1_PK(stuff1)
      

R1 decrypts "stuff1" and gets:

      R2-addr, R2_PK(stuff2)

R1, strips off "R2-addr" and e-mails R2_PK(stuff2) to "R2-addr".

R2 receives

     R2_PK(stuff2)
    

R2 decrypts "stuff2" and gets

     Ted-addr, Ted_PK(message)

R2 strips off "Ted-addr" and e-mails Ted_PK(message) to "Ted-addr".

Ted receives

     Ted_PK(message)
     

Ted decrypts it, and gets Bob's message.


As you can see, you need to use a special type of remailer to get this to  
work.  Not all remailers support the "decrypt, strip, and re-send"  
operation.

You seem to be familiar with the type of remailer that sets up an  
anonymizing "account" (e.g. an12345 at anon.penet.fi).  These "Penet-style"   
remailers give you an easy mechanism for doing 2-way anonymous  
communication.  Ted can use ordinary e-mail commands to send a reply  
addressed to "an12345 at anon.penet.fi".

The "decrypt, strip, and re-send" remailers do not provide a trivial way  
to send reply messages.  The SASE mechanism is an attempt to extend these  
types of remailers so Ted can reply to whomever sent him the anonymous  
message (Ted doesn't know anything about the original sender, not even a  
anonymous id.  Ted only knows that R2 forwarded a message to him).


Jim_Miller at suite.com






From jim at bilbo.suite.com  Tue Feb  1 21:40:48 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Tue, 1 Feb 94 21:40:48 PST
Subject: 2-way anonymous via SASE
Message-ID: <9402020534.AA07060@bilbo.suite.com>



I finally got around to downloading and reading the remailer stuff from  
the cypherpunks ftp site*.  I could have saved myself some embarrassment  
if I had read it before posting my "original" SASE idea.  The file

     pub/cypherpunks/remailer/hals.instructions

describes a mechanism that is basically a simplified SASE.

Oh well...

Jim_Miller at suite.com

---------
*ftp soda.berkeley.edu





From nobody at qwerty.org  Tue Feb  1 22:10:49 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Tue, 1 Feb 94 22:10:49 PST
Subject: New Remailer Up.
Message-ID: <199402020607.WAA29302@mail.netcom.com>


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

Greetings.

New remailer: qwerty at netcom.com.

No logs. Only a "counter" that works by appending the word "R" or "ER" to a
text file so I can get an idea if anyone is using it. However, I'm sure the
Netcom and other site's mail logs will be enough to track serious abusers
of anonymity down, without my help. This remailer is dedicated to honest
people who desire PRIVACY.

(The extra "-" and "space" characters at the beginning of some lines are an
artifact of my signing this with PGP).

Accepts standard,
::
Request-Remailing-To: address
(space)
message

or standard,
::
Encrypted:PGP
(blank line)
- -----BEGIN PGP MESSAGE-----
Version: 2.3

Blah blah blah.
- -----END PGP MESSAGE-----
(blank line)
Optional message here.

in which the first two lines of the decrypted message contains,
::
Request-Remailing-To: address
(blank line)

Spelling mistakes will land mail in my mail box where I will emotionlessly
delete them. Leaving out the blank lines may cause messages to dissapear.

Public key for Qwerty Remailer <qwerty at netcom.com>,

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

mQCNAi1NtgAAAAEEALD07N5RllpklGhOQaiYtRupb+8Jm1M34ya8rxmcNUCVndcb
JgH9EW1Z2VvkJ3vTcEOOBK9jM/HCIGDqBbQZR8VOLbLNOD7VQIzTpyTOmZJCMSZG
bqZtRtP6KDtMcTx1SgHq9LiRNz5YUyB3WOV963y8W/x00QS4yGkgCDZkVQXZAAUR
tCNRd2VydHkgUmVtYWlsZXIgPHF3ZXJ0eUBuZXRjb20uY29tPokAlQIFEC1OzEgE
sxus60J9UQEB224D/jUcYRnXmIj9nt4Y7sjGYTmO+v7b9W+rsxYLn6+hCGmx5iQJ
zPr3ggvm8ylBZnNp3WUxssDlb9GyiK801vzm6HDXWd/yCeGXHX7YB2DDFd5WrK70
/XGTMGv3gvNnExIM+UVv5tl8y/YXOfeLWWGttD6a60MkUNxAOGT9qBsUTqJNiQCV
AgUQLU3TdWkgCDZkVQXZAQH1ygP/TCY7T0PdNVRUVbEpN9YsbxFKhFT/7+hZTySr
Md0j2GrObjcRc7aa0c9lEZrtKpaDCJkgF+7k20z1eQpw7zD/dO+ZsSqni62TLGYa
pdTsAiYbev90Nb+1S2ST36KvIgJSmQS6zvgpToTRpGwYhJhqTZhTo8Z2U5ufb+SF
TsNMd0Q=
=BXnK
- -----END PGP PUBLIC KEY BLOCK-----

See the PGP FAQ for how to use encrypted remailers. Send mail to
na38138 at anon.penet.fi with subject "Bomb me!" for Gary Edstrom's PGP FAQ
and my "Here's How to MacPGP!" guide.
That's NA (not AN), thirty-eight, one-thirty-eight.

Thanks to Hal Finney for sending me updated perl scripts and a working copy
of UNIX PGP2.3a. I am looking into ViaCrypt UNIX PGP 2.4 as well.

Send mail regarding the remailer to qwerty at netcom.com.

 -Xenon

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLU77FgSzG6zrQn1RAQHlvgQAj2S4bYB+5dEDubfzk8etdBOSbehxfF/o
B8ycAHgbHjs0SI9HEb0Xm9RJP+ZLtFfD8J7KgOWe0cJlWdy8NKwJxh55Uqn6yiQn
IHB2M9x51nXD3ySCIH8f2USXuHYj8qiInzvQwP6naNiC0vU9E+4ab02Th+IbC8zL
n9Jthe+vTf8=
=MEvY
-----END PGP SIGNATURE-----






From nobody at qwerty.org  Tue Feb  1 22:55:29 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Tue, 1 Feb 94 22:55:29 PST
Subject: SuperPing1.2
Message-ID: <199402020651.WAA05123@mail.netcom.com>


This may not be elegant, but it works well in my account. It checks
the entire Cypherpunk remailer network connections and is user friendly.

-Xenon

#!/usr/bin/perl
# Change this to reflect where your system has perl.

# SuperPing version 1.2: Ping Cyperpunk remailer connections.
# Now pings in both directions, as I have learned they are NOT equivalent.
# Brought to you by Xenon <na38138 at anon.penet.fi>.
# Thanks to Alan Barrett for teaching me some perl.

# Warning: outputs ~40 e-mails at a time. May give "too many processes"
# error towards the end if you haven't killed all of your stopped jobs.
# Increase the sleep(sec) time if needed. 

# Be careful. If mail bounces between any two remailers in either
# direction, "Mr. Remailer Operator" will obtain a full mailbox! 

# To test the program, comment out all the remailers in the list and add
# YOUR address at least three times to the list of "remailers".

# You MUST make a file called .PingFile that contains:
#::
#Request-Remailing-To: your.address
#
#Ping!
#
#-----Begin Test-----
#Test
#-----End Test-----

# Will also function as a convenient method to shut down all remailers at
# once by making .PingFile 500K instead of 1K. Not recommended if you
# value your life ;-). 

# List of remailers (not complete). Make any line a comment to remove that
# line's remailer. cicada and pmantis are not meant for heavy traffic so I
# have removed them. Soda is commented for no particular reason.

@Rm = (
"catalyst at netcom.com",
"remailer at dis.org",
"ebrandt at jarthur.claremont.edu",
"remailer at merde.dis.org",
"qwerty at netcom.com",
"elee7h5 at rosebud.ee.uh.edu",
"hfinney at shell.portal.com",
#"hh at soda.berkeley.edu",
);

#Nicknames for output and subject lines.

@Nick = (
"catalyst",
"dis.org",
"jarthur",
"merde",
"qwerty",
"rosebud",
"shell",
#"soda",
);

# Select a marking character for this SuperPing session.
@Mark = ("A","B","C","D","E","F","G","H","I","J","K","L","M","N","O",
"P","Q","R","S","T","U","V","W","X","Y","Z");

srand(time);
$M = $Mark[rand(26)];

# Strings, since lines got too long below.
# Obviously this could be written better using sendmail but I'm writing
# perl code without KNOWING any perl.

  $A = "(echo \"::\" ; echo \"Request-Remailing-To: ";
  $B = " ; echo \"\" ; cat .PingFile) | mail -s \"$M.";

# Send a "Ping!" between all combinations of two remailers, in both
# directions. $Num is a count that ends up in the Subject line. Each number
# is used twice, with a < and > telling which direction the mail went. Change
# "system" to "print" to see the Unix commands being produced. 

foreach $Sec (0..$#Rm) {
    foreach $First ($Sec+1..$#Rm) {
     $Num++ ;

     $C = " $Nick[$First] > $Nick[$Sec]\" " ;
     system "$A$Rm[$Sec]\"$B$Num$C$Rm[$First]";
     print "$M.$Num $Nick[$First] > $Nick[$Sec]\n";
     sleep(1) ;
 
     $C = " $Nick[$First] < $Nick[$Sec]\" " ;
     system "$A$Rm[$First]\"$B$Num$C$Rm[$Sec]";
     print "$M.$Num $Nick[$First] < $Nick[$Sec]\n";
     sleep(1) ;
   }
}


# Output (with only catalyst, qwerty and rosebud checked) looks like this:

# S.1 qwerty > catalyst
# S.1 qwerty < catalyst
# S.2 rosebud > catalyst
# S.2 rosebud < catalyst
# S.3 rosebud > qwerty
# S.3 rosebud < qwerty

# These are printed out as the program progresses and they also appear as
# the Subject of each piece of mail.

# alias g '(grep Subject: /usr/spool/mail/n/name | sort -t. +1 -n) | more'
# will make the command "g" give a list of received pings, in order. /n/name
# is your part of the mail spool. You should also check that the received
# pings really came from the second remailer instead of getting short
# circuited by the first remailer.

# Sample output mail as received by a remailer:
# 
#From: Your name <your.address>
#Message-Id: <numbers at your.site>
#To: qwerty at netcom.com
#Subject: S.1 qwerty > catalyst
#Status: R
#
#::
#Request-Remailing-To: catalyst at netcom.com
#
#::
#Request-Remailing-To: your.address
#
#Ping!
#
#-----Begin Test-----
#Test
#-----End Test-----





From ritter at cactus.org  Tue Feb  1 23:25:29 1994
From: ritter at cactus.org (Terry Ritter)
Date: Tue, 1 Feb 94 23:25:29 PST
Subject: NxM DES
Message-ID: <9402020724.AA29200@cactus.org>





                   Ritter Software Engineering
                       2609 Choctaw Trail
                       Austin, Texas 78745
                (512) 892-0494, ritter at cactus.org



          Strong Block Ciphers from Weak Ones: NxM DES
               A New Class of DES Operating Modes

                          Terry Ritter
                        January 31, 1994


Introduction

Many security vendors are now preparing a new generation of software
and hardware products.  Given the well-known criticism of DES, and the
government's unwillingness to publish their new Skipjack algorithm,
much attention has been focused on triple-DES as a replacement for DES.
But triple-DES requires three times the processing of normal DES, and
retains the same small block size which must be increasingly vulnerable
to improved dictionary attacks.  Thus it is reasonable to seek
alternatives to triple-DES, and compare them with respect to keyspace,
processing requirements, and block size.  Vendors should be cautioned
that triple-DES is not the only, nor necessarily the best, alternative
to DES.  They should consider delaying implementation of alternatives
until a consensus develops on exactly what the replacement should be.

New ciphering algorithms are often challenged to "prove" they are
stronger than DES.  Since it is impossible to measure the "strength"
of a cipher (and there has been no absolute proof of strength for any
practical cipher), new cipher algorithms are often considered
curiosities.  On the other hand, DES itself is well-known and accepted
(despite having no proof of strength), so there seems to be great
interest in the possibility of forming from DES a stronger cipher. 
Triple-DES is one approach at forming that stronger cipher, and is what
we could call a 1x3 DES structure: one DES block wide by three DES
cipherings deep.  Naturally, we expect software for any three-level
ciphering to operate at about one-third the speed of normal DES. 

There is an alternative approach which offers a larger keyspace,
reduced processing, and larger block sizes (which, nevertheless, can
often be used without data-expansion beyond that of normal DES).  I
call that approach "NxM DES," of which 2x2 DES is perhaps the easiest
nontrivial example:


2x2 DES

Instead of repeatedly enciphering a single 8-byte block, consider using
multiple DES cipherings to form a 16-byte block operation and thereby
improve plaintext block statistics.  2x2 DES will be two DES blocks
wide by two DES cipherings deep.  

First, encipher two data blocks with DES, each under a different key. 
Exchange half the data in the first and second blocks.  Then encipher
the resulting blocks again, using two more keys:

Let us denote a DES enciphering by:  

     ciphertext := DESe( plaintext, key ) .  

We want to encipher two DES-size blocks, call them A and B, and end up
with ciphertext blocks G and H:

     C := DESe( A, k1 );          D := DESe( B, k2 );
     E := C[0..3],D[4..7];        F := D[0..3],C[4..7];
     G := DESe( E, k3 );          H := DESe( F, k4 );

The byte-index notation on the second line is intended to convey the
exchange of the rightmost four bytes of the first two DES ciphertexts. 
The exchange is a permutation, costless in hardware, and simple and
cheap in software.  This particular permutation is also a self-inverse,
so that the same permutation can be used for both enciphering and
deciphering.  If we give each two-bytes of data a symbol and denote the
original data as:

     0123  4567

then after the permutation we have:

     0167  4523 .

For example,

     A:    01A1D6D039776742       B:   5CD54CA83DEF57DA
     k1:   7CA110454A1A6E57       k2:  0131D9619DC1376E
     C:    690F5B0D9A26939B       D:   7A389D10354BD271
     E:    690f5b0d354bd271       F:   7a389d109a26939b
     k3:   07A1133E4A0B2686       k4:  3849674C2602319E
     G:    b4de11d10c55c267       H:   64f1a0b723d360a7 .

Deciphering is similar to enciphering, except that the last-stage keys
are used first, and we use DES deciphering instead of enciphering:

     E := DESd( G, k3 );          F := DESd( H, k4 );
     C := E[0..3],F[4..7];        D := E[0..3],F[4..7];
     A := DESd( C, k1 );          B := DESd( D, k2 );

Thus, 2x2 DES enciphers DES blocks A and B to DES blocks G and H in
four DES cipherings.  This is faster than triple DES, because twice as
much data are enciphered in each block:  2x2 DES has a cost similar to
double-DES.  But 2x2 DES is potentially stronger than triple-DES,
because each of the resulting ciphertext bits is a function of 128
plaintext bits (instead of 64), as well as three DES keys.  (Although
four keys are used in 2x2 DES, only three keys affect each output
block, a 168-bit keyspace.) 

2x2 DES does have a larger block size, so, when used alone, last-block
padding overhead increases from four bytes (on average) to eight; a
four-byte data expansion.  Naturally, when used alone in CBC mode, the
initialization vector (IV) will also be larger, 16 bytes instead of 8. 
This 12-byte overall increase in overhead should be weighed against the
stronger 16-byte block size, since strength is the reason for moving
away from normal DES in the first place.  


4x2 DES

In a manner similar to 2x2 DES, we can consider enciphering four DES
blocks of plaintext, sharing data between them, and then enciphering
the resulting four blocks again.  4x2 DES has a larger keyspace than
2x2 DES, yet retains the same ciphering cost.  4x2 DES does have some
additional last-block and IV overhead, in return for a greater keyspace
and larger block-size strength.  Each 4x2 ciphering requires eight DES
keys:  

     E[0..7] := DESe( A, k1 );
     F[0..7] := DESe( B, k2 );
     G[0..7] := DESe( C, k3 );
     H[0..7] := DESe( D, k4 );

     (swap right-hand half of the data in {E,F} and {G,H})
     I := E[0..3],F[4..7]
     J := F[0..3],E[4..7]
     K := G[0..3],H[4..7]
     L := H[0..3],G[4..7]

     (swap the middle half of the data in {I,L} and {J,K})
     M := I[0..1],L[2..5],I[6..7]
     N := J[0..1],K[2..5],J[6..7]
     O := K[0..1],J[2..5],K[6..7]
     P := L[0..1],I[2..5],L[6..7]

     Q := DESe( M, k5 );
     R := DESe( N, k6 );
     S := DESe( O, k7 );
     T := DESe( P, k8 );

The intermediate permutation involves four 32-bit exchange operations,
an expense still trivial compared to the DES ciphering operations.  (In
a hardware implementation, the byte-swaps are the connections always
needed between stages, just connected differently, with no added
expense at all.)  This permutation is also a self-inverse.  If we
denote each two-bytes of the data symbolically:

     0123  4567  89ab cdef

then after the permutation, we have:

     0da7  49e3  852f c16b .


Alternately, if we denote the data prior to permutation as:

     0000  1111  2222 3333

then after the permutation we have:

     0321  1230  2103 3012 ,

showing that each permuted block contains exactly two bytes from each
of the four original DES blocks.  Each 8-byte output block in 4x2 DES
is a function of 32 bytes of input plaintext, as well as five DES keys,
a 280-bit keyspace.

For example,

     A:    01A1D6D039776742       B:   5CD54CA83DEF57DA 
     C:    0248D43806F67172       D:   51454B582DDF440A

     k1:   7CA110454A1A6E57       k2:  0131D9619DC1376E
     k3:   07A1133E4A0B2686       k4:  3849674C2602319E

     E:    690F5B0D9A26939B       F:   7A389D10354BD271
     G:    868EBB51CAB4599A       H:   7178876E01F19B2A

     M:    690f876ecab4d271       N:   7a38bb5101f1939b 
     O:    868e9d109a269b2a       P:   71785b0d354b599a

     k5:   04B915BA43FEB5B6       k6:  0113B970FD34F2CE
     k7:   0170F175468FB5E6       k8:  43297FAD38E373FE

     Q:    89af722f592664c4       R:   012d483a04db300f
     S:    dd60060ad098e3e0       T:   a3832dc4ff5c99ad .


Again, 4x2 DES deciphering is similar, except that we use the last-
stage keys first, and DES deciphering instead of enciphering.  


NxM DES

8x2 DES would have a 64-byte block and 16 DES keys, yet should still
be considerably faster than triple-DES.  Even larger blocks are
possible, but would seem to require exchange operations on non-byte
boundaries (to assure that each permuted block contains bits from each
stage-one ciphertext block), so 16x2 DES and larger structures may have
a larger software permutation cost.  Nevertheless, the Nx2 approach
gives us a way to increase the keyspace while generally retaining
processing costs similar to double-DES.

DES structures with additional ciphering levels, such as 2x3 DES or
4x3 DES, are also available, at a processing cost similar to triple-
DES, but with the increased strength of a larger block size.  A 2x3 DES
structure would have a 280-bit keyspace similar to 4x2 DES, but with
50 percent higher processing costs.  A 4x3 DES structure could be
appropriate for some applications, but would have a huge 504-bit
keyspace which would require us to create, transport and store the
associated 84-byte key set.  


Large Blocks in Existing Systems

It should be possible to adapt many existing systems to use larger
blocks without further data expansion.  Consider an 82-byte message,
which would normally be structured as eleven 8-byte DES blocks, for a
total of 88 bytes:  An NxM DES alternative might use two 4x2 DES
blocks, one 2x2 DES block, and one 1x3 DES block, for 32+32+16+8 or 88
bytes, exactly the same as normal DES.  A 63-byte message (normally 8
DES blocks) would use just two 4x2 DES blocks for a total of 64 bytes,
also the same as normal DES.  If larger blocks are always used until
smaller blocks would be more efficient, there is exactly one way to
structure any given amount of data, and the resulting length is
sufficient to reproduce the multiple-size blocking structure.  The
overhead of these blocking manipulations remains insignificant when
compared to the DES ciphering operations.  We could call this sort of
use of multi-size blocking "NxM+ DES," and 4x2+2x2+1x3 DES (which we
could call "4x2+ DES") would seem to be a very practical system.  

Clearly, in CBC mode, 4x2 DES will require a larger IV than normal DES. 
Perhaps the IV could be transferred as part of the key-exchange; there
is obviously no way to avoid using larger keys if we want a stronger
cipher, whatever approach we use.  Smaller blocks at the end of a data
area could just take the left-most part of the preceding block as their
chain value.  Similarly, a 2x2 DES block might use the left-most two
DES keys at both levels of a 4x2 DES block (k1,k2,k5,k6), while a 1x3
DES block might just use the first three keys of the 2x2 DES block.  

Overall, 4x2+ DES might be a simple firmware upgrade for existing DES
hardware.  


Summary

Because the DES cipher is well known, there is interest in creating a
stronger cipher which builds on normal DES as a base.  By introducing
a larger block width in addition to repeated cipherings, additional
complexity can be obtained with a moderate increase in processing. 
This approach is unusual in that various levels of strength can be
obtained at virtually the same processing cost, a cost comparable to
double-DES and substantially less than triple-DES.  Furthermore, the
larger data blocks can be used even in systems which would not support
data expansion beyond that inherent in normal DES.  Consequently, the
NxM DES approach would seem to have significant practical advantages
over either double-DES or triple-DES as a replacement for DES.  

NxM DES is a product of my own research.  I am not aware that this
approach has been previously published.  







From sameer at soda.berkeley.edu  Wed Feb  2 00:30:50 1994
From: sameer at soda.berkeley.edu (Sameer)
Date: Wed, 2 Feb 94 00:30:50 PST
Subject: Anonymous mail service up for alpha testing
Message-ID: <m0pRcum-00010YC@infinity.hip.berkeley.edu>


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

	I've written a small anonymous mail service, and it's now
available for testing. There's no security, and I'll be keeping logs,
so don't think that it's secure, in any way. It's also running on a
PPP link which isn't connected all the time, so it's rather flaky.
	(I'll set it up as a real service once I get a real link-- if
anyone else wants to do it, they're welcome to use my code.)

	How to get an anonymous account:

	Send mail to admin at infinity.hip.berkeley.edu -- include in the
message a login, a "Full Name", a choice of remailer, and an encrypted
return address block encrypted with that remailer's public key.
	I'll set it up.

	How the anonymous account works:

	Someone will send mail to
login at infinity.hip.berkeley.edu. Then the system looks up in a table
which remailer is associated with that login. It then sends out mail
to that remailer, starting with the contents of the encrypted return
address block, then a "##" and then all of the message to
login at infinity, with "Received" lines taken out.

	Thus once the message gets to the last remailer of the chain
in the encrypted return block, the ## pasts the identifying
information of the person mailing to login at infinity.hip in the header
of the message. (It *should* do that...) If the person mailing to the
infinity address would like anonymity he/she should use an anon-mailer
on his/her end.

The encrypted-return address you send me should look like:

::
Encrypted: PGP

- -----BEGIN PGP MESSAGE-----
etc.

	Make sure you include that ::/Encrypted or the remailer which
gets it won't know that it's PGP encrypted.

	Remember, this is just setup for testing. Don't use it for
real applications.

- -Sameer

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU9jrni7eNFdXppdAQH/FwP/b9pllDYnW6L4x0y1dVnC6km9TQ9lTw2x
U/ea87JnguYSHYRxOk6lZoBBx5ZH/A48OCHJztzWHaSP2Tq69Oro4FTrtRcpTjbf
ti8L97x9+Xvx1A6/Vkw1nuS5MRJ8SoPUV4bDKFdf80Ykhik5bk8b0WOUew1uF6dq
QJzyDsKDFQU=
=2EIr
-----END PGP SIGNATURE-----




From qwerty at netcom.com  Wed Feb  2 01:10:50 1994
From: qwerty at netcom.com (Qwerty Uiopas)
Date: Wed, 2 Feb 94 01:10:50 PST
Subject: New Remailer Up.
Message-ID: <199402020908.BAA13212@mail.netcom.com>


...and, to mail to an anon.penet.fi address, you must change the an1234 to
na1234 (not anonymous), for I have a password/anon.penet.fi address for
this account but I don't wish to either 1) give it out so anyone could then
change it, or 2) have Julf remove it, so anyone could remail to anon.penet.fi
but a few could also forge mail from qwerty to set a password.

-Xenon





From edgar at spectrx.saigon.com  Wed Feb  2 01:10:56 1994
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Wed, 2 Feb 94 01:10:56 PST
Subject: Remailer Tearline Conventins
Message-ID: <wo44gc6w165w@spectrx.saigon.com>


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

Someone (not me) asked about remailer tearline conventions to
eliminate automatic sigs:

    Though this subject came up some months ago, I never noticed any
    final decision.

    Is there now an accepted tearline convention for the generic
    cypherpunks remailers?  The mail handler here and at most of my
    other accounts automagically adds the host address and/or my
    address to all outgoing mail, which
    is...well..._counterproductive_ when sending mail to a remailer.
    The extropia remailer by accepting encrypted messages avoids this
    problem, but most of the other remailers seem to have no
    provisions for excluding extraneous text and address footers.

    Was there ever a "8<----(cut here)" arrangement agreed upon and
    incorporated into the remailers?

I'm the one who brought this up "months ago" and the short answer to
your question is "no."

One remailer

    Hall Remailer     <nowhere at bsu-cs.bsu.edu>

added a "cut line" of

   --ignore--

[no indentation in actual use].  I tested this when Hall first
announced it and it seems to work.  You would be advised to test it
yourself before relying on it.  Unfortunately the Hall Remailer is one
of the remailers that does not support encryption.  AFIK, this "cut
line" code was never propagated to any other Cypherpunks remailers.

At the time I brought this up, the attitude of most remailer operators
(Chael Hall and Miron Cuperman notably excepted) was that anyone who
couldn't figure out how and remember to turn off their auto sig didn't
deserve any privacy.

I recommend that you always use the wimsey (extropia) remailer as the
first (or only) leg of a remailer chain.  It is also the only
Cypherpunks remailer outside the USA (it's in Canada) which will make
tracing msgs a little more difficult for USA authorities.

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU5FJt4nNf3ah8DHAQECYQP/f2LDs7Tq1PfrH4PQBOR0Iu1XIrCDztZB
dVapPFSjfF2Y20ljWqHsMK7xjUpfLpaXluFogav9DpGgey/zrO48MJJf8gFBGsJA
7gsOUl3Yc3VDPWvWI18zN4MgYeeEfRoTXIToWSeiadJmiEMq5m0hqs1bjZwOmmSr
rewqGMxMUeI=
=U43w
-----END PGP SIGNATURE-----

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






From nobody at qwerty.org  Wed Feb  2 02:10:49 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 02:10:49 PST
Subject: SuperPing1.2
Message-ID: <199402021008.CAA22797@mail.netcom.com>


If it wasn't obvious, SuperPing is the sort of utility that only needs to
be run say once a day by ONE person out there. Since I did it today, and
I haven't reported any down links, you can be rest assured the network
is fully connected, at least the remailers listed in the code.

-Xenon





From nobody at qwerty.org  Wed Feb  2 02:25:28 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 02:25:28 PST
Subject: Remailer Tearline ConventiOns.
Message-ID: <199402021025.CAA23813@mail.netcom.com>


Edgar wrote,
"I recommend that you always use the wimsey (extropia) remailer as the
first (or only) leg of a remailer chain."

I'm not too familiar with extropia these days. Does it have a direct
internet connection? What is its characteristics? I'm trying to make
up a more useful list of remailers, with details, since different
users do have different needs for remailers. Thanks.

-Xenon





From pmetzger at lehman.com  Wed Feb  2 04:15:30 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 04:15:30 PST
Subject: archiving on inet
In-Reply-To: <9402012201.AA23756@internal.apple.com>
Message-ID: <199402021211.HAA05378@snark>



Lefty says:
> >In what way does my internet provider 
> >(netcom) have a "legal" distribution of usenet news, while a cd-rom 
> >provider does not?
> 
> I have "provided" my postings to Usenet, for the personal use of Usenet
> subscribers.

Excellent. Now, please tell me how to determine if someone is a
subscriber. Is there a big subscriber list available somewhere for the
judge to check?

>  By providing my postings to a particular distribution
> mechanism, I implicitly give permission for them to be redistributed _via_
> _that_ _mechanism_.  I _do_ _not_ give permission for them to be repackaged
> and resold via another medium, any more than David Byrne has given me
> permission to resell cassettes of his music by allowing it to be broadcast
> on the radio.

Wonderful. Now, can you please explain what the usenet transmission
mechanism is? It obviously includes magtapes. It appears to include
CD-ROMs -- they have been used to distribute newsfeeds for years
now. In theory, an NNTP site that never expires articles makes those
articles available forever via NNTP, so time is obviously not a
criterion. Usenet has always been gatewayed to email, so email isn't
excluded (indeed, CNews explicitly provides a "by email" news
distribution mechanism). So, what exactly, is NOT part of the usenet
mechanism?

Perry





From pmetzger at lehman.com  Wed Feb  2 04:20:53 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 04:20:53 PST
Subject: archiving on inet
In-Reply-To: <199402020036.QAA20961@mail.netcom.com>
Message-ID: <199402021218.HAA05396@snark>



Now all you have to do is explain what an "expiration date" is and
explain the legal liability of sites that miss cancel messages by
accident. 

.pm

Jim Nitchals says:
> There is.  Copyright 1994 James Nitchals.  Duplication and redistribution
> rights permitted only until the expiration date or issuance of a cancel
> message by the author.
> 
> CD-ROM publishers cannot honor the request except by reissuing the CD-ROM
> without my content.  Anyone who backs up their home directory is safe,
> but if they redistribute my article after it's expired or cancelled, they
> are in violation of my copyright.
> 
> 





From pmetzger at lehman.com  Wed Feb  2 04:25:30 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 04:25:30 PST
Subject: archiving on inet
In-Reply-To: <199402020030.QAA20097@mail.netcom.com>
Message-ID: <199402021222.HAA05404@snark>



Many news systems don't understand expiration dates, and some don't
grok cancel messages. CD-ROMs can easily carry cancel messages, too,
by the way -- they are a transport medium.

Next bright idea?

Anyway, people who want to use the law to restrict distribution of
their news articles are extremely foolish. Your words are out there
and they WILL be read. Forever. You can't help it. If you find your
words embarassing, don't say them.

.pm

Jim Nitchals says:
> I've already said it.  I own the copyright to my posts, and only permit
> them to be distributed by Usenet because I can *cancel* and provide
> expiration dates with my posts.  CD-ROMs do not provide these standard
> Usenet message control features.
> 
> If I issue a cancel message, it's obvious that I'm asserting control
> over the further distribution of my content (sites that ignore them
> notwithstanding.)  Any time a CD-ROM is published with my message, and
> it contains an expiration date or is later cancelled, the publication
> violates my right as a copyright holder to retract my message.
> 
> [portions deleted]                         >  No providers of usenet news
> > have any agreements between themselves and the posters regarding 
> > copyrights. Netcom and all the other internet providers receive postings 
> > "free" and a cd-rom manufacturer has the same "right" to use postings as 
> > any other internet provider.
> 
> My expiration dates or cancel messages are perfectly reasonable ways
> to communicate the way in which I'm exercising my copyright.  Netcom
> and other service providers currently honor those communications, but
> CD-ROM publishers of Usenet news do not.
> > 
> > Kirk Sheppard
> > 
> > kshep at netcom.com
> > 
> > P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
> > Bethesda, MD 20824-0911      Live On Your Knees."
> > U.S.A.
> > 			    			     - Emiliano Zapata
> > 





From boone at psc.edu  Wed Feb  2 07:00:55 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Wed, 2 Feb 94 07:00:55 PST
Subject: New Remailer Up.
In-Reply-To: <199402020607.WAA29302@mail.netcom.com>
Message-ID: <9402021500.AA11889@igi.psc.edu>



nobody at qwerty.org  writes:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Greetings.
> 
> New remailer: qwerty at netcom.com.
> 
> No logs. Only a "counter" that works by appending the word "R" or "ER" to a
> text file so I can get an idea if anyone is using it. However, I'm sure the
> Netcom and other site's mail logs will be enough to track serious abusers
> of anonymity down, without my help. This remailer is dedicated to honest
> people who desire PRIVACY.

  Is the sendmail (I assume you are using sendmail for SMTP services) daemon
  set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other
  syslog facility]?  Otherwise, it may well be possible to track the usage
  of the remailer through browsing the syslog logs.

  This is one of the problems (it seems to me) with using a remailer and
  *not* having root access.  Unless you can convince your sysadmin to
  remove the syslog mechanism that sendmail uses, you may be exposing your
  users (presumably by accident).

 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From hughes at ah.com  Wed Feb  2 07:40:56 1994
From: hughes at ah.com (Eric Hughes)
Date: Wed, 2 Feb 94 07:40:56 PST
Subject: New Remailer Up.
In-Reply-To: <9402021500.AA11889@igi.psc.edu>
Message-ID: <9402021536.AA17122@ah.com>



>> New remailer: qwerty at netcom.com.

>  Is the sendmail [...] daemon
>  set up so that it *doesn't* log to /usr/spool/mqueue/syslog [...] ?

>  This is one of the problems (it seems to me) with using a remailer and
>  *not* having root access.

The remailers could implement their own outoing SMTP, to get rid of
one end of the log, albeit the less important end.

They could also run a SMTP server on a non-reserved TCP port, but that
would require a few things:

-- The remailer would have to be in the process table at all times and
listening to some TCP port.  Right now the remailer is activated by
incoming mail and appears only transiently in the process table.

-- The remailer chain would have to know to use the alternate port
when sending.  This should require new syntax for setting up source
routes.

It would, however, eliminate the standard mail logging.

Eric





From hughes at ah.com  Wed Feb  2 08:15:32 1994
From: hughes at ah.com (Eric Hughes)
Date: Wed, 2 Feb 94 08:15:32 PST
Subject: On return addresses
Message-ID: <9402021609.AA17192@ah.com>


I've been troubled for many months by an invariant in all forms of
return address schemes: The outside world contains sufficient
_persistent_ information to find a real adress.  There are lots of
clever schemes to split this information up so as to require
reassembly between many parties, but the information is still out of
one's control.  (I use 'reassembly' rather than 'collusion' since the
latter indicates an intent; see my rant of a few days ago.)  The
fundamental problem seems impenetrable.

So how do we solve it?  By abandoning return addresses and using mail
spool facilities.

Consider the following service.  

1. I have a machine and I'll sell you an address on it, say
"onyma at privacy.net".  This address is _not_ an account, merely an
address.  Your mail is password or public key protected.

2. When mail come in for you, it sits in a spool.  This service comes
with a spool of a certain size and an allowance for checking your mail
at a certain rate, with overages at extra cost for both.  (This is to
bound known promised capacity of the machine by a sufficient amount of
money to pay for it.)

3. Your mail sits in the spool until you access it with, say, a POP
client like Eudora.  Just point the client at a different address to
pick up mail.  The server can further support a number of protocols
for getting the mail, including a mail server command of "send me a
mailbox file of my waiting mail".

The main advantage is that the only _persistent_ information out in
the world is the address itself and the authenticator (password or
public key).  The address is already public and the authenticator is
arbitrary, so no identity information is persistent.  

A complete chain could still be forged between sender and receiving
pseudonym, but we now have some amount of forward secrecy.  If in fact
an intermediate link does discard connection information, it is gone
forever.  With any kind of SASE, however, the information therein,
however encrypted, still contains a full path back.

Now consider two ways of getting your mail out of this service,
supposing you don't trust the service with your identity.

A IP redirector can be with POP service to conceal origin from the
mail service.  An IP redirector is a remailer for packets, with a
bidirectional link set up when the service starts and removed when it
goes away.  Matt Blaze has a name for this--'packet laundry'--which is
a wonderful but politically unfortunate term.  The IP redirectors can
be chained just like remailers.

With a mail server, the command to 'send me my mailbox' can be sent to
a remailer address with an encrypted remailing block prepended.  In
this case, however, the encrypted remailer block is provided with the
mail command that requests the mailbox and it is not by design stored
persistently.  (By design.  It could, of course, actually be stored.)
The address on the other side of the first remailer hop could be
another mail spooing service, in addition.

The elimination of persistent identifying information for return paths
is a worthwhile design objective.  I propose that we start thinking
about it more thoroughly.

Eric





From sameer at soda.berkeley.edu  Wed Feb  2 08:50:56 1994
From: sameer at soda.berkeley.edu (Sameer)
Date: Wed, 2 Feb 94 08:50:56 PST
Subject: REMAIL: ping, script
In-Reply-To: <9402020140.AA07524@screech.owlnet.rice.edu>
Message-ID: <m0pRkQt-00010lC@infinity.hip.berkeley.edu>


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

Karl Lui Barrus spake:
> 10:y:sameer at netcom.com
> 15:y:sameer at soda.berkeley.edu

	These remailers are down. :-(

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU/UkXi7eNFdXppdAQEJ6wP/ZyqgG4nF32c8/4MaG/DNaqeHJpd1KyW1
YfZ58gR9GzWlnE7zhDgfiLRo1I0W6PVUO7mMxj8aIou7xhzME3F9fwqZfPbX8yZN
DWbSY4yDBgSyVu1wcs5gtwOK8htlLdpinBxDXjSh6rH6d9tQEQi55tXz6ocveveI
i1euOShTWoI=
=9Hax
-----END PGP SIGNATURE-----




From ravage at wixer.bga.com  Wed Feb  2 09:11:06 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Wed, 2 Feb 94 09:11:06 PST
Subject: Archiving on Inet
Message-ID: <9402021708.AA09079@wixer>


I would like to ask all subscribers who are not addressing the issues of this
question to please move their responces to private mail. I have no interest
in exploring your personalities or views of others personalities.

If a global network is to survive there must be a commen understanding of
what is public domain and what is private or commercial. At the present time
this is completely new ground. The fact is that the copyright laws of the US
are of little interest to a net user in Moscow, Russia or Pretoria, S. Africa.

If as a cpunk you don't feel that a anonymous regulatory agency can protect
your privacy why do you feel they can protect your intellectual property? The
issue has direct bearing on both intellectual property and the wide spread
use of cryptographic techniques. As a active cpunk it seems to me that your
first motivation after producing the actual code is to creat a atmosphere
where it can be used for the betterment of all. To create a useable global
community (what I am striving for) it seems to me that entries on that
network must be public domain by default. Otherwise every country who joins,
and by reduction every potential user, will have to agree on how to
recompense each and every user who desires to be paid for their submissions.
This, to me, leads incontrovertibly to the conclusion of a beurocratic
nightmare that will not significanly assist anyone other than the regulatory
agencies. The only other answer that seems even close to working (and I
consider this a stretch of the imagination) is one where everyone is given
access for free and the governments regulate the traffic completely and pat
for it with tax dollars.

As to the issue as it applies to community bbs'es. I run such a system and am
in the process of getting it on the net. As part of this project I have 2
other systems that I will be providing feeds for. These systems are all run
by individuals who have these boxes sitting in their den. By insisting on a
priori copyright of all material it is my opinion that you are creating a
situation which will prevent the growth of such systems. Now if we don't have
regulatory agencies and the sites are indipendant (and I assume self
supporting) how can we expect some Joe or Jill to put up a system to help the
people in their neighborhood if they have to keep looking over thier
shoulders for the copyright police? The answer is they won't put up such
systems and we all loose.

By providing strong crypto tools for business and individuals to protect
their intellectual and commercial property we are creating an open door
atmosphere which motivates people to join the network for their own enjoyment
and edification. This to me is more important than keeping the present view
(as applied to non-networked environments) of copyright. It is time that we
as uses of Internet set a precedence before the legislators set one for us
that will in the long run only assist those already in power by strangthening
the need for regulatory agencies.

I strongly suggest that you all consider this idea from the global and long
term view. I think you will find that the view "information wants to be free'
is the way to go.

To this end I propose that organizations such as EFF and cpunks take the
position of a priori public domain status of network submissions. Also that
all individuals who wish to retain intellectual or commercial rights either
use strong crypto w/ e-mail distribution of keys or a change be implimented
in message headers such that sites who don't wish to carry such material can
filter it, along with this should be a requirement that any such non-
crptographicly secure material must contain a fair use policy at the
beginning of each and every document.

It is time we quite letting big brother tell us what we can do with our ideas
and how to distribute them.






From nobody at qwerty.org  Wed Feb  2 09:15:32 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 09:15:32 PST
Subject: New Remailer Up.
Message-ID: <199402021713.JAA08629@mail.netcom.com>


Jon Boone wrote,
"  Is the sendmail (I assume you are using sendmail for SMTP services) daemon
  set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other
  syslog facility]?  Otherwise, it may well be possible to track the usage
  of the remailer through browsing the syslog logs.

  This is one of the problems (it seems to me) with using a remailer and
  *not* having root access.  Unless you can convince your sysadmin to
  remove the syslog mechanism that sendmail uses, you may be exposing your
  users (presumably by accident)."

No, fortunately for other users, I do not have root access on Netcom ;-).
So who is going to be doing this browsing? Other Netcom users can't read
the mqueue:

qwerty: cd /usr/spool
qwerty: ls
cron        lpd.lock    news        news4       uucp
locks       mail        news2       rwho        uucppublic
lpd         mqueue      news3       secretmail  uumaps
qwerty: cd mqueue
mqueue: Permission denied
qwerty: ls -la
total 480
drwxr-sr-x 15 bin           512 Feb  2 01:38 .
drwxr-xr-x 13 root          512 Feb  2 01:38 ..
drwxr-sr-x  4 root          512 Feb  2 01:38 cron
drwxr-sr-x  2 uucp          512 Feb  2 08:30 locks
drwxrwsr-x  2 daemon        512 Feb  2 03:47 lpd
-rw-r--r--  1 root            4 Feb  2 01:38 lpd.lock
drwxrwsrwt  4 root       430080 Feb  2 08:37 mail
drwxr-s---  2 root        18944 Feb  2 08:37 mqueue
drwxr-xr-x284 netnews     12288 Feb  2 05:29 news
drwxr-sr-x  2 netnews       512 Aug 28 17:03 news2
drwxr-sr-x  2 netnews       512 Aug 28 17:03 news3
drwxr-sr-x  2 netnews       512 Jan 16 19:56 news4
drwxr-sr-x  2 root          512 Jan 31 14:40 rwho
drwxrwsrwx  2 bin           512 Nov  3 08:49 secretmail
drwxr-sr-x 11 uucp          512 Feb  2 01:38 uucp
lrwxrwxrwx  1 root           20 Nov 26 15:48 uucppublic -> /usr/hack/uucppublic
drwxrwxr-x  5 netnews     12288 Feb  2 05:48 uumaps

"Is the sendmail (I assume you are using sendmail for SMTP services) daemon
  set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other
  syslog facility]?  Otherwise, it may well be possible to track the usage
  of the remailer through browsing the syslog logs."

I'm using Hal's remailer, so ask him the details of what I have running.
How many of those private sites with remailers having root, keep NO personal
logs? Any? I would like to compile a more detailed listing of the details
about each remailer's capabilities, situation, and policy statements.

If someone sends anonymous mail through my mailer victimizing someone in
a criminal manner, and law enforcement convinces Netcom to check the logs,
then more power to them. If someone sends mail discussing large doses of
vitamin C, when vitamin supplementys are banned a year from now, and the
FDA wants to arrest them, and Netcom allows them to see the mqueue then
that would be unfortunate indeed. I am running a remailer. Here is the
situation. What more can I offer? I would ask people to look at the
various remailers and ask in a street smart practical manner what the
pros and cons of each one is.

What, exactly, does the mqueue record? How long does it get saved? I
needed remailers to maintain some simple privacy by distancing myself
from the character Xenon. No 5AM fone calls and letters from people
asking me to send them PGP.... I figured if I was going to become the
largest volume user of the remailers, I should become a remailer
myself. The other option was to use the Netcom account to directly
mail out what I am sending to people, but that wasn't as fun of an
idea.

-Xenon





From mmarkley at microsoft.com  Wed Feb  2 09:30:56 1994
From: mmarkley at microsoft.com (Mike Markley)
Date: Wed, 2 Feb 94 09:30:56 PST
Subject: fwd: Canadian gov't eavesdropping
Message-ID: <9402021727.AA04813@netmail2.microsoft.com>


| From: Eli Brandt  <netmail!ebrandt at jarthur.Claremont.EDU>
| To: cypherpunks list  <cypherpunks at toad.com>
| Subject: fwd: Canadian gov't eavesdropping
| Date: Tuesday, February 01, 1994 7:26PM
|
| Received: from relay2.UU.NET by netmail.microsoft.com with SMTP (5.65/25-eef)
| 	id AA07450; Tue, 1 Feb 94 19:59:09 -0800
| Received: from toad.com by relay2.UU.NET with SMTP
| 	(5.61/UUNET-internet-primary) id AAwbln22133; Tue, 1 Feb 94 22:55:33 -0500
| Received: by toad.com id AA05602; Tue, 1 Feb 94 19:30:49 PST
| Received: by toad.com id AA05533; Tue, 1 Feb 94 19:26:28 PST
| Return-Path: <ebrandt at jarthur.Claremont.EDU>
| Received: from jarthur.Claremont.EDU ([134.173.42.1]) by
| toad.com id AA05527; Tue, 1 Feb 94 19:26:21 PST
| Message-Id: <9402020326.AA05527 at toad.com>
| In-Reply-To: <94Feb1.201622est.83288(2)@ivory.educom.edu>;
| from "E-D-U-P-A-G-E" at Feb 1, 94 8:21 pm
| X-Arcane-Subliminal-Header: fooquayleglorkpsilocybinrkbapinkyogsothothquux
| X-Mailer: ELM [version 2.3 PL11]
|
| > Date:	Tue, 1 Feb 1994 20:21:46 -0500
| [...]
| > HIGH-TECH SNOOP GADGET.  A super-secret branch of the Canadian Security
| > Intelligence Service has awarded three contracts to a Montreal firm to make
| > equipment that can quickly isolate key words and phrases from millions of
| > airborne phone, fax, radio signals and other transmissions. The hardware
| > has the "Orwellian potential to sweep through ... and keep records of all
| > conversations," said one CSIS critic.  (CTV National News, 01/31/94 11:00
| > pm).
|
| Dunno how feasible this kind of keyword recognition presently is,
| but here's another reason to encrypt.

I'd be curious to see how they are going to do voice recognition on 
random conversations. Unless I am very sadly out of date you need to 
teach the pattern matcher individual voices.


|
| > EDUPAGE. To subscribe to Edupage send e-mail to listproc at educom.edu,
| > containing the following text: SUB EDUPAGE yourfirstname yourlastname. To
|
|    Eli   ebrandt at jarthur.claremont.edu
|
|
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Markley              || The opinions here do not represent the
mmarkley at microsoft.com    || opinions of my employer. Attempts to
			  || associate the two are pointless.

   "I want to look at life, In the available light"
					- Neil Peart -






From werner at mc.ab.com  Wed Feb  2 09:40:57 1994
From: werner at mc.ab.com (werner at mc.ab.com)
Date: Wed, 2 Feb 94 09:40:57 PST
Subject: remailers
Message-ID: <9402021739.AA04726@werner.mc.ab.com>


Hi,

Can a remailer be used to post to an arbitrary Usenet group?

Is the above a stupid question?





From blake.coverett at canrem.com  Wed Feb  2 10:00:56 1994
From: blake.coverett at canrem.com (Blake Coverett)
Date: Wed, 2 Feb 94 10:00:56 PST
Subject: archiving on inet
In-Reply-To: <9402011752.AA00225@jazz.hal.com>
Message-ID: <60.2666.6525.0C19348B@canrem.com>


jazz at hal.com, in a message on 1 February, wrote:

JA> If you were a ligitimate recipient of the work in the first place (i.e. g
JA> it in a newsfeed) and you store those postings for your own use or for th
JA> use of others on that node in the store-and-forward network, then you can
JA> keep the work 'til the bits rot. Infringement occurs when you copy those
JA> bits onto some medium for some purpose other than store-and-forward
JA> propagation or the allowed fair-use exceptions; stuffing articles on a
JA> CD-ROM and selling them falls into neither category and hence is an
JA> infringement.

Hmm... why is "stuffing articles on a CD-ROM and selling them" not a type
of store-and-forward propagation?  Usenet is not just a bunch of machines
speaking CNews.

I agree that you have a copyright on the expression of ideas that make up
a Usenet post.  However I maintain that by posting them on Usenet you are
explicitly allowing them to be distributed (either freely or for a cost)
by all methods used to distribute Usenet.


I would seem obvious to me that taking a nice piece of Usenet prose 
and publishing it a collection of essays would be in violation of
a copyright.  On the other hand, publishing the same thing in a collection 
of this month's Usenet traffic would not.  People redistribute and sell
your Usenet postings all the time, why would it make a difference if they
do so via CD-ROM?


-Blake  
(Never underestimate the bandwidth of a trunk full of CD-ROMs)  
...
 * ATP/DJgcc 1.42 * blake.coverett at canrem.com, disclaimers? fooey!







From nobody at qwerty.org  Wed Feb  2 10:15:56 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 10:15:56 PST
Subject: remailers
Message-ID: <199402021815.KAA24792@mail.netcom.com>


werner asked,
"Can a remailer be used to post to an arbitrary Usenet group?"

newsgroup at news.cs.indiana.edu posts things quickly via e-mail. When I
use anon.penet.fi for Usenet, I often use this, since it is quite a bit
faster than using anon.penet.fi's posting feature.

"Is the above a stupid question?"

Is this a stupid answer? Both are in various FAQs.

-Xenon






From pgpkeys at wasabi.io.com  Wed Feb  2 10:20:56 1994
From: pgpkeys at wasabi.io.com (PGP Slave Key Server)
Date: Wed, 2 Feb 94 10:20:56 PST
Subject: system logging
Message-ID: <199402021245.MAA19515@wasabi.io.com>


> Greetings.
>
> New remailer: qwerty at netcom.com.
>
> No logs. Only a "counter" that works by appending the word "R" or "ER" to a
> text file so I can get an idea if anyone is using it. However, I'm sure the
> Netcom and other site's mail logs will be enough to track serious abusers
> of anonymity down, without my help. This remailer is dedicated to honest
> people who desire PRIVACY.

People should be aware that whether Niko makes personal logs on his
qwerty account or not, the public logs on netcom show more than enough
info to trivially track people down.

By the way it's very bad practice to forge From: lines, especially
with completely non-existant site names like qwerty.org...perhaps
you should ask netcom to register it for you.  Or if they charge real
money for it, your postmaster at columbia.edu might do it for free if
you asked him nicely.





From nobody at qwerty.org  Wed Feb  2 10:25:33 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 10:25:33 PST
Subject: fwd Canadian gov't eavesdropping
Message-ID: <199402021825.KAA27093@mail.netcom.com>


Mike Markley say,
"I'd be curious to see how they are going to do voice recognition on
random conversations. Unless I am very sadly out of date you need to
teach the pattern matcher individual voices."

But of course they will just collect voice samples from everyone soon,
and use them to IDENTIFY you. It'll probably be put on our US national
health care cards. Ever since I started worrying about leaving DNA on
postage stamps, I've started to think what can be done will be done.

-Xenon





From gnu  Wed Feb  2 10:25:56 1994
From: gnu (John Gilmore)
Date: Wed, 2 Feb 94 10:25:56 PST
Subject: Josh Quittner's Newsday column on Cypherpunks
Message-ID: <9402021823.AA26464@toad.com>


Date:      Wed, 02 Feb 1994 10:41:42 est
From: "josh quittner" <quit at newsday.com>
To: gnu at cygnus.com
Subject:   newsday column

Hiya John:
Here's the little column I did for my newspaper on the cypherpunks
meeting I sat in on last month. Thought you might be interested. I know
it's laymanlike, but if you want, you have my permission to distribute
it to your list. I told Eric I'd send him a copy, but I left his email
address at home, so if you'd be good enough, would you either pass this 
on to him or email me his address so I can? Thanks. Hope all is well with
you. Be glad you're not freezing your ass off back here.
	Regards,
	-jq


PUBLICATION DATE      Tuesday. February 1, 1994
EDITION               NASSAU AND SUFFOLK
SECTION               DISCOVERY
PAGE                  53
OTHER EDITIONS        59 C
HEADLINE              Life In Cyberspace
                      COMPUTERS IN THE ^90s
                      Coding Up a Bit of Privacy
BYLINE                Joshua Quittner
DATELINE              MOUNTAIN VIEW, Calif.
LENGTH                91   Lines

  MOUNTAIN VIEW, Calif.
       THIS MUST BE HOW the Founding Fathers looked when they hacked out
  the Constitution:
      A roomful of young men, mostly  -  frazzled hair, eager eyes, wild
  beards, arms flailing and fingers jabbing the air, reaching for big
  ideas. You can't help but feel it; urgency tempers their voices. The
  earnest men plan and argue in this corporate conference room as the last
  sun rays of a winter Saturday afternoon fade in through a skylight. 
      Time is running out for the Cypherpunks.
      There is much work to be done before the information highway
  arrives. The information highway   -   that 500-channel shopping mall /
  cineplex championed by cable and telephone companies   -   is a noxious
  concept to the people in this room. They are not technophobes or
  Luddites, these Cypherpunks. Instead, they are a collection of clever
  computer programers, engineers and wire heads from some of the nation's
  best-known Silicon Valley software houses and hardware shops.
      This is their central question: In a future world where all
  information is centralized on a network, where all information is
  tracked by the bit, where every purchase you make and every
  communication can be monitored by corporate America, how does privacy
  survive? If you go to a bookstore now and buy a book, you can pay in
  cash. No one knows your name or what you purchased. "What happens to
  cash transactions on the information highway?" they ask.
      The Cypherpunks believe that they can preserve your privacy through
  good cyphers, or codes. But they must hurry, must get their codes out
  and their networks up and running.
       "The whole information highway thing is now part of the public
  eye," explains Eric Hughes, a founder of the Cypherpunk movement. "If we
  don't change it now, it'll be impossible later."
     The Cypherpunks know what technology is capable of. We visit them
  today because they represent one edge of the national debate on the
  structure of the information highway. And as we all know, extreme
  positions help define the middle.
      Many of the Cypherpunks have been heavy Internet users for years and
  hope to preserve the communal spirit of that freewheeling world of
  interconnected computer networks. They dread the coming commercial
  network of televisions and computers, saying it will displace the
  Internet and destroy many of the freedoms they now enjoy.
      So the Cypherpunks, with the kind of zeal they professionally bring
  to marathon, 72-hour sessions hacking computer code, are plotting to
  keep free networks alive. That's "free" in the sense of unfettered,
  unmonitored, uncensored.
      One way they're going about it is by spreading easy-to-use, cheap
  cryptography. Cryptography is the science of keeping two-way
  communication private. Computers, it turns out, are revolutionary
  cryptographic tools, able to encode and decode files quickly. For the
  first time, virtually unbreakable codes are now possible, thanks to
  computers.
      The Cypherpunks post cryptographic software on the Internet where
  anyone can access it, and can encode their communications, including
  electronic mail, pictures and video. 
      But the U.S. government is concerned, as governments always are,
  about the spread of powerful cryptography (terrorists could use it,
  kidnapers could use it, drug dealers could use it, all of them on
  cellular phones that encode conversations). It currently is pushing its
  own commercial cryptographic standard, through a special chip known as
  the Clipper. The chip is reviled by Cypherpunks and other civil
  libertarians because it provides a back door that law-enforcement
  agencies could enter, with the proper warrants, for surveillance. 
      By getting good, unbreakable cryptography out there now, the
  Cypherpunks hope, whatever the government finally decides will be moot.
      Software has a wonderful property, the Cypherpunks are fond of
  saying: Once it's created, it can never be destroyed. It can be copied
  infinitely, from computer to computer, spreading like a secret. Come
  what may, unbreakable Cypherpunk code, and Cypherpunk networks, will be
  out there forever, they hope. But just to be safe, the Cypherpunks are
  toying with different network-related plans to create an economy of 
  "digicash"   -   network money that, like the dollars in your pocket,
  isn't tied to a user's credit cards or other personal identification.
  Digicash will help pay for Cypherpunk networks and will allow people to
  purchase goods without revealing their identity.
     "I'm starting a bank, and it's not going to be a U.S. bank," Hughes
  says. He's standing at the whiteboard now. A strawberry-blond ponytail
  dangles down his back and he grasps a magic marker in his hand. "We have
  several long-term strategies, one of which is the elimination of central
  banks." He tells the assembled crowd what they already know. Heads nod.
  Some people take notes.
      Hughes is a self-employed programer in Berkeley. His hand flies
  across the whiteboard, sketching out a schematic diagram, showing how
  his bank will operate. The bank will store depositers^ money (he's
  thinking a $200 minimum deposit) and disburse payments to anyone   - 
  all over the Internet. It will be based abroad, maybe in Mexico. A
  Cypherpunk network bank is one way to pay for a network of truly
  encrypted, private communications, you see.
      "Is this going to lead the way to portable laptop ATM machines?"
  someone asks in the back. People snicker. 
      "Have you thought about its name?" someone else asks.
      "First Bank of Cyberspace!" yells one person.
      "First Internet Bank!" yells another.
      "The Nth National Bank!"
      Laughter. Billy goat beards bob.
      There is much work to be done.

--end of story--
-- 
          josh quittner
             vox: 516-843-2806
                fax: 516-843-2873
                   quit at newsday.com





From wjm at MIT.EDU  Wed Feb  2 10:30:57 1994
From: wjm at MIT.EDU (william j mitchell)
Date: Wed, 2 Feb 94 10:30:57 PST
Subject: unsubscribe wjm@mit.edu
Message-ID: <9402021826.AA26210@MIT.EDU>


unsubscribe wjm at mit.edu





From pgpkeys at wasabi.io.com  Wed Feb  2 10:45:32 1994
From: pgpkeys at wasabi.io.com (PGP Slave Key Server)
Date: Wed, 2 Feb 94 10:45:32 PST
Subject: New US keyserver now fully operational - pgp-public-keys@io.com
Message-ID: <199402021313.NAA19622@wasabi.io.com>


The US-based keyserver  'pgp-public-keys at io.com' is now open to the public.

Come one, come all!

Here is the current file as returned by 'Subject: help'.

This site is a PGP key server SLAVE site.  It behaves
very similarly to the European PGP master sites, but there
are a few small differences which will be noted below.
The most noticable difference is that it answers your
requests immediately instead of waiting for a daily
batch job to run :-)

The particular installation at io.com does *not* log the details of
requests for keys, however the fact that you have sent mail to the
key server at all is logged in the daily sendmail logs.  These logs
will be erased automatically after one week.


PGP Public Keyservers
---------------------

There are PGP public key servers which allow one to exchange public
keys running through the Internet and UUCP mail systems.

This service is NOT supported in any way whatsoever by the schools or
organizations on which these servers run.  It is here only to help
transfer keys between PGP users.  It does NOT attempt to guarantee
that a key is a valid key; use the signators on a key for that kind of
security.  This service can be discontinued at any time without prior
notification.

Each keyserver processes requests in the form of mail messages.  The
commands for the server are entered on the Subject: line.

        To: pgp-public-keys at io.com
        From: johndoe at some.site.edu
        Subject: help

Sending your key to ONE server is enough.  After it processes your
key, it will forward your add request to other servers automagically.

For example, to add your key to the keyserver, or to update your key if it is
already there, send a message similar to the following to any server:

        To: pgp-public-keys at io.com
        From: johndoe at some.site.edu
        Subject: add

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

        <blah blah blah>
        -----END PGP PUBLIC KEY BLOCK-----

COMPROMISED KEYS:  Create a Key Revocation Certificate (read the PGP
docs on how to do that) and mail your key to the server once again,
with the ADD command.

Valid commands are:

Command                Message body contains
---------------------- -------------------------------------------------
ADD                    Your PGP public key (key to add is body of msg)
                       *** Note: your update is forwarded to a master
                           server and may take a few days to reappear
INDEX                  List all PGP keys the server knows about (-kv)
VERBOSE INDEX          List all PGP keys, verbose format (-kvv)
GET                    Get the whole public key ring
GET 0xA1B2C3           Get a single key by Key ID
                       *** Note: the master servers allow you to omit
                           the 0x in front of the Key ID.  The slave
                           servers do not.
GET userid             Get a single key by User ID
MGET substr            List all keys which match "substr"
                       *** Note: this is different from the master servers
                           which return the keys themselves, not just a
                           listing of their Key IDs.  Also the master
                           servers accept a wild-card expression; at
                           the moment we do not.
LAST days              Get the keys updated in the last `days' days
                       *** Note: not yet implemented
------------------------------------------------------------------------

Examples for the MGET command:

        MGET michael         Lists all keys which have "michael" in them
        MGET @iastate.edu    Lists all keys which contain "@iastate.edu"


Check the Usenet newsgroup alt.security.pgp for updates to this system
and for new sites.

Based on a document originally by Michael <explorer at iastate.edu>





From cknight at crl.com  Wed Feb  2 10:55:33 1994
From: cknight at crl.com (Chris Knight)
Date: Wed, 2 Feb 94 10:55:33 PST
Subject: fwd: Canadian gov't eavesdropping
In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com>
Message-ID: <Pine.3.87.9402021054.A21677-0100000@crl.crl.com>




On Wed, 2 Feb 1994, Mike Markley wrote:

> 
> I'd be curious to see how they are going to do voice recognition on 
> random conversations. Unless I am very sadly out of date you need to 
> teach the pattern matcher individual voices.
> 
Drop by your nearest Apple Macintosh dealer and ask them to show you the 
speach recognition system that comes shipped with the Quadra AV series.

I gave a demo in a crowded room, and a stereo in the background...  
Several people took turns asking the computer what time it was, open the 
control panel, etc.  I think you will be suprised.


-ck







From boone at psc.edu  Wed Feb  2 10:55:58 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Wed, 2 Feb 94 10:55:58 PST
Subject: New Remailer Up.
In-Reply-To: <199402021713.JAA08629@mail.netcom.com>
Message-ID: <9402021852.AA15745@igi.psc.edu>



nobody at qwerty.org  writes:
>
> Jon Boone wrote,
> "  Is the sendmail (I assume you are using sendmail for SMTP services) daemon
>   set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other
>   syslog facility]?  Otherwise, it may well be possible to track the usage
>   of the remailer through browsing the syslog logs.
> 
> No, fortunately for other users, I do not have root access on Netcom ;-).
> So who is going to be doing this browsing? Other Netcom users can't read
> the mqueue:
> 
> qwerty: cd /usr/spool
> qwerty: ls
> cron        lpd.lock    news        news4       uucp
> locks       mail        news2       rwho        uucppublic
> lpd         mqueue      news3       secretmail  uumaps
> qwerty: cd mqueue
> mqueue: Permission denied
> qwerty: ls -la
> total 480
> drwxr-sr-x 15 bin           512 Feb  2 01:38 .
> drwxr-xr-x 13 root          512 Feb  2 01:38 ..
> drwxr-sr-x  4 root          512 Feb  2 01:38 cron
> drwxr-sr-x  2 uucp          512 Feb  2 08:30 locks
> drwxrwsr-x  2 daemon        512 Feb  2 03:47 lpd
> -rw-r--r--  1 root            4 Feb  2 01:38 lpd.lock
> drwxrwsrwt  4 root       430080 Feb  2 08:37 mail
> drwxr-s---  2 root        18944 Feb  2 08:37 mqueue
> drwxr-xr-x284 netnews     12288 Feb  2 05:29 news
> drwxr-sr-x  2 netnews       512 Aug 28 17:03 news2
> drwxr-sr-x  2 netnews       512 Aug 28 17:03 news3
> drwxr-sr-x  2 netnews       512 Jan 16 19:56 news4
> drwxr-sr-x  2 root          512 Jan 31 14:40 rwho
> drwxrwsrwx  2 bin           512 Nov  3 08:49 secretmail
> drwxr-sr-x 11 uucp          512 Feb  2 01:38 uucp
> lrwxrwxrwx  1 root           20 Nov 26 15:48 uucppublic -> /usr/hack/uucppubl
ic
> drwxrwxr-x  5 netnews     12288 Feb  2 05:48 uumaps

  Well, anyone who is the group which owns mqueue (you need to do an ls -ldg
  to show this info) can read the directory and (likely) the logs.  It would
  not be unusual for the daemon or bin id's to be allowed read access to these
  files/directories, so anyone who could exploit the latest sendmail bug
  could end up reading those files...

  And that doesn't even go into the potential access by legitimate sysadmins
  who may not care too much about other users' privacy...

> I'm using Hal's remailer, so ask him the details of what I have running.
> How many of those private sites with remailers having root, keep NO personal
> logs? Any? I would like to compile a more detailed listing of the details
> about each remailer's capabilities, situation, and policy statements.

  As would I.

> If someone sends anonymous mail through my mailer victimizing someone in
> a criminal manner, and law enforcement convinces Netcom to check the logs,
> then more power to them. If someone sends mail discussing large doses of
> vitamin C, when vitamin supplementys are banned a year from now, and the
> FDA wants to arrest them, and Netcom allows them to see the mqueue then
> that would be unfortunate indeed. I am running a remailer. Here is the
> situation. What more can I offer? I would ask people to look at the
> various remailers and ask in a street smart practical manner what the
> pros and cons of each one is.

  Good advice.  Caveat Emptor!

> What, exactly, does the mqueue record? How long does it get saved? 

  Here is an example of what sendmail might log to syslog:

Feb  2 12:31:18 localhost: 15068 sendmail: AA15068: message-id= \
		<199402021713.JAA08629 at mail.netcom.com>
Feb  2 12:31:18 localhost: 15068 sendmail: AA15068: from= \
		<owner-cypherpunks at toad.com>, size=4402, class=0, \
		received from mailer.psc.edu (128.182.62.100)
Feb  2 12:31:19 localhost: 15070 sendmail: AA15068: to=<boone at igi.psc.edu>, \
		delay=00:00:13, stat=Sent

I have re-formatted the lines to make them easier to read...  This is the log
of you sending this mail to me...

Here's my previous response, which I sent to the list, logged again...

Feb  2 10:00:27 localhost: 11889 sendmail: AA11889: message-id= \
			   <9402021500.AA11889 at igi.psc.edu>
Feb  2 10:00:27 localhost: 11889 sendmail: AA11889: from=<boone at igi.psc.edu>,
			   size=1391, class=0, received from local
Feb  2 10:00:31 localhost: 11891 sendmail: AA11889: to=<cypherpunks at toad.com>,
			   delay=00:00:04, stat=Sent

And here's the list sending it back to me...

Feb  2 10:19:09 localhost: 13086 sendmail: AA13086: message-id= \
			   <9402021500.AA11889 at igi.psc.edu>
Feb  2 10:19:09 localhost: 13086 sendmail: AA13086: from= \
			   <owner-cypherpunks at toad.com>, size=2028, class=0, \
			   received from mailer.psc.edu (128.182.62.100)
Feb  2 10:19:11 localhost: 13089 sendmail: AA13086: to=<boone at igi.psc.edu>, \
			   delay=00:00:02, stat=Sent

If the mailer recieves a lot of messages, then it would not be easy (if at all
possible to correlate the messages received with the id's that they were sent
out to...).  If the traffic load is small, then correlation is fairly easy.

Similarly, if the load is very high, it might become easier -- if I set up a 
script which sent mail to a particular anonid every 2 seconds or so, I would
probably be able to correlate, given access to the syslog logs.  Of course,
I could forgo the logs and just look at the packets passed on your network,
but we were discussing the use of the syslog logs.


> I needed remailers to maintain some simple privacy by distancing myself
> from the character Xenon. 

  Aside from traffic obscuring random messages, a forced, random delay and
  a medium sized load of traffic seem to be the best ways to defeat the use
  of the syslog logs.  Disabling syslog calls in sendmail (or whatever you
  use for SMTP) would be an even better tack to take.  Remember folks, even
  if I can't get root when the machine is up, I may be able to force it into
  single-user mode and access the logs then -- physical security of the 
  machines [as well as software security] is an important consideration of
  *any* remailer you use.

> No 5AM fone calls and letters from people asking me to send them PGP.... 
> I figured if I was going to become the largest volume user of the remailers, 
> I should become a remailer myself. The other option was to use the Netcom 
> account to directly mail out what I am sending to people, but that wasn't 
> as fun of an idea.

  I'm not advising you to not be a remailer, but you should be aware of the
  potential holes -- even if you can't do anything about them...

  If you're concerned with your own personal privacy, I can't think of a
  good way to ensure that you will not be "outed" from your anon-id.
  Even if you use a personal machine which connects to the network via a
  dialup slip IP pool, the provider is likely to keep logs of what machines
  have access to that pool and who their owners are...  And, of course, a
  permanent connection (T1 or the like) is a dead give-away...

  We really need the IP security -- the proposal put forward by Mssr. Blaze
  and Mssr. Ioannidis for encrypted-IP would help.. but you still rely on
  having the other side *not* log...

 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From talon57 at well.sf.ca.us  Wed Feb  2 11:00:59 1994
From: talon57 at well.sf.ca.us (Brian D Williams)
Date: Wed, 2 Feb 94 11:00:59 PST
Subject: digital signatures/copyright
Message-ID: <199402021858.KAA17982@well.sf.ca.us>



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

 A question for Mike Godwin and other attorneys on the list:

 Could one make a case that the use of Digital signatures in
messages imply's copyright retention by the author?

 Does digital signature=copyright or is it at least equivalent?



Brian Williams
Extropian
Cypherpatriot

"Cryptocosmology: Sufficently advanced comunication is
                  indistinguishable from noise." --Steve Witham
 
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU/2HdCcBnAsu2t1AQF15gP+IqS3o0gNeHng9BSqlk95KzmPwp3oo70p
j2FVYHNOeUKgDSAAwvWr+p3/DOwTafSkJf4A5gW33NOKr0E9JZ4In349RAoueTku
J94VMajT4i7yhOC8X41RPkVLlCltPDRo04SS8h5UFnEk/zFxiTkvXY9mpBcK3yUw
vYY9pbmupSc=
=KbXS
-----END PGP SIGNATURE-----







From mnemonic at eff.org  Wed Feb  2 11:25:33 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Wed, 2 Feb 94 11:25:33 PST
Subject: digital signatures/copyright
In-Reply-To: <199402021858.KAA17982@well.sf.ca.us>
Message-ID: <199402021924.OAA23853@eff.org>


 
>  A question for Mike Godwin and other attorneys on the list:
> 
>  Could one make a case that the use of Digital signatures in
> messages imply's copyright retention by the author?

I suppose one could, but, really, there's no issue of "copyright
retention" out there. Post something to the Net, and it's copyrighted, and
you hold the copyright. Doesn't matter whether you've digsigged it or not.

>  Does digital signature=copyright or is it at least equivalent?
 
No.



--Mike







From Tomaz.Borstnar at arnes.si  Wed Feb  2 11:35:32 1994
From: Tomaz.Borstnar at arnes.si (Tomaz Borstnar)
Date: Wed, 2 Feb 94 11:35:32 PST
Subject: New US keyserver now fully operational - pgp-public-keys@io.com
In-Reply-To: <199402021313.NAA19622@wasabi.io.com>
Message-ID: <9402021932.AA27987@toad.com>


In-reply-to: Your message dated: Wed, 02 Feb 1994 13:13:22 GMT
> The US-based keyserver  'pgp-public-keys at io.com' is now open to the public.

I would like to set up server in Slovenia and don't want to reinvent wheel so
I need server's software. Where can one get it?


Thanks in advance.

	Tomaz





From bob at USCWS4.gat.com  Wed Feb  2 11:51:01 1994
From: bob at USCWS4.gat.com (bob harvey)
Date: Wed, 2 Feb 94 11:51:01 PST
Subject: No Subject
Message-ID: <9402021945.AA12911@USCWS4.gat.com>


unsubscribe bob at USCWS4.gat.com






From nobody at qwerty.org  Wed Feb  2 12:01:00 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 12:01:00 PST
Subject: New Remailer Up.
Message-ID: <199402021959.LAA15215@mail.netcom.com>


Jon wrote,
"  Aside from traffic obscuring random messages, a forced, random delay and
  a medium sized load of traffic seem to be the best ways to defeat the use
..."

How LONG should the such a random delay BE, at max? I am not willing to add
more than 10-15 minutes, max. Is this worth it then? Hours is just too
primitive when it comes to electronic communications. Even minutes!

-Xenon





From reagle at gl.umbc.edu  Wed Feb  2 12:05:33 1994
From: reagle at gl.umbc.edu (Joseph Reagle Jr.)
Date: Wed, 2 Feb 94 12:05:33 PST
Subject: test
Message-ID: <199402022003.PAA24245@xsg02.gl.umbc.edu>


Regards,
Joseph M. Reagle Jr.   | 
reagle at umbc.edu        | It's celluar peptide cake with mint frosting!
jreagl1 at umbc8.umbc.edu |         -- Worf





From smb at research.att.com  Wed Feb  2 12:06:10 1994
From: smb at research.att.com (smb at research.att.com)
Date: Wed, 2 Feb 94 12:06:10 PST
Subject: digital signatures/copyright
Message-ID: <9402022005.AA28855@toad.com>


It's worth noting that U.S. copyright law makes explicit provision
for copyrighting anonymous works.





From nobody at qwerty.org  Wed Feb  2 12:21:02 1994
From: nobody at qwerty.org (nobody at qwerty.org)
Date: Wed, 2 Feb 94 12:21:02 PST
Subject: system logging
Message-ID: <199402022017.MAA20262@mail.netcom.com>


PGP Slave,

Could you please announce my full name, phone number, address, visa card
number, a giff of my signature, height, weight and driver's licence number
not only to the Cypherpunks mailing list but to many usenet groups as well,
since you obviously feel I no longer wish to be known to the masses as
Xenon, and I instead want them to start calling me and postal mailing me
asking for copies of PGP. Thanks asshole. I thought the people on this
list were concerned with privacy, but I was wrong. I mention Xenon in
my personal .plan, but I ask people to let me keep the small amount of
extra privacy I still retain.

You wrote,
"qwerty account or not, the public logs on netcom show more than enough
info to trivially track people down."

Trivial? And so you hack out the info that a message went from remailer
A through qwerty and on to remailer B, at a certain time. You haven't
tracked down anyone my friend.

-Xenon





From DBS5112 at ibm.MtSAC.edu  Wed Feb  2 12:51:02 1994
From: DBS5112 at ibm.MtSAC.edu (DBS5112 at ibm.MtSAC.edu)
Date: Wed, 2 Feb 94 12:51:02 PST
Subject: unsubscribe
Message-ID: <9402022047.AA29669@toad.com>


(mailing to cypherpunks-request at toad.com doesn't seem to work)...
please unsubscribe me from the list...
                                  thanxs





From nobody at pmantis.berkeley.edu  Wed Feb  2 13:05:34 1994
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Wed, 2 Feb 94 13:05:34 PST
Subject: anonymous mail
Message-ID: <9402022101.AA15882@pmantis.berkeley.edu>


There's a jerk that's been mail-bombing me, and I can't do anything
because he's root at his site.  Would it be ethical to use a remailer to 
bomb him back?

Or maybe I shoudl simply fakemail a message to 
alt.fan.rush-limbaugh at anon.penet.fi with his name and have the contents 
say something like 'Limbaugh sucks', or post to alt.sex.wanted with the 
subject 'SWF virgin seeks man for first time'.

Any ideas on how to get someone back, or at least make life annoying?






From mab at research.att.com  Wed Feb  2 13:11:01 1994
From: mab at research.att.com (Matt Blaze)
Date: Wed, 2 Feb 94 13:11:01 PST
Subject: Notes on key escrow meeting with NSA
Message-ID: <9402022105.AA18514@big.l1135.att.com>


A group from NSA and FBI met the other day with a group of us at Bell
Labs to discuss the key escrow proposal.  They were surprisingly
forthcoming and open to discussion and debate, and were willing to at
least listen to hard questions.  They didn't object when asked if we
could summarize what we learned to the net.  Incidentally, the people
at the meeting seemed to base a large part of their understanding of
public opinion on Usenet postings.  Postings to sci.crypt and
talk.politics.crypto seem to actually have an influence on our
government.

A number of things came out at the meeting that we didn't previously
know or that clarified previously released information.  What follows
is a rough summary; needless to say, nothing here should be taken as
gospel, or representing the official positions of anybody.  Also,
nothing here should be taken as an endorsement of key escrow, clipper,
or anything else by the authors; we're just reporting.  These notes
are based on the collective memory of Steve Bellovin, Matt Blaze, Jack
Lacy, and Mike Reiter; there may be errors or misunderstandings.
Please forgive the rough style.  Note also the use of "~ ~" for
'approximate quotes' (a marvelous Whit Diffie-ism).

NSA's stated goals and motives for all this:
	* DES is at the end of its useful life
	* Sensitive, unclassified government data needs protection
	* This should be made available to US Citizens
	* US business data abroad especially needs protection
	* The new technology should not preclude law enforcement access

They indicated that the thinking was not that criminals would use key
escrowed crypto, but that they should not field a system that
criminals could easily use against them.  The existence of key escrow
would deter them from using crypto in the first place.  The FBI
representative said that they expect to catch "~only the stupid
criminals~" through the escrow system.

Another stated reason for key escrow is that they do not think that
even government-spec crypto devices can be kept physically secure.
They do expect enough to be diverted to the black market that they feel
they need a response.  NSA's emphasis was on the foreign black market...

There seems to be a desire to manipulate the market, by having the
fixed cost of key escrow cryptography amortized over the government
market.  Any private sector devices would have to sell a much larger
number of units to compete on price.  (This was somewhere between an
implication and an explicit statement on their part.)

When asked about cryptography in software, "~...if you want US
government cryptography, you must do it with hardware~".

Clipper chips should be available (to product vendors) in June.  You
can't just buy loose chips - they have to be installed in approved
products.  Your application interface has to be approved by NIST for
you to get your hands on the chips.

An interesting point came up about the reverse-engineering resistance
of the chips: they are designed to resist reverse engineering the data
in the chip without destroying the chip.  It is not clear (from the
information presented at the meeting) whether the chips are equally
resistant to destructive reverse-engineering to learn the skipjack
algorithm.   They said the algorithm was patented, but they may have
been joking.  ("~And if that doesn't scare you enough, we'll turn the
patent over to PKP.~")

The resistance to reverse engineering is not considered absolute by
NSA.  They do feel that "~it would require the resources of a national
laboratory, and anyone with that much money can design their own
cryptosystem that's just as strong.~"

They repeated several times that there are "~no plans to regulate the
use of alternate encryption within the US by US citizens.~"  They also
indicated they "~weren't naive~" and didn't think that they could if
they wanted to.

There were 919 authorized wiretaps, and 10,000 pen register monitors,
in 1992.  They do not have any figures yet on how often cryptography
was used to frustrate wiretaps.

They do not yet have a production version of the "decoder" box used by
law enforcement.  Initially, the family key will be split (by the same
XOR method) and handled by two different people in the athorized
agencies.  There is presently only one family key.  The specifications
of the escrow exploitation mechanism are not yet final, either; they
are considering the possibility of having the central site strip off
the outer layers of encryption, and only sending the session key back
to the decoder box.

The escrow authorities will NOT require presentation of a court order
prior to releasing the keys.  Instead, the agency will fill out a form
certifying that they have a legal authorization.  This is also backed
up with a separate confirmation from the prosecutor's office.  The
escrow agencies will supply any key requested and will not themselves
verify that the keys requested are associated with the particular court
order.

The NSA did not answer a question as to whether the national security
community would obtain keys from the same escrow mechanism for their
(legally authorized) intelligence gathering or whether some other
mechanism would exist for them to get the keys.

The masks for the Clipper/Capstone chip are unclassified (but are
protected by trade secret) and the chips can be produced in an
unclassified foundry.  Part of the programming in the secure vault
includes "~installing part of the Skipjack algorithm.~" Later
discussion indicated that the part of the algorithm installed in the
secure vault are the "S-tables", suggesting that perhaps unprogrammed
Clipper chips can be programmed to implement other 80-bit key, 32 round
ciphers.

The Capstone chip includes an ARM-6 RISC processor that can be used for
other things when no cryptographic functions are performed.  In
particular, it can be used by vendors as their own on-board processor.
The I/O to the processor is shut off when a crypto operation is in
progress.

They passed around a Tessera PCMCIA (type 1) card.  These cards
contain a Capstone chip and can be used by general purpose PC
applications.  The cards themselves might not be export controlled.
(Unfortunately, they took the sample card back with them...)  The card
will digitally sign a challenge from the host, so you can't substitute
a bogus card.  The cards have non-volatile onboard storage for users'
secret keys and for the public keys of a certifying authority.

They are building a library/API for Tessera, called Catapult, that
will provide an interface suitable for many different applications.
They have prototype email and ftp applications that already uses it.
They intend to eventually give away source code for this library.
They responded favorably to the suggestion that they put it up for
anonymous ftp.

Applications (which can use the library and which the NSA approves for
government use) will be responsible for managing the LEAF field.  Note
that they intend to apply key escrowed Skipjack to other applications,
including mail and file encryption.  The LEAF would be included in
such places as the mail header or the file attributes.  This implies
that it is possible to omit sending the LEAF -- but the decrypt chip
won't work right if it doesn't get one.

When asked, they indicated that it might be possible wire up a pair of
Clipper/Capstone chips to not transmit the LEAF field, but that the
way to do this is "~not obvious from the interface we give you~" and
"~you'd have to be careful not to make mistakes~".  They gave a lot of
attention to obvious ways to get around the LEAF.

The unit key is generated via Skipjack itself, from random seeds
provided by the two escrow agencies (approximately monthly, though
that isn't certain yet).  They say they prefer a software generation
process because its correct behavior is auditable.

Capstone (but not Clipper) could be configured to allow independent
loading of the two key halves, in separate facilities.  "~It's your
money [meaning American taxpayers].~"

The LEAF field contains 80 bits for the traffic key, encrypted via the
unit key in "~a unique mode <grin>~", 32 bits for the unit id, and a 16
bit checksum of some sort.  (We didn't waste our breath asking what the
checksum algorithm was.)  This is all encrypted under the family key
using "~another mode <grin>~".

They expressed a great deal of willingness to make any sort of
reasonable changes that vendors needed for their products.  They are
trying *very* hard to get Skipjack and key escrow into lots of
products.






From pmetzger at lehman.com  Wed Feb  2 13:25:34 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 13:25:34 PST
Subject: anonymous mail
In-Reply-To: <9402022101.AA15882@pmantis.berkeley.edu>
Message-ID: <199402022122.QAA05944@snark>



nobody at pmantis.berkeley.edu says:
> There's a jerk that's been mail-bombing me, and I can't do anything
> because he's root at his site.  Would it be ethical to use a remailer to 
> bomb him back?
> 
> Or maybe I shoudl simply fakemail a message to 
> alt.fan.rush-limbaugh at anon.penet.fi with his name and have the contents 
> say something like 'Limbaugh sucks', or post to alt.sex.wanted with the 
> subject 'SWF virgin seeks man for first time'.
> 
> Any ideas on how to get someone back, or at least make life annoying?

Call his network service provider and explain that he's violating
federal law by attempting to disrupt your service from his site.
Alternatively, rig your sendmail.cf file to forward any mail he sends
you back to him.

.pm





From beker at netcom.com  Wed Feb  2 13:45:33 1994
From: beker at netcom.com (Brian Beker)
Date: Wed, 2 Feb 94 13:45:33 PST
Subject: Anonymous mail service up for alpha testing
In-Reply-To: <m0pRcum-00010YC@infinity.hip.berkeley.edu>
Message-ID: <Pine.3.85.9402021356.A11138-0100000@netcom5>


On Wed, 2 Feb 1994, Sameer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 	I've written a small anonymous mail service, and it's now
> available for testing. There's no security, and I'll be keeping logs,
> so don't think that it's secure, in any way. 

Excellently and well done, Sameer!  Ah, the pleasure of seeing a budding 
cypherpunk do us all some good.  Keep us posted.

Mucho Obligado, Amigo,
brianB






From paul at poboy.b17c.ingr.com  Wed Feb  2 13:51:01 1994
From: paul at poboy.b17c.ingr.com (Paul Robichaux)
Date: Wed, 2 Feb 94 13:51:01 PST
Subject: Notes on key escrow meeting with NSA
In-Reply-To: <9402022105.AA18514@big.l1135.att.com>
Message-ID: <199402022151.AA02282@poboy.b17c.ingr.com>


Thank you very much for a) taking the time to meet with these people
and b) posting a lucid and timely summary to the list.

-Paul Robichaux

-- 
Paul Robichaux, KD4JZG     | "Though we live in trying times 
perobich at ingr.com          |  We're the ones who have to try." - Neil Peart
Intergraph Federal Systems | Be a cryptography user- ask me how.






From nate at VIS.ColoState.EDU  Wed Feb  2 13:51:12 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Wed, 2 Feb 94 13:51:12 PST
Subject: WWW Anonymous Remailer Software release
Message-ID: <9402022148.AA12174@vangogh.VIS.ColoState.EDU>


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



I have modified my WWW Anonymous remailer interface and put it up
for ftp on vangogh.vis.colostate.edu in /pub/nate/remailer

There is a README in there which should explain how to set it
up, but if I missed anything, please tell me.

The remailer no longer needs you to tell it that you're using the 
remailers, it just knows.

Hope you like it,

- -nate

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From qwerty-remailer at netcom.com  Wed Feb  2 13:55:33 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 13:55:33 PST
Subject: Remailer FAQ. Info request!
Message-ID: <199402022153.NAA10067@mail.netcom.com>


I have only seen unsatisfying info on the remailers out there. If people
know the details up front, the Cypherpunk remailers will become more popular.
Different people have different needs for remailing as well.

Please help me out with this. I would appreciate info from operators as
well as users of remailers. If you do not want to disclose a specific
bit of info, I will enter it as "N/A". If I get no answer at all I will
leave it as "?". Send responses to qwerty at netcom.com. If you wish your
remailer be taken off the list I will comply.

-Xenon

Xenon's Full Disclosure Remailer List.

Remailer   Who's Fast?   PGP?    Logs?   Comments
---------- ----- ------- ------- ------  ------------------------------------
bsu-cs     NSA?   +      ?       ?       Strips Subject.
catalyst   Scott  +      Y(2.3a) ?
choas      NSA?   +      ?       ?       Strips Subject.
cicada     Eric   ++     N       ?       Tread lightly.
dis.org    NSA?   -      Y(2.3a) ?
extropia   NSA?   ?      Y(2.3a) ?       Only accepts PGP remailing.
jarthur    Eli    +/--   ?       ?
menudo     NSA?   --     ?       ?
merde      NSA?   -/--   ?       ?       batches out at midnight??
penet.fi   Julf   --     N       Stats   <48K. Overloaded. Slow.
pmantis    Eric   ++     N       ?       Tread lightly.
qwerty     Xenon  +      Y(2.3a) Count
rosebud    NSA?   ++/-   Y(2.3a) ?
shell      Hal    ++/+/- Y(2.3a) Stats+
soda       Eric   ++/-   N       Stats+? Can post to Usenet


++ <5 min
- ~10-30 min delay
-- pinging isn't practical due to long delays
+ ~10 min
+/- sometimes +, sometimes -
Normal internet mail delays are common, and are not equivalent in the two
directions between any two remailers. Mail still gets through.

Full: full copies of all mail is archived. My large volume mailing should
      help put a stop to this.
Stats: logs of when mail was remailed.
Stats+: logs of when and where mail was remailed.
None: operator keeps no logs.
Count: simple counter.

bsu-cs    nowhere at bsu-cs.bsu.edu
catalyst  catalyst at netcom.com
chaos     remailer at chaos.bsu.edu
cicada    hh at cicada.berkeley.edu
dis.org   remailer at dis.org
extropia  remail at extropia.wimsey.com
jarthur   ebrandt at jarthur.claremont.edu
menudo    nobody at Menudo.UH.EDU
merde     remailer at merde.dis.org
penet.fi  anon.penet.fi
pmantis   hh at pmantis.berkeley.edu
qwerty    qwerty at netcom.com
rosebud   elee7h5 at rosebud.ee.uh.edu
shell     hfinney at shell.portal.com
soda      hh at soda.berkeley.edu

Discontinued remailers still on some lists out there:

phantom at mead.u.washington.edu
remail at tamaix.tamu.edu
sameer at netcom.com (spelling?)
sameer at berkeley.edu (spelling?)
cdodhner at indirect.com
remailer at entropy.linet.org??
00x at uclink.berkeley.edu?
hal at alumni.cco.caltech.edu?
remail at tamaix.tamu.edu?
remailer at entropy.linet.org?

Background on each remailer:

bsu-cs:
Run by Chael Hall.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

catalyst:
Run by Scott Collins.
Machine: personal dial-up account on Netcom.
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

chaos:
Run by ??
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Comments: finger remailer.help at chaos.bsu.edu for info. ??
History: ??

cicada:
Run by Eric Hollander.
Machine: ???
Problems policy: ?? Contact ??
Software: ??
Comments: being "phased out".

dis.org:
Run by ??
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

extropia:
Run by ??
Machine: ??
Problems policy: ??  Contact ??
Software: ??
Comments: ??
History: ??

jarthur:
Run by Eli Brandt.
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

menudo:
Run by ??
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Comments: Stores messages and sends them at midnight??
History: ??

merde:
Run by ??
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

penet.fi:
Run by Julf (last name?)
Machine: ?? Operator owned.
Problems policy: Account revokation. Contact ??@anon.penet.fi.
Software: custom.
Comments: ??
History: ??

pmantis:
Run by Eric Hollander.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Comments: being "phased out".
History: ??

qwerty:
Run by Xenon.
Machine: dial-up account on Netcom.
Problems policy: "What problems?". Contact qwerty at netcom.com.
Software: Hal's remailer.
Comments: ??
History: Up 2/94. Set up by Xenon who needed more remailers to use to send
         PGP info to people with, since anon.penet.fi was overloaded.

rosebud:
Run by Karl Barrus.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Comments: ??
History: ??

shell:
Run by Hal Finney.
Machine: ??
Problems policy: ?? Contact ??
Software: Hal's Remailer.?
Comments: ??
History: ??

soda:
Run by Eric Hollander.
Run by: ??
Machine: ??
Problems policy: ?? Blocking of addresses. Mail sent to problem causer.
                 Contact ??
Software: custom. ??
Comments: Was keeping full logs till Xenon's bulk mailing venture. ??
History: ??

Remailer Public Keys:

Anonymous Remailer <catalyst at netcom.com>
1024-bit key, Key ID C0EA49, created 1993/08/30
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4
YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d
xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR
tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+iQCVAgUQ
LIaqhIOA7OpLWtYzAQH4sgQAsc6s3X75LwWTV65Dw76wdSRKuoI57F2ZZWjSOIQK
n1CWUn6YEYOIs3kkdHNd0uz9Mspoy+6BsnWGSW11r8k88VThEoVpJ74o91apR1ML
yCEdD7O/+nZK8N484+mN2BcKOdeze4QvgTt+qHHUd+Q5alW9VfXtbNImmSnI3FC/
8n4=
=Hh6a
-----END PGP PUBLIC KEY BLOCK-----

Remailing Service <remailer at dis.org>
512-bit key, Key ID 64E8A7, created 1993/03/05
Also known as:  Anonymous Remailer <remailer at utter.dis.org>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQBNAiuX3kAAAAECAMd6YkS3ylajgNSzX+wYLrpW03D+99OFvePQLlR5N+R5iZBr
y4FbAMeDj+eCeEAqiEyNjUxHN5tGlqx1g6tk6KcABRG0JFJlbWFpbGluZyBTZXJ2
aWNlIDxyZW1haWxlckBkaXMub3JnPokAVQIFECwomeN8p7i9YJH3xQEBDhEB/A7+
RLEw2bGJeBdBy0yXn5mIenda/tHHs9NGXJZR5BvOsU9EwVY+9s86E33R2/tgqAjY
UYc5MiWS0r1+H9Zw+FeJAJUCBRArmsesg4Ds6kta1jMBAW4zA/4waabkcIHN93Jy
/9OMXhRDqrRf2kickmeUWOGHF0KALLo37kAqfDvMNDtFs1u3WbdaBWdTSiLR8qIM
6TQNq0IEhAeny07AVweLlIpJc7lVN7biHqVIPknxJTAI/xscybuMUin3yALzFpWR
54uFMbd45iuKWBJ2/IGdUYcd39H0FbQsIEFub255bW91cyBSZW1haWxlciA8cmVt
YWlsZXJAdXR0ZXIuZGlzLm9yZz6JAJUCBRArmsmdg4Ds6kta1jMBAbdwA/9m2GYJ
978xxchux7nnl4HAo3N+A2Nx+n40kQftWNiyJwivrG8kYwDI24QYaUpr2l6+2HDd
xedEOFsX6DiHbDQK5J7dGYOigASmZHPs39lEdJ3AHvrTVYVYjOxBMQ2W6p+Q5rbn
qxfmVlqRMzPRosPJ1gpbfcTzIpqznwSTl7tztQ==
=v3Hk
-----END PGP PUBLIC KEY BLOCK-----

Remailer <remail at extropia.wimsey.com>
1024-bit key, Key ID B5A32F, created 1992/12/13
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB
mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l
yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR
tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQK2SV
p4OA7OpLWtYzAQG8eQP9F9ye/F/rXhJLNR5W/HV5k+f6E0zWSgtmTTWUYyydfJw+
lKDEDH6v+OFOFE3+fuTIL5l0zsNMSMdF5u7thSSWiwcFgaBFQF9NWmeL/uByOTSY
tsB6DQSbw656SBH7c7V7jvUsPit/DubwBXZi9sOlULau3kQqXeeQxPhNE+bpMy6J
AJUCBRArKwSLk3G+8Dfo40MBAXYAA/4hCVDFD0zG47pYPMg+y7NPE5LktWt2Hcwt
Z4CRuT5A3eWGtG8Sd5QuHzbE4S9mD3CFn79bxZi0UDhryD8dsCG4eHiCpAcZqSvR
JSkpgamdRaUQHNmMxv5goxHhRem6wXrKxZQNn5/S0NtQOrS6QKhFlGrzDIh/2ad1
J9qpyzJ/IYkARQIFECsrA9RLrSJixHgP9wEBNcEBewWpzywKk/SBDwocXebJmsT6
zug/ae78U/cu9kTX620Xcj1zqOdx9Y9Ppwem9YShaQ==
=I7QE
-----END PGP PUBLIC KEY BLOCK-----

jarthur remailer  c/o <ebrandt at jarthur.claremont.edu>
512-bit key, Key ID 7D154B, created 1993/04/04
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQBNAiu+hVUAAAECAMVjEfl2IMNgSOJ+/fx1V6EbH50ofa6K4r1PBKMmkcHQextP
ghwC4lXIgaAWUlLJ9x61+qf4jB5fpNUZLrF9FUsABRG0NWphcnRodXIgcmVtYWls
ZXIgIGMvbyA8ZWJyYW5kdEBqYXJ0aHVyLmNsYXJlbW9udC5lZHU+iQCVAgUQK8M/
BIOA7OpLWtYzAQGJRAP9GIVi0qoQW4bjU9sikIPG4zIEbQ9O3rU1vd2uCrrnGQMM
tdE9NoOx4umoVZKYTpCc96TlFQetb2UVd9JhaayXO7+nwNNHYgApkRJboolq9UzU
wCRBA8k1EMAkdzCjzYglpZIQJz2yNP50Izu7g2LMbC1pHQX3CHVL7YlQrKGNLz4=
=ItNk
-----END PGP PUBLIC KEY BLOCK-----

Qwerty Remailer <qwerty at netcom.com>
1024-bit key, Key ID 5505D9, created 1994/02/01
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAi1NtgAAAAEEALD07N5RllpklGhOQaiYtRupb+8Jm1M34ya8rxmcNUCVndcb
JgH9EW1Z2VvkJ3vTcEOOBK9jM/HCIGDqBbQZR8VOLbLNOD7VQIzTpyTOmZJCMSZG
bqZtRtP6KDtMcTx1SgHq9LiRNz5YUyB3WOV963y8W/x00QS4yGkgCDZkVQXZAAUR
tCNRd2VydHkgUmVtYWlsZXIgPHF3ZXJ0eUBuZXRjb20uY29tPokAlQIFEC1OzEgE
sxus60J9UQEB224D/jUcYRnXmIj9nt4Y7sjGYTmO+v7b9W+rsxYLn6+hCGmx5iQJ
zPr3ggvm8ylBZnNp3WUxssDlb9GyiK801vzm6HDXWd/yCeGXHX7YB2DDFd5WrK70
/XGTMGv3gvNnExIM+UVv5tl8y/YXOfeLWWGttD6a60MkUNxAOGT9qBsUTqJNiQCV
AgUQLU3TdWkgCDZkVQXZAQH1ygP/TCY7T0PdNVRUVbEpN9YsbxFKhFT/7+hZTySr
Md0j2GrObjcRc7aa0c9lEZrtKpaDCJkgF+7k20z1eQpw7zD/dO+ZsSqni62TLGYa
pdTsAiYbev90Nb+1S2ST36KvIgJSmQS6zvgpToTRpGwYhJhqTZhTo8Z2U5ufb+SF
TsNMd0Q=
=BXnK
-----END PGP PUBLIC KEY BLOCK-----

Remailer (remailer at rebma.mn.org)
1024-bit key, Key ID BA80A9, created 1992/11/26
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECtkldODgOzq
S1rWMwEBnx8D/1p9vNDfnSzgKhd0q0xF0KTQWBzbQgXFeWLTUwLPLN30vGQRZHVc
IrOSzjCOSflhcl0zc7tp7q+GQkVT5P/PIUG0yeL0mFi+oUswcws14LRaelYmVbgw
OsjwJ7g4vwKICqzOWRVsdtSurMfw/65LzdgSUNPS18pGpD/4MJF3kHpkiQCVAgUQ
KxQkYRiQVHeOVJ+HAQHXOAP/Usb0O200RU8V13GRQs/D4CSRuZKiWuolSZXH/fLd
BLUC1b69WoXTKGBaC+DvvRvv7EyfDM78jWeHQUrayF3UmTHgVUIDly3KpTNUWOTU
0TpVppFzkG8EPWdTG1SF5HRZcNznR/4A0eBE2THbYwZG+mGx4zJer86TzyilKfsM
is4=
=jbyA
-----END PGP PUBLIC KEY BLOCK-----

remailer03 <elee7h5 at rosebud.ee.uh.edu>
1022-bit key, Key ID ABFBB3, created 1992/12/02
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm
uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v
gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR
tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1PokAlQIFECtk
lUeDgOzqS1rWMwEBUdAEAIosaOm/+kTsQI53GAqPXr08v5AAfwup5lDiUbCWp17C
ueYHZrP4zolAqQ7kyWrkIeHgJHkX3yB6YH/jQ0MeDZERXS69kq2SGVQSH6inGoF9
3WerfGRpdONa597JVcRpklzMUz6bmXnhsiEm/K1FP9pNOZYyS6h/3gs92ikezq3X
iQBVAgUQKxwo79I3XvyZ21fpAQG27AIAk7r8plkjpH1X9uQcsqFqjdjJtXGmHCeA
dLV7tiviHlljDe2RqOKkjfFsQtzZV+yjCNXr8OhW0TiE0J5WqBwECA==
=VK3C
-----END PGP PUBLIC KEY BLOCK-----

Remailing Service <hfinney at shell.portal.com>
510-bit key, Key ID 5620D5, created 1992/11/15
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3

mQBNAisGf+IAAAEB/ieS6th8hI1QBjGpmctVvsIxZBtmpykVXc3psh0XVfH4sECS
ugouk2zm/PJtt59A2E5SO3xjpDjeKlkQ745WINUABRG0LFJlbWFpbGluZyBTZXJ2
aWNlIDxoZmlubmV5QHNoZWxsLnBvcnRhbC5jb20+iQCVAgUQK3Azm4OA7OpLWtYz
AQHzawQAwZPaJUR9iNwyKMDm4bRSao0uu381pq6rR3nw0RI+DSLKTXPqDaT3xBmL
dVv1PVguLcoao/TRLkAheV7CIxodEiI9lAC2o6lqSXCP+vm3jYmulSgUlKafXYbj
LAbZpsKRAUjCpyx0wlYmoHhkA+NZDzMcWp6/1/rM/V1i4Jbt2+GJAJUCBRArBpKv
qBMDr1ghTDcBASTlBACfTqODpVub15MK5A4i6eiqU8MDQGW0P0wUovPkNjscH22l
0AfRteXEUM+nB+Xwk16RG/GdrG8r9PbWzSCx6nBYb7Fj0nPnRPtS/u69THNTF2gU
2BD0j2vZF81lEHOYy6Ixao2b6Hxmab2mRta2eTg7CV6XP3eRFDPisVqgooAWgw==
=arSc
-----END PGP PUBLIC KEY BLOCK-----






From jim at uu4.psi.com  Wed Feb  2 14:05:33 1994
From: jim at uu4.psi.com (jim at uu4.psi.com)
Date: Wed, 2 Feb 94 14:05:33 PST
Subject: contemplating remailer postage
Message-ID: <9402022200.AA01456@uu4.psi.com>




Although lot of people (including me) have mentioned Digital Stamps, or  
remailer postage, when describing advanced remailers, I've yet to see a  
good description of a practical remailer postage mechanism.  I assume it  
will be (or has been) modeled after one of the Chaumian digital cash  
protocols.  If there has been work done on a remailer postage mechanism,  
could somebody post the details? (or a reference)

Here's what I think would make up a practical remailer postage mechanism:

I think that each remailer should issue its own stamps, rather than using  
a central digital postage service.  The existence of a centralize digital  
postage service creates a single point of failure for the entire remailer  
system.  It also complicates the protocol needed to validate digital  
stamps and check for double spending.  Of course, having each remailer  
issue its own stamps would increase the complexity for the users of the  
remailer system.  However, I believe the increased user-side complexity  
can be completely hidden within a good set of scripts (e.g. the scripts  
could maintain a subdirectory for each remailer to hold stamps for that  
remailer).

If all digital stamps have the same "denomination", then the protocol for  
obtaining stamps can be greatly simplified.  You wont need to engage in a  
cut-and-choose protocol with the remailer (see page 121, Digital Cash  
Protocol #4, Applied Cryptography).  To obtain 100 stamps from R1, Bob  
would generate and blind 100 uniqueness strings (random numbers large  
enough that they are unlikely to collide with anyone else's) and send them  
all to R1.  R1 would simply sign all 100 of them and send them back.  Bob  
would unblind them and store them in his "R1_stamps" subdirectory.

Given the low value of individual stamps, it is probably not necessary to  
try to determine who is attempting to double spend stamps.  Therefore,  
stamps wouldn't need the identity strings used in Digital Cash Protocol  
#4.  Also, since the remailer is both "bank" and "merchant", there's no  
chance of the "merchant" cheating the "bank".

...

When Bob wants to route a message through R1, he place an R1 stamp at the  
appropriate level within the nested envelopes.  These stamps can also be  
used in SASE's.

When R1 receives a stamped message (or SASE) it will check the signature  
of the stamp.  If the signature doesn't verify, R1 discards the message.   
If the signature verifies, R1 checks the uniqueness string against his  
archive of "used" stamps.  If the uniqueness string is present in the  
archive, the stamp has already been used and the message will be  
discarded.  If the uniqueness string is not present in the archive, R1  
will route the message on to the next hop.  Finally, R1 places the  
uniqueness string in his "used stamp" archive.

Seems simple enough.  The major sticking point (to me) is the remailer's  
"used stamp" archive.  This could grow to be very large.  Something needs  
to be done to keep the archive from getting too large.

One idea is to have the remailer periodically change the key it uses to  
sign stamps.  Changing the "stamp validation key" effectively invalidates  
all unused stamps signed by that key.  If you haven't used the stamp by  
that time, you're out of luck.  The remailer can purge its "used stamp"  
archive whenever it changes its "stamp validation key".

Of course, invalidating peoples' unused stamps out from under them is not  
a nice thing for a remailer to do.  The remailer could provide a mechanism  
whereby people could get new stamps from old, unused stamps.  To make this  
work, the remailer would have to retain the previous "used stamp" archive  
for a while to give people a chance to get new stamps.  However, there  
still needs to be a limit on how long the remailer retains the "used  
stamp" archives for old validation keys.  If you wait too long, you would  
lose any chance to get new stamps from old.

Comments welcome.

Jim_Miller at suite.com





From reagle at gl.umbc.edu  Wed Feb  2 14:45:33 1994
From: reagle at gl.umbc.edu (Joseph Reagle Jr.)
Date: Wed, 2 Feb 94 14:45:33 PST
Subject: Quantum Crypto.
In-Reply-To: <Pine.3.85.9402021356.A11138-0100000@netcom5>
Message-ID: <Pine.3.89.9402021751.A13320-0100000@umbc8.umbc.edu>



[Here is the conclusion to my QC paper, unfortunately I can't get the 
whole file into a PS format because of the faulty file translators in the 
Mac applications.]

Conclusion
	Quantum cryptography has proven to be an interesting and novel 
application of quantum physics.   It does posses some severe limitations 
that I have considered.
	Optimistic predictions of it�s affective area is still far below 
100 km.  This may of course change depending on technological 
development.  It has been suggested to me that one could have secure 
stations where interception and reception of the message would be 
allowed. [10]  This is possible, but weakens the �absoluteness� that is 
the appeal of quantum cryptography.  
	A basic assumption is made previous to the research mentioned: 
that Eve will not interfere on the public channel.  It could be very 
possible that Eve would set herself up between Alice and Bob on the 
quantum and private channels, and act as a relay station that I mentioned 
in the first point.  She would have to impersonate both Alice and Bob, 
who in reality might not even be on the same public and quantum channels, 
but merely think they are.  Public key methods could be used for 
authentication, but this destroys the motivation for the use of quantum 
cryptography.
		I feel the solution here is in the definition of 
�public�.  Meaning a random and public switching of public channels, 
phone numbers and such.  Even this may be subverted by a very powerful 
Eve who may also control the phone company�s switching circuits.  Perhaps 
further thought can resolve this issue, but the problem of identification 
and authentication on the public channel is severe.
	Further, quantum cryptography is subject to a denial of service 
attack.  If Eve wishes, she may destroy the unique and expensive quantum 
channel, or merely observe everything that goes by, not caring to read 
the information, just making it unsuitable for use by Alice and Bob.  
Ekert�s concept of keeping shared EPR pairs in permanent storage (perhaps 
using a superconductor to warehouse keys when the quantum channel is 
open) is not yet feasible, and it will be necessary to keep these keys 
somewhere , but the security of keys is not a problem unique to quantum 
cryptography.  
		I look forward to the resolution of these issues and the 
further  development of the technology that will allow quantum 
cryptography to become a �practical� security mechanism.


1.	C. Bennett. Science.. vol. 257, p. 752 (August, 1992).
2,	C. Bennett, G. Brassard, and A. Ekert.  Scientific American. p. 	
	50 (Oct., 1992)
3.	A. Ekert, Phys. Rev. Lett. vol. 67, p. 661 (1991)
4.	C. Bennet, and G. Brassard, Phys. Rev. Lett. vol. 68, p. 557 	(1992)
5.	A. Ekert, J. Rarity, P. Tapster, and G. Palma, Phys. Rev. Lett. 
	vol. 	69, p. 1293, (1993).
6.	A. Muller, J. Breguet, and N. Gisin. Europhs. Lett., vol. 23 (6), 
p. 	383 (1993).
7. 	S. Barnett, and S. Phoenix. Phys. Rev. A, vol 48 (1), p. R5, 
	(July, 	1993).
8.	C. Bennett. Phys. Rev. Lett. vol 68 (21), p. 3121 (1992)
9.	D. Denning. Cryptography and Data Security.
10.     Personal e-mail as a follow-up to a posting to sci.crypt.  I have 	
	unfortunately lost the person�s name.







From qwerty-remailer at netcom.com  Wed Feb  2 15:01:01 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 15:01:01 PST
Subject: New remailer up.
Message-ID: <199402022259.OAA21968@mail.netcom.com>


Out of personal curiousity concerning the claims of how trivial
"traffic analysis" of the qwerty or catalyst remailers on Netcom
would be for "anyone" to carry out, I offer $20 to the first
person to reveal from which SITE this message originated from.
Please do not announce my name or login ID. Just the site. I am
logged into a friend's account and I am remailing this with no
encryption just through qwerty at netcom.com. It is now 5:41 PM EST.

You do not have to reveal your methods to receive the award, which
I will mail to you. Happy hacking you WIMPS.

If you wish to remain anonymous, mail the answer to qwerty at netcom.com
and my lips are sealed except for announcing success.

-Xenon





From pmetzger at lehman.com  Wed Feb  2 15:15:33 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 15:15:33 PST
Subject: New remailer up.
In-Reply-To: <199402022259.OAA21968@mail.netcom.com>
Message-ID: <199402022311.SAA06225@snark>



Tapping Netcom's net connections would take more than $20 of effort.
Up it to $50,000 and I'll happily take on your offer. However, I am
going to need assurances that the money will actually be paid.

Perry Metzger

qwerty-remailer at netcom.com says:
> Out of personal curiousity concerning the claims of how trivial
> "traffic analysis" of the qwerty or catalyst remailers on Netcom
> would be for "anyone" to carry out, I offer $20 to the first
> person to reveal from which SITE this message originated from.
> Please do not announce my name or login ID. Just the site. I am
> logged into a friend's account and I am remailing this with no
> encryption just through qwerty at netcom.com. It is now 5:41 PM EST.
> 
> You do not have to reveal your methods to receive the award, which
> I will mail to you. Happy hacking you WIMPS.
> 
> If you wish to remain anonymous, mail the answer to qwerty at netcom.com
> and my lips are sealed except for announcing success.
> 
> -Xenon





From daemon at fidonet.fidonet.org  Wed Feb  2 12:40:28 1994
From: daemon at fidonet.fidonet.org (Gateway Mail Daemon)
Date: 02 Feb 94 15:40:28 -0500
Subject: Message returned to sender
Message-ID: <e0f_9402021540@nisc.fidonet.org>


(Invalid host or address: cypherecho at f21.n216.z1.fidonet.org)

The address you are trying to send to does not exist on
this side of the gateway.  If you have any problems, email
the postmaster of this gateway for assistance.

Please note that the biggest reason for bounced messages is due
to a simple typo.  Please, double check your spelling!

A copy of the original message is listed below:

-----8< cut here 8< ------------------------------------
>From owner-cypherpunks at toad.com  Wed Feb  2 12:30:16 1994
Received: from relay2.UU.NET by zeus.ieee.org (4.1/Z-3.46-01.31.94)
	id AA12961; Wed, 2 Feb 94 12:30:16 EST
Received: from toad.com by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AAwbnp25485; Wed, 2 Feb 94 12:25:12 -0500
Received: by toad.com id AA24880; Wed, 2 Feb 94 09:11:06 PST
Received: by toad.com id AA24877; Wed, 2 Feb 94 09:11:05 PST
Return-Path: <ravage at wixer.bga.com>
Received: from ghostwheel.bga.com ([198.3.118.4]) by toad.com id AA24873; Wed, 2 Feb 94 09:10:58 PST
Received: from wixer.UUCP by ghostwheel.bga.com with UUCP id AA05678
  (5.65c/IDA-1.4.4 for cypherpunks at toad.com); Wed, 2 Feb 1994 11:09:24 -0600
Received: by wixer (5.65/1.35)
	id AA09079; Wed, 2 Feb 94 11:08:26 -0600
Message-Id: <9402021708.AA09079 at wixer>
Subject: Archiving on Inet
To: cypherpunks at toad.com
Date: Wed, 2 Feb 94 11:08:26 CST
From: Jim choate <ravage at wixer.bga.com>
X-Mailer: ELM [version 2.3 PL11]

I would like to ask all subscribers who are not addressing the issues of this
question to please move their responces to private mail. I have no interest
in exploring your personalities or views of others personalities.

If a global network is to survive there must be a commen understanding of
what is public domain and what is private or commercial. At the present time
this is completely new ground. The fact is that the copyright laws of the US
are of little interest to a net user in Moscow, Russia or Pretoria, S. Africa.

If as a cpunk you don't feel that a anonymous regulatory agency can protect
your privacy why do you feel they can protect your intellectual property? The
issue has direct bearing on both intellectual property and the wide spread
use of cryptographic techniques. As a active cpunk it seems to me that your
first motivation after producing the actual code is to creat a atmosphere
where it can be used for the betterment of all. To create a useable global
community (what I am striving for) it seems to me that entries on that
network must be public domain by default. Otherwise every country who joins,
and by reduction every potential user, will have to agree on how to
recompense each and every user who desires to be paid for their submissions.
This, to me, leads incontrovertibly to the conclusion of a beurocratic
nightmare that will not significanly assist anyone other than the regulatory
agencies. The only other answer that seems even close to working (and I
consider this a stretch of the imagination) is one where everyone is given
access for free and the governments regulate the traffic completely and pat
for it with tax dollars.

As to the issue as it applies to community bbs'es. I run such a system and am
in the process of getting it on the net. As part of this project I have 2
other systems that I will be providing feeds for. These systems are all run
by individuals who have these boxes sitting in their den. By insisting on a
priori copyright of all material it is my opinion that you are creating a
situation which will prevent the growth of such systems. Now if we don't have
regulatory agencies and the sites are indipendant (and I assume self
supporting) how can we expect some Joe or Jill to put up a system to help the
people in their neighborhood if they have to keep looking over thier
shoulders for the copyright police? The answer is they won't put up such
systems and we all loose.

By providing strong crypto tools for business and individuals to protect
their intellectual and commercial property we are creating an open door
atmosphere which motivates people to join the network for their own enjoyment
and edification. This to me is more important than keeping the present view
(as applied to non-networked environments) of copyright. It is time that we
as uses of Internet set a precedence before the legislators set one for us
that will in the long run only assist those already in power by strangthening
the need for regulatory agencies.

I strongly suggest that you all consider this idea from the global and long
term view. I think you will find that the view "information wants to be free'
is the way to go.

To this end I propose that organizations such as EFF and cpunks take the
position of a priori public domain status of network submissions. Also that
all individuals who wish to retain intellectual or commercial rights either
use strong crypto w/ e-mail distribution of keys or a change be implimented
in message headers such that sites who don't wish to carry such material can
filter it, along with this should be a requirement that any such non-
crptographicly secure material must contain a fair use policy at the
beginning of each and every document.

It is time we quite letting big brother tell us what we can do with our ideas
and how to distribute them.






From qwerty-remailer at netcom.com  Wed Feb  2 16:01:02 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 16:01:02 PST
Subject: New remailer up.
Message-ID: <199402022358.PAA02516@mail.netcom.com>


Perry Metzger wrote,
"Tapping Netcom's net connections would take more than $20 of effort.
Up it to $50,000 and I'll happily take on your offer. However, I am
going to need assurances that the money will actually be paid."

This is exactly the point I was trying to make. I wanted the
word "trivial" to be clarified by those who were being so vocal
about dismissing a remailer on Netcom.

You'll also need a good lawyer when Netcom finds your tap ;-).

But I'm sure some skilled hacker will be able to tell me the site and
I'll happily be out $20, in say, a couple days? No use hacking my
password, as I keep no logs (for now). The reason it's only $20, is
that I am indeed honestly interested in knowing something about my
remailer's security, and I don't know enough internet/Unix to risk
being a total sucker.

-Xenon






From lefty at apple.com  Wed Feb  2 16:06:13 1994
From: lefty at apple.com (Lefty)
Date: Wed, 2 Feb 94 16:06:13 PST
Subject: New remailer up.
Message-ID: <9402030002.AA22907@internal.apple.com>


>Tapping Netcom's net connections would take more than $20 of effort.
>Up it to $50,000 and I'll happily take on your offer. However, I am
>going to need assurances that the money will actually be paid.

Oh, very, _very_ impressive.

Hey, Xenon, _I'll_ do it for only $47,500, but I'll need 50% up front.

"Oh, I don't mind a parasite; it's a _cut-rate_ one I object to..."

--
Lefty (lefty at apple.com)
C:.M:.C:., D:.O:.D:.







From kshep at netcom.com  Wed Feb  2 16:15:32 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Wed, 2 Feb 94 16:15:32 PST
Subject: List Scum and Other Dross (was: system logging)
In-Reply-To: <199402022017.MAA20262@mail.netcom.com>
Message-ID: <Pine.3.85.9402021928.A14809-0100000@netcom6>


On Wed, 2 Feb 1994 nobody at qwerty.org wrote:

> PGP Slave,
> 
> Could you please announce my full name, phone number, address, visa card
> number, a giff of my signature, height, weight and driver's licence number
> not only to the Cypherpunks mailing list but to many usenet groups as well,
> since you obviously feel I no longer wish to be known to the masses as
> Xenon, and I instead want them to start calling me and postal mailing me
> asking for copies of PGP. Thanks asshole. I thought the people on this
> list were concerned with privacy, but I was wrong. I mention Xenon in
> my personal .plan, but I ask people to let me keep the small amount of
> extra privacy I still retain.

My sympathies to you. Others, too, on this list have no respect for 
privacy, as they post private e-mail to the list with out permission, but 
make threats in private unposted e-mail. This especially applies to those 
who violate privacy and make threats under pseudonyms at places and 
servers that don't support finger or netfind. It is ironic, but sadly 
this is what the "notorious" Detweiler was teaching us. 

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata







From bgold at tlcnet.aps.muohio.edu  Wed Feb  2 16:21:02 1994
From: bgold at tlcnet.aps.muohio.edu (Bruce Goldflies)
Date: Wed, 2 Feb 94 16:21:02 PST
Subject: unsubscribe
Message-ID: <9402030020.AA00850@tlcnet.aps.muohio.edu>


please unsubscribe me from the list
Thanks





From pmetzger at lehman.com  Wed Feb  2 16:21:14 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Wed, 2 Feb 94 16:21:14 PST
Subject: New remailer up.
In-Reply-To: <199402022358.PAA02516@mail.netcom.com>
Message-ID: <199402030019.TAA06390@snark>



qwerty-remailer at netcom.com says:
> Perry Metzger wrote,
> "Tapping Netcom's net connections would take more than $20 of effort.
> Up it to $50,000 and I'll happily take on your offer. However, I am
> going to need assurances that the money will actually be paid."
> 
> This is exactly the point I was trying to make. I wanted the
> word "trivial" to be clarified by those who were being so vocal
> about dismissing a remailer on Netcom.

Well, the problem is that NETCOM has logs that are good enough that
THEY can trivally trace things if they want. Assuming they are doing
normal SMTP logging tracking you down should be easy. I would require
a network tap assuming that I wasn't going to have their help.
However, make no mistake that Netcom can and will cooperate with the
police if you use your remailer in a way that the government doesn't
like, so it seems that the security afforded isn't that good.

> But I'm sure some skilled hacker will be able to tell me the site and
> I'll happily be out $20, in say, a couple days?

Without any information out of the network logs or the network itself,
no one is going to be able to say. Besides, $20 is a paltry sum for
the amount of work involved.

> No use hacking my password, as I keep no logs (for now).

Netcom keeps logs.

.pm





From loki at nately.UCSD.EDU  Wed Feb  2 16:41:03 1994
From: loki at nately.UCSD.EDU (Lance Cottrell)
Date: Wed, 2 Feb 94 16:41:03 PST
Subject: SASE Suggestion
Message-ID: <9402030041.AA12425@nately.UCSD.EDU>



:Lance Cottrell writes:
:
:> I have been meditating on this problem of return
:> addresses, and have a proposal. The remailers
:> can not be allowed to choose the return path,
:> as any corrupted remailer will corrupt the rest
:> of the path.
:
Jim Miller writes:
:As I understand it, the remailers don't "chose" the return path, Bob (the  
:sender of the original message) choses the return path when he creates the  
:SASE.  All the remailers do is interpret the part of the SASE that becomes  
:readable to them after decrypting the SASE portion sent to them from the  
:previous hop.  If all is working, what becomes readable is the address of  
:the next hop (closer to Bob) and some misc other stuff (postage, maybe,  
:and perhaps another encryption key).
:
:Am I not understanding something correctly?
:
:Jim_Miller at suite.com
:

One SASE scheme recently suggested involved sending a request for
a SASE to a ramailer, stating the number of jumps required. It then
sent it to another remailer, and so on. Each adding a layer, and eventually
sending the results to the desired correspondent. I mentioned that if the
first remailer was corrupted, that the whole chain was (it would only send
to other corrupt remailers).
----------------------------------------------------------
Lance Cottrell	who does not speak for CASS/UCSD
loki at nately.ucsd.edu
PGP 2.3 key available by finger or server.

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
			--Nietzsche
----------------------------------------------------------





From qwerty-remailer at netcom.com  Wed Feb  2 17:21:03 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 17:21:03 PST
Subject: New remailer up.
Message-ID: <199402030119.RAA17214@mail.netcom.com>


Perry wrote,
"However, make no mistake that Netcom can and will cooperate with the
police if you use your remailer in a way that the government doesn't
like, so it seems that the security afforded isn't that good."

So you aren't interested unless you can commit serious felony crimes
using a given remailer? I would be happy if criminals stayed away from
my remailer. What do you mean by "security"? And if the police find out
a personally owned machine was involved, I couldn't imagine them not
just swooping in at midnight and taking it away at gunpoint. I hope
those privately owned machines don't have logs ;-). In my mind, the whole
secret to gaining privacy is not attracting attention in the first place.
Using a remailer DOES allow a person to communicate anonymously with
someone else, in two directions. If a party has enough power to tap
Netcom, then sendmail logs or no sendmail logs, they will find you.

and,
"Besides, $20 is a paltry sum for the amount of work involved."

Think of it as a trophy, which I'm sure most understood. I'm not offering
you a job.

I appreciate your view though, and since I've posted a request for
remailer comments, might you help us all and send me some comments about
the various remailers and what types of security each affords? If some
wish to use remailers for serious underground activity, which should they
use or not use? If they just want to keep bounced mail from telling their
system postmaster who they're talking to, then that's a different type
of security need.

-Xenon





From wisej at acf4.NYU.EDU  Wed Feb  2 17:21:14 1994
From: wisej at acf4.NYU.EDU (wisej)
Date: Wed, 2 Feb 94 17:21:14 PST
Subject: fwd: Canadian gov't eavesdropping
In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com>
Message-ID: <Pine.3.87.9402022029.A16772-0100000@acf4.NYU.EDU>


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

On Wed, 2 Feb 1994, Mike Markley wrote:

> | From: Eli Brandt  <netmail!ebrandt at jarthur.Claremont.EDU>

> | > HIGH-TECH SNOOP GADGET.  A super-secret branch of the Canadian Security
> | > Intelligence Service has awarded three contracts to a Montreal firm to mak
e
> | > equipment that can quickly isolate key words and phrases from millions of
> | > airborne phone, fax, radio signals and other transmissions. The hardware
> | > has the "Orwellian potential to sweep through ... and keep records of all
> | > conversations," said one CSIS critic.  (CTV National News, 01/31/94 11:00
> | > pm).
> |
> | Dunno how feasible this kind of keyword recognition presently is,
> | but here's another reason to encrypt.
>
> I'd be curious to see how they are going to do voice recognition on
> random conversations. Unless I am very sadly out of date you need to
> teach the pattern matcher individual voices.
>
You'd be surprised.  For example, Plaintalk, a system extension bundled with the
AV-series macintoshes, does voice recognition based solely on phonemes.  
Although it is not perfect yet, I can personally attest to having walked up to a
model on display in a store, tried a few simple commands by voice, and had no 
problem with recognition.  The technology _is_ there.

				Jim Wise
				wisej at acf4.nyu.edu
				jaw7254 at acfcluster.nyu.edu
-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVBRwzS8O1DgkhNpAQEQcgP/cQZm7qvbwTzRrHFVO7NeGtTKCoguSqng
kH/6Mj2HOkndDydTpeZh5Zcb9JeuZHERagcD6ese71Yjihry/KTh6fNzDnYJhb/N
5vOlZZAa/8LgnLaF3IZWJJmrHqhTGlitD9AFMrFGrt420ij4GzTWsLN93Ctm7MBg
sWZvuj9JL7o=
=U/4B
-----END PGP SIGNATURE-----







From qwerty-remailer at netcom.com  Wed Feb  2 17:31:14 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 17:31:14 PST
Subject: New remailer up.
Message-ID: <199402030131.RAA20660@mail.netcom.com>


Sure, a vanilla user at netcom probably can't track the remailer logs,
unless of course there are BUGS in SENDMAIL (gasp!) or SunOS or whatever.
But remailers aren't just to keep random users from knowing who you are
so you can post better anonymous letters to alt.sex.anonymous.
At least some of us would like real privacy, and consider remailers
a useful part of this, and this means that if you're using remailers
to communicate with your sources for the newspaper article you're writing
on the CIA's cocaine delivery shortfalls or the NSA/Trilateralist designs for
the National Health Care ID Card or your mayor's child pornography habits,
that nobody can track you or your sources down easily.
That means that root at netcom.com can't do it using the root password,
even if they want to comply with the subpoena, and the Secret Service
can't do it after confiscating netcom's machines or wiretapping their phones.

Non-encrypting remailers can never really get that good, but they can
at least d part of the job, and encrypting remailer networks may get
that good if there's enough traffic through the system.

So meanwhile, are you giving root at netcom.com permission to try to
identify the source of your mail and win the $20 for finding out
whether you're really Xenon or you're really L.D.'s evil twin Skippy?
(No idea if they'll try, or if they're even listening....)

					- Radon
					





From frissell at panix.com  Wed Feb  2 17:55:34 1994
From: frissell at panix.com (Duncan Frissell)
Date: Wed, 2 Feb 94 17:55:34 PST
Subject: Josh Quittner`s Newsday c
Message-ID: <199402030153.AA21905@panix.com>


Welcome to new lurkers (if any) from our recent NYT and Newsday publicity.

To give you something a little more interesting than "Is Usenet in the 
Public Domain?" to read, here is my response to Joshua Quittner's column 
in Newsday.

>Tuesday, 01 February 1994
>
>CODING UP A BIT OF PRIVACY
>
>Time is running out for the Cypherpunks.

Actually we have all the time in the world.  One cannot build a New 
Information Infrastructure without including the tools that anyone can 
use to communicate privately.

>This is their central question:  In a future world where all information 
>is centralized on a network, where all information is tracked by the bit, 
>where every purchase you make and every communication can be monitored by 
>corporate America, how does privacy survive?  

More of a problem in the past than in the future.  When P.J. O'Rourke had 
lived in a small New Hampshire town for a year or so and went to the 
store to shop for some clothes the clerk remarked, "That's not the brand 
of underwear you usually buy."  One's life was more of an open book in 
the village and the tribe than it will be in the electronic village.  
Particularly since you can build private networks/"places" that exclude 
anyone you want.

>"The whole information highway thing is now part of the public eye," 
>explain Eric Hughes, a founder of the Cypherpunk movement.  "If we don't 
>change it now, it'll be impossible later."

Misquote?  It's usually better to do the job early than late but the 
nature of network communications is such that it's hard to control at any 
time.

>They dread the coming commercial network of televisions and computers, 
>saying it will displace the Internet and destroy many of the freedoms 
they
>now enjoy.

Surely not the anarcho capitalists who probably represent a majority of 
active cypherpunks.

>For the first time, virtually unbreakable codes are now possible, thanks 
to 
>computers.

I won't say it.  Certainly computers make it easier to *use* encryption.

>The the U.S. government is concerned, as governments always are, about 
>the spread of powerful cryptography (terrorists could use it, kidnappers 
>could use it, drug dealers could use it,

Communications intercepts are rarely used to prosecute crimes.

>The (Clipper) chip is reviled by Cypherpunks and other civil libertarians 
>because it provides a back door that law-enforcement agencies could 
enter,
>with the proper warrants, for surveillance.

Warrants not required, just a certification that the law enforcement 
agency has proper authority to do a communications intercept.

>"I'm starting a bank, and it's not going to be a U.S. bank," Hughes 
>says.  

>The bank will store depositors' money (he's thinking a $200 minimum 
>deposit) and disburse payments to anyone --- all over the Internet.  It 
>will be based abroad, maybe in Mexico. 

Where did Mexico come from?

>A Cypherpunk network bank is one way to pay for a network of truly 
>encrypted, private communications, you see.

Along with lots of other nice things.  Computers have been killing 
traditional banks for years (ever since they enabled the creation of 
Money Market Funds in the '70s).  Netbank (and its many competitors) will 
continue the process.

***********

Duncan Frissell

You don't have to be nice to nation states you meet on the way up if 
you're not coming back down. 
--- WinQwk 2.0b#1165                                                                     





From mediak at well.sf.ca.us  Wed Feb  2 18:11:03 1994
From: mediak at well.sf.ca.us (Joseph Matheny)
Date: Wed, 2 Feb 94 18:11:03 PST
Subject: UNSUBSCRIBE
Message-ID: <199402030210.SAA22612@well.sf.ca.us>


Unsubscribe:mediak at well.sf.ca.us





From qwerty-remailer at netcom.com  Wed Feb  2 18:11:14 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 18:11:14 PST
Subject: New remailer up.
Message-ID: <199402030211.SAA00952@mail.netcom.com>


"So meanwhile, are you giving root at netcom.com permission to try to
identify the source of your mail and win the $20 for finding out
whether you're really Xenon or you're really L.D.'s evil twin Skippy?"

I have no answer to that. I don't know what "permission" means in this
context. I never discluded Netcom employees though. I doubt they would
wish to appear to have lax security by posting the answer though.

Does L.D. have an evil twin? I hope he doesn't get a Unix account.

Seriously, your comments were the first I've seen that really explain to
me what sort of security problem a Netcom remailer faces. Now then, I
ask you as well, might you fill in a few of the blanks in the remailer
list I posted. I could send it to you if you missed it. What are the
"serious" remailers, do they keep mail logs, and are they reliable?

-Xenon





From qwerty-remailer at netcom.com  Wed Feb  2 18:16:14 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 18:16:14 PST
Subject: anonymous mail bombers and what to do about them
Message-ID: <199402030216.SAA01922@mail.netcom.com>


Don't feed the animals.

Generally, when one person is mail-bombing another, either there 
has been a fair amount of provocation by at least one of the parties,
and escalation of childishness isn't as useful as trying to
resolve some of your differences, though it can offer a certain amount
of basic 4-year-old ego satisfaction.  

If somebody's mail-bombing you, and they're root, and they're not doing
it anonymously, you don't need to either; the worst revealing your 
identity will do at that point is encourage them to mail-bomb you.
And your system administrator probably already knows who you are by now,
assuming the bombing has been at a high rate.

If the bomber is root on his home machine, and the bombs include
bad words that aren't mere reflections of your words to him,
you could always complain to the phone company that you're receiving
obscene phone calls.  I doubt the policies or laws about that
specify whether the calls have to be made in spoken English....

If the bomber is root on his business machine, you can complain to
his management, assuming you can locate them.  Some managers get
very bent out of shape about this and do random clueless things,
others conservatively protect their company images,
others ask what state and federal laws have been broken and
tell you to stifle yourself if the answer is "none".

If the bomber is root on his home PC at a university,
arbitrary randomness can occur.

On the other hand, if you're really L- D-, and the person who is
mailbombing you is Perry Metzger, expending large amounts of
childishness in his direction will not accomplish anything positive
for either of you, and if both of you start sending N copies of
each others' mail to each other, exponential growth will not
help either of your systems.  If you're not really L- D-, but
the person who is mailbombing you is still Perry, try talking
rationally to him; he can do that just fine if he thinks it's worthwhile.

If you're really L- D-, and the person is or is not Perry, we can help.
Post your full name, home address with precise latitude  and longitude,
and we'll be happy to deliver some advanced plutonium products 
you may find useful in resolving your problems.

				"Deuterium"
				(oh - wait - maybe I'm "Tritium" today?)
				(or was that "Lithium"?)
				





From CHRISTI1 at MUVMS6.WVNET.EDU  Wed Feb  2 18:21:03 1994
From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR)
Date: Wed, 2 Feb 94 18:21:03 PST
Subject: anonymous mail
Message-ID: <01H8FA8ERMXS001OXX@MUVMS6.WVNET.EDU>


If there is an admin above him, speak with that admin, also mail cert at cert.org
and mail the nsf explaining to them what has been happening, or mail
kfithen at cert.org  She is a really nice lady, and she could help you on this. 
If all else fails, do that and send the fakemail...if you are sure that you
wont get caught.

Bob


                                    \////           
 			            (0 0)                                  
 *------------------------------oOO--(_)--OOo---------------------------------*
 | Bob Christian II  "IGOR"      *       Internet:Christi1 at muvms6.mu.wvnet.edu|
 | Marshall University         *****     E-Mail: Christi1 at muvms6.wvnet.edu    |
 | Huntington, WV                *       GET HIGH....LEARN TO FLY!  IP-ASEL   |
 | Student/D.J 88.1 WMUL FM      *       Major:Undecided(CJ/LAW) Minor:AVT    |
 *----------------------------------------------------------------------------*
--I love flying because there is no speed limit(^10k) and Radar is your friend!
--Marshall assumes no libility for what I say, because my words are MINE!






From wcs at anchor.ho.att.com  Wed Feb  2 18:35:34 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Wed, 2 Feb 94 18:35:34 PST
Subject: Qwerty Remailer Delays
Message-ID: <9402030231.AA03865@anchor.ho.att.com>


It's not very clear how long the delays should be; depends on traffic
to/from your remailer and to some extent to/from the other sites
your remailer cooperates with and the machine it runs on.

If the delay is near-zero, relative to the rest of your traffic,
traffic-analysts can see mail going to your remailer,
followed quickly by similar-sized mail going to another location,
and guess that the two are related, especially if they're
reading the mail itself.  (For instance, if netcom is a bunch of
machines on an Ethernet, and somebody breaks root on one of them,
packet-sniffing the net may catch a non-trivial amount of your
mail going in at least one direction.  It's certainly easier than
tapping all the phones if you don't have a warrant.)

How much you need also depends on your threat model - do you expect
monitoring by netcom users only, active monitoring by root,
logfile examination without ongoing monitoring, etc....?

If there are a bunch of other messages in between,
especially if you're sending most of them to the same destination
(e.g. instead of always choosing a random remailer to send through,
you pick one remailer and send a batch of N messages to it;
and maybe use a different remailer for the next batch)
then it's harder to correlate incoming and outgoing messages.

One strategy for batching is to accumulate N messages and send them
at once, rather than delaying for N minutes.  This may cause rather long
delays, unless you either get lots of traffic or else give up
and send the real message and some fake ones after rand{5..N} minutes.
(If you use  fixed N, it's easy to track when traffic is low.)

Bill





From wcs at anchor.ho.att.com  Wed Feb  2 18:41:04 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Wed, 2 Feb 94 18:41:04 PST
Subject: digital signatures/copyright
Message-ID: <9402030239.AA03921@anchor.ho.att.com>


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

Brian Williams asks:
>  Could one make a case that the use of Digital signatures in
>  messages imply's copyright retention by the author?

No - you can make a case that the author doesn't want his words to be 
forged or tampered with, and is using technology rather than law to enforce it.

Doesn't affect the rest of the legal situation, though one could
try to argue either that the author was or was not expecting copyright.

-----BEGIN PGP SIGNATURE-----
Version: 2.3z

iQCVAgUBLU/2HdCcBnAsu2t1AQF15gP+IqS3o0gNeHng9BSqlk95KzmPwp3oo70p
j2FVYHNOeUKgDSAAwvWr+p3/DOwTafSkJf4A5gW33NOKr0E9JZ4In349RAoueTku
J94VMajT4i7yhOC8X41RPkVLlCltPDRo04SS8h5UFnEk/zFxiTkvXY9mpBcK3yUw
vYY9pbmupSc=
=KbXS
-----END PGP SIGNATURE-----



		Bill





From pgpkeys at wasabi.io.com  Wed Feb  2 18:51:03 1994
From: pgpkeys at wasabi.io.com (PGP Slave Key Server)
Date: Wed, 2 Feb 94 18:51:03 PST
Subject: New server up.
Message-ID: <199402022116.VAA20077@wasabi.io.com>


	PGP Slave,

I hear and obey O Master.

	Could you please announce my full name, phone number, address, visa card
	number, a giff of my signature, height, weight and driver's licence number
	not only to the Cypherpunks mailing list but to many usenet groups as well,

If you insist :-)  (Can you give me a few more days to comply?...I`m having
some trouble getting a copy of your signature.  One of the guys in the chem
faculty says he knows where he can get one at the weekend...)

	since you obviously feel I no longer wish to be known to the masses as
	Xenon, and I instead want them to start calling me and postal mailing me
	asking for copies of PGP. Thanks asshole. I thought the people on this
	list were concerned with privacy, but I was wrong. I mention Xenon in
	my personal .plan, but I ask people to let me keep the small amount of
	extra privacy I still retain.

Hey bud, you`ve clearly misunderstood the whole point of the movement.  You
get whatever privacy you can make for yourself through technology.  Any dolt
who goes to the extent of using two remailers and a penet id to hide his
identity then puts his nym`s secret key in his True Name signature file
gets the privacy he deserves.  Anyway, whats the big deal?...noone who
read my post will have a clue who you are unless you tell them yourself; and
anyone who could track you down from the two bits of info in that post is
more than capable of tracking you down the same way I did from the public
logs on netcom.  I was just waving enough of a red rag at you to make the
point forcefully...  (remember your the one arguing against putting delays
more than 15 minutes in a remailer system...)

The point I was making was that you cannot rely on trust such as a lack of
logs alone to keep things like remailer chains secure...you *have* to build
the security into the technology and the protocols.  You must assume that
The Bad Guys (tm) have full access to all the logs of all the machines that
run remailers...if not directly then by watching the wires.  So any remailer
scheme has to include dummy traffic, significant delays, and encrypted input
way back at the sender`s end.  And the protocol has to be such that a remailer
chain is as strong as its strongest link, not as weak as its weakest link,
meaning if 9 out of 10 remailers have been compromised but the 10`th is run by
Honest Joe, then Honest Joe`s trustworthiness is sufficient to defeat the evil
forces of TBG with there 9 bogus servers.

	You wrote,
	"qwerty account or not, the public logs on netcom show more than enough
	info to trivially track people down."

	Trivial? And so you hack out the info that a message went from remailer
	A through qwerty and on to remailer B, at a certain time. You haven't
	tracked down anyone my friend.

Yo dude, I found *you* didn`t I?  And it took me less than 5 minutes.  So
bite me.

PS How to build your own mailer logs on netcom...just stay on long enough
and keep typing `mailq`...no problemo...I can`t be bothered but if I could
thats how I`d track traffic through qwerty for your $20...





From qwerty-remailer at netcom.com  Wed Feb  2 19:11:03 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 19:11:03 PST
Subject: New remailer up
Message-ID: <199402030311.TAA14987@mail.netcom.com>


I haven't really kept track of which remailers are how reliable;
they're almost all relatively new and experimental,
people are hacking software, they go up and down a lot,
and I almost never use them anyway.  I also don't like
keeping track of the syntax and which ::'s are followed by which ##s :-)

Julf's anon.penet.fi remailer is serious; he's done a lot of work
to get a private machine, payng for a reasonably expensive
64kbps line himself, and has it located somewhere that only 3 people know.
(The original was located at a university, and somebody decided
they wanted it Closed.)  It's also outside the US, which is useful,
.  On the other hand, it works differently than the one-way anonymous remailers,
uses up a substantial fraction of the net.bandwidth into FInland,
and costs him real bucks - somebody ought to start a US equivalent
and deload him.

I'd guess tht extropia is also probably well-run, or at least 
has good features.  But I haven't used it.





From kevin at axon.cs.byu.edu  Wed Feb  2 19:35:34 1994
From: kevin at axon.cs.byu.edu (Kevin Vanhorn)
Date: Wed, 2 Feb 94 19:35:34 PST
Subject: New remailer up.
In-Reply-To: <199402030119.RAA17214@mail.netcom.com>
Message-ID: <9402030335.AA16272@axon.cs.byu.edu>


>> However, make no mistake that Netcom can and will cooperate with the
>> police if you use your remailer in a way that the government doesn't
>> like, so it seems that the security afforded isn't that good."
>
> So you aren't interested unless you can commit serious felony crimes
> using a given remailer? I would be happy if criminals stayed away from

Things "that the government doesn't like" and "serious felony crimes"
are not the same.  People in positions of governmental power have
all too often in the past used that power to harrass others who have
committed no crime.  Remember how Nixon used to sic the IRS on his
political enemies?  And the ATF has a sordid history of harrassing
harmless people, including trying to trick them into committing
technical violations of obscure gun-control regulations.  Often enough,
government officials harrass people who have broken no law, but have
only behaved in a way that those officials WANT to be made illegal.

-----------------------------------------------------------------------------
Kevin S. Van Horn     | It is the means that determine the ends.
kevin at bert.cs.byu.edu |






From remailer at merde.dis.org  Wed Feb  2 20:01:04 1994
From: remailer at merde.dis.org (remailer bogus account)
Date: Wed, 2 Feb 94 20:01:04 PST
Subject: PGPTools Minor Bug
Message-ID: <9402030359.AA28381@merde.dis.org>


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

There is a minor bug in PGPTOOLS.C which needs to be fixed. In 
pgp_extract_rsa, two lines need to be added. This variable was not being
cleared. When the precision was later set to max, there was garbage left
in the high-order bytes of the mpi. This caused the size of the MPI to be
wrong, and the function would not decrypt 2.2 or earlier packets. It could
also occasionally fail to decrypt a 2.3 packet. Sorry about that.

					   Pr0duct Cypher

/* Decrypts and extracts the key from an RSA-encrypted block */
/* Returns true if successful, false if not */
int pgp_extract_rsa(struct fifo *f,byte ideakey[16],
     struct pgp_pubkey *pk,struct pgp_seckey *sk)
{
struct mpi *p=safemalloc(sizeof(struct mpi));
struct mpi *c=safemalloc(sizeof(struct mpi));
unit *dp=safemalloc(sizeof(unitarr));
unit *dq=safemalloc(sizeof(unitarr));
unit *temp=safemalloc(sizeof(unitarr));
byte result;

word16 checksum=0;
byte *pp;
byte type;
word32 length;
set_precision(MAX_UNIT_PRECISION);        <--------- ADD
mp_burn(p->value);                        <--------- ADD
set_precision(bits2units(pk->n.bits+SLOP_BITS));
pgp_examine_packet(f,&type,&length);

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLU4ptsGoFIWXVYodAQG3GQQApg45mfrbfoUP4BhrtmvE+zRGdSp6zx9+
M7GDnJ+vpCVzQj6S7Z+y1RZ4FFAT6yX/63oeVvhW8FzNZ1s5xOZivbIZrhC6WPJU
qZiuy/veXD7OrWpUJueucT5xPF/Nsjdx3w2DiAy2x7YtRycpzugMSpSdvJcCcOuK
rGBkPV2eJDc=
=+WVh
-----END PGP SIGNATURE-----





From fnerd at smds.com  Wed Feb  2 20:15:34 1994
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Wed, 2 Feb 94 20:15:34 PST
Subject: fwd: Canadian gov't eavesdropping
Message-ID: <9402030355.AA05275@smds.com>


Mike Markley says-

> I'd be curious to see how they are going to do voice recognition on 
> random conversations. Unless I am very sadly out of date you need to 
> teach the pattern matcher individual voices.

I remember a story from a conference in the sixties where someone 
wanted to prove the point that it's much easier to make a recognizer 
for all voices if you're only looking for a certain word.  So he built 
a "watermelon" box.  He sits this up on the podium with him and gives 
his talk, which naturally at some point gets to...

"...a single word, for instance 'watermelon.'" *beep!*

Then later there's a Q&A period, of course...

A: Please step up to the microphone...
Q: You mean all this thing does is recognize the word "watermelon,"
   *beep!* and that it can recognize the word "watermelon" *beep!*
   no matter who says it?
A: That's right, it's an any-speaker, "watermelon" *beep!* recognizer.
Q2: Why the word... "watermelon" *beep!* exactly?
...

-fnerd *BZZZT! AAAAARRRRROOOOGAH!*
quote me
- -
cryptocosmology- sufficiently advanced communication is indistinguishable
                 from noise - god is in the least significant bits
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----





From matthew at gandalf.rutgers.edu  Wed Feb  2 20:31:04 1994
From: matthew at gandalf.rutgers.edu (Matthew Bernardini)
Date: Wed, 2 Feb 94 20:31:04 PST
Subject: Archiving mail-lists...
Message-ID: <CMM-RU.1.3.760249617.matthew@gandalf.rutgers.edu>


What do you call 1,000 copyright lawyers chained to the bottom of the ocean ?








1)A good start.
2)A drop in the bucket.
3)A boring Swim Party.



I can't take five hundred messages in a week from people calling each other
names and including 500 lines of previous posts !!!!
Give my mailbox a rest, eh ?





From remailer-admin at chaos.bsu.edu  Wed Feb  2 20:41:04 1994
From: remailer-admin at chaos.bsu.edu (Anonymous)
Date: Wed, 2 Feb 94 20:41:04 PST
Subject: No Subject
Message-ID: <199402030530.XAA11324@chaos.bsu.edu>



Perry almost wrote:

> Anyway, people who want to use the law to restrict distribution of
> their software are extremely foolish. Your code is out there
> it WILL be copied. Forever. You can't help it. If you don't want
> people to use your software, don't write it.






From newsham at uhunix.uhcc.Hawaii.Edu  Wed Feb  2 21:26:04 1994
From: newsham at uhunix.uhcc.Hawaii.Edu (Tim Newsham)
Date: Wed, 2 Feb 94 21:26:04 PST
Subject: LPC on ADSP2105
Message-ID: <9402030525.AA18455@uhunix.uhcc.Hawaii.Edu>




I have recently finished my senior project on low-bandwidth coding
of speech.  I outline an implementation of Linear Predictive Coding
(LPC) on the ADSP2105.  I am making the paper and the source code
freely available in hopes that it may interest and possibly help
someone.  In order to avoid having to mail out copies seperately
to everyone who is interested I am putting the paper temporarily
on:

    ftp.uu.net:/tmp/lpc-paper.tar.gz

If you know of an archive for which this paper is suitable please
let me know how to submit it there or submit it yourself and let
me know.  The archive is a tar'ed collection of files, to unpack:

   gzip -d lpc-paper.tar.gz
   tar xvfp lpc-paper.tar

The contents of the archive are:

   Makefile
   README
   a4.sty
   lpc.ps
   lpc.tex
   lpc4b.asm
   notes.tex
   schematic
   schematic.ps
   source.tex
   
and contain postscript and LaTeX formats of the document. 

Here is the abstract:

\begin{abstract}
An implemenation of Linear Predictive Coding, a low-bandwidth 
speech encoding scheme, 
built around the ADSP-2105 signal processing CPU is described.  The
hardware schematics and software source code listing are included.
\end{abstract}

                                   Tim N.

(ps.  I am no longer subscribed to the cypherpunks list so
if you wish to reply, send the reply directly to me)






From catalyst-remailer at netcom.com  Wed Feb  2 22:25:35 1994
From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com)
Date: Wed, 2 Feb 94 22:25:35 PST
Subject: New remailer up.
Message-ID: <199402030624.WAA23896@mail.netcom.com>


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

ndw1: mail qwerty at netcom.com
Subject: Re: new server up.
::
Request-Remailing-To: cypherpunks at toad.com

(Skip to end for actual remailer discussion.)

PGP Slave,
"If you insist :-)  (Can you give me a few more days to comply?...I'm having
some trouble getting a copy of your signature.  One of the guys in the chem
faculty says he knows where he can get one at the weekend...)"

Thanks again. Now everyone knows to never tell YOU any secrets, no matter
how trivial they might be, since you will post them. Who's the 'punk?

and,
"Hey bud, you`ve clearly misunderstood the whole point of the movement.  You
get whatever privacy you can make for yourself through technology.  Any dolt
who goes to the extent of using two remailers and a penet id to hide his
identity then puts his nym`s secret key in his True Name signature file
gets the privacy he deserves."

I'm not sure you understand what -----BEGIN PUBLIC KEY BLOCK----- means.
Or were you fingering someone else? Am I missing something?

I am using two remailers to help out with the lack of traffic, not to hide my
identity.

There are many levels of privacy, and the one I am concerned with does not
involve anything other than that Usenetters who are NEWBIES being forced to
contact me via e-mail. It also involves not having the people I work around
who are not my close friends gossiping about, mindlessly, about "what I am
trying to hide" with my use of PGP. This is a personal thing, and using
a nickname on Usenet is as strong of security as I need to meet this need.

When I joined this list and started using Cypherpunk remailers I decided to
not maintain my anonymity in a vigorous manner. I think you are trying to
show off what a super hacker you are by typing "last qwerty", or even just
"finger qwerty" from outside, to see my local site that I telnet in from,
then typing the master-hacker magic-line "rusers my.site". I am impressed
that you too can type these commands, and you get the Xenon Hacker God
Award for the entire year of 1994. However, I would rather talk about
remailer security levels than trying to cope with someone embarrassing
themselves posting their "discovery" of my "real identity".

I am not "hiding my identity", I am maintaining a minimal amount of PERSONAL
privacy, at a security level that fits my needs; I am using a NICKNAME. For this
purpose, qwerty and catalyst serve me well. I'm not sure why you have so
much fun disrespecting a person's privacy. I arrived here with a simple
question, "Can I use your remailers for bulk mailing of 1-3MB a day to
people wanting the PGP FAQ and MacPGP Guide? What are the qualities
of each remailer?" I think I understand the movement quite well, but
I understand there IS NO fully secure remailer network which I would bet my
life on. And I understand and am acting upon what few seem to care about,
which is getting a large number of people outside of the internet-skilled culture
using secure encryption. There are 50-100 million Mac and Windows users,
and the majority of those with a modem use their internet connection for simple
e-mail ONLY. Many only HAVE e-mail in fact. PGP has mass media attention,
but very few are using it since they can't get it by a 1-800 number. I hope
ViaCrypt will change this, with Mac and Windows versions.

 -----BEGIN REMAILER DISCUSSION BLOCK-----

and,
"logs on netcom.  I was just waving enough of a red rag at you to make the
point forcefully...  (remember your the one arguing against putting delays
more than 15 minutes in a remailer system...)"

Finally we are talking about remailers! Thank-you. My telnet log is public.
Netcom's sendmail logs are not (?). There IS a difference. I was arguing
against long delays, which should only be needed if no baseline traffic is
going on. Many people will not be able to function well if say, mail is
batched out at midnight. Rapid two-way communication is very important these
days in getting ANYTHING done, be it above ground OR underground.

and,
"PS How to build your own mailer logs on netcom...just stay on long enough
and keep typing `mailq`...no problemo...I can`t be bothered but if I could
thats how I`d track traffic through qwerty for your $20..."

Now you really do get an award, but not the $20 since that will go to the person
who WAS downloading mailq logs from Netcom ;-). You seem to be absolutely
right. Here is an outgoing piece of mail sent from qwerty:

qwerty: mail alt.test at news.cs.indiana.edu
Subject: Ignore ignore test.
This is a test of 'mailq'.





From catalyst-remailer at netcom.com  Wed Feb  2 22:35:35 1994
From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com)
Date: Wed, 2 Feb 94 22:35:35 PST
Subject: New remailer up.
Message-ID: <199402030633.WAA01347@mail.netcom.com>


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

(Skip to end for actual remailer discussion.)

PGP Slave,
"If you insist :-)  (Can you give me a few more days to comply?...I'm having
some trouble getting a copy of your signature.  One of the guys in the chem
faculty says he knows where he can get one at the weekend...)"

Thanks again. Now everyone knows to never tell YOU any secrets, no matter
how trivial they might be, since you will post them. Who's the 'punk?

and,
"Hey bud, you`ve clearly misunderstood the whole point of the movement.  You
get whatever privacy you can make for yourself through technology.  Any dolt
who goes to the extent of using two remailers and a penet id to hide his
identity then puts his nym`s secret key in his True Name signature file
gets the privacy he deserves."

I'm not sure you understand what -----BEGIN PUBLIC KEY BLOCK----- means.
Or were you fingering someone else? Am I missing something?

I am using two remailers to help out with the lack of traffic, not to hide my
identity.

There are many levels of privacy, and the one I am concerned with does not
involve anything other than that Usenetters who are NEWBIES being forced to
contact me via e-mail. It also involves not having the people I work around
who are not my close friends gossiping about, mindlessly, about "what I am
trying to hide" with my use of PGP. This is a personal thing, and using
a nickname on Usenet is as strong of security as I need to meet this need.

When I joined this list and started using Cypherpunk remailers I decided to
not maintain my anonymity in a vigorous manner. I think you are trying to
show off what a super hacker you are by typing "last qwerty", or even just
"finger qwerty" from outside, to see my local site that I telnet in from,
then typing the master-hacker magic-line "rusers my.site". I am impressed
that you too can type these commands, and you get the Xenon Hacker God
Award for the entire year of 1994. However, I would rather talk about
remailer security levels than trying to cope with someone embarrassing
themselves posting their "discovery" of my "real identity".

I am not "hiding my identity", I am maintaining a minimal amount of PERSONAL
privacy, at a security level that fits my needs; I am using a NICKNAME. For this
purpose, qwerty and catalyst serve me well. I'm not sure why you have so
much fun disrespecting a person's privacy. I arrived here with a simple
question, "Can I use your remailers for bulk mailing of 1-3MB a day to
people wanting the PGP FAQ and MacPGP Guide? What are the qualities
of each remailer?" I think I understand the movement quite well, but
I understand there IS NO fully secure remailer network which I would bet my
life on. And I understand and am acting upon what few seem to care about,
which is getting a large number of people outside of the internet-skilled
culture using secure encryption. There are 50-100 million Mac and Windows
users, and the majority of those with a modem use their internet connection
for simple e-mail ONLY. Many only HAVE e-mail in fact. PGP has mass media
attention, but very few are using it since they can't get it by a 1-800 number.
I hope ViaCrypt will change this, with Mac and Windows versions.

 -----BEGIN REMAILER DISCUSSION BLOCK-----

and,
"logs on netcom.  I was just waving enough of a red rag at you to make the
point forcefully...  (remember your the one arguing against putting delays
more than 15 minutes in a remailer system...)"

Finally we are talking about remailers! Thank-you. My telnet log is public.
Netcom's sendmail logs are not (?). There IS a difference. I was arguing
against long delays, which should only be needed if no baseline traffic is
going on. Many people will not be able to function well if say, mail is
batched out at midnight. Rapid two-way communication is very important these
days in getting ANYTHING done, be it above ground OR underground.

and,
"PS How to build your own mailer logs on netcom...just stay on long enough
and keep typing `mailq`...no problemo...I can`t be bothered but if I could
thats how I`d track traffic through qwerty for your $20..."

Now you really do get an award, but not the $20 since that will go to the person
who WAS downloading mailq logs from Netcom ;-). You seem to be absolutely
right. Here is an outgoing piece of mail sent from qwerty:

qwerty: mail alt.test at news.cs.indiana.edu
Subject: Ignore ignore test.
This is a test of 'mailq'.

qwerty: mailq
                Mail Queue (58 requests)
 --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
(much deleted....)
UAA29300*      27 Wed Feb  2 20:13 qwerty
                                   alt.test at news.cs.indiana.edu

And some incoming, as bounced off of hh at cicada.berkeley.edu:

UAA29978*       6 Wed Feb  2 20:20 <hh at cicada.berkeley.edu>
                                   "|/u1/qwerty/remail/slocal.pl"

slocal.pl is part of Hal's remailer scripts.

So who has a remailer to send me that will avoid this? Looks like I'd not use
qwerty or catalyst as the first or last stop in a remailing chain. But if the
only way to track this is AS the mail arrives or goes out, I'd still classify
qwerty/catalyst as being good for casual security uses such as my post
to Usenet above. It would be a lot faster than anon.penet.fi! Then again, a
person could blackmail someone for posting to alt.sex.bestiality. When can
I and many others switch from Netcom to a pubic service Unix network
that is private/secure?

*Again, I'm trying to compile a list of remailers and what levels of
   security each entails. Such a list does not seem to exist. If you ever
   want more traffic....

 -----END REMAILER DISCUSSION BLOCK-----

PGP Slave, despite this misunderstanding, could we declare peace and get
on with a discussion about REMAILERS, instead of my nickname. I'm out
here to learn and try to contribute what I can. I am sending info about
secure encryption to at least a dozen people a day, many of whom would
not otherwise get their hands on PGP or even the PGP FAQ, and I have thus
become the most prolific user of the Cypherpunk remailers. I am doing this
randomly, chained between two remailer at a time. This volume could triple
if I started advertising. I don't misunderstand the movement?

 -Nik (Xenon)

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVBTPASzG6zrQn1RAQH2/QP/dexRZeXe7KRZpADn+hCBUoUExelRJ6hv
A6kARzcymCAa3571u1XDauIcmNTPXDQTQ4bf3D5x94eR2AM43NjPcVBWkZcUYgEk
ROGkIP3fAFnpBCbn0RZPOhIfYt8NnvWY53knRd5JxJbJ6jQxjRG9SfADs2ip8Fpl
v4p6WPlnFHM=
=j2FI
-----END PGP SIGNATURE-----





From qwerty-remailer at netcom.com  Wed Feb  2 23:05:35 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Wed, 2 Feb 94 23:05:35 PST
Subject: New remailer up.
Message-ID: <199402030705.XAA03827@mail.netcom.com>


I must thank Hal Finney for pointing me to 'gopher chaos.bsu.edu'. I will
be much better informed about remailers for having found this site. I'm
not sure why it's taken a week for someone on this list to tell me this.

-Nik (Xenon)





From nobody at pmantis.berkeley.edu  Wed Feb  2 23:31:05 1994
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Wed, 2 Feb 94 23:31:05 PST
Subject: A serious question of ethics
Message-ID: <9402030727.AA27027@pmantis.berkeley.edu>


Ok, I'm in a bit of a quandry.  While surfing the net last week, I
happened across an address addached to a machine that belongs the the 
federal reserve.  No big deal.  I telnetted there on a lark, and entered 
'guest' for the account.  It dropped me into a shell.  It didn't ask for 
a password.  Intrigued, I did a little looking around.  Nothing special, 
a CDRom and about 80 accounts.  But(!!), /etc/passwd was there and 
available and not using shadows.  No, I didn't snatch a copy.

Quandry(ies)

1)  Should I alert someone there about the obvious (and, IMHO serious) 
seciruty hole?

	or

2)  Should I ignore it?

3)  Should I take advantage of it (well, maybe not)

----------

I don't like to see systems so open, no matter who they belong too, and 
the fact that the governments (whether you like them or not) has one this 
open REALLY bothers me. 

But, I also wonder what kind of trouble I could get into.  Technically, I 
violated something just by being there as I didn't have permission, and 
the fact I accessed the passwd file makes it even worse.  If I report it, 
I could be in deep shit.

I could mail to them via a remailer (like penet.fi, so that they could 
answer for more information if needed).  That is a little securer and 
Julf is out of jurisdiction of the FBI hunting me down.

Yes, I'm a little paranoid, but Uncle Sam likes to make examples out of 
white-collar hackers, and for me it was pure and dumb luck (like a jury 
would believe a 22 year-old computer geek isn't trying to gain illegal 
access).

Any suggestions?  Please?  I consider this to be serious (most may not).






From gnu  Wed Feb  2 23:41:05 1994
From: gnu (John Gilmore)
Date: Wed, 2 Feb 94 23:41:05 PST
Subject: Commodity Jurisdiction success for Kerberos Bones!
Message-ID: <9402030739.AA08429@toad.com>


(            )				United States Department of State
( State Dept )				Bureau of Politico-Military Affairs
(    Logo    )				Office of Defense Trade Controls
(            )
					Washington, D.C. 20522-0602

In reply refer to			   Feb  1 1994
OTDC Case:  CJ-012-94

YOUR LETTER DATED:   January 13, 1994

REQUEST FOR COMMODITY JURISDICTION FOR:  "Kerberos 900104
bones.tar.Z patchlevel 6" software program

This commodity jurisdiction (CJ) request was referred to the 
Departments of Commerce and Defense for their review and
recommendations.  As a result, the Department of State has
determined that the referenced commodity falls under the licensing 
jurisdiction of the Department of Commerce.  Please consult that
agency's Office of Technology and Policy Analysis at (202) 482-4145
to determine their requirements prior to export.

Should you require further assistance on this matter, please contact
Maj. Gary Oncale at (703) 875-5655.

			Sincerely,

			   (signed -- but it doesn't look 
			    anything like the name below)

			William B. Robinson
			Director
			Office of Defense Trade Controls






John Gilmore
Cygnus Support
1937 Landings Drive
Mt. View, CA 94043

		-- end of letter from State Department --

Now, what does it mean that we got a Commodity Jurisdiction for the
Kerberos Bones?

It means that the State Department has formally excused itself from
worrying about us exporting the Bones.  If the Commerce Department lets
us do it, it's fine with the State Department.  Exporting the Bones
will not violate the International Traffic in Arms Regulations (ITAR).
(Doing so might still violate other laws -- the State Dept has
expressed no opinion on that.)

This is no surprise, since the Kerberos Bones were deliberately
emasculated to remove anything that might cause the State Department or
the NSA to get upset.  The letter just confirms that that effort was a
success.

I will do a formal check with the Commerce Department, as suggested in
the State Department letter.  My current understanding is that under
Commerce rules (the Export Administration Act), publicly available
software can be exported to any destination.

In particular, I believe this means that there's nothing to fear from
putting up the Bones for ordinary FTP.  (There's a serious First
Amendment issue being debated, over whether export control laws can
prevent you from publishing software via FTP at all -- but even the
most paranoid should now figure it's not an issue for the Bones.)

I encourage people and companies who are interested in export issues
to submit a commodity jurisdiction request for some software that you
want to export, and go through the process.  In public.  The State
Department and NSA don't publish their guidelines for what is exportable
and what isn't, so the only way we-the-public are going to find out
is by asking, and then telling each other.

I've set up an FTP archive of such information on
ftp://ftp.cygnus.com/pub/export.  It includes `cjr.kit', which is the
info you need to file your own CJ Requests, and three files regarding
Commerce Department licensing.  `commerce.gtda.license.faq' in
particular is a FAQ from the Commerce Department about when the General
license for Technical Data to All destinations lets you export without
any paperwork.
-- 
John Gilmore                gnu at toad.com  --  gnu at cygnus.com  --  gnu at eff.org
Can we talk in private?        Join me in the Electronic Frontier Foundation.
Not if the FBI and NSA have their way.            Ask membership at eff.org how.





From sameer at soda.berkeley.edu  Thu Feb  3 00:36:05 1994
From: sameer at soda.berkeley.edu (Sameer)
Date: Thu, 3 Feb 94 00:36:05 PST
Subject: J. Michael Diehl's procmail-pgp
Message-ID: <m0pRyXZ-00010yC@infinity.hip.berkeley.edu>


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

	If J. Mike Diehl is out there (mail to the address I have for
him is bouncing) or someone else has that procmail-pgp .procmailrc he
has written, I would appreciate it if you sent it to me. Thanks!

- -Sameer


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVCoZni7eNFdXppdAQHzQwP/eXkVO/lN0794NwREP/YXfpF3xVubCYAA
TN6F+fjv3zpxkp95GRDbwpIxiw/Aytz/5qXjgJfV0Gatrc8CNPj/zbzBdB0Wc7Yq
kcaLJYwoBCazhUy6gC+3w1A79H8Uav8bgbWfx2coBQMhp69+OYyH88GuNf+01m+4
LTNcml4sJEc=
=InuS
-----END PGP SIGNATURE-----




From rpmartin at acs.ucalgary.ca  Thu Feb  3 00:55:34 1994
From: rpmartin at acs.ucalgary.ca (Rob P. Martin)
Date: Thu, 3 Feb 94 00:55:34 PST
Subject: Qwerty Remailer Delays
In-Reply-To: <9402030231.AA03865@anchor.ho.att.com>
Message-ID: <9402030854.AA69861@acs2.acs.ucalgary.ca>


> 
> It's not very clear how long the delays should be; depends on traffic
> to/from your remailer and to some extent to/from the other sites
> your remailer cooperates with and the machine it runs on.
> 
> If the delay is near-zero, relative to the rest of your traffic,
> traffic-analysts can see mail going to your remailer,
> followed quickly by similar-sized mail going to another location,
> and guess that the two are related, especially if they're
> reading the mail itself.  (For instance, if netcom is a bunch of

I have an idea I don't think has been proposed before.  There has
been a lot of discussion of having "background noise" by having
remailers mail random messages to various bit-buckets and other
remailers on a constant basis.  But why not do it this way.  If a
remailer recieves a message of size N, it holds that message for
a short (< 15min) period of time, and then it sends out X (5 <
rnd X <15) messages of size N, some going to remailers as noise
messages, some going to bit buckets as dummy recipients, and of
course one heading on it's origional route.  One problem with
this is that messages would multiply, ie. 'A' sends to remailer
'B' whichs sends 10 messages out, 5 to other remailers who in
turn send out 10 messages a piece, 5 of which goes to other
remailers who again multiply this.  And you end up with one of
those annoying commercials, where, he tells 5 friends, and they
tell 5 friends until the network shuts down.  So Remailers must
establish some code (which would be send pgp encrypted) that
would give a message a max possible life span of say 5-10
generations. (even that may be too much) 

	Well it is just my $.02 (and Canadian cents at that!)

	Rob

"Remeber, the day after tomorrow is the second day of the rest of
your life." 
     Unknown.






From wcs at anchor.ho.att.com  Thu Feb  3 01:21:05 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Thu, 3 Feb 94 01:21:05 PST
Subject: A serious question of ethics
Message-ID: <9402030916.AA06954@anchor.ho.att.com>


Well, if the Federal Reserve has a guest account with no password,
maybe they're inviting guests...  Ok,, mailing them through a remailer
might not hurt, though it might point out to them that remailers exist,
if they haven't figured it out already.

Personally, if I were logged on to one of their machines,
I'd start looking for the "print" command :-)

			Signed, Anonymous

--





From tcmay at netcom.com  Thu Feb  3 02:21:06 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 3 Feb 94 02:21:06 PST
Subject: (fwd) Notes on key escrow meeting with NSA
Message-ID: <199402031018.CAA19497@mail.netcom.com>



This interesting report on the Clipper/Capstone/Tessera Key Escrow
system was posted by Matt Blaze to several groups. I hope most of you
have seen it already, but for those who haven't, here it is.

Apologies for using bandwidth to reproduce an article here, but I
think the machinations over Clipper and key escrow in general are
pretty germane to the Cypherpunks charter.

--Tim May


Newsgroups:
sci.crypt,talk.politics.crypto,comp.org.eff.talk,alt.privacy.clipper
From: mab at research.att.com (Matt Blaze) Subject: Notes on key escrow
meeting with NSA Organization: AT&T Date: Wed, 2 Feb 1994 21:02:55 GMT
Message-ID: <mab.760222975 at merckx>


A group from NSA and FBI met the other day with a group of us at Bell
Labs to discuss the key escrow proposal.  They were surprisingly
forthcoming and open to discussion and debate, and were willing to at
least listen to hard questions.  They didn't object when asked if we
could summarize what we learned to the net.  Incidentally, the people
at the meeting seemed to base a large part of their understanding of
public opinion on Usenet postings.  Postings to sci.crypt and
talk.politics.crypto seem to actually have an influence on our
government.

A number of things came out at the meeting that we didn't previously
know or that clarified previously released information.  What follows
is a rough summary; needless to say, nothing here should be taken as
gospel, or representing the official positions of anybody.  Also,
nothing here should be taken as an endorsement of key escrow, clipper,
or anything else by the authors; we're just reporting.  These notes
are based on the collective memory of Steve Bellovin, Matt Blaze, Jack
Lacy, and Mike Reiter; there may be errors or misunderstandings.
Please forgive the rough style.  Note also the use of "~ ~" for
'approximate quotes' (a marvelous Whit Diffie-ism).

NSA's stated goals and motives for all this:
	* DES is at the end of its useful life
	* Sensitive, unclassified government data needs protection
	* This should be made available to US Citizens
	* US business data abroad especially needs protection
	* The new technology should not preclude law enforcement access

They indicated that the thinking was not that criminals would use key
escrowed crypto, but that they should not field a system that
criminals could easily use against them.  The existence of key escrow
would deter them from using crypto in the first place.  The FBI
representative said that they expect to catch "~only the stupid
criminals~" through the escrow system.

Another stated reason for key escrow is that they do not think that
even government-spec crypto devices can be kept physically secure.
They do expect enough to be diverted to the black market that they feel
they need a response.  NSA's emphasis was on the foreign black market...

There seems to be a desire to manipulate the market, by having the
fixed cost of key escrow cryptography amortized over the government
market.  Any private sector devices would have to sell a much larger
number of units to compete on price.  (This was somewhere between an
implication and an explicit statement on their part.)

When asked about cryptography in software, "~...if you want US
government cryptography, you must do it with hardware~".

Clipper chips should be available (to product vendors) in June.  You
can't just buy loose chips - they have to be installed in approved
products.  Your application interface has to be approved by NIST for
you to get your hands on the chips.

An interesting point came up about the reverse-engineering resistance
of the chips: they are designed to resist reverse engineering the data
in the chip without destroying the chip.  It is not clear (from the
information presented at the meeting) whether the chips are equally
resistant to destructive reverse-engineering to learn the skipjack
algorithm.   They said the algorithm was patented, but they may have
been joking.  ("~And if that doesn't scare you enough, we'll turn the
patent over to PKP.~")

The resistance to reverse engineering is not considered absolute by
NSA.  They do feel that "~it would require the resources of a national
laboratory, and anyone with that much money can design their own
cryptosystem that's just as strong.~"

They repeated several times that there are "~no plans to regulate the
use of alternate encryption within the US by US citizens.~"  They also
indicated they "~weren't naive~" and didn't think that they could if
they wanted to.

There were 919 authorized wiretaps, and 10,000 pen register monitors,
in 1992.  They do not have any figures yet on how often cryptography
was used to frustrate wiretaps.

They do not yet have a production version of the "decoder" box used by
law enforcement.  Initially, the family key will be split (by the same
XOR method) and handled by two different people in the athorized
agencies.  There is presently only one family key.  The specifications
of the escrow exploitation mechanism are not yet final, either; they
are considering the possibility of having the central site strip off
the outer layers of encryption, and only sending the session key back
to the decoder box.

The escrow authorities will NOT require presentation of a court order
prior to releasing the keys.  Instead, the agency will fill out a form
certifying that they have a legal authorization.  This is also backed
up with a separate confirmation from the prosecutor's office.  The
escrow agencies will supply any key requested and will not themselves
verify that the keys requested are associated with the particular court
order.

The NSA did not answer a question as to whether the national security
community would obtain keys from the same escrow mechanism for their
(legally authorized) intelligence gathering or whether some other
mechanism would exist for them to get the keys.

The masks for the Clipper/Capstone chip are unclassified (but are
protected by trade secret) and the chips can be produced in an
unclassified foundry.  Part of the programming in the secure vault
includes "~installing part of the Skipjack algorithm.~" Later
discussion indicated that the part of the algorithm installed in the
secure vault are the "S-tables", suggesting that perhaps unprogrammed
Clipper chips can be programmed to implement other 80-bit key, 32 round
ciphers.

The Capstone chip includes an ARM-6 RISC processor that can be used for
other things when no cryptographic functions are performed.  In
particular, it can be used by vendors as their own on-board processor.
The I/O to the processor is shut off when a crypto operation is in
progress.

They passed around a Tessera PCMCIA (type 1) card.  These cards
contain a Capstone chip and can be used by general purpose PC
applications.  The cards themselves might not be export controlled.
(Unfortunately, they took the sample card back with them...)  The card
will digitally sign a challenge from the host, so you can't substitute
a bogus card.  The cards have non-volatile onboard storage for users'
secret keys and for the public keys of a certifying authority.

They are building a library/API for Tessera, called Catapult, that
will provide an interface suitable for many different applications.
They have prototype email and ftp applications that already uses it.
They intend to eventually give away source code for this library.
They responded favorably to the suggestion that they put it up for
anonymous ftp.

Applications (which can use the library and which the NSA approves for
government use) will be responsible for managing the LEAF field.  Note
that they intend to apply key escrowed Skipjack to other applications,
including mail and file encryption.  The LEAF would be included in
such places as the mail header or the file attributes.  This implies
that it is possible to omit sending the LEAF -- but the decrypt chip
won't work right if it doesn't get one.

When asked, they indicated that it might be possible wire up a pair of
Clipper/Capstone chips to not transmit the LEAF field, but that the
way to do this is "~not obvious from the interface we give you~" and
"~you'd have to be careful not to make mistakes~".  They gave a lot of
attention to obvious ways to get around the LEAF.

The unit key is generated via Skipjack itself, from random seeds
provided by the two escrow agencies (approximately monthly, though
that isn't certain yet).  They say they prefer a software generation
process because its correct behavior is auditable.

Capstone (but not Clipper) could be configured to allow independent
loading of the two key halves, in separate facilities.  "~It's your
money [meaning American taxpayers].~"

The LEAF field contains 80 bits for the traffic key, encrypted via the
unit key in "~a unique mode <grin>~", 32 bits for the unit id, and a 16
bit checksum of some sort.  (We didn't waste our breath asking what the
checksum algorithm was.)  This is all encrypted under the family key
using "~another mode <grin>~".

They expressed a great deal of willingness to make any sort of
reasonable changes that vendors needed for their products.  They are
trying *very* hard to get Skipjack and key escrow into lots of
products.

***end of article***







From m5 at vail.tivoli.com  Thu Feb  3 05:36:11 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Thu, 3 Feb 94 05:36:11 PST
Subject: A serious question of ethics
In-Reply-To: <9402030727.AA27027@pmantis.berkeley.edu>
Message-ID: <9402031335.AA17716@vail.tivoli.com>



This seems like a textbook example of an ideal use of a remailer.
What makes you hesitant to use that method?  As you say, it's unlikely
that the government would go to the extensive trouble of trying to
bust you if you go through penet.  The worst that could happen would
be that they'd ignore the blowing whistle, but that'd be their
problem.

Note that there may be some way that they could figure out where you
telnetted in from once you alert them to the security hole.

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From mg5n+ at andrew.cmu.edu  Thu Feb  3 08:54:43 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Thu, 3 Feb 94 08:54:43 PST
Subject: Canadian gov't eavesdropping
In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com>
Message-ID: <khIGbGu00awQI2M1A1@andrew.cmu.edu>


Eli Brandt <ebrandt at jarthur.Claremont.EDU>
  sent the the following to cypherpunks:

> > HIGH-TECH SNOOP GADGET.  A super-secret branch of the Canadian
> > Security Intelligence Service has awarded three contracts to a Montreal
> > firm to make equipment that can quickly isolate key words and
> > phrases from millions of airborne phone, fax, radio signals and other
> > transmissions. The hardware has the "Orwellian potential to sweep
> > through ... and keep records of all conversations," said one CSIS critic.
> > (CTV National News, 01/31/94 11:00 pm).
>
> Dunno how feasible this kind of keyword recognition presently is,
> but here's another reason to encrypt.

VERY feasible.  The US government has had this technology for several
years; the Canadians are just catching up.  In the late 80s the US
military launched a satellite to spy on the Russians.  The satellite was
programmed to scan radio transmissions - especially cellular phones -
searching for key words which might be related to military or government
activities.  It seems a few communist party members got a little too
confortable with their cellular phones in their limosuines, and spoke
very loosely about some secret government projects...

They have mentioned this in the series "Space Age" which airs
periodically on PBS.





From CHRISTI1 at MUVMS6.WVNET.EDU  Thu Feb  3 08:59:45 1994
From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR)
Date: Thu, 3 Feb 94 08:59:45 PST
Subject: Can you see....
Message-ID: <01H8G0JDA9FE001WLN@MUVMS6.WVNET.EDU>


in VMS if someone goes into the sendmail services (i.e. port 25 and see what
they send out?)

Bob


                                    \////           
 			            (0 0)                                  
 *------------------------------oOO--(_)--OOo---------------------------------*
 | Bob Christian II  "IGOR"      *       Internet:Christi1 at muvms6.mu.wvnet.edu|
 | Marshall University         *****     E-Mail: Christi1 at muvms6.wvnet.edu    |
 | Huntington, WV                *       GET HIGH....LEARN TO FLY!  IP-ASEL   |
 | Student/D.J 88.1 WMUL FM      *       Major:Undecided(CJ/LAW) Minor:AVT    |
 *----------------------------------------------------------------------------*
--I love flying because there is no speed limit(^10k) and Radar is your friend!
--Marshall assumes no libility for what I say, because my words are MINE!






From pmetzger at lehman.com  Thu Feb  3 08:59:46 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Thu, 3 Feb 94 08:59:46 PST
Subject: No Subject
In-Reply-To: <199402030530.XAA11324@chaos.bsu.edu>
Message-ID: <199402031414.JAA10810@snark>



Anonymous says:
> 
> Perry almost wrote:
> 
> > Anyway, people who want to use the law to restrict distribution of
> > their software are extremely foolish. Your code is out there
> > it WILL be copied. Forever. You can't help it. If you don't want
> > people to use your software, don't write it.

Of course, Perry didn't write that, and the person reading his
messages obviously had an extremely weak understanding of what Perry
had suggested in his messages (which was that if you are giving
something away for free to all comers it is hard to argue economic
damages have occured in "unauthorized" distribution), so it makes
sense that the person replying would be too embarassed to use his own
name.

Perry





From CHRISTI1 at MUVMS6.WVNET.EDU  Thu Feb  3 08:59:46 1994
From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR)
Date: Thu, 3 Feb 94 08:59:46 PST
Subject: UNSUBSCRIBE
Message-ID: <01H8G0CIH0LQ001WLN@MUVMS6.WVNET.EDU>


UNSUBSCRIBE

And yes I have tried the -request part.

Bob 

                                    \////           
 			            (0 0)                                  
 *------------------------------oOO--(_)--OOo---------------------------------*
 | Bob Christian II  "IGOR"      *       Internet:Christi1 at muvms6.mu.wvnet.edu|
 | Marshall University         *****     E-Mail: Christi1 at muvms6.wvnet.edu    |
 | Huntington, WV                *       GET HIGH....LEARN TO FLY!  IP-ASEL   |
 | Student/D.J 88.1 WMUL FM      *       Major:Undecided(CJ/LAW) Minor:AVT    |
 *----------------------------------------------------------------------------*
--I love flying because there is no speed limit(^10k) and Radar is your friend!
--Marshall assumes no libility for what I say, because my words are MINE!






From boone at psc.edu  Thu Feb  3 08:59:46 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Thu, 3 Feb 94 08:59:46 PST
Subject: New remailer up.
In-Reply-To: <199402022259.OAA21968@mail.netcom.com>
Message-ID: <9402031518.AA22688@igi.psc.edu>



qwerty-remailer at netcom.com  writes:
> Out of personal curiousity concerning the claims of how trivial
> "traffic analysis" of the qwerty or catalyst remailers on Netcom
> would be for "anyone" to carry out, I offer $20 to the first
> person to reveal from which SITE this message originated from.
> Please do not announce my name or login ID. Just the site. I am
> logged into a friend's account and I am remailing this with no
> encryption just through qwerty at netcom.com. It is now 5:41 PM EST.
> 
> You do not have to reveal your methods to receive the award, which
> I will mail to you. Happy hacking you WIMPS.
> 
> If you wish to remain anonymous, mail the answer to qwerty at netcom.com
> and my lips are sealed except for announcing success.

  Can someone from netcom mail me the syslog logs...


 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From boone at psc.edu  Thu Feb  3 09:04:43 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Thu, 3 Feb 94 09:04:43 PST
Subject: New remailer up.
In-Reply-To: <199402030119.RAA17214@mail.netcom.com>
Message-ID: <9402031548.AA23590@igi.psc.edu>



qwerty-remailer at netcom.com  writes:
>
> Perry wrote,
> "However, make no mistake that Netcom can and will cooperate with the
> police if you use your remailer in a way that the government doesn't
> like, so it seems that the security afforded isn't that good."
> 
> So you aren't interested unless you can commit serious felony crimes
> using a given remailer? I would be happy if criminals stayed away from
> my remailer. What do you mean by "security"? And if the police find out
> a personally owned machine was involved, I couldn't imagine them not
> just swooping in at midnight and taking it away at gunpoint. I hope
> those privately owned machines don't have logs ;-). In my mind, the whole
> secret to gaining privacy is not attracting attention in the first place.
> Using a remailer DOES allow a person to communicate anonymously with
> someone else, in two directions. If a party has enough power to tap
> Netcom, then sendmail logs or no sendmail logs, they will find you.

  It seems that most (if not all) of netcom's unix machines are SunOS
  based.  If that is the case, by installing NIT in the kernel, one
  would be able to grab all of the packets that flow across that
  ethernet (192.100.81)  This includes your remailer mail.  The "cost"
  to set this up would be the risk of being caught and the time and 
  trouble to come up with root on one of their sun machines.  Aside
  from the obvious legal risks, there are ethical considerations to 
  keep in mind.  While I personally would not attempt such a thing,
  there are many out there who feel otherwise.  

  I won't hack into mail.netcom.com to demonstrate that it is possible
  to figure out who used your remailer.  But, if one of the admins from
  netcom wants to send me their syslogs, I'll do my best to put together
  a correlation.

> and,
> "Besides, $20 is a paltry sum for the amount of work involved."
> 
> Think of it as a trophy, which I'm sure most understood. I'm not offering
> you a job.

  Yes, but the trophy is hardly worth the effort.  Even though it wouldn't
  cost $50,000 in terms of actual equipment or time, it might well take
  such a sum to cause Perry to take the risk of being caught.  Unless the
  netcom folks are real slouches, I would think that they would notice
  that their kernel had been re-compiled and the machine rebooted.  Good
  luck not being detected...  Of course, there is always the off chance
  that they already have NIT compiled into the kernel...

 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From mg5n+ at andrew.cmu.edu  Thu Feb  3 09:09:43 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Thu, 3 Feb 94 09:09:43 PST
Subject: contemplating remailer postage
In-Reply-To: <9402022200.AA01456@uu4.psi.com>
Message-ID: <IhIGwnW00awQA2M2Ep@andrew.cmu.edu>


Jim_Miller at suite.com wrote:

> Seems simple enough.  The major sticking point (to me) is the remailer's
> "used stamp" archive.  This could grow to be very large.  Something needs
> to be done to keep the archive from getting too large.
>
> One idea is to have the remailer periodically change the key it uses to
> sign stamps.  Changing the "stamp validation key" effectively invalidates
> all unused stamps signed by that key.  If you haven't used the stamp by
> that time, you're out of luck.  The remailer can purge its "used stamp"
> archive whenever it changes its "stamp validation key".
>
> Of course, invalidating peoples' unused stamps out from under them is
> not a nice thing for a remailer to do.  The remailer could provide a
> mechanism whereby people could get new stamps from old, unused
> stamps.  To make this work, the remailer would have to retain the
> previous "used stamp" archive for a while to give people a chance to get
> new stamps.  However, there still needs to be a limit on how long the
> remailer retains the "used stamp" archives for old validation keys.  If
> you wait too long, you would lose any chance to get new stamps from old.
>
> Comments welcome.

How about this: 

Issue numbered stamps sequentially.  Encrypt them and add a
cryptographic checksum to each stamp.  You then create a database such
that one bit of data corresponds to one stamp.  With a mere 64K
database, you could issue and keep track of 524288 postage stamps.  That
ought to last you a few years.  (At 100 letters a day, it would last
over 14 years.  Most cypherpunk remailers get considerably less than 100
emails a day.)





From darrellp at cajal.uoregon.edu  Thu Feb  3 11:19:43 1994
From: darrellp at cajal.uoregon.edu (Darrell Perko)
Date: Thu, 3 Feb 94 11:19:43 PST
Subject: Unsubscribe.
Message-ID: <9402031918.AA05711@cajal.uoregon.edu>


Please unsubscribe me.  Thanks.





From drzaphod at brewmeister.xstablu.com  Thu Feb  3 12:09:44 1994
From: drzaphod at brewmeister.xstablu.com (DrZaphod)
Date: Thu, 3 Feb 94 12:09:44 PST
Subject: A serious question of ethics
In-Reply-To: <9402030727.AA27027@pmantis.berkeley.edu>
Message-ID: <m0pSA96-0003DcC@brewmeister.xstablu.com>


> 3)  Should I take advantage of it (well, maybe not)

	How about offering your services to them as a security 
consultant.. grin.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- DrZaphod                #Don't Come Any Closer Or I'll Encrypt!   -
- [AC/DC] / [DnA][HP]     #Xcitement thru Technology and Creativity -
- [drzaphod at brewmeister.xstablu.com] [MindPolice Censored This Bit] -
-         50 19 1C F3 5F 34 53 B7   B9 BB 7A 40 37 67 09 5B         -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-




From mg5n+ at andrew.cmu.edu  Thu Feb  3 12:24:46 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Thu, 3 Feb 94 12:24:46 PST
Subject: New remailer up.
In-Reply-To: <9402031548.AA23590@igi.psc.edu>
Message-ID: <UhIJlGi00awHMorUcc@andrew.cmu.edu>


"Jon 'Iain' Boone" <boone at psc.edu>

> Yes, but the trophy is hardly worth the effort.  Even though it wouldn't
> cost $50,000 in terms of actual equipment or time, it might well take
> such a sum to cause Perry to take the risk of being caught.  Unless the
> netcom folks are real slouches, I would think that they would notice
> that their kernel had been re-compiled and the machine rebooted.  Good
> luck not being detected...  Of course, there is always the off chance
> that they already have NIT compiled into the kernel...

Ah, yes, but if you were a skilled machine lanugage hacker you could use
a dissassembler to patch the code while it was in RAM.  Very difficult
to do, but also very difficult to detect.  In theory, if you could steal
their kernal (or had a similiar one) and you compiled it on your own Sun
station, you could could probably isolate the routines you needed to
patch, write a program to locate the processes running on root, scan
memory looking for that subroutine, and then let you insert your own. 
The Netcom folks would have to look pretty hard to catch on to that type
of attack...and if they rebooted - poof! - the evidence disappears!  :)

It's certainly more than $20 worth of work tho...  and you'd still have
to find a way to get to root (or at least grab control of the cpu chip
for a few microseconds).

What kind of cpu do Suns use anyway?  (I've never used a sun before, and
I don't know much about them.)  I know NeXT used the 680x0...  What
about DEC?
(I'm just a PC user type showing my ignorace about other systems. :-)





From hkhenson at cup.portal.com  Thu Feb  3 12:34:46 1994
From: hkhenson at cup.portal.com (hkhenson at cup.portal.com)
Date: Thu, 3 Feb 94 12:34:46 PST
Subject: San Jose BBS subject to Memphis standards?
Message-ID: <9402031230.1.2582@cup.portal.com>


Just got word a few minutes ago that Robert Thomas (who ran Amateur 
Action BBS) and his wife were picked up on a Federal warrant for 
obscenity from Memphis, TN.  From what I hear from a local Postal 
inspector, they are going to extradited to TN to face charges there 
because the Feds have a choice of trying a person at either end of a 
transaction. 

This really sucks! 

I find it akin to busting a pron shop owner in New York for one of his 
customers taking "filthy pictures" back to Hicksvill. 

In operation Longarm the Feds argued that the person downloading stuff 
was responsible for knowing if it was illegal.  This at least makes 
some sense.  But, if BBS owners have to be responsible for knowing the 
what is considered obscene in all 50 states and each locality, then the 
onramps to the Information Superhighway are going to be choked off by 
the most backwater places in the country! 


Keith Henson 

(The entire tale of AA has been posted.  I can repost if more than a 
few want it.)

----

The above was widely posted, this below is going to the cypherpunks 
list only.  (for all the protection that may provide :) )

I have rather mixed feeling about the feds making these kinds of 
busts.  I sort of wish they would not try to apply obscenity standards 
from the least enlightened parts of the country to all of the net 
community.  ON the other hand, the serious adult bbs owners have 
enough computing resources (and now a strong motivation!) that 
encrypting, digital payments, "webs of trust," DC nets, etc. can be 
implemented at relatively low cost to them.  If the feds persist, I 
suspect that adult bbs's are where--for all the trouble it may later 
cause--cypherpunk code will *really* get wide use. 

If you have things on which you want further information, please cc me 
by email as well as sending it to the list.  I recently took on 
running Xanadu Operating Company, and am days behind reading the list 

Keith Henson





From The.Ghost  Thu Feb  3 12:54:46 1994
From: The.Ghost (The.Ghost)
Date: Thu, 3 Feb 94 12:54:46 PST
Subject: No Subject
Message-ID: <9402032051.AA08204@banneker.Stanford.EDU>


testing...





From nobody at shell.portal.com  Thu Feb  3 13:14:48 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Thu, 3 Feb 94 13:14:48 PST
Subject: San Jose BBS subject to Memphis standards?
Message-ID: <199402032112.NAA26624@jobe.shell.portal.com>


This is one of the best essays I've seen concerning the burning of the
Constitution and Bill of Rights. Looking just at porno isn't the big
picture. It's consensual crimes in general. Too bad most people only
care about their corner of the room, cause the house is on fire and
it'll get to their corner soon.

Subject: January 1994 -- Casualties of War Drug prohibition has shot gaping holes in the Bill of Rights.

Magazine: Reason
Issue: February 1994
Title: Casualties of War Drug prohibition has shot gaping holes in the Bill of Rights.
Author: Steven B. Duke and Albert C. Gross


At 2 a.m. on June 29, 1991, Tracy White of Los Angeles was awakened by the
explosion of a diversionary grenade set off in a trash can outside her front
door. She stumbled out into the upstairs hallway and was met by a shaft of light
and a man's voice. "Freeze," he said. "Police."

At that moment, her bedroom windows shattered and two men clad in black hoods
swung into the room. Her three infants shrieked in fright. Several guns were
pointed at her. More men dressed in black bounded through the bathroom window.
One ran into an adjoining bedroom and pinned Tracy's sister Yolanda and her
12-year-old daughter behind a door. The youngster tried to squirm free and found
the barrel of a pistol against her head. She closed her eyes and urinated on
herself. "I thought," she later said, "he was going to kill me.

The police had been searching for White's cousin, a reputed gang member, who did
not live there and was not there when the raid occurred. The White apartment was
left a shambles. Almost all the windows were gone, crystal glassware was reduced
to shards, and a chunk was missing from a couch armrest. Six months after the
raid, White and her children still refused to move back into the old apartment,
unable to find peace of mind in a place that reminded them of hooded men
crashing through their windows.

The injuries inflicted on the Whites were mostly psychological, but some
searches are lethal. In Atlanta, in 1991, a pre-Christmas raid by nine cops with
guns drawn awakened Bobby Bowman as they broke down his door with a battering
ram. Bowman, who says he thought he was being robbed, opened fire with a
shotgun. A gunfight ensued, and Bowman's 8-year-old stepson, Xavier, who had
been sleeping in the front room, was killed by a detective's bullet. The police
found $780 worth of crack in Bowman's apartment.

Teresa Nelson, Georgia director of the American Civil Liberties Union,
questioned whether it was worth the life of an innocent 8-year-old to get
evidence in a drug case, but Atlanta police defended the tactics, as do police
across the country. They claim that surprise and overwhelming force are
necessary to minimize destruction of evidence. Many also make the debatable
claim that violent attacks reduce the danger to the police from counterattacks.

Such raids and ransackings are standard procedure in most large cities and,
except in the most outrageous cases, they receive the approval of courts. Police
can get search warrants on the flimsiest of suspicion -- even the word of an
anonymous informant. In many cases, though, the police don't even bother to get
a warrant, since they are virtually unfettered by the risk of successful suits
or other sanctions, especially if they confine their warrantless invasions to
poor members of minority groups.

The Fourth Amendment of the U.S. Constitution, which guarantees against
"unreasonable searches and seizures" and prohibits warrants on anything but
"probable cause," is a casualty of the drug war. Other provisions intended to
protect Americans from overzealous law enforcement -- the right to defense counsel,
the right to a fair trial, and the right to property -- are also in danger. The
debris of the war on drugs may ultimately include shreds of the Constitution as
well as splintered doors, shattered glass, and broken furniture.

Since the early 1970s, almost all the searches  and seizures reaching the
U.S. Supreme Court have been upheld. The Court has held, for example,
that a search made on an invalid warrant does not require any remedy so long as
the police acted in "good faith." People may be stopped in their cars, in
airports, on trains, or on buses, and subjected to questioning and dog sniffs of
their persons and possessions. Police may search an open field without warrant
or cause, even if it has "no trespassing" signs and the police incursion is a
criminal offense. They may also, as in Orwell's 1984, conduct close helicopter
surveillance of our homes and backyards.

If it is outside the house, they may search our garbage without cause. If 
they have "reasonable suspicion," the police may even search our persons
and possessions. Mobile homes, closed containers within cars, as well as cars
themselves may be searched without a warrant.

The Court has also held, in the 1985 case United States v. Montoya De Hernandez,
that an international traveler, if a suspected "balloon swallower," may, without
warrant or probable cause, be seized as she arrives at the airport,
strip-searched, and ordered to remain incommunicado until she defecates over a
wastebasket under the watchful eye of two matrons. In sanctioning such an
18-hour ordeal, Chief Justice William H. Rehnquist unabashedly listed other
invasions that the Court had upheld: "[F]irst class mail may be opened without a
warrant on less than probable cause.IAutomotive travelers may be stoppedInear
the border without individualized suspicion even if the stop is based largely on
ethnicityIand boats on inland waters with ready access to the sea may be hailed
and boarded with no suspicion whatever." Those incursions, as well as detention
for defecation, Rehnquist said, are responses to "the veritable national crisis
in law enforcement caused by smuggling of illegal narcotics.

In the compulsory defecation case, as in countless others, searches or seizures
have been up- held on nothing more than "reasonable" or even "articulable"
suspicion that drugs are being transported. That level of suspicion can be
achieved by matching up the victim of the search or seizure with a few of the
characteristics contained in secret "drug-courier profiles" that rely heavily
upon ethnic stereotypes. As a result of such profiles, hundreds of innocent
people are subjected to indignities every day.

Twenty-seven-year-old Kurt Disser is an example. A diamond dealer, he frequently
drives between San Diego and Los Angeles on business. Sixty-six miles from the
Mexican border, on Interstate Route 5, near San Clemente, the Immigration and
Naturalization Service maintains a checkpoint, allegedly to detect illegal
aliens but increasingly serving in the drug war. Most of the 115,000 drivers who
pass through the checkpoint each day are merely required to slow down while an
officer glances at them. Disser, however, was stopped and searched 15 of the 30
times he traversed the route during a 17-month period. On several occasions, he
was frisked and his car trunk was searched. Drug-sniffing dogs were given
repeated whiffs of Disser's car. Several times, agents told him the dogs
detected drugs and this led to a full search. No evidence of drugs or
criminality of any kind was ever found. Disser has no criminal record. He was
stopped and searched solely because of his appearance (he has long hair and
drives an elderly Cadillac, both characteristics apparently found in the
profiles).

Hispanics and "hippie types" bear the brunt of the profiles near our southern
border, but young African Americans suffer from them throughout the country. An
African American who drives a car with an out-of-state license plate is likely
to be stopped almost anywhere he goes in the United States. A survey of car
stoppings on the New Jersey Turnpike revealed that, although only 4.7 percent of
the cars were driven by blacks with out-of-state plates, 80 percent of the drug
arrests were of such people. In 1991 the Pittsburgh Press examined 121 cases in
which travelers were searched and no drugs were found. Seventy-seven percent of
the people were black, Hispanic, or Asian. In Memphis, about 75 percent of the
air travelers stopped by drug police in 1989 were black, yet only 4 percent of
the flying public is black.

Almost as offensive as relying on racial characteristics in a profile
to justify searches or seizures is permitting the trivial and subjective
profile characteristics to count as "reasonable" or "articulable" suspicion.
Warren Ferguson, a judge on the U.S. Court of Appeals for the Ninth Circuit, has
observed that the Drug Enforcement Administration's profiles have a
"chameleon-like way of adapting to any particular set of observations." In one
case, a suspicious circumstance (profile characteristic) was deplaning first. In
another, it was deplaning last. In a third, it was deplaning in the middle. A
one-way ticket was said to be a suspicious circumstance in one case; a
round-trip ticket was suspicious in another. Taking a nonstop flight was
suspicious in one case, while changing planes was suspicious in another.
Traveling alone fit a profile in one case; having a companion did so in another.
Behaving nervously was a tipoff in one case; acting calmly was suspicious in
another.

Another favorite basis for suspicion is that the suspect is traveling to or from
a major source city for drugs, even though every U.S. city with a major airport
qualifies for that designation. Even the same agents take contradictory
positions. In Tennessee, the Pittsburgh Press reports, an agent testified that
he was leery of a man because he "walked quickly through the airport." Six weeks
later, the same agent swore that his suspicions were aroused by a man because he
"walked with intentional slowness after getting off the bus.

As even their users admit, the profiles are self-fulfilling. If the profiles are
based on who is searched and found guilty, the guilty will necessarily fit the
profiles. The DEA claims to catch 3,000 or more drug violators through the
profiles, but no records are kept of how many people are hassled, detained, or
searched to produce the 3,000. The DEA keeps no records of the profile system's
failures.

Some numbers, however, are available. Rudy Sandoval, a commander of Denver's
vice bureau, estimated that his police conducted 2,000 airport searches in 1990,
yielding only 49 arrests. In Pittsburgh, where records were kept, 527 people
were searched in 1990, and 49 were arrested. In the Buffalo airport, in 1989,
600 people were stopped by police and only 10 were arrested. Said George Pratt,
a judge on the U.S. Court of Appeals for the Second Circuit: "It appears that
they have sacrificed the Fourth Amendment by detaining 590 innocent people in
order to arrest 10 who are not -- all in the name of the `war on drugs.' When, 
pray tell, will it end? Where are we going?

What the drug war has done to the Fourth Amendment, it has also done to the
Sixth. The Sixth Amendment guarantees, among other things, that in "all
criminal prosecutions" the accused shall enjoy "the assistance of counsel for
his defense." No other right is as precious to one accused of crime as the right
of counsel. A loyal, competent lawyer is essential for the protection of every
other right the defendant has, including the right to a fair trial.

In recognition of that fact, the definition of the enemy in the war against
drugs has been expanded. Not only are drug sellers and drug users targets, so
are their lawyers. Criminal-defense lawyers, especially if they practice in
federal courts, have increasingly come to expect their law offices to be
searched, their phones to be tapped, or their offices bugged. They are rarely
surprised when they get Internal Revenue Service summonses seeking information
about their criminal clients, about themselves, or about both.

Prosecutors frequently serve subpoenas on defense lawyers prior to trial,
requiring them to produce documents and testify about their client before a
grand jury, in secret. Having thus driven a wedge between client and attorney,
creating mistrust of the lawyer at least and a disqualifying conflict of
interest at worst, the prosecutor is then in a strong position to coerce a
guilty plea or, in intractable cases, to seek disqualification of the lawyer on
the eve of trial, when no other lawyer has time to prepare a defense.

The courts have upheld all these practices, the effect of which is to deprive
the accused of his only real defensive armament. The Supreme Court added a
powerful missile to the government's arsenal when it held, in the 1989 case
Caplin & Drysdale v. United States, that federal authorities could freeze and
later obtain the forfeiture of the assets of a person accused of a drug crime,
so that he would have no money with which to pay a lawyer.

The centuries-old tradition that confidential conversations between a lawyer and
client cannot be divulged without the consent of the client also seems headed
for the basement of American legal history. Courts have held that because
"monitoring" of conversations in jails and prisons is well-known, any
attorney-client conversations that are eavesdropped upon or tapped are fair
game -- they have been implicitly "consented" to. This absurd fiction was even
applied to Col. Manuel Noriega, who barely speaks English. After he was
kidnapped in Panama and thrown in a Miami jail, his phone conversations with his
lawyers were "monitored." A federal court found he waived his rights by talking
on the phone.

Courts have expanded other exceptions to the attorney-client privilege to the
point that little is left of the privilege in criminal prosecutions. Two
exceptions together almost swallow the privilege: 1) If the attorney's services
were sought, in whole or in part, to aid in the commission of a crime or a
fraud, the crime-fraud exception applies; 2) if necessary to clear himself of
suspicion, the attorney can disclose privileged confidential communications,
even if they bury the client. In short, if the interests of attorney and client
are in conflict, the interests of the attorney prevail.

Anyone accused of being involved with illegal drugs who is (or ever has been)
guilty of the crime charged or any other acquisitive crime and hires a lawyer is
necessarily seeking, at least in part, to cover up past crimes and to avoid
future claims against his assets, such as tax claims, forfeiture claims, and the
like. Courts have ruled that it's enough for prosecutors to show there is
"probable cause" to believe the attorney is helping his client achieve such
objectives, which are usually regarded as impermissible. (Probable cause can
even be based on the attorney-client conversations themselves.) It is not
possible to separate consultations concerning past money-making crimes, to which
the attorney-client privilege supposedly still applies, and consultations about
future crimes or frauds, to which the privilege does not apply. Faced with such
overlaps, courts commonly find there is no privilege.

Even if the crime-fraud exception does not destroy the privilege, the second,
save-the-lawyer-at-any-cost exception often will. A prosecutor can apparently
trump the privilege simply by making insinuations about the complicity of
counsel in the client's alleged criminal activities. The lawyer can then betray
the client to clear himself. That this rule permits the prosecutor to destroy
the accused's privilege by a mere insinuation seems not to bother either courts
or experts on legal ethics.

Courts have also upheld recent requirements that criminal-defense lawyers report
to the IRS anyone who pays them $10,000 or more in cash, whether a client or a
third party. Attorneys who have refused to make such reports about their clients
have been jailed. As of 1986, it is also a felony for anyone, including a
lawyer, to accept money or property in excess of $10,000 that was derived from
specified unlawful activity.

It is no defense for a lawyer or any other recipient that the money or property
was received for legitimate goods or services, even essential legal services.
Nor is it a defense that the attorney had nothing to do with the illegal
activity that generated the money or property. Nor is it a defense that the
attorney was unaware of the specific kind of criminal activity that produced the
money. It is not even a defense for the attorney that he had no actual knowledge
that the money or property was illegally derived. "Willful blindness" is a
substitute for knowledge, and the lifestyle of the client -- fitting stereotypes
of how drug dealers comport themselves -- may go far toward establishing the
attorney's guilty "knowledge" or "willful blindness." Thus, an attorney who
represents a person who is charged with a drug offense who "looks like" a drug
dealer is at risk of being indicted also.

Defense lawyers therefore risk losing not only their fee but their freedom and
their license to practice law for trying to protect the constitutional rights of
their clients. And the possible charges against lawyers are not limited to
accepting "tainted" money as payment of a fee. Lawyers who help their clients
avoid indictment or who represent them in business dealings, such as real-estate
transactions, can be indicted with the client for money laundering, tax evasion,
or even drug trafficking. Attorneys who confine their professional activities
solely to defending clients who have already been arrested on charges still risk
their own indictment, for "obstruction of justice" if nothing else.

Nobody knows what the limits of that crime are. Many prosecutors think that
anything a defense attorney does that might be helpful in defending the client
is such an obstruction. Courts have not yet embraced that interpretation, but
neither have they repudiated it. According to Columbia University law professor
H. Richard Uviller, a former prosecutor, it is almost possible to say that the
statute threatens a five-year penalty for virtually any conduct that the
government deems evasive, abusive, or inconvenient while a judicial proceeding
is pending.

It has always been difficult for persons accused of drug crimes to find
competent attorneys willing to bear the stigma of being "a drug dealer's
lawyer." But now that such attorneys also risk losing both their fees and their
freedom, privately retained drug-defense lawyers are on their way to
extinction -- which is what the Congress and the Supreme Court appear to want.

Court opinions that chisel away at specific constitutional guarantees
ought to be alarming to all who value liberty, but such decisions are
at least visible and are subject to intense scrutiny and criticism. Legal
scholar Steven Wisotsky calls the result of this chiseling process "the Emerging
`Drug Exception' to the Bill of Rights." A less visible and therefore more
ominous "drug exception" corrodes the amorphous right to a fair trial protected
by the Fifth and 14th Amendments' Due Process clauses.

In most drug prosecutions, the trial proceedings are ignored by the press and no
opinions are written by the trial judges justifying or explaining their rulings.
Those accused of crime must rely on the integrity of appellate judges to
scrutinize the record and ensure that the trial proceedings were fair and
consistent with due process. Yet in many courts criminal convictions and long
prison sentences are routinely upheld without even hearing argument of the
appeal and without even the writing of an appellate opinion. In such cases,
there is no basis for believing that the appellate judges bothered to read the
briefs or understood the issues, much less that they dealt with them fairly.

The prevailing, although rarely acknowledged, attitude in American courts is
that almost any trial is too good for a person accused of a drug crime. That
attitude was succinctly displayed in a remark by one of the most liberal Supreme
Court justices. In a 1987 interview with Life, Thurgood Marshall said, "If it's
a dope case, I won't even read the petition. I ain't giving no break to no dope
dealer." That statement caught the attention of some in the legal profession,
but it produced neither a bark of criticism nor a paragraph of protest.

The pressures that the drug war have brought to bear on already overburdened
courts have produced a breakdown in both their integrity and the respect in
which they are held. Many defense lawyers and scholars are convinced that
appellate judges will say anything to uphold a drug conviction. If such judges
don't affirm without writing any opinion at all, they often issue unsigned
opinions and, because such opinions are so shoddy, forbid their publication. The
courts will not even allow lawyers to cite such "opinions" as precedent in other
cases. Finally, when they do publish their opinions, judges often invent
nonexistent "facts" to support their affirmances. Respect for the American
judiciary by lawyers who appear before them has probably never been lower.

Occasionally, a judge rails against the trampling of rights under the tanks of
the drug war. Usually, this is done as part of a multi-judge panel, where a
judge can dissent from the decision of the majority while having no discernible
effect on the outcome. Such dissenting opinions can ring the bells of
freedom while the majority orders the defendant packed off to prison. The
dissenter has little responsibility for what he says, since he is not deciding
the case. Protests by judges at the trial level, where a single judge is
responsible for the outcome, require more courage and happen less often.

One such judge was U.S. Magistrate Peter Nimkoff of Miami. Nimkoff frequently
offended prosecutors and other judges by granting bail to defendants accused of
major drug crimes. Most judges either order the defendant detained without any
bail at all -- a power given to them by the 1984 Bail Reform Act -- or find out how much bail the defendant can post and then set bail at five or 10 times that
amount. Nimkoff asserted that the Constitution presumes the innocence of all
persons accused of crime, even a drug crime.

In a 1984 case, he blasted as "outrageous" the tactics of a DEA agent who,
posing as a friend of a lawyer's client, tried to get the Miami attorney to
divulge confidential communications from his client. DEA agents then tried to
implicate the lawyer himself in an escape plot. Failing that, they obtained a
search warrant on a fraudulent affidavit and thus were able to read privileged
letters between attorney and client. In another case, Nimkoff denounced the
DEA's use of a female informant who set up at least 40 men, enticing them into
drug deals after developing a sexual relationship with them. The "boyfriend"
would be busted, and the "girlfriend" would get paid by the DEA.

Finally, in 1986, Nimkoff had enough. He resigned to protest the relentless
erosion of rights and the governmental abuses of power with which he was daily
confronted. In a press conference, he decried the view "that there are two
constitutions -- one for criminal cases generally and another for drug cases." 
Such a view is not only wrong, he said. It "invites police officers to behave 
like criminals. And they do." Nimkoff's lamentations had the impact of a flower
falling in the forest. Miami's major newspaper, the Herald, found nothing about
his resignation or his press conference that warranted reporting.

The drug war's threats to the Bill of Rights extend not only to those
civil liberties favored by ACLU liberals but also to property rights.
The signers of the Declaration of Independence believed, with John Locke, that
the right of property was fundamental, inalienable, an aspect of humanity. They
regarded liberty as impossible without property, which was the guardian of every
other right. These beliefs are reflected in constitutional text. The Fifth
Amendment declares that "no person shall be deprived of life, liberty or
property without due process of law; nor shall private property be taken for
public use, without just compensation." Under forfeiture statutes enacted since
1970, however, both deprivations occur routinely, with the approval of courts.

Under federal statutes, any property is subject to forfeiture if it is "used, or
intended to be used, in any manner or part, to commit or to facilitate the
commission" of a drug crime. (See "Ill-Gotten Gains," August/September 1993.) No
one need be convicted or even accused of a crime for forfeiture to occur.
Forfeiture is a "civil" matter. Title vests in the government instantly upon the
existence of the use or the intention to use the property in connection with a
drug offense. All the government needs to establish its right to seize the
property is "probable cause," the same flimsy standard needed to get a search
warrant.

The government can take a home on no stronger a showing than it needs to take a
look inside. Hearsay or even an anonymous informant can suffice. No legal
proceedings are required before personal property may be seized. If the police
have "probable cause" concerning a car, a boat, or an airplane, they just grab
it. Although a hearing has to take place before property can be repossessed at
the behest of a conditional seller, before a driver's license can be revoked,
before welfare benefits can be terminated, and before a state employee can be
fired, persons can have their motor homes confiscated without any proceedings of
any kind, if the confiscation is a drug forfeiture. There may be a right to
contest the forfeiture after the seizure, but even this right is lost if not
promptly asserted. Moreover, the costs of hiring a lawyer and suing to recover
the seized property may be prohibitive unless the seized property is of great
value.

As construed by the courts, the forfeiture statutes also encourage police to
make blatantly unconstitutional seizures. Property may be seized without
probable cause -- on a naked hunch -- and still be retained and forfeited. Courts hold
that illegally seized property may be forfeited if the police establish probable
cause at the forfeiture proceeding itself. It doesn't matter that there was no
cause whatever for the seizure; it doesn't matter that the seizure was illegal,
even unconstitutional. If the government can later establish probable cause
(through the seized property itself or investigation occurring after the
seizure), that is sufficient to uphold a forfeiture.

If the government wants to seize real property without notice, it has to get a
court's approval, but that is as easy as getting a search warrant. A seizure
warrant is obtained in the same way as a search warrant and on the same hearsay
grounds. In 1988, a six-story apartment building in New York, containing 41
apartments, was seized on such a warrant, which the appellate court upheld.

No civilized country imposes criminal punishment for mere evil intentions, but
the forfeiture statutes -- since they are "civil," not "criminal" -- are apparently
subject to no such limitation. In 1991 the U.S. Court of Appeals for the Third
Circuit held that a home was forfeitable because the owner, when he applied for
a home equity loan, "intended" to use the proceeds to buy drugs. By the time the
loan actually came through, he had used other funds for that purpose, but that
didn't matter, the court said, because he had intended to use the home to secure
a loan, the proceeds of which he intended to use for drugs. The home was
therefore no longer his. It would apparently have made no difference if he never
even applied for the loan, as long as he thought about it.

Any activities within a home that relate to drugs are sufficient for forfeiture
of the home: a phone call to or from a source; the possession of chemicals,
wrappers, paraphernalia of any kind; the storing or reading of any how-to books
on the cultivation or production of drugs. The operative question is whether any
of these activities was "intended" to facilitate a drug offense.

If a car is driven to or from a place where drugs are bought or sold and is then
parked in a garage attached to a home, the home has been used to store the car,
which facilitated the transaction, and is probably forfeitable along with the
car. If the home is located on a 120-acre farm, the entire farm goes as well. If
only a few square feet of land in a remote section of a farm are devoted to
marijuana plants, the grower loses not only the entire farm, but, if it is on
the same land as the farm, his home as well.

Once any property qualifies for forfeiture, almost any other property owned or
possessed by the same person can fall into the forfeiture pot. Notions about how
otherwise "innocent" property can "facilitate" illegal activities are almost
limitless. In a 1991 Hawaii case, when drug proceeds were deposited in a bank
account that contained several hundred thousand dollars in "clean" funds, the
entire account was declared forfeit on the theory that the "clean" funds
facilitated the laundering of the tainted funds. In a 1989 case involving a drug
dealer who owned and operated a ranch in Georgia, his quarter horses -- all 27 of
them -- were forfeited on the theory that, as part of a legitimate business, the
livestock helped create a "front" for the owner's illegal activities. On this
theory, the more "innocent" one's use of property is, the more effective it is
as a "front" or "cover" and therefore the more clearly forfeitable.

Entire hotels have been forfeited because one or more rooms were used by guests
for drug transactions. Entire apartment houses have been lost because drug
activities occurred in some apartments. In 1991 proceedings were brought to
forfeit fraternity houses at the University of Virginia because some of the
members sold drugs there. Those seizures created a stir, but they pale when
compared to the potential. Imagine the government taking over New York's Plaza
Hotel or one of the giant casino hotels in Atlantic City or Las Vegas on the
same theory. Or taking over a company town because of a single drug sale or
backyard marijuana plant. Harvard University is also available for the taking.
There are certainly drug sales, drug use, even drug manufacturing taking place
on campus.

Under federal law, property owners can defeat civil forfeiture if they
can prove either that the claimed offending use did not occur and was
not even intended, or that the offending use occurred or was intended "without
the knowledge or consent of that owner." Unfortunately, even this seemingly
clear provision provides little protection for innocent owners. Courts have
treated "knowledge" and "willful blindness" as equivalents and have then merged
"willful blindness" into "negligence.

Despite the plain language of the statute, most courts are unwilling to lift a
forfeiture unless the owners can prove that the offending activity not only
occurred without their knowledge or consent, but also that they did all that
"reasonably could be expected to prevent the proscribed use of the property."
The owner has been conscripted as a police officer to ensure that no improper
use is made of the property. In a 1990 Milwaukee case, the owner of a 36-unit
apartment building plagued by dope dealing evicted 10 tenants suspected of drug
use, gave a master key to the police, forwarded tips to the police, and even
hired two security firms. The city seized the building anyway.

If owners discover that their property is being used to "facilitate" drug use or
sale, what can they do to ensure that they will not lose their property to
forfeiture? Nothing, probably. If they call the police and inform on their
tenants, they have established their knowledge, as of the date they informed,
which will usually be sufficient for forfeiture. Informing the police may go far
toward establishing that owners did not "consent" to the illicit use, but many
courts have held that the owner must both lack knowledge and not consent to the
illicit use.

As scary as forfeiture already is, it is spreading to other offenses. When it is
extended to new areas, the punishment becomes drastically disproportionate to
the offense and the constitutional safeguards of criminal procedure are
circumvented. Already, federal forfeiture statutes apply to pornography,
gambling, and several other offenses, as well as drugs. Some state forfeiture
laws apply to property used in any felony. The forfeiture of cars used in sex
offenses is commonplace. Hartford, Connecticut, recently began confiscating the
cars of johns who cruise neighborhoods looking for prostitutes. Some states take
one's car for drunk driving.

Where will it end? Why not extend forfeiture to income-tax evasion and take the
homes of the millions -- some say as many as 30 million -- who cheat on their taxes?
The statutory basis for forfeiting homes and businesses of tax evaders is
already in place. The Internal Revenue Code reads: "It shall be unlawful to have
or possess any property intended for use in violating the provisions of the
Internal Revenue Service LawsIor which has been so used, and no property rights
shall exist in any such property.

Although use of this provision has mainly been limited to seizures of moonshine
and gambling equipment, and sometimes businesses, there is no reason, given the
breadth of the drug forfeiture decisions, why it can't be employed to take the
homes and offices of tax evaders and even those of their accountants and
lawyers. A congressman who failed to pay Social Security tax on wages of his
housekeeper could lose his home. Moreover, unlike drug forfeiture, the tax
forfeiture statutes have no innocent-owner defense.

If there is a shard of moral justification for forfeiture, it is that an owner,
duly forewarned, chooses to use or permit his property to be used illegally and
therefore voluntarily "waives" his constitutional rights of property. But such a
"waiver" theory can be extended to destroy all rights and all liberty. It is a
cancer on the Constitution, certain to metastasize if not eliminated soon.

Steven B. Duke is Law of Science and Technology Professor at Yale Law School.
Albert C. Gross is an attorney and writer in San Diego. This article is adapted
from their book, America's Longest War: Rethinking Our Tragic Crusade Against
Drugs (Putnam).

    ------------------------------------------------------------
    The contents of this file are copyright 1993 by the publisher
    in whose directory this file appeared.  Unauthorized copying
    of this information is strictly forbidden.  Please read the
    general notice at the top menu of the Gopher Server for
    the Electronic Newsstand.  For information regarding reprints,
    please send mail to REPRINTS at Enews.Com
    ------------------------------------------------------------


 









From pgpkeys at wasabi.io.com  Thu Feb  3 13:14:48 1994
From: pgpkeys at wasabi.io.com (PGP Slave Key Server)
Date: Thu, 3 Feb 94 13:14:48 PST
Subject: PGP KEYS NOW BY FINGER!  *** STOP PRESS ***
Message-ID: <199402031525.PAA03435@wasabi.io.com>


pgp key server functionality just took a great leap forward today when
io.com's email server suddenly went interactive!

finger @wasabi.io.com      for details
        ^^^^^^
        Note the 'wasabi' - finger @io.com won't work.

You can get a list of users by doing:   finger user at wasabi.io.com
or even:                                finger user at host@wasabi.io.com

And once you find their Key ID from the summary listing, you can
then do:
                                        finger 0x123456 at wasabi.io.com
                                                 ^^^^^^
                                                  The hex digits from the keyid


Have fun!

The Mgt.

PS The finger requests to this server are *NOT* logged.
(At least by us.  Who knows what the NSA is up to :-) )





From qwerty-remailer at netcom.com  Thu Feb  3 13:29:44 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Thu, 3 Feb 94 13:29:44 PST
Subject: New remailer up.
Message-ID: <199402032127.NAA18079@mail.netcom.com>


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

qwerty at netcom.com gains a bit bucket.

::
Request-Remailing-To: /dev/null

Bye bye mail.  "BB" entered into my counter.

Comments? Are slashes OK in a header line?

- -Nik (Xenon)


-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVElIwSzG6zrQn1RAQE1qAP9Fu4tDpJclibx3CuzHGICpshNwULdYmn2
zfBMC+wuHGWvDvTtDX0+0HxfxLouOKAvvESJFt35Y0YSszT8KZmarSz5msOA179v
+trsnSPw/BhjNvKQlhxHm7HpOr8JNoL3gB2zHz3EISEkdDtvRE3LRj4wu20P8DaP
7reDXreuDE4=
=n99G
-----END PGP SIGNATURE-----





From hlin at nas.edu  Thu Feb  3 13:54:46 1994
From: hlin at nas.edu (Herb Lin)
Date: Thu, 3 Feb 94 13:54:46 PST
Subject: Study of National Cryptography Policy
Message-ID: <9401037603.AA760322850@nas.edu>



February 3, 1994

To: Whom It May Concern
Subject: A Study of National Cryptography Policy

This message should be forwarded to any and all individuals or groups that
may be interested.

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

In a message broadcast electronically and by fax in December 1993, the
Computer Science and Telecommunications Board (CSTB) of the National
Research Council (NRC) issued a call for nominations of possible committee
members who would undertake a study of national policy with respect to the
use and regulation of cryptography.  This report was requested by the U.S.
Congress in the Defense Authorization Bill for FY 1994.

That message said that ALL committee members (and associated staff) would
have to be cleared at the "SI/TK" level.  Since that time, there has been some
discussion of a study that would only require SOME members of the study
committee to be cleared.  Thus, in the interests of casting the broadest
possible net to capture the necessary expertise, we are re-issuing the call for
nominations to find those people who otherwise fit the criteria below but who
would have been reluctant to accept security clearances or to undergo the
required investigation.

It is expected that the study committee will be a high-level group that will
command credibility and respect across the range of government, academic,
commercial, and private interests.  The committee will include members with
expertise in areas such as:

  - relevant computer and communications technology;
  - cryptographic technologies and cryptanalysis;
  - foreign, national security, and intelligence affairs;
  - law enforcement;
  - commercial interests (both users and technology vendors); and
  - privacy and consumer interests.

Committee members will be chosen for their stature, expertise, and seniority
in their fields; their willingness to listen and consider fairly other points of
view; and their ability to contribute to the formulation of consensus
positions.
The committee as a whole will be chosen to reflect the range of judgment and
opinion on the subject under consideration.

Note that NRC rules regarding conflict of interest forbid the selection as
committee members of individuals that have substantial personal financial
interests that might be significantly affected by the outcome of the study; in
addition, individuals currently employed by the federal government are
ineligible to serve on the study committee.

Please forward suggestions for people to participate in this project to
CSTB at NAS.EDU by February 11, 1993; please include their institutional
affiliations, their field(s) of expertise, a note describing how the criteria
described above apply to them, and a way to contact them.  For our
administrative convenience, please put in the "SUBJECT:" field of your
message the words "crypto person".

If you would like a copy of the original solicitation, please send a request to
CSTB at NAS.EDU.

On the National Research Council

The National Research Council (NRC) is the operating arm of the Academy
complex, which includes the National Academy of Sciences, the National
Academy of Engineering, and the Institute of Medicine. The NRC is a source
of impartial and independent advice to the federal government and other
policy makers that is able to bring to bear the best scientific and technical
talent in the nation to answer questions of national significance.  In addition,
it often acts as a neutral party in convening meetings among multiple
stakeholders on any given issue, thereby facilitating the generation of
consensus on controversial issues.

The Computer Science and Telecommunications Board (CSTB) of the NRC
considers technical and policy issues pertaining to computer science,
telecommunications, and associated technologies.  CSTB monitors the health
of the computer science, computing technology, and telecommunications
fields, including attention as appropriate to the issues of human resources and
information infrastructure and initiates studies involving computer science,
computing technology, and telecommunications as critical resources and
sources of national economic strength.  A list of CSTB publications is
available on request.





From jim at bilbo.suite.com  Thu Feb  3 15:14:49 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Thu, 3 Feb 94 15:14:49 PST
Subject: contemplating remailer postage
Message-ID: <9402032304.AA18410@bilbo.suite.com>




Matthew J Ghio writes:

> How about this: 

> 

> Issue numbered stamps sequentially.  Encrypt them and
> add a cryptographic checksum to each stamp.  You then
> create a database such that one bit of data corresponds to
> one stamp.  With a mere 64K database, you could issue and
> keep track of 524288 postage stamps.  That ought to last
> you a few years.  (At 100 letters a day, it would last over 14
> years.  Most cypherpunk remailers get considerably less
> than 100 emails a day.)
> 

> 

> 


If the remailer constructs the stamp, rather than just signs it blindly,  
it could keep a log of which stamps were issued to which users.  The  
remailer could then use this information to figure out the original sender  
of a stamped message regardless of how many other remailers the message  
passed through.

To thwart this, users would have to purchase stamps anonymously.  However,  
this begs the question: How does the user anonymously purchase stamps for  
the first remailer?  I suppose you could use "free" remailers to send  
anonymous purchase requests to stamp-issuing remailers.

The system I described does not require you to purchase stamps  
anonymously.  You can purchase stamps directly from each remailer without  
giving the remailer the opportunity to record which stamp went to which  
user.  To understand why this is true you need to understand how blind  
signatures work.  The book "Applied Cryptography (Bruce Schneier)" gives a  
good description of the properties of blind signatures.  That is how I  
learned about them.

The remailer could still record the fact that you purchased stamps, thus  
alerting the bad guys that you plan to use the remailer system.  However,  
I don't think it is possible to prevent the bad guys from learning that  
you use remailers.  I assume the bad guys will be logging all traffic to  
the remailers and would learn about your use of remailers, stamps or no  
stamps.


Jim_Miller at suite.com





From mg5n+ at andrew.cmu.edu  Thu Feb  3 15:14:49 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Thu, 3 Feb 94 15:14:49 PST
Subject: No Subject
In-Reply-To: <9402032051.AA08204@banneker.Stanford.EDU>
Message-ID: <AhIMGvW00VBANK_lU_@andrew.cmu.edu>


The.Ghost at toad.com writes:

> Received: by toad.com id AA04069; Thu, 3 Feb 94 12:51:58 PST
> Received: from banneker.Stanford.EDU ([36.14.0.77]) by toad.com id
AA04063; Thu, 3 Feb 94 12:51:55 PST
> Received: by banneker.Stanford.EDU (5.57/Ultrix3.0-C)
>	id AA08204; Thu, 3 Feb 94 12:51:14 -0800
> Date: Thu, 3 Feb 94 12:51:14 -0800
> From: The.Ghost at toad.com
> Message-Id: <9402032051.AA08204 at banneker.Stanford.EDU>
> Apparently-To: cypherpunks at toad.com
>
> testing...

Wow, look, someone at Stanford figured out how to use port 25!

I hope that's a new anonymous remailer that you're testing there... :)





From hughes at ah.com  Thu Feb  3 15:24:48 1994
From: hughes at ah.com (Eric Hughes)
Date: Thu, 3 Feb 94 15:24:48 PST
Subject: ADMIN: list statistics
Message-ID: <9402032319.AA20066@ah.com>


I gathered some list statistics for the subscriber base as of
Thursday, February 3, 1994, 12:00 noon.

657 subscription addresses total. 49 contain the string 'cypher' and
are suspected gateways, either to individuals or large groups, so the
exact amount is extremely hard to pin down.

Here are the subscribers, broken down by top-level domain

 300 com	USA commercial
 204 edu	USA educational
  25 org	USA organizational
  18 ca		Canada
  15 net	networks
  13 us		USA geographical
  10 uk		United Kingdom
   9 uucp	UUCP links
   8 se		Sweden
   7 gov	USA government
   7 au		Australia
   6 fi		Finland
   5 no		Norway
   4 de		Denmark
   3 mil	USA military
   3 it		Italy
   2 fido	Fidonet
   2 za		South Africa
   2 mx		Mexico
   1 ve		Venezuela
   1 su		USSR (er, someone call a NIC)
   1 si		( ? Slovenia ? )
   1 sg		Singapore
   1 nl		Netherlands
   1 jp		Japan
   1 in		India
   1 ie		Ireland
   1 hk		Hong Kong
   1 gb		United Kingdom
   1 fr		France
   1 es		Spain
   1 ee		?
   1 ec		Ecuador

If anybody knows for sure where SI and EE are, I'd love to know.  My
list of ISO country codes is a little old.

Here are the top individual domain names.  We can see who has market
share, at least.

  51 netcom.com
  16 aol.com
   9 mcimail.com
   8 well.sf.ca.us
   7 delphi.com
   6 world.std.com
   5 umich.edu
   5 shell.portal.com
   5 microsoft.com
   5 cleveland.Freenet.Edu
   5 CompuServe.COM
   4 phantom.com
   4 panix.com
   4 gnu.ai.mit.edu
   4 crl.com
   4 apple.com
   3 ucsu.Colorado.EDU
   3 toad.com
   3 prodigy.com
   3 nyx.cs.du.edu
   3 mason1.gmu.edu
   3 engin.umich.edu
   3 ecf.toronto.edu
   3 anon.penet.fi
   3 access.digex.com
   3 CUNYVM.CUNY.EDU

Happy lack of trails.

Eric





From ravage at wixer.bga.com  Thu Feb  3 15:24:49 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Thu, 3 Feb 94 15:24:49 PST
Subject: Message returned to sender (fwd)
Message-ID: <9402031634.AA14363@wixer>


Forwarded message:




From jim at bilbo.suite.com  Thu Feb  3 15:39:44 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Thu, 3 Feb 94 15:39:44 PST
Subject: SASE Suggestion
Message-ID: <9402032330.AA18898@bilbo.suite.com>



Lance Cottrell writes:

> One SASE scheme recently suggested involved sending a
> request for a SASE to a ramailer, stating the number of
> jumps required. It then sent it to another remailer, and
> so on. Each adding a layer, and eventually sending the
> results to the desired correspondent. I mentioned that
> if the first remailer was corrupted, that the whole chain
> was (it would only send to other corrupt remailers). 

> 


Oh, I see.  I was confused as to which scheme you were talking about.  You  
were refering (I think) to the "prepaid mailer" idea Tim May described in  
his "Re: Anonymous Anonymous ftp" post of Jan 27.


Jim_Miller at suite.com





From hayden at krypton.mankato.msus.edu  Thu Feb  3 15:54:48 1994
From: hayden at krypton.mankato.msus.edu (Robert A. Hayden)
Date: Thu, 3 Feb 94 15:54:48 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402032319.AA20066@ah.com>
Message-ID: <Pine.3.89.9402031747.A11773-0100000@krypton.mankato.msus.edu>


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

On Thu, 3 Feb 1994, Eric Hughes wrote:

>    1 si		( ? Slovenia ? )
>    1 ee		?

> If anybody knows for sure where SI and EE are, I'd love to know.  My
> list of ISO country codes is a little old.

si =	Slovenia (you were right)
ee = 	Estonia

Source:  The Big Dummy's Guide to the Internet
	 Adam Gaffin and Jorg Heitkotter
	 Available at ftp.eff.org


____        Robert A. Hayden          <=> hayden at krypton.mankato.msus.edu
\  /__          -=-=-=-=-             <=>          -=-=-=-=-
 \/  /   Finger for Geek Code Info    <=> In the United States, they
   \/  Finger for PGP 2.3a Public Key <=> first came for us in Colorado...
- -=-=-=-=-=-=-=-
(GEEK CODE 1.0.1)  GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
		       n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVGO553BsrEqkf9NAQFd6AQAiu8TlrJ5ZU52vpfvMrS/YMYaCZCc6uZ2
yLoUcWBsv4FSbk2pXwjMTacWBvvFonKntwUT3GtWB0GRUqRzLCOYRG5cqcb0iPgC
uK8BXhyTXcHxZXAfSW+qI53z+4dwCb9Tc/WRihkNuS+RaPWIBIllLRxtyiUQKopr
fTDAVeWr7OM=
=Jhqu
-----END PGP SIGNATURE-----





From Tomaz.Borstnar at arnes.si  Thu Feb  3 15:54:48 1994
From: Tomaz.Borstnar at arnes.si (Tomaz Borstnar)
Date: Thu, 3 Feb 94 15:54:48 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402032319.AA20066@ah.com>
Message-ID: <9402032349.AA06456@toad.com>


In-reply-to: Your message dated: Thu, 03 Feb 1994 15:19:11 PST
>    1 si		( ? Slovenia ? )

Good. :)

Yeah, it's Slovenia. :)

Tomaz





From hughes at ah.com  Thu Feb  3 16:04:48 1994
From: hughes at ah.com (Eric Hughes)
Date: Thu, 3 Feb 94 16:04:48 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402032319.AA20066@ah.com>
Message-ID: <9402040000.AA20195@ah.com>


Followups to me have yielded the following info:

SI = Slovenia
EE = Estonia

One subscriber each.

Thanks to Tomaz and Stephen for the info.

Eric





From pgpkeys at wasabi.io.com  Thu Feb  3 16:49:44 1994
From: pgpkeys at wasabi.io.com (PGP Slave Key Server)
Date: Thu, 3 Feb 94 16:49:44 PST
Subject: A question of ethics.
Message-ID: <199402031859.SAA03790@wasabi.io.com>


>Ok, I'm in a bit of a quandry.  While surfing the net last week, I
>happened across an address addached to a machine that belongs the the 
>federal reserve.  No big deal.  I telnetted there on a lark, and entered 
>'guest' for the account.  It dropped me into a shell.  It didn't ask for 
>a password.  Intrigued, I did a little looking around.  Nothing special, 
>a CDRom and about 80 accounts.  But(!!), /etc/passwd was there and 
>available and not using shadows.  No, I didn't snatch a copy.
>
>Quandry(ies)
>
>1)  Should I alert someone there about the obvious (and, IMHO serious) 
>seciruty hole?
>
>	or
>
>2)  Should I ignore it?
>
>3)  Should I take advantage of it (well, maybe not)
>
>----------
>
>I don't like to see systems so open, no matter who they belong too, and 
>the fact that the governments (whether you like them or not) has one this 
>open REALLY bothers me. 
>
>But, I also wonder what kind of trouble I could get into.  Technically, I 
>violated something just by being there as I didn't have permission, and 
>the fact I accessed the passwd file makes it even worse.  If I report it, 
>I could be in deep shit.
>
>I could mail to them via a remailer (like penet.fi, so that they could 
>answer for more information if needed).  That is a little securer and 
>Julf is out of jurisdiction of the FBI hunting me down.
>
>Yes, I'm a little paranoid, but Uncle Sam likes to make examples out of 
>white-collar hackers, and for me it was pure and dumb luck (like a jury 
>would believe a 22 year-old computer geek isn't trying to gain illegal 
>access).
>
>Any suggestions?  Please?  I consider this to be serious (most may not).

Go to a COCOT and call Ms Flanagan below.  *Not* the Tech contact, who is
most likely the person who fucked up and will want to cover his butt.  The
admin contact should be more sympathetic...

   20th and C Streets, NW
   Washington, DC 20551

   Domain Name: FRB.GOV

   Administrative Contact:
      Flanagan, Elizabeth R.  (ERF7)  erf at FED.FRB.GOV
      (202) 452-2672
   Technical Contact, Zone Contact:
      Drzyzgula, Robert P.  (RPD5)  rcd at FED.FRB.GOV
      (202) 452-3425

   Record last updated on 14-Aug-91.

   Domain servers in listed order:

   NS.UU.NET                    137.39.1.3
   UUCP-GW-1.PA.DEC.COM         16.1.0.18
   UUCP-GW-2.PA.DEC.COM         16.1.0.19







From cmckie at ccs.carleton.ca  Thu Feb  3 17:29:44 1994
From: cmckie at ccs.carleton.ca (Craig McKie)
Date: Thu, 3 Feb 94 17:29:44 PST
Subject: Canadian voice recognition article
Message-ID: <9402040124.AA03270@superior.YP.nobel>


Spy Agency works on eavesdropping device for phones, faxes
New snoop gadget would identify voices carried through air

The Canadian Press

Used on page 1, Ottawa Citizen, Monday January 31, 1994

   An elite wing of Canada's spy agency is secretly developing devices
that can monitor and identify voices carried through the air by phone,
fax and radio signals, according to a broadcast report citing
government documents.
   The Communications Security Establishment is a super-secret branch
of the Canadian Security Intelligence Service that specializes in
gathering signals intelligence - SIGINT to insiders.
   Since 1989, the CSE has awarded three contracts worth $1.1 million
to a Montreal firm to make machines that can quickly isolate key words
and phrases from the millions of signals the CSE monitors each day,
CTV reported Sunday.
   In May 1983, the CSE awarded the Centre de Recherche Informatique
de Montreal a contract to develop a "speaker identification system,"
which can pick voices from the electronic haze and identify them.
   "Its frightening," says Bill Robinson, a researcher with the peace
group, Project Ploughshares. "It has Orwellian potential to sweep
through everybody's conversations. As computers get faster and faster,
theoretically, one would be able to keep records of all
conversations."
   The CSE is supposed to provide the federal government with foreign
intelligence, but parliamentarians have often voiced concerns about
the agency's potential to violate the privacy of Canadians.
   Liberal MP Derek Lee, the head of a Commons committee that oversees
Canada's spy agency, said the CSE is overstepping its mandate.
   "Have they been asked, or have they decided for themselves to take
on a new role that requires them to analyse the human voice? And if
they have, they've gone beyond what I think they've told us."
   The CSE is accountable to Parliament through the defence minister.
   But Defense Minister David Colonette told CTV her was unaware of
the CSE's latest electronic snooping projects.
   "This is the first I've heard of this," Collenette said. "It is
certainly something I'll discuss with my officials."
   While in Opposition, the Liberals pledged to make the CSE more
accountable.
   With a budget of about $250 milliojn and more than 800 employees
the CSE operates out of a building on Heron Road in Confederation
Heights surrounded by a barbed-wire fence.
   Its work is considered so sensitive that employees are told not to
take commercial flights, in case the plane is hijacked and they are
held hostage.





From anonymous at extropia.wimsey.com  Thu Feb  3 17:49:44 1994
From: anonymous at extropia.wimsey.com (anonymous at extropia.wimsey.com)
Date: Thu, 3 Feb 94 17:49:44 PST
Subject: Remailer Tearline Conventions
Message-ID: <199402040132.AA19447@xtropia>


 * Reply to msg originally in CYPHERPUNKS

 Uu> From: edgar at spectrx.saigon.com (Edgar W. Swank)

 Uu> Someone (not me) asked about remailer tearline conventions to
 Uu> eliminate automatic sigs:

 Uu> I'm the one who brought this up "months ago" and the short answer to
 Uu> your question is "no."

 Uu> Hall Remailer     <nowhere at bsu-cs.bsu.edu>
 Uu> added a "cut line" of
 Uu> --ignore--

 Uu> At the time I brought this up, the attitude of most remailer operators
 Uu> (Chael Hall and Miron Cuperman notably excepted) was that anyone who
 Uu> couldn't figure out how and remember to turn off their auto sig didn't
 Uu> deserve any privacy.

An astonishing bit of Internet provincial fuckheadedness, I must say!
When one considers that there are _many_ other nets that gate into
Internet these days and innumerable store-and-forward host systems whose
message handling processes are _completely_ beyond the control of the
end user (even smug Cypherpunk geniuses), this attitude mystifies me.

 Uu> I recommend that you always use the wimsey (extropia) remailer as the
 Uu> first (or only) leg of a remailer chain.  It is also the only
 Uu> Cypherpunks remailer outside the USA (it's in Canada) which will make
 Uu> tracing msgs a little more difficult for USA authorities.

That remail at extropia.wimsey.com is in Canada specifically makes
communications with it fair game for NSA interception, however.






From kshep at netcom.com  Thu Feb  3 19:04:49 1994
From: kshep at netcom.com (Kirk Sheppard)
Date: Thu, 3 Feb 94 19:04:49 PST
Subject: Remailer Tearline Conventions
In-Reply-To: <199402040132.AA19447@xtropia>
Message-ID: <Pine.3.85.9402032200.A25248-0100000@netcom9>



On Thu, 3 Feb 1994 anonymous at extropia.wimsey.com wrote:

> 
> That remail at extropia.wimsey.com is in Canada specifically makes
> communications with it fair game for NSA interception, however.

NSA interception is world wide.

Kirk Sheppard

kshep at netcom.com

P. O. Box 30911             "It is  Better to Die on Your Feet Than to 
Bethesda, MD 20824-0911      Live On Your Knees."
U.S.A.
			    			     - Emiliano Zapata







From jim at bilbo.suite.com  Thu Feb  3 19:19:44 1994
From: jim at bilbo.suite.com (Jim Miller)
Date: Thu, 3 Feb 94 19:19:44 PST
Subject: On return addresses
Message-ID: <9402040310.AA22295@bilbo.suite.com>



Eric Hughes writes:

> I've been troubled for many months by an invariant in all forms of
> return address schemes: The outside world contains sufficient
> _persistent_ information to find a real adress.
> 

> [stuff deleted]
> 

> So how do we solve it?  By abandoning return addresses and
> using mail spool facilities. 

> 

> [more stuff deleted]
>
> 1. I have a machine and I'll sell you an address on it...
>
> 2. When mail come in for you, it sits in a spool...
>
> 3. Your mail sits in the spool until you access it with... a
> mail server command of "send me a mailbox file of my
> waiting mail".
> 

> [even more stuff deleted]
>
> The elimination of persistent identifying information
> for return paths is a worthwhile design objective.  I
> propose that we start thinking about it more thoroughly.
> 

> Eric 

> 


Let me see if I understand your idea correctly.  I am picturing  
something like the following:

There will exist a bunch of remailers that, in addition to forwarding  
mail, will also sell mailboxes.  (I'm combining the remailer with the  
mail spools to add to the mix of messages to and from).  The  
"mailboxes" are actually e-mail addresses referring to a  
pseudo-account on some machine that hosts a remailer/mail spooler.

Bob would purchase a number of mailboxes scattered throughout the  
remailer/mail spooler system.  Bob would give out the address of one  
of these mailboxes to people so they can send "reply" messages to  
him.  Messages addressed to Bob's "public" mailbox would be spooled  
by the remailer hosting that mailbox.

Periodically (perhaps frequently), Bob would send an anonymous  
message (via other remailers) to the remailer hosting his public  
mailbox to command the remailer to send the contents of his mailbox  
to one of his other mailboxes.  The remailer wouldn't necessarily  
know it's sending to another mailbox, it's just sends to an address  
supplied in the command message.

Bob repeats this process to move his messages from his second mailbox  
to his third mailbox, and so on.  Eventually, he moves his messages  
from his Nth mailbox to his "real" address.

Is this approximately what you had in mind?  I left out IP  
redirectors and POP clients because I'm not familiar with them.

Jim_Miller at suite.com





From fringeware at illuminati.io.com  Thu Feb  3 20:04:49 1994
From: fringeware at illuminati.io.com (FringeWare List)
Date: Thu, 3 Feb 94 20:04:49 PST
Subject: CRYPTO - New US keyserver now fully operational -
Message-ID: <199402031618.KAA29816@illuminati.IO.COM>


Sent from the cyberdeck of: pgpkeys at wasabi.io.com (PGP Slave Key Server)

The US-based keyserver  'pgp-public-keys at io.com' is now open to the public.

Come one, come all!

Here is the current file as returned by 'Subject: help'.

This site is a PGP key server SLAVE site.  It behaves
very similarly to the European PGP master sites, but there
are a few small differences which will be noted below.
The most noticable difference is that it answers your
requests immediately instead of waiting for a daily
batch job to run :-)

The particular installation at io.com does *not* log the details of
requests for keys, however the fact that you have sent mail to the
key server at all is logged in the daily sendmail logs.  These logs
will be erased automatically after one week.


PGP Public Keyservers
---------------------

There are PGP public key servers which allow one to exchange public
keys running through the Internet and UUCP mail systems.

This service is NOT supported in any way whatsoever by the schools or
organizations on which these servers run.  It is here only to help
transfer keys between PGP users.  It does NOT attempt to guarantee
that a key is a valid key; use the signators on a key for that kind of
security.  This service can be discontinued at any time without prior
notification.

Each keyserver processes requests in the form of mail messages.  The
commands for the server are entered on the Subject: line.

        To: pgp-public-keys at io.com
        From: johndoe at some.site.edu
        Subject: help

Sending your key to ONE server is enough.  After it processes your
key, it will forward your add request to other servers automagically.

For example, to add your key to the keyserver, or to update your key if it is
already there, send a message similar to the following to any server:

        To: pgp-public-keys at io.com
        From: johndoe at some.site.edu
        Subject: add

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

        <blah blah blah>
        -----END PGP PUBLIC KEY BLOCK-----

COMPROMISED KEYS:  Create a Key Revocation Certificate (read the PGP
docs on how to do that) and mail your key to the server once again,
with the ADD command.

Valid commands are:

Command                Message body contains
---------------------- -------------------------------------------------
ADD                    Your PGP public key (key to add is body of msg)
                       *** Note: your update is forwarded to a master
                           server and may take a few days to reappear
INDEX                  List all PGP keys the server knows about (-kv)
VERBOSE INDEX          List all PGP keys, verbose format (-kvv)
GET                    Get the whole public key ring
GET 0xA1B2C3           Get a single key by Key ID
                       *** Note: the master servers allow you to omit
                           the 0x in front of the Key ID.  The slave
                           servers do not.
GET userid             Get a single key by User ID
MGET substr            List all keys which match "substr"
                       *** Note: this is different from the master servers
                           which return the keys themselves, not just a
                           listing of their Key IDs.  Also the master
                           servers accept a wild-card expression; at
                           the moment we do not.
LAST days              Get the keys updated in the last `days' days
                       *** Note: not yet implemented
------------------------------------------------------------------------

Examples for the MGET command:

        MGET michael         Lists all keys which have "michael" in them
        MGET @iastate.edu    Lists all keys which contain "@iastate.edu"


Check the Usenet newsgroup alt.security.pgp for updates to this system
and for new sites.

Based on a document originally by Michael <explorer at iastate.edu>







From jdblair at nextsrv.cas.muohio.EDU  Thu Feb  3 20:14:49 1994
From: jdblair at nextsrv.cas.muohio.EDU (jdblair at nextsrv.cas.muohio.EDU)
Date: Thu, 3 Feb 94 20:14:49 PST
Subject: Prodigy Hard Drive Scans
Message-ID: <9402040414.AA25368@ nextsrv.cas.muohio.EDU >


I heard from a friend that Prodigy was scanning user's hard drives. 
Basically, when you logged on Prodigy made a complete directory of your
hard drive and uploaded it.  Prodigy was using this to find out what
applications you used so they could direct the appropriate advertising
towards you.  Apparently, they're suffering several lawsuits now because
of it.

My friend heard this on the trailing end of a radio talk show.  If it was
really happening, it sounds horrible.  Could Secure Drive be set up to
stop this kind of attack?

Can anyone tell me if this is more than a rumour?  If it is more than a
rumour, would you be able to point me towards some information about this?

-john.
jdblair at nextsrv.cas.muohio.edu





From tcmay at netcom.com  Thu Feb  3 20:39:44 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Thu, 3 Feb 94 20:39:44 PST
Subject: Prodigy Hard Drive Scans
In-Reply-To: <9402040414.AA25368@ nextsrv.cas.muohio.EDU >
Message-ID: <199402040436.UAA14470@mail.netcom.com>



> I heard from a friend that Prodigy was scanning user's hard drives. 
> Basically, when you logged on Prodigy made a complete directory of your
> hard drive and uploaded it.  Prodigy was using this to find out what
> applications you used so they could direct the appropriate advertising
> towards you.  Apparently, they're suffering several lawsuits now because
> of it.
> 
> My friend heard this on the trailing end of a radio talk show.  If it was
> really happening, it sounds horrible.  Could Secure Drive be set up to
> stop this kind of attack?
> 
> Can anyone tell me if this is more than a rumour?  If it is more than a
> rumour, would you be able to point me towards some information about this?

Just a rumor, disposed of several years ago. A hot topic of debate
around 1990.

This rumor arose because Prodigy set aside a block of user disk space
for its own files. Sometimes this block had random stuff in it (recall
that "erasing" a file doesn't actually overwrite the disk, it just
removes pointers to the stuff being erased and allows other stuff to
later be overwritten over it). Prodigy used part (a small part, given
1200- and 2400-baud modems in use then) of this block to send back to
the main computers, so in principle it could see miscellaneous scraps
of erased data.

But this was accidental, was a tiny fraction of the disk, was not used
or even looked at by Prodigy, and would have absolutely no value in
determining applications used. (Think about what a samll random chunk
of "erased" disk space would really mean in terms of telling outsiders
what applications you use!)

Ironically, an old college buddy of mine is now in charge of e-mail
for Prodigy, in White Plains, New York. He visited me last summer and
I showed him a _real_ computer service (Netcom) and we had a few good
chortles about this Prodigy Conspiracy.

--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.




From nobody at shell.portal.com  Thu Feb  3 20:59:44 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Thu, 3 Feb 94 20:59:44 PST
Subject: New remailer up.
Message-ID: <199402040459.UAA04387@jobe.shell.portal.com>


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

Jon Boone expressed what seems to be a consensus, " I won't hack into
mail.netcom.com to demonstrate that it is possible to figure out who used
your remailer. But, if one of the admins from netcom wants to send me their
syslogs, I'll do my best to put together a correlation."

Netcom logs mail. The mail queue is viewable by most anyone willing to set
up a mail queue logging routine. If someone wants to see the mail logs
after it is no longer in the mail queue they have to be root on Netcom or
illegally hack in. If the FDA wants your illegal smart drugs, they might
get Netcom to hand over mail logs. If a hacker or the NSA taps into root,
they don't need mail logs; they'll just "wiretap" the qwerty account,
including its secret key and pass phrase.

Is there any OTHER serious but unrelated problems with a Netcom remailer?

Now I know what warnings and hints to put in qwerty's .plan: "Since Netcom
keeps mail logs, people should only have contact with qwerty via other
remailers or send mail out from qwerty only to public sites like Usenet or
a mailing list, so the real addresses of the users never shows up on
Netcom's logs or in the mail queue. It is also best to use encryption in
case someone is reading the contents instead of just the logs."

Routing through qwerty will add another layer of difficulty to someone
trying to track down a message sender, since if forces them to get Netcom's
sendmail logs after the fact or to make their own logs every day of the
year from an account on Netcom. Is this legal for say the FDA to do? How
about my new idea for a company called "Netlog!" in which I log the mail
queue on Netcom and offer to sell CD ROMs containing a year's mail logs
from Netcom? These tricks could be made more difficult with traffic
analysis countermeasures.

However, the issue seems more touchy than this rationalization for the
existance of Netcom remailers. Not assuming qwerty remains in its current
state, will adding qwerty to a mailing chain, say between extropia to
hfinney at shell, using encryption, add to or decrease security? The question
needs to be answered, with the assumption that someone IS collecting mail
queue logs. How would you have me alter qwerty so that this link ADDED to
the security of a chain? More than an hour delay must be avoided by making
the scheme more sophisticated, in my view. If I add a 0-30 min. random
delay, with added dummy traffic going out from qwerty in a circle through
other remailers and back to qwerty's bit bucket, every few minutes, would
this make it useful also to SERIOUS remailer users?

Before I start throwing out ideas that I'm sure aren't new to readers here,
I have a simple question that perhaps I should post to comp.unix.questions
or comp.lang.perl, but.... Can I, and how would I, get a perl script to
kick in and send out mail every few minutes when I am NOT logged in. Is this
possible on Netcom?

The question is pretty general, and involves any public access or personal
account machine. So send me a remailer or tell me how to patch Hal's.

 -Nik (Xenon)

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVGOgQSzG6zrQn1RAQFGLAP+N31dNMjnArEOklm4AeruT7pu6LgfNdUM
OawRDPY8CYgxYi5kJ4yByh7+uD+Asr7FCMaKacln8YwO6oOz3FlceNupC1czWFI5
NWuS9b4r5ZPKpLClv9K3oY1QvRePc1r0Ypl4SYCtZux/7U787BoyT/VUHmkfwple
I6X6+irFXns=
=6Klu
-----END PGP SIGNATURE-----





From wcs at anchor.ho.att.com  Thu Feb  3 23:04:52 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Thu, 3 Feb 94 23:04:52 PST
Subject: Remailer Tearline Conventions
Message-ID: <9402040701.AA23632@anchor.ho.att.com>


> > That remail at extropia.wimsey.com is in Canada specifically makes
> > communications with it fair game for NSA interception, however.
> 
> NSA interception is world wide.

On the other hand, extropia uses PGP encrypted messages to its
remailer, and NSA PGP-breaking is distinctly *not* world-wide.
I assume it doesn't use PGP encryption for the anonymous outgoing side,
but you can always encrypt the message before encrypting it for extropia.





From wcs at anchor.ho.att.com  Thu Feb  3 23:14:52 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Thu, 3 Feb 94 23:14:52 PST
Subject: finger user@wasabi.io.com
Message-ID: <9402040712.AA23739@anchor.ho.att.com>


Neat stuff!  You can finger billstewart at wasabi.io.com,
even though I don't exactly have an account there...
Is the source code available for your finger daemon?

It doesn't seem to have any regular-expression matching;
it mostly matches exact character strings, presumably case-insensitive.
I couldn't figure out how to get it to match spaces, though:
requesting 'bill stewart' got all the bills and all the stewarts,
rather than getting the lines with bill stewart in them.

	Thanks!





From hfinney at shell.portal.com  Thu Feb  3 23:19:44 1994
From: hfinney at shell.portal.com (Hal)
Date: Thu, 3 Feb 94 23:19:44 PST
Subject: Running regularly
Message-ID: <199402040708.XAA17954@jobe.shell.portal.com>


> Before I start throwing out ideas that I'm sure aren't new to readers here,
> I have a simple question that perhaps I should post to comp.unix.questions
> or comp.lang.perl, but.... Can I, and how would I, get a perl script to
> kick in and send out mail every few minutes when I am NOT logged in. Is this
> possible on Netcom?

Most public Unix systems will not let you do this, in my experience.
The two Unix commands which usually give you the ability to run programs
at regular intervals are "at" and "crontab".  You can read the man pages
and try running these to see if they are enabled for you.

I had an idea for how to get around this, so that people could run batching
remailers which sent out mail, say, every 30 minutes or whatever.  (Unlike
Xenon, I am of a generation which is accustomed to waiting more than a few
seconds for mail to travel across the country!)  The idea was simply for
someone who DID have an account which would let them use at or cron, to
run a program which would simply send a "ding" message (not to be confused
with a "ping" message :) at regular intervals to a list of subscribers.
This message could have a special header field so that the remailer programs
could easily recognize it and take whatever action they wanted, like running
Karl Barrus' script to scan a directory for pending outgoing remailer mail
and send it out.  (Karl has had batching running for months, as well as
postage-stamp-based remailers (albeit with non-anonymous stamps).  He is
way ahead of most of this discussion.)

Hal






From hfinney at shell.portal.com  Thu Feb  3 23:24:53 1994
From: hfinney at shell.portal.com (Hal)
Date: Thu, 3 Feb 94 23:24:53 PST
Subject: contemplating remailer postage
Message-ID: <199402040715.XAA18357@jobe.shell.portal.com>


As Jim points out, Matthew's scheme for one-bit-per-stamp has the
problem that it requires non-anonymous stamps.  Jim suggested a variant
on Chaum's digital cash where the stamp numbers would be re-blinded by
the recipient so that the remailer would not recognize them (but could
verify their validity).

Matthew's bitmap idea could still be used, though.  The incoming stamp
numbers could be hashed down to, say, 24 bits.  This could then be an
index into a 2^24-bit file, which would take 2 MB.  Set the bit when the
stamp is used, and reject the mail if the bit is already set.

Granted, this would create false rejections.  But email is already not
perfectly reliable.  You could send 160,000 messages before you had as
many as 1% false rejections (2^24 / 100).  I think this would be better
than trying to save this many digital stamps and check through the list
each time for duplications.

Hal






From catalyst-remailer at netcom.com  Thu Feb  3 23:34:53 1994
From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com)
Date: Thu, 3 Feb 94 23:34:53 PST
Subject: Remailer FAQ. Details.
Message-ID: <199402040732.XAA02211@mail.netcom.com>


I hope I can get a bit more attention to this, now that it has become more
sophisticated. Please code warriers, take a break and let the human race
know what the existing remailers are all about. I know exactly why they
don't have enough traffic; knowledge about them is still insider
knowledge. A list of remailer addresses and year-old partial info from a
request made my Tim May was all I could find. Specs needed.

I will send this to Gary Edstrom for the PGP FAQ if I don't have to spend
the rest of my life compiling it. Mail info to qwerty at netcom.com. I'm
interested in hearing from users as well as operators. 

-Nik (Xenon)

Xenon's Full Disclosure Remailer List.

Remailer  Fast?  OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ?what else?
--------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- -----------
bsu-cs    +      ?      ?/?    +    ?    ?   ?  ?   ?   23a  ?
catalyst  +      N?    SM/MQ   -    -    ?   -  PA  M   23a  -
choas     +      ?      ?/?    +    ?    ?   ?  ?   ?   -    -
cicada    ++     ?      ?/?    -    -    -   -  ?   ?   -    -
dis.org   -      ?      ?/?    -    ?    ?   ?  ?   ?   23a  ?
extropia  ?      ?      ?/?    +    ?    ?   ?  Pr? ?   23a  ?
jarthur   +/--   St    SM/MQ?  -    ?    ?   ?  Un  ?   23a  -
menudo    --     ?      ?/?    -    t1   ?   ?  ?   ?   -    ?
merde     -/--   ?      ?/?    -    ?    ?   ?  ?   ?   -    ?
penet.fi  --     St     ?/?    -    t?   24  +  Pr  H   -    -
pmantis   ++     ?      ?/?    -    ?    -   -  ?   ?   -    -
qwerty    +      C     SM/MQ   -    -    -   -  PA  M   23a  +
rosebud   ++/-   ?      ?/?    -    -    -   ?  ?   ?   23a  ?
remba       ?    ?      ?/?    ?    ?    ?   ?  ?   ?   23a  ?
shell     ++/+/- St     ?/?    -    ?    ?   ?  ?   ?   23a  -
soda      ++/-   St+?   ?/?    -    ?    ?   ?  ?   ?   -

Subj: Strips Subject header?
NL: Non-linear remailing? 123->231.
RD: Random delay added (max, in hours)?
Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages.
CPU: Pr = private. PA = account on public access machine. Un = university.
Phys: Physical security of the CPU, especially at night. H/M/L.
BitB: BitBucket feature?

Fast?:
++ <5 min
+   5-10 min.
-  ~10-30 min delay
--  Pinging isn't practical due to long delays, but may be more secure.
+/- Sometimes +, sometimes -
Normal internet mail delays are common, and are not equivalent in the two
directions between any two remailers. Mail still gets through.

OpLog:
F: Full copies of all mail is archived. My large volume mailing should
   help put a stop to this.
St: Stats logs of when mail was remailed.
St+: Stats logs of when and where mail was remailed.
St-: Simple counter.
N: Operator keeps no logs.

SysLog:
SM: sendmail logs of when and where mail was exchanged. Root access.
MQ: mailqueue accessible by anyone on the site. Could make logs.

bsu-cs    nowhere at bsu-cs.bsu.edu
catalyst  catalyst at netcom.com
chaos     remailer at chaos.bsu.edu
cicada    hh at cicada.berkeley.edu
dis.org   remailer at dis.org
extropia  remail at extropia.wimsey.com
jarthur   ebrandt at jarthur.claremont.edu
menudo    nobody at Menudo.UH.EDU
merde     remailer at merde.dis.org
penet.fi  anon.penet.fi
pmantis   hh at pmantis.berkeley.edu
qwerty    qwerty at netcom.com
rosebud   elee7h5 at rosebud.ee.uh.edu
shell     hfinney at shell.portal.com
soda      hh at soda.berkeley.edu

Discontinued remailers still on some lists out there:

phantom at mead.u.washington.edu
remail at tamaix.tamu.edu
sameer at netcom.com (spelling?)
sameer at berkeley.edu (spelling?)
cdodhner at indirect.com
remailer at entropy.linet.org??
00x at uclink.berkeley.edu?
remail at tamaix.tamu.edu?
remailer at entropy.linet.org?

Background on each remailer:

bsu-cs:
Run by Chael Hall.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

catalyst:
Run by Scott Collins.
Machine: personal dial-up account on Netcom.
Problems policy: Outgoing address blocking, with proof of ID.
         Contact catalyst at netcom.com.
Software: Customized Hal's ?
Security: Netcom keeps sendmail logs, which root at netcom.com can read.
          Any Netcom user could also compile his own sendmail logs, by
          constantly logging mail as it arrives and leaves.
Comments:
History: ??

chaos:
Run by ??
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security:
Comments: Finger remailer.help at chaos.bsu.edu for info using any remailer. ??
          gopher chaos.bsu.edu for a collection of info about Cypherpunks.
Comments:
History: ??

cicada:
Run by Eric Hollander.
Machine: ???
Problems policy: ?? Contact ??
Software: ??
Security: Tread lightly. Being "phased out".

dis.org:
Run by ??
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

extropia:
Run by ??
Machine: ??
Problems policy: ??  Contact ??
Software: ??
Security: ??
Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional.
          Privately owned, in Canada.
History: ??

jarthur:
Run by Eli Brandt.
Machine: Sequent Symmetry.
Problems policy: Destination blocking is available w/ sufficient ID.
                 Contact ebrandt at jarthur.claremont.edu.
Software: the usual, tweaked for MMDF. Hal's?
Security: jarthur keeps sendmail logs.
Comments:
History: Set up late '92.  PGP added mid-'93.

menudo:
Run by ??
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Security: Stores messages and sends them at midnight??
Comments:
History: ??

merde:
Run by ??
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

penet.fi:
Run by Julf (last name?)
Machine: ?? Operator owned.
Problems policy: Account revokation. Contact ??@anon.penet.fi.
Software: custom.
Security:
Comments: By far the most popular remailer, dwarfing in a day what the
          entire Cypherpunk remailers combined carry in a month. Supports
          easy return addresses as well as non-anonymous mailing to
          someone's anonymous address (na1234... instead of an1234...).
          Your real address is kept on Julf's hard disk, but is fairly safe
          there, especially if you do not abuse your anonymity to harass
          someone. On a bad day your mail and especially Usenet posts may
          be delayed up to two days. Very reliable though. Sends error
          messages back to you for failed mail. Limited to 48K mail.
History: ??

pmantis:
Run by Eric Hollander.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: Tread lightly. Being "phased out".
Comments:
History: ??

qwerty:
Run by Xenon.
Machine: dial-up account on Netcom.
Problems policy: "What problems?". Contact qwerty at netcom.com.
Software: Hal's remailer.
Security: Netcom keeps sendmail logs, which root at netcom.com can read.
          Any Netcom user could also compile his own sendmail logs, by
          constantly logging mil as it arrives and leaves.
Comments: You must use na1234 at anon.penet.fi not an1234 at anon.penet.fi.
          Finger qwerty at netcom.com for a blurb on the remailer and updates
          on its software.
          Request-Remailing-To: /dev/null is a bit bucket.
          whitehouse.gov gets blocked and fully logged.
History: Up 2/94. Set up by Xenon who needed more remailers to use to send
         PGP info to people with, since anon.penet.fi was overloaded.

rembe:
Run by ?
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments: ??
History: ??

rosebud:
Run by Karl Barrus.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

shell:
Run by Hal Finney.
Machine: ??
Problems policy: ?? Contact ??
Software: Hal's Remailer.
Security: ??
Comments: whitehouse.gov blocked and fully logged.
          hal at alumni.caltech.edu forwards all mail to shell.
History: ??

soda:
Run by Eric Hollander.
Run by: ??
Machine: ??
Problems policy: ?? Blocking of addresses. Mail sent to problem causer.
                 Contact ??
Software: custom. ??
Security: ??
Comments:
History: ??

Remailer Public Keys:
(I've got these...)





From jkreznar at ininx.com  Fri Feb  4 00:44:53 1994
From: jkreznar at ininx.com (John E. Kreznar)
Date: Fri, 4 Feb 94 00:44:53 PST
Subject: New remailer up
In-Reply-To: <199402030311.TAA14987@mail.netcom.com>
Message-ID: <9402040838.AA06813@ininx>


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

> Julf's anon.penet.fi remailer is serious; he's done a lot of work
> to get a private machine, payng for a reasonably expensive
> 64kbps line himself, and has it located somewhere that only 3 people know.

How can this be?  What about the people who operate his connection point
to the net?  Wouldn't they know where his machine is located?  What is
the physical embodiment of his 64kbps line?  Can't that line be traced
to its terminus?

	John E. Kreznar		| Relations among people to be by
	jkreznar at ininx.com	| mutual consent, or not at all.

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVIJS8Dhz44ugybJAQHzdAP+JXuFhoq8mksb733rTgfLQJMVZrLzZsjI
qxRd+ijfS7EjqELajoNivY+gOjvjJ6V1LpXhTTnC+1Zkcaf6C7JK+qgLuH3GbrQp
XkWMeuoIxw3ThyVAYF6mFqPQ5ARAda+HckMeTRS/Cm3Nl2p6LK8s2c1lxbXWg/Dl
C5ZLsqF6dWY=
=UlVb
-----END PGP SIGNATURE-----





From mech at eff.org  Fri Feb  4 01:54:53 1994
From: mech at eff.org (Stanton McCandlish)
Date: Fri, 4 Feb 94 01:54:53 PST
Subject: info on local/regional groups & sublists
Message-ID: <199402040948.EAA19495@eff.org>


For my OUTPOSTS list/FAQ, if you have any (public) inforation about local
cypherpunks groups and sublists, like the Austin lists, or the UK branch,
please let me know via personal email. Need to put out a new version of
the FAQ soon, and am missing much info.  All I have so far is:

        Main general: hughes at soda.berkeley.edu
        Main subscribe requests: cypherpunks-request at toad.com
        Main FTP: soda.berkeley.edu, pub/cypherpunks
        Hardware general: jdblair at nextsrv.cas.muohio.edu
        Hardware requests: cp-hardware-request at nextsrv.cas.muohio.edu
        Wonks general: cypherwonks-owner at lassie.eunet.fi
        Wonks requests: majordomo at lists.eunet.fi (message body of:
                       subscribe cypherwonks [1st & last name] [address])
        Austin general: Jim McCoy <mccoy at bongo.cc.utexas.edu>
                        Doug Barnes <barnes at io.com>
        Austin req. austin-cypherpunks-request at bongo.cc.utexas.edu
                    austin-cypherpunks-announce-request at bongo.cc.utexas.edu
        Austin FTP: ftp.cc.utexas.edu, pub/cypherpunks

Any info on other CP groups, corrections to what little I have, pointers
to other CP file sites, gopher/WWW/Wais servers, etc. all appreciated.
Even some BBS number, snailmail addresses for any local groups that are
getting less virtually, more physically organized, etc.  That, and
relevant other lists (anything that might be consider "online activist" or
civil libertarian in nature) and resources.

Again, please send via email to mech at eff.org rather than on the list.

Muchas gracias in advance!

-- 
Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist
F O R   M O R E   I N F O,    E - M A I L    T O:     I N F O @ E F F . O R G 
O  P  E  N    P  L  A  T  F  O  R  M     O  N  L  I  N  E    R  I  G  H  T  S
V  I   R   T   U   A   L   C  U   L   T   U   R   E      C  R   Y   P   T   O




From boone at psc.edu  Fri Feb  4 05:05:03 1994
From: boone at psc.edu (Jon 'Iain' Boone)
Date: Fri, 4 Feb 94 05:05:03 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402032319.AA20066@ah.com>
Message-ID: <9402041301.AA04130@igi.psc.edu>



hughes at ah.com (Eric Hughes)  writes:
>
>    1 si		( ? Slovenia ? )  

   Yep, this is correct.

>    1 ee		?

   This is estonia.


 Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 | PGP Key # B75699
 PGP Public Key fingerprint =  23 59 EC 91 47 A6 E3 92  9E A8 96 6A D9 27 C9 6C





From CCVARGA at delphi.com  Fri Feb  4 05:55:03 1994
From: CCVARGA at delphi.com (CCVARGA at delphi.com)
Date: Fri, 4 Feb 94 05:55:03 PST
Subject: CONTENT AND QUALITY NET DISCUSSION.
Message-ID: <01H8HCEZOUGI91W5VO@delphi.com>


GENTLEMEN,  MOST OF MEANINGFUL DISCUSSION ON THE NET HAVE BEEN BOTH
WELL THOUGHT AND INTELLECTUALLY "NON'TRIVIAL".  THE REMAILING OF 
MULTIPLE COPIES OF HIGH NOISE INFORMATION DRIBBLE WOULD CAUSE ME TO 
LOOK AT THE TRAFFIC ON THE NET AND AS : IS IT WORTH IT?
RIGHT NOW, THE NUMBER OF UNSUBSCRIBE MESSAGES LEADS ME TO BELIEVE 
THAT IT IS NOT.  IF THIS IS WHAT TOAD WANTS, SO BE IT. IF THERE IS 
AN INDIVIDUAL AMONG YOU THAT WOULD LIKE TO MAKE A CASE FOR 
CONTINUED SUBSCRIPTION, I WOULD REALLY APPRECIATE SERIOUS REPLY'S.
CCVARGA at DELPHI.COM





From jwc00 at cas.org  Fri Feb  4 06:15:06 1994
From: jwc00 at cas.org (Jim Cooper jwc00@cas.org; 614-447-3600 ext 3581)
Date: Fri, 4 Feb 94 06:15:06 PST
Subject: Subscribe
Message-ID: <9402040913.AA4494@cas.org>


Subscribe cypherpunks Jim Cooper





From davidm at smtplink.chey.com  Fri Feb  4 06:49:50 1994
From: davidm at smtplink.chey.com (David Michel)
Date: Fri, 4 Feb 94 06:49:50 PST
Subject: Prodigy Hard Drive Scans
Message-ID: <9402040948.A03416@smtplink.chey.com>


Prodigy durring installation sets up a temp/swap file on your hard disk.
Now this part is a funtion of DOS, 
Delete a file and all the data is there just the FAT entry is gone.
So what ever is on the disk at the location of the temp/swap file is 
what can be seen at the prodigy end.
davidm at chey.com






From dmandl at lehman.com  Fri Feb  4 06:50:04 1994
From: dmandl at lehman.com (David Mandl)
Date: Fri, 4 Feb 94 06:50:04 PST
Subject: CONTENT AND QUALITY NET DISCUSSION.
Message-ID: <9402041446.AA05230@disvnm2.lehman.com>


> From: CCVARGA at delphi.com
> 
> GENTLEMEN,  MOST OF MEANINGFUL DISCUSSION ON THE NET HAVE BEEN BOTH
> WELL THOUGHT AND INTELLECTUALLY "NON'TRIVIAL".  THE REMAILING OF 
> MULTIPLE COPIES OF HIGH NOISE INFORMATION DRIBBLE WOULD CAUSE ME TO 
> LOOK AT THE TRAFFIC ON THE NET AND AS : IS IT WORTH IT?
> RIGHT NOW, THE NUMBER OF UNSUBSCRIBE MESSAGES LEADS ME TO BELIEVE 
> THAT IT IS NOT.  IF THIS IS WHAT TOAD WANTS, SO BE IT. IF THERE IS 
> AN INDIVIDUAL AMONG YOU THAT WOULD LIKE TO MAKE A CASE FOR 
> CONTINUED SUBSCRIPTION, I WOULD REALLY APPRECIATE SERIOUS REPLY'S.
> CCVARGA at DELPHI.COM

So--another noisemaker complaining about noise on the list.  Why don't
you decide for yourself whether it's worth continuing your subscription?
Would you actually base your decision on the number of people who
tell you that it's worth continuing?  If you're new to the list, why
don't you stick around for a while and see what you think?  If not,
you're probably fully capable of deciding for yourself now whether this
is the place for you.

Related issue: The number of people unsubscribing because of excessive
noise who are so rude and clueless as to post their unsubscribe requests
to the entire list (thereby increasing noise) is really getting to me.
Almost no tangential or "off-topic" thread pollutes this list as much as
unsubscribe requests that everyone has to read.  The cypherpunks welcome
message clearly states that unsubscribe messages should be sent to
cypherpunks-request at toad.com.  Simple.  Again, the list administrator is
a human being, not a machine, so those requests may take a couple of days
to process.  Big deal.  Losing your patience and whining to the list is
as useful as pushing the elevator call button a hundred times, and has the
added disadvantage of getting hundreds of people really angry.  It also
makes you look like a clueless newbie.

I usually send these messages to individuals, not the whole list, but it
seems that there's been an increase in unsubs sent to all of us.

Again, folks, if you want to unsubscribe (which I'm not encouraging you
to do), it's

cypherpunks-request at toad.com

   --Dave.





From SERPE at morgan.com  Fri Feb  4 06:59:52 1994
From: SERPE at morgan.com (SERPE at morgan.com)
Date: Fri, 4 Feb 94 06:59:52 PST
Subject: unsubscribe
Message-ID: <94Feb4.095752est.41748@gateway.morgan.com>



please unsubscribe me.  Thanks and good luck!!





From sdw at meaddata.com  Fri Feb  4 07:09:50 1994
From: sdw at meaddata.com (Stephen Williams)
Date: Fri, 4 Feb 94 07:09:50 PST
Subject: New remailer up
In-Reply-To: <9402040838.AA06813@ininx>
Message-ID: <9402041508.AA18037@jungle.meaddata.com>


> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> > Julf's anon.penet.fi remailer is serious; he's done a lot of work
> > to get a private machine, payng for a reasonably expensive
> > 64kbps line himself, and has it located somewhere that only 3 people know.
> 
> How can this be?  What about the people who operate his connection point
> to the net?  Wouldn't they know where his machine is located?  What is
> the physical embodiment of his 64kbps line?  Can't that line be traced
> to its terminus?

That started me down an interesting line of thought...

You can get spread spectrum radio/data modems that do 256Kbits/sec
(Cylink) and can go up to 30 Miles.  It is unlicensed in the US
because it is limited to .8watts (I think).  I believe 10 miles is the
limit with an omnidirectional antenna.  Spread spectrum should be
pretty hard to triangulate on.  Remember that the technology came from
unjammable military radios.

I think you'd have to have a fairly sophisticated scanner to even pick
it up.

Using a creative arrangement, this could provide a good cover for
physical location.  (If you could get the server in the back of a city
bus or something...)

> 	John E. Kreznar		| Relations among people to be by
> 	jkreznar at ininx.com	| mutual consent, or not at all.

sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw at lig.net sdw at meaddata.com
OO R&D Source Dist.  By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Comm. Consulting     ICBM: 39 34N 85 15W I love it when a plan comes together




From matthew at gandalf.rutgers.edu  Fri Feb  4 07:45:06 1994
From: matthew at gandalf.rutgers.edu (Matthew Bernardini)
Date: Fri, 4 Feb 94 07:45:06 PST
Subject: Running regularly
Message-ID: <CMM-RU.1.3.760376482.matthew@gandalf.rutgers.edu>


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


Perhaps this is too rudimentary .....

Why not make two shell scripts, one that sleeps for so long (say 20 minutes)
using the unix sleep command, and then calls the remailer scripts in an
infinite while loop.  This would work if you set it up as a background
process,and you don't need to be root for it to work.  Only downsides are
that when the machine crashes you have to log back in and restart script,
your sleep command will always be in the top window if your sys-admin is
watching, and you have to be careful not to spawn to many processes and
bring the system down.

Matt





From mech at eff.org  Fri Feb  4 07:49:50 1994
From: mech at eff.org (Stanton McCandlish)
Date: Fri, 4 Feb 94 07:49:50 PST
Subject: White House crypto briefings: Clipper, FIPS, escrow agents, export
Message-ID: <199402041548.KAA22031@eff.org>


Briefings on Federal Encryption Policy/Telecommunications Security

Today (Feb 4), the Administration will hold 2 briefings about cryptography
and the Clipper chip.  The briefings will "report on a review of federal
policies and procedures for encryption and telecommunications
security-related products and technologies."

The first briefing, at 11am EST (i.e., in less that half an hour of this
posting), will update Congressional committee staff, and the second will
address concerns of industry reps, public interest groups, privacy
advocates and other non-government parties.  EFF will attend this second
meeting, at 1pm EST.

EFF will share what it learns about the results of either briefing
as soon as possible.  

An early "heads up" from the the Administration indicates that the main
subjects for the briefings will be:

        Administration will announce Clipper/Skipjack Federal Information
          Processing Standard (FIPS)
        Justice Dept. key escrow procedures to be announced
        Announcement of Treasury and NIST as Escrow Agents
        Decisions on encrytion products that fit under current export
          standards announced.

Other topics also likely to be addressed (unconfirmed):

        State Dept. will, surprisingly, streamline procedures for 
          export of Clipper
        Administration not going forward with DSS licensing agreement
          with PKP/RSADSI.

-- 
Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist
F O R   M O R E   I N F O,    E - M A I L    T O:     I N F O @ E F F . O R G 
O  P  E  N    P  L  A  T  F  O  R  M     O  N  L  I  N  E    R  I  G  H  T  S
V  I   R   T   U   A   L   C  U   L   T   U   R   E      C  R   Y   P   T   O




From rondavis at datawatch.com  Fri Feb  4 08:15:07 1994
From: rondavis at datawatch.com (Ron Davis)
Date: Fri, 4 Feb 94 08:15:07 PST
Subject: d3des code question
Message-ID: <9402041113.aa05790@gateway.datawatch.com>


Has anyone had any experience using the DES code by Richard Outerbridge
that appears in the back of Applied Crypto, and is available via ftp from
ripem.msu.edu?  Specifically can someone send me an example of how to call
the functions?

Thanks.

___________________________________________________________________________
"I want to know God's thoughts...the rest are details."
                                           -- Albert Einstein
_________________________________________
Ron Davis                                  rondavis at datawatch.com       
Datawatch, Research Triangle Park, NC      (919)549-0711






From schneier at chinet.com  Fri Feb  4 08:45:09 1994
From: schneier at chinet.com (Bruce Schneier)
Date: Fri, 4 Feb 94 08:45:09 PST
Subject: Review of APPLIED CRYPTOGRAPHY in Cryptologia
Message-ID: <m0pSTHe-000BycC@chinet.chinet.com>



The following review of APPLIED CRYPTOGRAPHY appeared in the
January 1994 issue of Cryptologia (v. 18, n. 1).  Written by
Louis Kruh.

     The past twenty years have seen an explosive growth in
     public research into cryptology, accompanied by an
     unprecedented public awareness of matters cryptologic. 
     Programmers and engineers trying to benefit from the fruits
     of this research, to solve real-world problems, have often
     been stymied by not knowing where to start looking, let
     alone when to stop.  This book is for them.  Written as a
     "comprehensive reference work for modern cryptology" the
     book succeeds both as an encyclopedia survey of the past
     twenty hears of public research and as a hansom "how-to"
     cookbook of the state-of-the-art.  It could well have been
     subtitled "The Joy of Encrypting."

     The author's style is colloquial and informal, but never
     imprecise.  Theory takes a back seat to clarity and
     directness, without deliberate misrepresentation; unabashed
     informed opinion wins out over academic hesitations.  Since
     the work is a practical snapshot of the field, circa mid-to-
     late 1993, several of the book's recommendations may prove
     timely: new results seem to be reported monthly.  While his
     political axe is never concealed the book is written as a
     whetstone for others rather than a soapbox rant, and the
     focus is manifestly practical solutions and the tools with
     which to achieve them.

     After a forward from Whitfield Diffie the author explains
     foundations; examined protocols; discusses techniques;
     presents algorithms; explores the real world (including
     legal and political aspects); and finishes up by printing
     read-to-run C source code programs of several of the
     algorithms, including ENIGMA, DES and IDEA.  Reflecting the
     confused nature of the real world, a set of IBM PC disks
     containing the sources published in the book is available
     from the author--but only to residents of the USA and
     Canada.  Drawing on 908 references and the collected
     experience of contributors throughout the Internet and
     around the world, this book will be a useful addition to the
     library of any active or wouldbe security practitioner.

It's the first review of the book that has appeared in print, and
I am very pleased with it.  The book has turned out to fill two
very different niches.  One, it is the book that people are being
handed to read when they want to learn about the field.  Two, it
is the reference work that people are turning to first if they
want to find out about some aspect of cryptography.  The third
important niche, which the book does not fill, is that of a
textbook.  This field sorely needs a textbook.  Anyone
interested?

Bruce


From qwerty-remailer at netcom.com  Fri Feb  4 09:25:09 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Fri, 4 Feb 94 09:25:09 PST
Subject: New remailer up.
Message-ID: <199402041723.JAA29445@mail.netcom.com>



>Before I start throwing out ideas that I'm sure aren't new to readers here,
>I have a simple question that perhaps I should post to comp.unix.questions
>or comp.lang.perl, but.... Can I, and how would I, get a perl script to
>kick in and send out mail every few minutes when I am NOT logged in. Is this
>possible on Netcom?

Rather than try to run in some asynchronous mode as you suggest, why
not do the following when each message arrives:

   place message in your queue, designating random hold time

   foreach message in the queue that's been held long enough
         send random number (1<=n<=3) dummy messages
         send the queued message
         send random number (1<=n<=5) dummy messages

The whole thing remains data-driven while you're not logged in
and can be manually flushed if you are logged in.  So long as
there is a steady stream of traffic, messages won't get stalled
for long times.  You could even send some 'activation' messages
at controlled intervals from some comfortable site (where you can
use cron), routed via another remailer.

Just some ideas off the top of my head.





From richardr at netcom.com  Fri Feb  4 09:39:48 1994
From: richardr at netcom.com (Richard L. Robertson)
Date: Fri, 4 Feb 94 09:39:48 PST
Subject: Practical Pencil & Paper Encryption (computerizable)
Message-ID: <199402041738.JAA19453@mail.netcom.com>



Bruce Schneier   <schneier at chinet.chinet.com>

     in Message-ID: <CEtKr4.7B7 at chinet.chinet.com>
              Date: Wed, 13 Oct 1993 05:04:13 GMT
           Subject: Pencil and paper encryption algorithm

proposed a pencil-and-paper encryption algorithm that could be used
without computers, but was still secure against computer-aided
attacks.  

I answered with what I felt were several practical usage problems
with his proposed methodology that made it infeasible to reliably
encrypt and decrypt messages in a finite time.

During a much needed vacation from the practical realities of work
and life, I have attempted to come up with a simplified message
encryption algorithm that meets Bruce's criteria and is practical
in use.

I took as design constraints that an inexpensive (< $30) pocket
calculator was acceptable for performing any necessary
calculations, but that something as big and complex as an HP-48 or
an Apple Newton was unacceptable. I also changed the requirement
from "secure against computer-aided attacks" to "highly resistant
against computer aided attacks".

My first attempt used a simple, multiple memory, non-programmable
Radio Shack checkbook pocket calculator. While the methodology met
the "resistance" criterion, it failed the practical test of error-
free calculation in a finite time. It turned out to be possible to
get reliable encryption and decryption by applying the result
cross-checking techniques used in hand pencil-and-paper
calculation, however the time required for error-free encryption
was exorbitant.

By relaxing the design constraints to allow limited programmability
in the pocket calculator, I was able to adequately address the
problem of speed of error-free encryption calculations. 

The constraint that I adopted was that the calculator's program
steps must be simple and compact enough for the user to be able to
memorize and to be able to re-enter the program into the calculator
each time that it was used to encrypt or decrypt a message. I
believe that this satisfies the reasonable requirement that there
be no incriminating evidence left lying around in the calculator
between encryption sessions.

The following encryption procedure was tested using an $18 Radio
Shack Model EC-4021 programmable scientific calculator. The
algorithms were modified as necessary to conform to the practical
limitations of the calculator keypad and limited programming
capabilities.

With only moderate training time (a couple of hours) I was able to
reliably encrypt and decrypt messages at a rate of 8-10 characters
per minute. The primary speed limitation was the actual tran-
scription on the results by pencil onto paper.

I would appreciate any and all comments, criticisms, error corrections
and suggestions for improvements.


Richard Robertson           richardr at netcom.com

------------------------------------------------------------
            A "Pencil and Paper" Encryption Algorithm
                     for Pocket Calculators

              Copyright 1993   Richard L. Robertson

Contents

     A:   Encryption Confusion Generators
     B:   Substitution Cipher Technique
     C:   Transposition Cipher Technique
     D:   Encryption Key Management
     E:   Cryptographic Hardness
     F:   Message Encryption Example
     G:   Sample Message Key Generation



A:   Encryption Confusion Generators

The core confusion generator chosen is a variation on the non-
linear equation Logistic Difference Equation (LDE). This is
selected for its adequate PRNG properties and its simplicity of
calculation.

The standard basic LDE can be written as 

     X[n+1] = R * X[n] * (1 - X[n])
          where     R = 4, and
                    0 < X[n] < 1

While the output of the LDE has reasonable unpredictability, this
basic formulation has limited cryptographic usefulness, partly
because of limited sequence length and partly because the seed can
be derived with sufficient information about successive values,
even if "jitterized" (as described by Terry Ritter).

By revising the constraints slightly to

               3.99 < R < 4.0

the resulting output is "sub-chaotic" but still has very good PRNG
properties. Another advantage of using R < 4.0 is that rounding
errors in calculations do not cause any numerical values that
result in the PRNG sequence degenerating from calculation errors.
Extensive numerical trials on a 486 PC with 15-digit (decimal)
floating point calculations have not uncovered any values of R or
X[n] that result in short or degenerate PRNG sequences.

The average length of a pseudo-random sequence from a (modified)
LDE is a function of the number of digits of precision used in the
calculations. For 9-digit fractional numbers, the expected length
of a pseudo-random sequence is ~ 3 * 10^4 and there are ~ 3 * 10^4
independent sequences. The sequence length is adequate for pencil
and paper encryption since messages would rarely exceed 200
characters.

To develop a reasonably secure cryptographic methodology using the
modified LDE as the confusion generator, proceed as follows:

1 -  Select two non-linear (LDE) confusion generators

               G1 = R * X * (1 - X),  and
               G2 = R'* Y* (1 - Y)

               where R' = 0.999 * R (used because of limitations in
                                   the number of memory registers
                                   in the pocket calculator)

2 -  The cryptographic key (or seed) consists of the values

          R, X[0] and Y[0],  where

               0 < X[0]  < 1  is a 9-digit key
               0 < Y[0]  < 1  is a 9-digit key
               3.99 < R < 4.0 is a 7-digit key

     The total key length is 25 digits, giving a key space size of
     10^25.  The keys are short enough to be easily memorized.  (If
     you are not convinced of this assertion, consider how many
     phone numbers, PIN numbers, bank account numbers, etc that the
     average person routinely commits to memory)


3 -  Select a non-linear combiner for the output of two confusion
     generators.

          This is the first level of serious cryptographic
          strength.

     We will chose the function

          K = G1 <*> G2

          where <*> is the floating point multiplication operator
          with rounding (see Knuth, Seminumerical Algorithms for
          details).

               At little inspection will show that it is not possible to
     recover the values G1 and G2 from a given K because K is not
     uniquely factorable. The rounding performed during the
     multiplication discards information necessary for factoring.

     In fact, for any 0 < K < 1, *all* values of G1 > K are valid
     factors of K. Rephrased, for any K {0 < K < 1} and for any p
     {1 > p > K, there exists at least one q {1 > q > K} such that
     K = p <*> q.

          Note: Because of rounding, numbers of the form K =
          (1/b)^n (where b is the base) are the only
          exceptions to this statement. For K = (1/b)^n, q =
          1-(1/b)^n is not a factor of K. 

     Recovering a sequence of G1 and G2 values from a sequence of
     K values, and from that recovering the cryptographic keys R,
     X[0] and Y[0], requires solving a series of simultaneous non-
     linear high-order polynomial equations.  I am not aware of any
     practical way to do this in the literature.

     Brute force recovery of the sequence of n-digit G1 and G2
     values requires checking a minimum of 10^(n*3) n-tuples 
     {G1,G2,G'1,G'2,G''1,G''2} to determine which are possible
     solutions for the generator functions G1 and G2.

4 -  Choose a domain transformation from quasi-continuous floating
     point to the finite to select digits from K to use for data
     encryption.

          This is the second level of serious cryptographic
          strength.

     Choose any algorithm for selecting a cipher value K' of either
     1 or 2 digits from "around the middle" of the value K to use
     for performing the encryption. Because the confusion
     generators G1 and G2 are independent and have reasonably
     uniform digit distributions, the nonlinear combination K = G1
     <*> G2 also has a reasonably uniform digit distribution. 

     For any particular 1-digit value K', there are 10^8 possible
     values of K that could have generated it.  For any particular
     2-digit value K', there are 10^7 possible corresponding values
     for K.

5a - Use the sequence {K'} as the key for a Vigenere cipher

5b - Use the sequence {K'} to control a pseudo-random transposition
     cipher.

5c - Combine (5a) and (5b). Use (5a) to "bit-level" the message
     text, then use (5b) to superencipher the output of (5a).

          This would require two complete encryption steps and is
          probably too labor and time intensive to be worth while
          for pencil and paper encryption.

In summary, the steps for calculating the encryption sequence K'
are as follows:

               X [n+1] = R * X[n] * (1 - X[n])
               Y [n+1] = .999 * R * Y[n] * (1 - Y[n])

               K [n+1] = X[n+1] * Y[n+1]
               K'[n+1] = 1 or 2 low-order digits of int (10^5 * K[n+1])


B:   Substitution Cipher Technique

In this system, the key consists of a series {K'} of 2-digit values
that is as long as the message. These are added to the plaintext
message characters modulo 100, considered the alphabet as numbered
from Sp=00, A=01 to Z=26, etc. This is your basic Vigenere cipher
with the cipher key as long as the message.

Decryption performs the same series of steps on the ciphertext
message characters except that subtraction modulo 100 is used.

Given that the K' form an unpredictable sequence, this is
equivalent to a one-time pad Vernam cipher where the one-time pad
does not have to be transmitted to the receiver. The message
recipient can regenerate the series {K'} from knowledge of the
cipher key <R,X[0],Y[0]>. 

The only problems that need to be addressed are the resistance of
the sequence {K'} to computer-assisted attack and how to manage the
necessary set of secret keys {<R,X[0],Y[0]>}, since one key-tuple
is consumed by each message.


In summary, the steps for encrypting a message M are as follows:

        compute K[n] as described above
        C[n] = 2 low-order digits of int (10^5 * K[n]) + M[n]

        where  M[n] is the nth plaintext character, and
               C[n] is the nth ciphertext character


and the steps for decrypting a ciphertext C are as follows:

        compute K[n] as described above
        M[n] = 2 low-order digits of 
               int (100001 - (10^5 * K[n]) + C[n])

        where  M[n] is the nth plaintext character, and
               C[n] is the nth ciphertext character

C:             Transposition Cipher Technique

In this system, the key consists of a series {K'} of 1-digit values
that is longer than the message.

     1 -  Write down the plaintext message into blocks of length 10
          (because the calculator operates in decimal mode). Repeat
          the message at least once because the algorithm will
          encipher more characters than are in the message. The
          exact number of excess characters enciphered is random
          but bounded.

          If the message text is:
               "Now is the time for all good men to come to the
               aid of their party."

          then this is written in blocks of 10 as:

                       1234567890

                       |Now is the|
                       | time for |
                       |all good m|
                       |en to come|
                       | to the ai|
                       |d of their|
                       | party.Now|
                       | is the ti|
                       |me for all|

           Repeat the message text as required.

     2 -  Calculate the sequence of 1-digit numbers {K'}

     3 -  For each value K', select and output the next unused
          character in column K'. Mark the selected character as
          used.

     4 -  Repeat this process until all characters in the base
          message have been transmitted.


Decryption proceeds as follows:

     1 -  Calculate the sequence of 1-digit numbers {K'}

     2 -  Get the next ciphertext character and place it in the
          next available column K'

     3 -  Repeat this process for all ciphertext characters.

     4 -  The row in which that last character is placed is the
          last row of the message. Discard any rows following that
          row because they are just random padding added by the
          encryption algorithm.

Transposition ciphers are substantially harder to attack than
substitution ciphers and normally require a lot of hand work. 
Normally they are attacked by anagramming when there is some
knowledge of the expected message contents.

I would assert, based on a moderate literature search, that this
pseudo-random transposition has no known effective methods for
attack because there are no fixed column boundaries and character
positions are pseudo-random. 

If the cryptographic key <R,X[0],Y[0]> is changed with each message
there should be no way short of brute force anagramming or a brute
force key space search to break this cipher because the
cryptographic cipher values are never exposed for cryptanalysis.


D:   Key Management

     To make the subsitution cipher encryption useful the key must
     be changed with each message because it is a one-time pad
     method. The encryption method has already addressed and
     eliminated the need for the sender to transmit a copy of the
     OTP to the receiver by having the receiver independently
     recreated the OTP used to encrypt the message. 

     While having a separate, unique encryption key for each
     message is less important for the transposition cipher, it
     does strengthen the cipher against any attack if the key can
     be easily changed for each message.  

     In order to not have to transmit each key used to generate the
     OTP for each message to the receiver, a technique must be
     developed that provides a similar facility. If this can be
     accomplished, then the only secret that the sender and
     receiver must share is a single, small master key. Sharing a
     small amount of secret information is a fairly easy problem to
     solve in practice.

     Inspection of the method for generating the encryption
     confus*ion sequence shows a way to accomplish the desired key
     management. Consider the sequence of values {K[i]}.  It is
     obvious from the earlier discussion that there are only two
     ways to be able to predict subsequent values K[n+1] from the
     series of values {K[1] ... K[n]}:

       -  obtain the generating seeds for G1 and G2 by brute force
          examining sets of possible values {G1[i],G2[i]} obtained
          by factoring {K[i]}. This would require examining at
          least ~ 10^24 (2^80) possible sets {G1[i],G2[i]} and as
          such is not feasible with current computing technology.

       -  obtain the generating seeds for G1 and G2 by solving a
          set of simultaneous high-order nonlinear system of
          equations. This is an extremely hard problem that is not
          (as far as my literature search has taken me) amenable to
          solution at this time.

     In  order to make the problem slightly harder for the crypt-
     analyst, the key generation algorithm chosen will not use the
     sequence {K[i]} directly so as not to expose the actual values
     K[n], but will use K[n] as a starting point for another
     nonlinear combiner. Again, the algorithms have been adjusted
     to compensate for the limitations of the pocket calculator.

To generate a cryptographically (reasonably) secure sequence of
encryption keys using the modified LDE as the confusion generator,
proceed as follows:

1 -  Select two non-linear (LDE) confusion generators

               G1 = R * X * (1 - X),  and
               G2 = R'* Y* (1 - Y)

               where R' = 0.999 * R (used because of limitations in
                                   the number of memory registers
                                   in the pocket calculator)

2 -  The master cryptographic key (or seed) consists of the values

        R, X[0] and Y[0],  where

               0 < X[0] < 1   is a 9-digit key
               0 < Y[0] < 1   is a 9-digit key
               3.99 < R < 4.0 is a 7-digit key

     The total key length is 25 digits, giving a key space size of
     10^25.  The keys are short enough to be easily memorized.  (If
     you are not convinced of this assertion, consider how many
     phone numbers, PIN numbers, bank account numbers, etc that the
     average person routinely commits to memory)


3 -  Select a non-linear combiner for the output of two confusion
     generators.

          This is the first level of serious cryptographic
          strength.

     We will chose the function

          K = G1 <*> G2

          where <*> is the floating point multiplication operator
          with rounding (see Knuth, Seminumerical Algorithms for
          details).

4 -            To generate the Nth message key iterate the basic sequence
     generator N times. Then use the values K[N] ... to alter the
     generator parameters R, X and Y as follows:

               R <- 3.99 + (K[n]/100)
               X <- K'[n+1] where K'[i] <> K[i] because the
                              generating parameters are different
               Y <- K'[n+2]
               R <- 3,99 + (K'(n+3)/100)

5 -  The final resulting values <R,X,Y> become the cryptographic
     key for the Nth message being encrypted or decrypted and are
     used as described above for message encryption and decryption.
     Only the value N must be transmitted with the message, not the
     values of the message key <R,X,Y>, because the receiver can
     recreate the message key from N and the master key shared by
     the sender and receiver.

     The only additional requirement for security is that no key be
     reused. This is easy to implement by having the sender number
     the messages as they are encrypted. The receiver verifies that
     a message is valid by rejected any message where the message
     number N is less than the message number of the last message
     received. This will prevent replay attacks in the event that
     an opponent obtains a message key.

In summary, the steps for calculating the encryption key <R,X,Y>
for the Nth message are as follows:

          Repeat N times:
               X [i+1] = R * X[i] * (1 - X[i])
               Y [i+1] = .999 * R * Y[i] * (1 - Y[i])
               K [i+1] = X[i+1] * Y[i+1]
               {end repeat}

          R <- 3.99 + (K[N]/100)
             calculate K[N+1]
          X <- K'[N+1]
             calculate K'[N+2]
          Y <- K'[N+2]
             calculate K'[N+3]
          R <- 3.99 + (K'[N+3]/100)

     The message encryption key conists of the values <R,X,Y> at
     the conclusion of this calculation.


E:   Cryptographic Hardness

Key space searches:

     The key space size is ~ 10^25 (~ 2^80), which is too large for
     brute force search with currently available computing
     resources.
     Because the key values are random 9-digit numbers there is no
     possible dictionary attack.


Known Plaintext:

     A known plaintext attack will immediately give the cipher
     sequence {K'}. However, an absolute minimum of 3 sequential
     values of the sequence {K} are needed to derive the encryption
     key <R,X[0],Y[0]>. For the 2-digit sequence {K'} used in the
     substitution cipher, this requires checking the validity of
     the encryption keys derived from the (at least) 10^21 (2^70)
     possible triples {K1,K2,K3}. This is well beyond current
     computational capabilities.

     Since each key <R,X[0],Y[0]> is used only once, possession of
     the key for one message does not give the opponent any direct
     value in a known plaintext attack. To determine the key for
     subsequent messages, at least 3 successive keys must be
     accumulated in order for the cryptanalyst to attack the key
     management.

Chosen Plaintext:

     No advantage over known plaintext.

Key Management:

     Same problems (or worse) for the cryptanalyst as aKnown
     Plaintext attack.

Differential Cryptanalysis:

     I don't see that this is applicable because the key changes
     with each message.


F:   Message Encryption Example:

     Sample message to be enciphered

           "Now is the time for all good men to come to
           the aid of their party."

     Message buffer is padded with repeats of the message, but
     it would be better to pad with randomly chosen text.

     The encryption calculations were performed on a Radio Shack
     Model EC-4021 programmable scientific calculator.

           Image of Message Text Buffer

     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | N | O | W |   | I | S |   | T | H | E |
     +---+---+---+---+---+---+---+---+---+---+
1    |   | T | I | M | E |   | F | O | R |   |
     +---+---+---+---+---+---+---+---+---+---+
2    | A | L | L |   | G | O | O | D |   | M |
     +---+---+---+---+---+---+---+---+---+---+
3    | E | N |   | T | O |   | C | O | M | E |
     +---+---+---+---+---+---+---+---+---+---+
4    |   | T | O |   | T | H | E |   | A | I |
     +---+---+---+---+---+---+---+---+---+---+
5    | D |   | O | F |   | T | H | E | I | R |
     +---+---+---+---+---+---+---+---+---+---+
     |   | P | A | R | T | Y | . | N | O | W | <- Message ends at
     =========================================    this line
7    |   | I | S |   | T | H | E |   | T | I |
     +---+---+---+---+---+---+---+---+---+---+ Buffer is loaded with
8    | M | E |   | F | O | R |   | A | L | L | repeated copies of the
     +---+---+---+---+---+---+---+---+---+---+ message text
9    |   | G | O | O | D |   | M | E | N |   |
     +---+---+---+---+---+---+---+---+---+---+
10   | T | O |   | C | O | M | E |   | T | O |
     +---+---+---+---+---+---+---+---+---+---+
11   |   | T | H | E |   | A | I | D |   | O |
     +---+---+---+---+---+---+---+---+---+---+
12   | F |   | T | H | E | I | R |   | P | A |
     +---+---+---+---+---+---+---+---+---+---+
13   | R | T | Y | . | N | O | W |   | I | S |
     +---+---+---+---+---+---+---+---+---+---+
14   |   | T | H | E |   | T | I | M | E |   |
     +---+---+---+---+---+---+---+---+---+---+
15   | F | O | R |   | A | L | L |   | G | O |
     +---+---+---+---+---+---+---+---+---+---+
16   | O | D |   | M | E | N |   | T | O |   |
     +---+---+---+---+---+---+---+---+---+---+
17   | C | O | M | E |   | T | O |   | T | H |
     +---+---+---+---+---+---+---+---+---+---+
18   | E |   | A | I | D |   | O | F |   | T |
     +---+---+---+---+---+---+---+---+---+---+
19   | H | E | I | R |   | P | A | R | T | Y |
     +---+---+---+---+---+---+---+---+---+---+

============================================================

     Substitution Encipherment of Sample Text

     The Message Encryption Key 

            X[0] = 0.123456789     register K1
            R    = 3.995678901     register K2
            Y[0] = 0.234567891     register M

            Calculator set to No Rounding (2nd Fn - Tab - .)
                       ie, show all decimal digits

     Substitution Cipher Character Translation Table

            Sp 00   J  10     T  20
            A  01   K  11     U  21
            B  02   L  12     V  22
            C  03   M  13     W  23
            D  04   N  14     X  24
            E  05   O  15     Y  25
            F  06   P  16     Z  26
            G  07   Q  17     .  27
            H  08   R  18
            I  09   S  19      


      Plain Text converted to decimal representation

     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | 14| 15| 23| 00| 09| 19| 00| 20| 08| 05|
     +---+---+---+---+---+---+---+---+---+---+
1    | 00| 20| 09| 13| 05| 00| 06| 15| 18| 00|
     +---+---+---+---+---+---+---+---+---+---+
2    | 01| 12| 12| 00| 07| 15| 15| 04| 00| 13|
     +---+---+---+---+---+---+---+---+---+---+
3    | 05| 14| 00| 20| 15| 00| 03| 15| 13| 05|
     +---+---+---+---+---+---+---+---+---+---+
4    | 00| 20| 15| 00| 20| 08| 05| 00| 01| 09|
     +---+---+---+---+---+---+---+---+---+---+
5    | 04| 00| 15| 06| 00| 20| 08| 05| 09| 18|
     +---+---+---+---+---+---+---+---+---+---+
6    | 00| 16| 01| 18| 20| 25| 27| * |         <-  * := EOM
     +---+---+---+---+---+---+---+---+


     Cipher Text in decimal representation

     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | 03| 96| 69| 02| 83| 49| 28| 31| 22| 13|
     +---+---+---+---+---+---+---+---+---+---+
1    | 21| 63| 92| 03| 90| 45| 72| 08| 26| 34|
     +---+---+---+---+---+---+---+---+---+---+
2    | 15| 65| 62| 01| 34| 84| 50| 12| 62| 83|
     +---+---+---+---+---+---+---+---+---+---+
3    | 07| 41| 71| 33| 72| 64| 38| 96| 73| 25|
     +---+---+---+---+---+---+---+---+---+---+
4    | 16| 96| 06| 57| 93| 39| 8 | 47| 60| 96|
     +---+---+---+---+---+---+---+---+---+---+
5    | 29| 49| 88| 37| 39| 37| 61| 24| 68| 38|
     +---+---+---+---+---+---+---+---+---+---+
6    | 60| 90| 25| 96| 67| 84| 65| * |         <-  * := EOM
     +---+---+---+---+---+---+---+---+



============================================================


     Transposition Encrypted Message Text

     The Message Encryption Key 

          X[0] = 0.123456789       register K
          R    = 3.995678901       register K2
          Y[0] = 0.234567891       register M

          Set calculator rounding to 0 decimal digits
                  (2nd Fn - Tab - 0)

                  ie, show only integer portion of answer

            Encrypted message in blocks of 10 letters

                       |HO T NR IT||AM ES OWOT|
                       | FE D EMLD||IF LOG  M |
                       |HC ORN  AE||OIOTOE MEI|
                       |TFTN TA LO||TE APH. DR|
                       |OSC ITW IE||Y|*               <-* := EOM

     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | H | O |   | T |   | N | R |   | I | T |
     +---+---+---+---+---+---+---+---+---+---+
1    | A | M |   | E | S |   | O | W | O | T |
     +---+---+---+---+---+---+---+---+---+---+
2    |   | F | E |   | D |   | E | M | L | D |
     +---+---+---+---+---+---+---+---+---+---+
3    | I | F |   | L | O | G |   |   | M |   |
     +---+---+---+---+---+---+---+---+---+---+
4    | H | C |   | O | R | N |   |   | A | E |
     +---+---+---+---+---+---+---+---+---+---+
5    | O | I | O | T | O | E |   | M | E | I |
     +---+---+---+---+---+---+---+---+---+---+
6    | T | F | T | N |   | T | A |   | L | O |
     +---+---+---+---+---+---+---+---+---+---+
7    | T | E |   | A | P | H | . |   | D | R |
     +---+---+---+---+---+---+---+---+---+---+
8    | O | S | C |   | I | T | W |   | I | E |
     +---+---+---+---+---+---+---+---+---+---+
9    | Y | * |                                 <- * := EOM
     +---+---+
 

============================================================


            Decrypted Transposition Message

     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | N | O | W |   | I | S |   | T | H | E |
     +---+---+---+---+---+---+---+---+---+---+
1    |   | T | I | M | E |   | F | O | R |   |
     +---+---+---+---+---+---+---+---+---+---+
2    | A | L | L |   | G | O | O | D |   | M |
     +---+---+---+---+---+---+---+---+---+---+
3    | E | N |   | T | O |   | C | O | M | E |
     +---+---+---+---+---+---+---+---+---+---+
4    |   | T | O |   | T | H | E |   | A | I |
     +---+---+---+---+---+---+---+---+---+---+
5    | D |   | O | F |   | T | H | E | I | R |
     +---+---+---+---+---+---+---+---+---+---+
6    |   | P | A | R | T | Y*| . | N | O | W | * := Last char
     +---+---+---+---+---+---+---+---+---+---+                received
7    |   | I | S |   |           |   | T | I |
     +---+---+---+---+           +---+---+---+    all partially
8    | M | E |   | F |           | A | L |         filled rows 
     +---+---+   +---+           +---+---+         after the row 
9    |   |       | O |           | E |                           with the last
     +---+       +---+           +---+                           char received
10   | T |       | C |           |   |                           are discarded
     +---+       +---+           +---+
11   |   |                       | D |
     +---+                       +---+
12                               |   | 
                                 +---+

     The actual shape of any particular received message block will
     vary randomly with the key and the length of the message
     transmitted.  


============================================================



     Transposition column selection table

     The Message Encryption Key 

          X[0] = 0.123456789       register K1
          R    = 3.995678901       register K2
          Y[0] = 0.234567891       register M

          Set calculator rounding to 0 decimal digits
               (2nd Fn - Tab - 0)

               ie, show only integer portion of answer


     =========================================
     : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 :
     =========================================
0    | 9 | 2 | 7 | 2 | 4 | 1 | 9 | 1 | 5 | 8 |
     +---+---+---+---+---+---+---+---+---+---+
1    | 1 | 4 | 4 | 1 | 6 | 6 | 6 | 3 | 8 | 4 |
     +---+---+---+---+---+---+---+---+---+---+
2    | 4 | 4 | 0 | 1 | 8 | 9 | 5 | 9 | 2 | 1 |
     +---+---+---+---+---+---+---+---+---+---+
3    | 3 | 7 | 1 | 3 | 7 | 5 | 6 | 1 | 1 | 0 |
     +---+---+---+---+---+---+---+---+---+---+
4    | 6 | 7 | 1 | 8 | 4 | 2 | 3 | 8 | 9 | 8 |
     +---+---+---+---+---+---+---+---+---+---+
5    | 5 | 9 | 3 | 2 | 9 | 7 | 4 | 0 | 0 | 0 |
     +---+---+---+---+---+---+---+---+---+---+
6    | 1 | 4 | 5 | 8 | 8 | 9 | 8 | 2 | 9 | 3 |
     +---+---+---+---+---+---+---+---+---+---+
7    | 6 | 8 | 5 | 3 | 2 | 7 | 7 | 8 | 8 | 0 |
     +---+---+---+---+---+---+---+---+---+---+
8    | 4 | 3 | 4 | 1 | 2 | 5 | 0 | 8 | 0 | 2 |
     +---+---+---+---+---+---+---+---+---+---+
9    | 6 | 7 | 2 | 1 | 1 | 2 | 6 | 4 | 1 | 3 |
     +---+---+---+---+---+---+---+---+---+---+
10   | 2 | 6 | 6 | 1 | 8 | 9 | 5 | 1 | 2 | 8 |
     +---+---+---+---+---+---+---+---+---+---+



G:   Sample Message Key Generation


     The Master Encryption Key 

            X[0] = 0.567890123     register K1
            R    = 3.998901234     register K2
            Y[0] = 0.345678912     register M

            Calculator set to No Rounding (2nd Fn - Tab - .)
                       ie, show all decimal digits

     Calculate the Message Encryption Key for the 5th message

         Repeat calculation of K[i] 5 times
                K[1] = 0.886684581
                K[2] = 0.025546435
                K[3] = 0.246545962
                K[4] = 0.268216342
                K[5] = 0.589846665

          R <- 3.99 + (K[5]/100) = 3.995898467
                K'[6] = 0.337260078
          X <- K'[6] = 0.337260078
                K'[7] = 0.83623299
          Y <- K'[7] = 0.83623299
                K'[8] = 0.208478335
          R <- 3.99 + (K'[8]/100) = 3.992084783

     The resulting Message Encryption Key for message #5 is:

          X[0] = 0.381353099       register K1
          R    = 3.992084783       register K2
          Y[0] = 0.546680583       register M





From sameer at soda.berkeley.edu  Fri Feb  4 09:45:09 1994
From: sameer at soda.berkeley.edu (Sameer)
Date: Fri, 4 Feb 94 09:45:09 PST
Subject: removing a key from the keyserver. (eeps)
Message-ID: <m0pSUV3-00011WC@infinity.hip.berkeley.edu>


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

	I seem to have a bit of a problem--

	There's about 4 different public keys with my name on them,
and I only use of them these days. I don't have the secret keys for
the unused keys-- they've been retired to the great bit bit bucket in
the sky..
	Is there some way I can get these keys off the servers?


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVKIAni7eNFdXppdAQGhcwQAgzqGzRmirI/7hfkcZj1UzXdloM1PjWw1
M+GbREctd4pkUTTZNQQI15bOFf7OQRNvE3/Yi7HqlqNlEbXGjS/RYG262SX+zi+5
QLF8fs2kzQc5gH/CRQUHMhnr8tceokhFzTU1sF2yDRb/h+5hJbFG4cTYv+W0A0se
IDCzSfgBa00=
=UDOy
-----END PGP SIGNATURE-----




From blake.coverett at canrem.com  Fri Feb  4 09:55:09 1994
From: blake.coverett at canrem.com (Blake Coverett)
Date: Fri, 4 Feb 94 09:55:09 PST
Subject: San Jose BBS subject to M
In-Reply-To: <199402032112.NAA26624@jobe.shell.portal.com>
Message-ID: <60.2831.6525.0C1938ED@canrem.com>


> This is one of the best essays I've seen concerning the burning of the
> Constitution and Bill of Rights. Looking just at porno isn't the big
> picture. It's consensual crimes in general. Too bad most people only
> care about their corner of the room, cause the house is on fire and
> it'll get to their corner soon.

Hmm... wish I had the exact original handy to mis-quote,

They came for the drug dealers, 
    but I wasn't a drug dealer so I said nothing
They came for the pornographers,
    but I wasn't a pornographer so I said nothing
They came for the gamblers,
    but I wasn't a gambler so I said nothing
Then they came for me,
    but there was no one left to say a thing


-Blake (who is feeling very cynical about life in general)  
...
 * ATP/DJgcc 1.42 * blake.coverett at canrem.com, disclaimers? fooey!






From PURTEB at vaxc.hofstra.edu  Fri Feb  4 09:59:51 1994
From: PURTEB at vaxc.hofstra.edu (PURTEB at vaxc.hofstra.edu)
Date: Fri, 4 Feb 94 09:59:51 PST
Subject: Information
Message-ID: <01H8HL3EC4ZS94EJ83@vaxc.hofstra.edu>


To Whom It May Concern:

I'd like some information/literature on you cryptography software.  My 
friend, Brian, is the one who is actually interested, so please send
any info to:

                          BRIAN T.L. STRAUSS
                          357 Doris Avenue
                          Franklin Square, NY  11010

Or, if necessary, you may email any info to the vax account listed at
the bottom of this letter.

Thank you.

Theresa Barley


_______________________________________________________________________________
Theresa Barley                       
Hofstra University                      "Only visiting this planet."
Purchasing Department

purteb at vaxc.hofstra.edu





From wex at media.mit.edu  Fri Feb  4 10:29:52 1994
From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat)
Date: Fri, 4 Feb 94 10:29:52 PST
Subject: CERT advisory
Message-ID: <9402041825.AA27913@media.mit.edu>


[Some items of interest to C-punks include CERT's advocacy of stopping
cleartext transmission of password (no shit sherlock), and their proposed
solutions, including the use of one-time passwords which I had queried about
on this list a few months back.  Of course they don't mention any sort of
real encryption, let alone PGP.  How hard would it be to build in PGP
security to the transmission layer of something like FTP?  Seems like a
fairly simple problem, given that any site which supports anonymous FTP can
publish a public key.  Even if we assume that encryption would slow down the
file transmission too much, we could still use it for the
login/authentication part of the session...  --AW]

Begin forwarded message:

From: CERT Advisory <cert-advisory-request at cert.org>
Date: Thu, 3 Feb 94 21:14:40 EST
To: cert-advisory at cert.org
Subject: CERT Advisory - Ongoing Network Monitoring Attacks
Organization: Computer Emergency Response Team : 412-268-7090

=============================================================================
CA-94:01                         CERT Advisory
                               February 3, 1994
                      Ongoing Network Monitoring Attacks
-----------------------------------------------------------------------------
                                   

In the past week, CERT has observed a dramatic increase in reports of
intruders monitoring network traffic.  Systems of some service
providers have been compromised, and all systems that offer remote
access through rlogin, telnet, and FTP are at risk.  Intruders have
already captured access information for tens of thousands of systems
across the Internet.

The current attacks involve a network monitoring tool that uses the
promiscuous mode of a specific network interface, /dev/nit, to capture
host and user authentication information on all newly opened FTP,
telnet, and rlogin sessions.

In the short-term, CERT recommends that all users on sites that offer
remote access change passwords on any network-accessed account. In
addition, all sites having systems that support the /dev/nit interface
should disable this feature if it is not used and attempt to prevent
unauthorized access if the feature is necessary. A procedure for
accomplishing this is described in Section III.B.2 below.  Systems
known to support the interface are SunOS 4.x (Sun3 and Sun4
architectures) and Solbourne systems; there may be others. Sun Solaris
systems do not support the /dev/nit interface. If you have a system
other than Sun or Solbourne, contact your vendor to find if this
interface is supported.

While the current attack is specific to /dev/nit, the short-term
workaround does not constitute a solution.  The best long-term
solution currently available for this attack is to reduce or eliminate
the transmission of reusable passwords in clear-text over the network.


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

I.   Description

     Root-compromised systems that support a promiscuous network
     interface are being used by intruders to collect host and user
     authentication information visible on the network.

     The intruders first penetrate a system and gain root access
     through an unpatched vulnerability (solutions and workarounds for
     these vulnerabilities have been described in previous CERT
     advisories, which are available anonymous FTP from
     info.cert.org).  


     The intruders then run a network monitoring tool that captures up
     to the first 128 keystrokes of all newly opened FTP, telnet, and
     rlogin sessions visible within the compromised system's domain.
     These keystrokes usually contain host, account, and password
     information for user accounts on other systems; the intruders log
     these for later retrieval.  The intruders typically install
     Trojan horse programs to support subsequent access to the
     compromised system and to hide their network monitoring process.

II.  Impact

     All connected network sites that use the network to access remote
     systems are at risk from this attack.
     

     All user account and password information derived from FTP,
     telnet, and rlogin sessions and passing through the same network
     as the compromised host could be disclosed.


III. Approach

     There are three steps in CERT's recommended approach to the
     problem:

     - Detect if the network monitoring tool is running on any of your
       hosts that support a promiscuous network interface.

     - Protect against this attack either by disabling the network
       interface for those systems that do not use this feature or by
       attempting to prevent unauthorized use of the feature on systems
       where this interface is necessary.

     - Scope the extent of the attack and recover in the event that
       the network monitoring tool is discovered.


     A.  Detection

         The network monitoring tool can be run under a variety of
         process names and log to a variety of filenames.  Thus, the
         best method for detecting the tool is to look for 1) Trojan
         horse programs commonly used in conjunction with this attack,
         2) any suspect processes running on the system, and 3) the
         unauthorized use of /dev/nit.

         1) Trojan horse programs: 


         The intruders have been found to replace one or more of the
         following programs with a Trojan horse version in conjunction
         with this attack:

           /usr/etc/in.telnetd 

           and /bin/login -  Used to provide back-door access for the
                             intruders to retrieve information
           /bin/ps  - Used to disguise the network monitoring process
           

         Because the intruders install Trojan horse variations of
         standard UNIX commands, CERT recommends not using other
         commands such as the standard UNIX sum(1) or cmp(1) commands
         to locate the Trojan horse programs on the system until these
         programs can be restored from distribution media, run from
         read-only media (such as a mounted CD-ROM), or verified using
         cryptographic checksum information.
         

         In addition to the possibility of having the checksum
         programs replaced by the intruders, the Trojan horse programs
         mentioned above may have been engineered to produce the same
         standard checksum and timestamp as the legitimate version.
         Because of this, the standard UNIX sum(1) command and the
         timestamps associated with the programs are not sufficient to
         determine whether the programs have been replaced.

         CERT recommends that you use both the /usr/5bin/sum and
         /bin/sum commands to compare against the distribution media
         and assure that the programs have not been replaced.  The use
         of cmp(1), MD5, Tripwire (only if the baseline checksums were
         created on a distribution system), and other cryptographic
         checksum tools are also sufficient to detect these Trojan
         horse programs, provided these programs were not available
         for modification by the intruder.  If the distribution is
         available on CD-ROM or other read-only device, it may be
         possible to compare against these volumes or run programs off
         these media.

         2) Suspect processes: 


         Although the name of the network monitoring tool can vary
         from attack to attack, it is possible to detect a suspect
         process running as root using ps(1) or other process-listing
         commands.  Until the ps(1) command has been verified against
         distribution media, it should not be relied upon--a Trojan
         horse version is being used by the intruders to hide the
         monitoring process.  Some process names that have been
         observed are sendmail, es, and in.netd.  The arguments to the
         process also provide an indication of where the log file is
         located.  If the "-F" flag is set on the process, the
         filename following indicates the location of the log file
         used for the collection of authentication information for
         later retrieval by the intruders.

         3) Unauthorized use of /dev/nit:

         If the network monitoring tool is currently running on your
         system, it is possible to detect this by checking for
         unauthorized use of the /dev/nit interface.  CERT has created
         a minimal tool for this purpose.  The source code for this
         tool is available via anonymous FTP on info.cert.org in the
         /pub/tools/cpm directory or on ftp.uu.net in the 

         /pub/security/cpm directory as cpm.1.0.tar.Z.  The checksum
         information is:

         Filename                Standard UNIX Sum         System V Sum
        --------------           -----------------         ------------
         cpm.1.0.tar.Z:               11097 6                 24453 12 


         MD5 Checksum
         MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155

         This archive contains a readme file, also included as
         Appendix C of this advisory, containing instructions on
         installing and using this detection tool.

     B.  Prevention

         There are two actions that are effective in preventing this
         attack.  A long-term solution requires eliminating
         transmission of clear-text passwords on the network.  For
         this specific attack, however, a short-term workaround
         exists.  Both of these are described below.

         1) Long-term prevention:

         CERT recognizes that the only effective long-term solution to
         prevent these attacks is by not transmitting reusable
         clear-text passwords on the network.  CERT has collected some
         information on relevant technologies.  This information is
         included as Appendix B in this advisory.  Note: These
         solutions will not protect against transient or remote access
         transmission of clear-text passwords through the network.

         Until everyone connected to your network is using the above
         technologies, your policy should allow only authorized users
         and programs access to promiscuous network interfaces.  The
         tool described in Section III.A.3 above may be helpful in
         verifying this restricted access.

         2) Short-term workaround:

         Regardless of whether the network monitoring software is
         detected on your system, CERT recommends that ALL SITES take
         action to prevent unauthorized network monitoring on their
         systems. You can do this either by removing the interface, if
         it is not used on the system or by attempting to prevent the
         misuse of this interface.

         For systems other than Sun and Solbourne, contact your vendor
         to find out if promiscuous mode network access is supported
         and, if so, what is the recommended method to disable or
         monitor this feature.

         For SunOS 4.x and Solbourne systems, the promiscuous
         interface to the network can be eliminated by removing the
         /dev/nit capability from the kernel.  The procedure for doing
         so is outlined below (see your system manuals for more
         details).  Once the procedure is complete, you may remove the
         device file /dev/nit since it is no longer functional.

         Procedure for removing /dev/nit from the kernel:

         1. Become root on the system. 


         2. Apply "method 1" as outlined in the System and Network
         Administration manual, in the section, "Sun System
         Administration Procedures," Chapter 9, "Reconfiguring the
         System Kernel."  Excerpts from the method are reproduced
         below:

         # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
         # cp CONFIG_FILE SYS_NAME  


         [Note that at this step, you should replace the CONFIG_FILE
         with your system specific configuration file if one exists.]

         # chmod +w SYS_NAME
         # vi SYS_NAME

            #
            # The following are for streams NIT support.  NIT is used by
            # etherfind, traffic, rarpd, and ndbootd.  As a rule of thumb,
            # NIT is almost always needed on a server and almost never
            # needed on a diskless client.
            #
            pseudo-device   snit            # streams NIT
            pseudo-device   pf              # packet filter
            pseudo-device   nbuf            # NIT buffering module
         

         [Comment out the preceding three lines; save and exit the
         editor before proceeding.]

         # config SYS_NAME
         # cd ../SYS_NAME
         # make

         # mv /vmunix /vmunix.old
         # cp vmunix /vmunix

         # /etc/halt
         > b

         [This step will reboot the system with the new kernel.]

         [NOTE that even after the new kernel is installed, you need
         to take care to ensure that the previous vmunix.old , or
         other kernel, is not used to reboot the system.]


     C.  Scope and recovery

         If you detect the network monitoring software at your site,
         CERT recommends following three steps to successfully
         determine the scope of the problem and to recover from this
         attack.

         1. Restore the system that was subjected to the network
         monitoring software.

         The systems on which the network monitoring and/or Trojan
         horse programs are found have been compromised at the root
         level; your system configuration may have been altered.  See
         Appendix A of this advisory for help with recovery.

         2. Consider changing router, server, and privileged account
         passwords due to the wide-spread nature of these attacks.
         

         Since this threat involves monitoring remote connections,
         take care to change these passwords using some mechanism
         other than remote telnet, rlogin, or FTP access.

         3. Urge users to change passwords on local and remote
         accounts.

         Users who access accounts using telnet, rlogin, or FTP either
         to or from systems within the compromised domain should
         change their passwords after the intruder's network monitor
         has been disabled.
         

         4. Notify remote sites connected from or through the local
         domain of the network compromise.

         Encourage the remote sites to check their systems for
         unauthorized activity.  Be aware that if your site routes
         network traffic between external domains, both of these
         domains may have been compromised by the network monitoring
         software.


---------------------------------------------------------------------------
The CERT Coordination Center thanks the members of the FIRST community
as well as the many technical experts around the Internet who
participated in creating this advisory.  Special thanks to Eugene
Spafford of Purdue University for his contributions.
---------------------------------------------------------------------------

 If you believe that your system has been compromised, contact the CERT
 Coordination Center or your representative in Forum of Incident
 Response and Security Teams (FIRST).

 Internet E-mail: cert at cert.org
 Telephone: 412-268-7090 (24-hour hotline)
            CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
            and are on call for emergencies during other hours.

 CERT Coordination Center
 Software Engineering Institute
 Carnegie Mellon University
 Pittsburgh, PA 15213-3890

 Past advisories, information about FIRST representatives, and other
 information related to computer security are available for anonymous 

 FTP from info.cert.org.

 ---------------------------------------------------------------------------
 Appendix A:  

                    RECOVERING FROM A UNIX ROOT COMPROMISE

A.   Immediate recovery technique

        1) Disconnect from the network or operate the system in
           single- user mode during the recovery.  This will keep users
           and intruders from accessing the system.

        2) Verify system binaries and configuration files against the
           vendor's media (do not rely on timestamp information to
           provide an indication of modification).  Do not trust any
           verification tool such as cmp(1) located on the compromised
           system as it, too, may have been modified by the intruder.
           In addition, do not trust the results of the standard UNIX
           sum(1) program as we have seen intruders modify system
           files in such a way that the checksums remain the same.
           Replace any modified files from the vendor's media, not
           from backups.

                                -- or --

           Reload your system from the vendor's media.

        3) Search the system for new or modified setuid root files.

                find / -user root -perm -4000 -print

           If you are using NFS or AFS file systems, use ncheck to
           search the local file systems.

                ncheck -s /dev/sd0a

        4) Change the password on all accounts.

        5) Don't trust your backups for reloading any file used by
           root.  You do not want to re-introduce files altered by an
           intruder.


B.   Improving the security of your system

        1) CERT Security Checklist
           Using the checklist will help you identify security
           weaknesses or modifications to your systems.  The CERT
           Security Checklist is based on information gained from
           computer security incidents reported to CERT. It is
           available via anonymous FTP from info.cert.org in the file
           pub/tech_tips/security_info.
        

        2) Security Tools
           Use security tools such as COPS and Tripwire to check for
           security configuration weaknesses and for modifications
           made by intruders.  We suggest storing these security
           tools, their configuration files, and databases offline or
           encrypted.  TCP daemon wrapper programs provide additional
           logging and access control.  These tools are available via
           anonymous FTP from info.cert.org in the pub/tools
           directory.

        3) CERT Advisories
           Review past CERT advisories (both vendor-specific and
           generic) and install all appropriate patches or workarounds
           as described in the advisories.  CERT advisories and other
           security-related information are available via anonymous
           FTP from info.cert.org in the pub/cert_advisories
           directory.

           To join the CERT Advisory mailing list, send a request to:

                        cert-advisory-request at cert.org

           Please include contact information, including a telephone number.

        


CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Copyright (c) Carnegie Mellon University 1994




---------------------------------------------------------------------------
Appendix B:  

                         ONE-TIME PASSWORDS

Given today's networked environments, CERT recommends that sites
concerned about the security and integrity of their systems and
networks consider moving away from standard, reusable passwords. CERT
has seen many incidents involving Trojan network programs (e.g.,
telnet and rlogin) and network packet sniffing programs.  These
programs capture clear-text hostname, account name, password triplets.
Intruders can use the captured information for subsequent access to
those hosts and accounts.  This is possible because 1) the password is
used over and over (hence the term "reusable"), and 2) the password
passes across the network in clear text.

Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). This document provides a list of sources
for products that provide this capability. The decision to use a
product is the responsibility of each organization, and each
organization should perform its own evaluation and selection.

I.  Public Domain packages

S/KEY(TM)
        The S/KEY package is publicly available (no fee) via
        anonymous FTP from:

                thumper.bellcore.com            /pub/nmh directory

        There are three subdirectories:

                skey            UNIX code and documents on S/KEY.
                                Includes the change needed to login,
                                and stand-alone commands (such as "key"),
                                that computes the one-time password for
                                the user, given the secret password and
                                the S/KEY command.

                dos             DOS or DOS/WINDOWS S/KEY programs.  Includes
                                DOS version of "key" and "termkey" which is
                                a TSR program.
                

                mac             One-time password calculation utility for 

                                the Mac.


II.  Commercial Products

Secure Net Key (SNK)                            (Do-it-yourself project)
        Digital Pathways, Inc.
        201 Ravendale Dr.
        Mountainview, Ca. 94043-5216
        USA
        Phone: 415-964-0707 

        Fax: (415) 961-7487

                Products:
                        handheld authentication calculators  (SNK004)
                        serial line auth interruptors (guardian)

        Note: Secure Net Key (SNK) is des-based, and therefore restricted
        from US export.

Secure ID                                       (complete turnkey systems)
        Security Dynamics
        One Alewife Center
        Cambridge, MA   02140-2312
        USA
        Phone: 617-547-7820
        Fax: (617) 354-8836

                 Products:
                        SecurID changing number authentication card
                        ACE server software

        SecureID is time-synchronized using a 'proprietary' number 

        generation algorithm

WatchWord and WatchWord II
        Racal-Guardata 

        480 Spring Park Place
        Herndon, VA 22070
        703-471-0892
        1-800-521-6261 ext 217

                 Products:
                        Watchword authentication calculator
                        Encrypting modems

        Alpha-numeric keypad, digital signature capability

SafeWord 

        Enigma Logic, Inc. 

        2151 Salvio #301   

        Concord, CA 94520  

        510-827-5707
        Fax: (510)827-2593

                Products:
                        DES Silver card authentication calculator
                        SafeWord Multisync card authentication calculator

        Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as
        other OS versions.  Supports one-time passwords and super
        smartcards from several vendors.





---------------------------------------------------------------------------
Appendix C:  

                         cpm 1.0 README FILE


       cpm -  check for network interfaces in promiscuous mode.

Copyright (c) Carnegie Mellon University 1994
Thursday Feb 3 1994

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890


   This program is free software; you can distribute it and/or modify
   it as long as you retain the Carnegie Mellon copyright statement.

   It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z.

   This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED
   WARRANTY of merchantability or fitness for a particular purpose.

   This package contains:
       README
       MANIFEST
       cpm.1
       cpm.c

   To create cpm under SunOS, type:
   % cc -Bstatic -o cpm cpm.c 


   On machines that support dynamic loading, such as Sun's, CERT recommends
   that programs be statically linked so that this feature is disabled.

   CERT recommends that after you install cpm in your favorite directory,
   you take measures to ensure the integrity of the program by noting
   the size and checksums of the source code and resulting binary.


   The following is an example of the output of cpm and its exit status.

   Running cpm on a machine where both the le0 and le2 interfaces are
   in promiscuous mode, under csh(1):

   % cpm
   le0
   le2
   % echo $status
   2
   %

   Running cpm on a machine where no interfaces are in promiscuous 

   mode, under csh(1):

   % cpm
   % echo $status
   0
   %








From edgar at spectrx.saigon.com  Fri Feb  4 10:35:10 1994
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Fri, 4 Feb 94 10:35:10 PST
Subject: Announcing SecureDrive 1.3A
Message-ID: <e2H9gc11w165w@spectrx.saigon.com>


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

This is to announce the availability of Version 1.3A of SecureDrive.

This is a maintenance release of SecureDrive 1.3.  It mainly fixes
reported problems and has minimal new function.  See file BUGS13.DOC.
The only visible functional change from 1.3 is the appearance of
msg

   Check bytes in Disk x: Boot Sector need updating from 1.3 to
   1.1/1.3A. Proceed?

which will be issued by both LOGIN and CRYPTDSK when they attempt to
verify a passphrase on a hard disk or diskette encrypted by version
1.3 CRYPTDSK operating in version 1.1 compatability mode.  This
corrects the error in computing the check bytes used to verify the
passphrase and updates the check bytes to the correct 1.1 value and
WRITES back the boot sector. Note that once this update has taken
place, this disk cannot be decrypted by release 1.3 anymore.

Releases 1.3 and 1.3A of Secure Drive are based on releases 1.0 and
1.1, mostly written by

  Mike Ingle <mikeingle at delphi.com>

and version 1.2, with significant new code by myself.

The code which we wrote is not copyrighted, but the program contains GNU
Copylefted code, and therefore may be freely distributed under the terms of
the GNU General Public Licence. See file COPYING for legalese.

Version 1.2 and 1.3 add significant new function.

As of Version 1.2, you may use an operand /PGP with LOGIN, either
by itself, or with other operands. By itself,

  LOGIN /PGP

will prompt for a passphrase and set the PGPPASS environment variable with
whatever is entered. If PGPPASS is already set then

  LOGIN D: /PGP

or

  LOGIN /F /PGP

will use whatever PGPPASS is set to as the passphrase. For the hard
disk partition, LOGIN will test the PGPPASS passphrase. If it is incorrect,
then it will prompt you for another passphrase.

If PGPPASS is NOT set when these forms of LOGIN are used, than a passphrase
is prompted for AND PGPPASS is set to this passphrase. This is more
secure than using the SET command since LOGIN only echoes "*"'s when
entering the passphrase.

As of Version 1.2, typing LOGIN /C /PGP will clear the SecureDrive crypto
keys from memory AND clear the PGPPASS environment variable. This is done
in a manner less likely to leave your passphrase in memory than just using
the DOS SET command.  In addition, Version 1.2 clears all the free memory
it can find, which is likely to include some plaintext.  However, if you
want to be absolutely sure all traces of sensitive data are erased from
memory then turning off the computer is still recommended.

As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK
will ask to use the value of PGPPASS for the passphrase before
prompting you (for encryption), or try PGPPASS (for decryption).
Obviously, if you encrypt or decrypt a lot of diskettes at once, this
feature can save you a lot of typing.

The purpose of these changes is to allow you to enter a single passphrase
only once per boot IF you choose to use the same passphrase for your PGP
secret key, your SecureDrive encrypted hard disk partition, and SecureDrive
encrypted floppies.

Version 1.3 supports up to four hard drive partitions in "safe" mode,
only one of which may be active at any given time.  One purpose of
having multiple encrypted hard disk partitions is so that up to four
users (perhaps members of a family) can each have their own encrypted
partition with its own unique passphrase.  This allows up to four
users to have privacy from each other, even if they all use the same
PC and physical hard disk(s).

Version 1.3 gives you a choice of whether to use the version 1.1
passphrase digest or to use the (faster but perhaps slightly less
secure) 1.0 version.  If you select 1.0 compatiblity, it's unnecessary
to decrypt and re-encrypt your 1.0-encrypted hard disk partition(s)
and floppies.

If you decide to switch to 1.1 passphrases, Version 1.3 CRYPTDSK will
allow you to convert in one pass with no plaintext stored on disk.

Version 1.3 includes the 1.2 changes for using PGPPASS. There are
additional ehhancements to allow you to use the hard disk passphrase
for the floppy disks without typing it in, even if PGPPASS is not set
or is something different.

Version 1.3 CRYPTDSK will operate on hard drives with SECTSR loaded.
It uses SECTSR to protect the disk during conversion and will leave an
encrypted disk partition in protected mode.

Mike Ingle and I have different opinions on the distribution of
SecureDrive.  Under the GNU General License (copyleft) I do not need
Mike's permission to distribute version 1.3 and I have not asked for
same.  My policy on distribution is in the version 1.3 doc:

    Exporting this program.  Cryptography is export controlled, and
    sending this program outside the country may be illegal.  Don't do
    it.

    The "author" of versions 1.2 and 1.3, Edgar Swank, says that the
    export ban should not prevent you from placing this program on
    public BBS's and anonymous FTP sites in the US and Canada.  If
    individuals outside the US/Canada use the internet or
    international long distance to obtain copies of the program, THEY
    may be breaking US law.

    Any such foreign individuals should be aware that US law
    enforcement may legally (under US law) apprehend individuals who
    break US laws even if such individuals are not on or even have
    never been on US soil.  Such apprehension may remove such
    individuals directly to US jurisdiction without benefit of
    extradition proceedings in such individuals' home country(ies).
    This has actually happened in at least two cases, Mexico --
    suspect in murder of US drug agent, Panama -- Noriega -- indicted
    in absencia for drug smuggling.  As is well known, after a small
    war with Panama, Noriega was brought to the USA, tried and
    convicted.  He is now a guest of the US Government in a Florida
    prison.

SecureDrive Version 1.3A is already available for download on the
following public BBS's as SECDR13A.ZIP:

  Eagle's Nest         (408)223-9821
  Flying Dutchman      (408)294-3065

Also I have a report (unverified so far) that Version 1.3 may now
be obtained from a mailserver. Send mail to

Server at Star.Hou.TX.US

with body text that looks like this

get /files/public/secdr13a.zip
quit

Please attempt to use the mailserver or the two BBS's above before
requesting a copy directly from me.

I will send a FEW more copies via E-mail to persons with a US/Canada
net address who request a copy AND promise to upload it to a
USA/Canada e-mail fileserver or anonymous FTP site.  (I don't have
access to FTP from my account here).

I will announce here as I learn of Version 1.3A availability via
additional automated e-mail or FTP sites.

Here is the contents of SECDR13A.ZIP:

 Length  Method   Size  Ratio   Date    Time    CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   -------- ----  ----
  18321  DeflatX   6914  63%  06-14-93  22:27  0767480b --w-  COPYING
   1332  DeflatX    518  62%  01-30-94  09:30  bbb5655c --w-  MAKEFILE
   1632  DeflatX   1260  23%  12-04-93  00:43  980125ec --w-  KEY.ASC
  19664  DeflatX   4183  79%  11-19-93  21:42  22c2502c --w-  CRYPT2.ASM
   1355  DeflatX    629  54%  01-21-94  08:44  db63ade4 --w-  RLDBIOS.ASM
  24652  DeflatX   7740  69%  01-29-94  14:51  d0f5feaf --w-  SECTSR.ASM
   7507  DeflatX   2581  66%  12-29-93  21:15  ceda9b20 --w-  SETENV.ASM
     33  Stored      33   0%  07-16-93  06:09  aa6151a5 --w-  M.BAT
  16175  DeflatX   3949  76%  01-29-94  17:57  88215957 --w-  CRYPTDSK.C
  12260  DeflatX   3167  75%  01-29-94  18:27  7b10d96f --w-  LOGIN.C
  11557  DeflatX   3277  72%  05-09-93  19:38  e71f3eea --w-  MD5.C
  10860  DeflatX   2878  74%  01-29-94  18:07  3a9154c0 --w-  SDCOMMON.C
   1778  DeflatX   1160  35%  01-30-94  09:31  48688ff7 --w-  SECTSR.COM
   1152  DeflatX    586  50%  01-30-94  10:15  e44c593f --w-  BUGS13.DOC
  31425  DeflatX  10610  67%  01-30-94  09:59  235f457a --w-  SECDRV.DOC
  35024  DeflatX  16598  53%  01-30-94  09:31  99417b77 --w-  CRYPTDSK.EXE
  34072  DeflatX  16021  53%  01-30-94  09:31  26a2fb82 --w-  LOGIN.EXE
   3407  DeflatX   1097  68%  05-11-93  12:49  f1f58517 --w-  MD5.H
   3020  DeflatX    909  70%  01-24-94  03:32  8ee1c1f6 --w-  SECDRV.H
   1254  DeflatX    541  57%  05-09-93  19:39  182978aa --w-  USUALS.H
    152  Stored     152   0%  01-30-94  10:03  68a2560c --w-  SECTSR.SIG
    152  Stored     152   0%  01-30-94  10:04  a1d33655 --w-  LOGIN.SIG
    152  Stored     152   0%  01-30-94  10:04  845de45f --w-  CRYPTDSK.SIG
 ------          ------  ---                                  -------
 236936           85107  65%                                       23


Also note that the ZIP file contains PGP detached signatures (*.SIG)
for the executable files.  Finally here is my public key, also
available on many public keyservers; note who has signed it.

Type bits/keyID   Date       User ID
pub  1024/87C0C7 1992/10/17  Edgar W. Swank <edgar at spectrx.saigon.com>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf
9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2
hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR
tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF
ECwAALo04ip/MkW/XQEBmNQD/0jUVqT0LMoVvw7Zz2FXyWrdBn6bRlyGxeqQWhig
DXRipZ824/fHbA2vkbAczEayw8ZpwRVmhWNsxxWhjYFIi92KYJbAP/XIbr+rEuTI
hPKKKKhuuGLUWhfXhCFluHjs3CA6ZQwnT4jnu1NlCkcnWLbL4ktqub2zLwrHCPUe
31L1iQCUAgUQK9Y50xgzoWUItwfFAQHPrAPzBbf6lQyzwbUwdxayzLDoh3Hygnun
Looi+yzziEVQchOgSt3sLe2I108DLxTgp+26lJYTAZB+Gg8HGyB+Nz6263D0XlVU
XQi9/7CSRyd8bhYFeuFPwFzHPWZlyLDAIsuaEfBsmp2DBLgffvhUCqiiWYmP9oa+
rOA+5IHS+xN8tIkAVQIFECu5dYOzvL/Jh3qmYQEBYDICAI5KdaTiPr2Y1OtRCTi6
xMG6hnRNalvK9C5d/bxrKnUYqsfSpKayX+Ts9psmq6a6doOrX3AAtgcZuTCYUfQk
d22JAJUCBRArlzITocE4X0qvAOUBAahdA/4rRoSVp3G+Ki0wvkcAvpnwt7vSEYpH
XSkyoC8LdAqs9bft5NDTOykgw5H1qFG1Doqk6oR0yxY0k91eVoBVclLWDb94sNO3
JjHJKO/QdODik5DpmXEnQhBfLlujuYkCtJjoBv1+QdImnnv9aNidGuLAneNvZ+UN
NqfE3IRShzNw3IkAlQIFECtj5iw2VpfGMt2Y2QEBDEYD/2iMMml65eFaNWrNP7ab
Yh8QW3+Mnjyl5CNpAjGkxejmIm4nZKqUHN5DuGzpJDnstRwbz6daXK15XcoM1m8g
uhu6UzIwHs9+hbKE6inTCz4C0mE55PSmvF/ejjexnGzsiFpuFnjN/sRrSHc57flO
IUWBCZD8Hizz3aYBxmvwJ863iQCVAgUQKxEXHOJ13g7/Z/cLAQGyYgP/apcv9V2M
bHFgU0hl0D4MLqGjBReUfDroxQCsgsTb/0nr1W9yltBMqYPgD7ThLAf2rxIPNbGy
D7VUA27LTwQTS6n2mbtkHOvGQVw7J2GwTA6319Gf0Qne0M1h7VJWjFX0Vzjuh/nk
6btxM2uTLSF2nUsDXe5/9N5XeesFhrbXNrM=
=4fGE
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVFwE94nNf3ah8DHAQEkVQP/QzHZ0oqDW3XYrpYANTfeA7hIMgweKz8N
7/UpkV5XHhePwEfJA3fFn2Gs/BwF6Oy0xsJOk16AIE5JtAWqp5x3jzQ6BuJhkhhk
RcVrmtqqBfj8PMnpm3rdQRUMC9CftxA/m06y3Cw5FHgxvrOXcZfyrsBIR26UejsI
4fOY+JjlglQ=
=sBOp
-----END PGP SIGNATURE-----

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






From hughes at ah.com  Fri Feb  4 10:45:10 1994
From: hughes at ah.com (Eric Hughes)
Date: Fri, 4 Feb 94 10:45:10 PST
Subject: STEG: a real-life use for steganography
Message-ID: <9402041840.AA21942@ah.com>


I had an extremely interesting conversation with a fellow last night,
say, X.  A mutual friend of ours had steered him towards me.

X has contacts in a country C which will remain nameless.  The
government of C is extremely repressive and has a large internal
police force.  The situation, evidently, is one similar to the old
USSR, where masks behind masks were used in daily life, little is
exactly as it appears, and the default discourse is sideways speaking.

The scenario is almost worst-case.  There is a need for steganography,
since the use of cryptography is grounds for suppression; likewise
there is a need for covert channels.  There is a need for
double-blinding of identities, since one's friends may be difficult to
detect.  And so on.  

The aspect that _is_ good is that C is not the whole world, and there
are plenty of us not in C.  The first most useful facility to set up,
X thinks, is simply news from outside of C as a bypass of the media in
C--wire service articles about C, for example, as well as a feed of
the newsgroup "soc.culture.<C>".

Here's the technique we came up with last night.  C has an indigenous
music M which is periodically performed in the United States.  We were
thinking about pressing short-run CD's of these live performances.  We
all know where the news feeds go.  The CD's would be distributed via
standard music channels and would be surprisingly brisk sellers.  The
costs of the project can evidently be footed by willing members of the
M industry in C.

Now let me address the standard comment "Oh, steganography completely
solves that problem."  Please.  That's like saying, "Oh, just use an
internal combustion engine to solve your long distance transport
problems."  Such statements are a failure of imagination and
seriousness.

A practical system to carry this project out is quite large.  I see at
least the following pieces needed:

 -- A facility to gather the data being put on the disks.  This by
itself is no trivial task, since it involves the collection of many
disparate sources.

 -- An authoring system to arrange the data, once collected, into a
usable structure.

 -- An encryption system for the arranged data.  Such a system can't
treat the data as one long stream, because of the segmented nature of
the data.  The ability to mount the CD as a file system would be good
leverage for other programmers.

 -- A mastering system to combine a music master CD (done separately)
and a data master (in some format) into a new music master CD.  This
will, at the least require a machine with a CD reader and writer.
Blank media, FYI, for a CD writer are about $20/disk.  The CD writer
is about $5K.  These numbers are approximate and falling rapidly.

 -- A CD pressing facility.  These are commercially available at quite
reasonable cost in quantities in the 100's.

 -- A CD distribution system.  This will likely be the M industry, and
thankfully the details of international shipping and customs will be
taken care of, as well as retail distribution.

 -- A decryption system to get the data off the CD.

 -- Client software to make use of the information.  It need not all
be in text format.

 -- A key distribution system.  A secret key per CD and word of mouth
may be sufficient.  A system to make rememberable sentences out of an
arbitrary 128 bits (and the inverse) would be useful to facilitate
word of mouth.

This is no small task.  Those interested in participating may start
working on any of the above.  The tasks are fairly separable.  Here
are some that I can identify as critical.

 -- A standard for encoding data into the low bits of an audio CD.
This will likely require a lot of specific knowledge of the low level
encoding and error correction systems used in CD's.  I do know that
they are not simple, being much more than bit-correcting linear codes.

 -- A standard for the encoding of file system data onto these low
bits.  This should be a separate document, even though the design of
this will be influenced by the bit encoding standard.  Some adaptation
of existing file system standards may be appropriate.

 -- A standard for the encryption format for the file system.  It may
be that Matt Blaze's CFS cryptograpy can be lifted wholesale.

 -- Multiplatform software support for all of the above.

I am pleased to have a real example to work on, rather than a lot of
wixering about hypotheticals.

I welcome discussion of this topic.  

Eric





From freeman at MasPar.COM  Fri Feb  4 10:55:12 1994
From: freeman at MasPar.COM (Jay R. Freeman)
Date: Fri, 4 Feb 94 10:55:12 PST
Subject: San Jose BBS subject to M
Message-ID: <9402041855.AA00762@cleo.MasPar.Com>


> Hmm... wish I had the exact original handy to mis-quote ...

  Is this the one you mean?

                First they came for the Communists,
                  and I didn't speak up,
                    because I wasn't a Communist.
                Then they came for the Jews,
                  and I didn't speak up,
                    because I wasn't a Jew.
                Then they came for the Catholics,
                  and I didn't speak up,
                    because I was a Protestant.
                Then they came for me,
                  and by that time there was no one
                    left to speak up for me.

                by Rev. Martin Niemoller, 1945.





From MCALVINK at ccmail.sunysb.edu  Fri Feb  4 11:15:20 1994
From: MCALVINK at ccmail.sunysb.edu (MCALVINK at ccmail.sunysb.edu)
Date: Fri, 4 Feb 94 11:15:20 PST
Subject: UNSUB
Message-ID: <01H8HO3DOA2Q95N79W@ccmail.sunysb.edu>


UNSUBSCRIBE m calvinkoons






From nobody at shell.portal.com  Fri Feb  4 11:25:15 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 11:25:15 PST
Subject: REMAILERS: Netcoms Policy and hazards to remailers
Message-ID: <199402041921.LAA06512@jobe.shell.portal.com>


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

  anon






From mg5n+ at andrew.cmu.edu  Fri Feb  4 11:29:55 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Fri, 4 Feb 94 11:29:55 PST
Subject: Running regularly
In-Reply-To: <CMM-RU.1.3.760376482.matthew@gandalf.rutgers.edu>
Message-ID: <ohIe6mW00awO8hvVIq@andrew.cmu.edu>


Matthew Bernardini <matthew at gandalf.rutgers.edu> wrote:

> Why not make two shell scripts, one that sleeps for so long (say 20 minutes)
> using the unix sleep command, and then calls the remailer scripts in an
> infinite while loop.  This would work if you set it up as a background
> process,and you don't need to be root for it to work.  Only downsides are
> that when the machine crashes you have to log back in and restart script,
> your sleep command will always be in the top window if your sys-admin
> is watching, and you have to be careful not to spawn to many processes and
> bring the system down.

I tried this on the system here, but it killed off the process when I
logged off.

As for starting too many processes, just don't start them...  leave it
as one single process that just repeats itself indefinently with sleeps
in between.





From beker at netcom.com  Fri Feb  4 12:09:54 1994
From: beker at netcom.com (Brian Beker)
Date: Fri, 4 Feb 94 12:09:54 PST
Subject: Remailer Delays
Message-ID: <Pine.3.85.9402041253.A23998-0100000@netcom7>



The last two messages I've sent through remailers have taken upwards of 
two days to arrive at their destinations.  Parallel messages sent 
directly arrived immediately.

The two remailers are Hal's and rebma.

What is making this happen?  Is it related to all the recent PGP FAQ 
traffic?  Which remailers if any are not suffering from these lags?

THX,
B






From wex at media.mit.edu  Fri Feb  4 12:10:14 1994
From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat)
Date: Fri, 4 Feb 94 12:10:14 PST
Subject: STEG: a real-life use for steganography
In-Reply-To: <9402041840.AA21942@ah.com>
Message-ID: <9402042009.AA09438@media.mit.edu>


Hunh.  I'm surprised that you would select a fixed medium (CDs) for a
variable information source.  How often do you plan to press new CDs?

Would it not be simpler to use steganography to encode the desired
information into GIFs of, say, US weather maps?  These maps are revised
quite often and it would be natural to send person X a new weather map every
day or so.

Yes, as we all know from past discussions, it's possible for someone who
knows what you're doing to recover the data "hidden" in the pictures.  But
how likely is that to happen?  What's the cost of this (or another non-
media-dependent solution) versus the complexity and cost of using CDs as
your transport mechanism?

[About the CDs: what will the sound like when played on a normal CD player?
Isn't this likely to attract attention?]

--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group	wex at media.mit.edu
Voice: 617-258-9168 Page: 617-945-1842		an53607 at anon.penet.fi
All the world's a stage and most of us are desperately unrehearsed.





From mab at research.att.com  Fri Feb  4 12:10:15 1994
From: mab at research.att.com (Matt Blaze)
Date: Fri, 4 Feb 94 12:10:15 PST
Subject: Followup: Notes on key escrow meeting with NSA
Message-ID: <9402042007.AA25589@big.l1135.att.com>


Newsgroups: sci.crypt,talk.politics.crypto,comp.org.eff.talk,alt.privacy.clipper
Subject: Re: Notes on key escrow meeting with NSA

In a recent article, I wrote:
>A group from NSA and FBI met the other day with a group of us at Bell
>Labs to discuss the key escrow proposal.  They were surprisingly
>forthcoming and open to discussion and debate, and were willing to at
>least listen to hard questions.  They didn't object when asked if we
>could summarize what we learned to the net.  Incidentally, the people
>at the meeting seemed to base a large part of their understanding of
>public opinion on Usenet postings.  Postings to sci.crypt and
>talk.politics.crypto seem to actually have an influence on our
>government.
>
>A number of things came out at the meeting that we didn't previously
>know or that clarified previously released information.  What follows
>is a rough summary; needless to say, nothing here should be taken as
>gospel, or representing the official positions of anybody.  Also,
>nothing here should be taken as an endorsement of key escrow, clipper,
>or anything else by the authors; we're just reporting.  These notes
>are based on the collective memory of Steve Bellovin, Matt Blaze, Jack
>Lacy, and Mike Reiter; there may be errors or misunderstandings.
>Please forgive the rough style.  Note also the use of "~ ~" for
>'approximate quotes' (a marvelous Whit Diffie-ism).

A couple of clarifications and new recollections.  Same disclaimers as
above.

The NSA people were asked whether they would consider evaluating
ciphers submitted by the private sector as opposed to simply proposing a
new cipher as a "black box" as they did with Skipjack.  They said they
can't do this because, among other things, of the extraordinary effort
required to properly test a new cipher.  They said that it often takes
from 8-12 years to design, evaluate and certify a new algorithm, and
that Skipjack began development "~about 10 years ago.~"  I asked if we
should infer anything from that about the value of the (limited time
and resource) civilian Skipjack review.  They took that with good
humor, but they did say that the civilian review was at least
presented with and able to evaluate some of the results of NSA's
previous internal reviews.

Regarding the scale of the escrow exploitation system, they said that
they did not yet have a final operational specification for the escrow
protocols, but did say that the escrow agencies would be expected to
deliver keys "~within about 2 hours~"  and are aiming for "~close to
real time.~" Initially, the FBI would have the decoder box, but
eventually, depending on costs and demand, any law enforcement agency
authorized to conduct wiretaps would be able to buy one.  The two
escrow agencies will be responsible for verifying the certification
from and securely delivering the key halves to any such police
department.

As an aside, we've since been informed by a member of the civilian
Skipjack review committee that the rationale for not having the escrow
agency see the actual wiretap order is so that they do not have access
to the mapping between key serial numbers and people/telephones.

Also, on second reading, I wasn't at all clear about the reverse
engineering resistance of the chips.  I wrote:

>...they are designed to resist reverse engineering the data in the
>chip without destroying the chip.  It is not clear (from the
>information presented at the meeting) whether the chips are equally
>resistant to destructive reverse-engineering to learn the skipjack
>algorithm....

That is, the chips are designed to resist non-destructive reverse
engineering to obtain the unit keys.  They do not believe that it is
possible to obtain the unit key of a particular chip without destroying
the chip.  They did not present any assertions about resistance to
destructive reverse engineering, such that several chips can be taken
apart and destroyed in the process, to learn the Skipjack algorithm.

Finally, I should have made clear that "Clipper" is more properly
called the "MYK-78T".

-matt






From Lyle_Seaman at transarc.com  Fri Feb  4 12:25:15 1994
From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com)
Date: Fri, 4 Feb 94 12:25:15 PST
Subject: Read-Once Messages?
In-Reply-To: <9401311747.AA12799@federal-excess.apple.com>
Message-ID: <QhIeqzeSMUw8QmXzRb@transarc.com>


lefty at apple.com (Lefty) writes:
> Has there been any work done on messages that can be read a single time,
> preferably only by a designated recipient, and is not amenable to being
> captured as it is "played"?  I know that Gibson's poem _Agrippa_ had some
> sort of self-destruct feature built into it, but I don't know what
> mechanism was used to implement this.

I think I received one of these once, but I can't remember what it was.







From dm at hri.com  Fri Feb  4 12:39:54 1994
From: dm at hri.com (dm at hri.com)
Date: Fri, 4 Feb 94 12:39:54 PST
Subject: Running regularly
In-Reply-To: <ohIe6mW00awO8hvVIq@andrew.cmu.edu>
Message-ID: <9402042034.AA29033@sparc31.hri.com>



      
   Date: Fri,  4 Feb 1994 14:27:46 -0500 (EST)
   From: Matthew J Ghio <mg5n+ at andrew.cmu.edu>
   
   Matthew Bernardini <matthew at gandalf.rutgers.edu> wrote:
   
   > Why not make two shell scripts, one that sleeps for so long (say 20 minutes)
   > using the unix sleep command, and then calls the remailer scripts in an
   > infinite while loop.  This would work if you set it up as a background
   > process,and you don't need to be root for it to work.  
   
   I tried this on the system here, but it killed off the process when I
   logged off.

If it's a UNIX system, try using the ``nohup'' (for ``no-hang-up'',
from the days when you connected to computers by telephone) command to
keep your background process alive after you log out.





From nobody at shell.portal.com  Fri Feb  4 12:45:15 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 12:45:15 PST
Subject: Magic Money Digicash System
Message-ID: <199402042044.MAA28800@jobe.shell.portal.com>


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

Magic Money Digital Cash System
Brought To You By Pr0duct Cypher
Based on PGP Tools - The Crypto Construction Set
Send to csn.org, should appear under /mpj somewhere

Magic Money is a digital cash system designed for use over electronic mail.
The system is online and untraceable. Online means that each transaction
involves an exchange with a server, to prevent double-spending. Untraceable
means that it is impossible for anyone to trace transactions, or to match
a withdrawal with a deposit, or to match two coins in any way.

The system consists of two modules, the server and the client. Magic Money
uses the PGP ascii-armored message format for all communication between the
server and client. All traffic is encrypted, and messages from the server
to the client are signed. Untraceability is provided by a Chaum-style blind
signature. Note that the blind signature is patented, as is RSA. Using it
for experimental purposes only shouldn't get you in trouble.

Digicash is represented by discrete coins, the denominations of which are
chosen by the server operator. Coins are RSA-signed, with a different e/d
pair for each denomination. The server does not store any money. All coins
are stored by the client module. The server accepts old coins and blind-
signs new coins, and checks off the old ones on a spent list.

Suppose Alice wants to pay Bob some Magic Money. Alice uses her client
module to extract some coins from her account (file). She then mails those
coins to Bob, using a secure channel such as a PGP message. Bob runs his
client module on the coins. The client module checks the signatures, and
totals up the value of the coins. 

It then prompts Bob to choose the values of new coins which total the same
value as the old ones. For example, Alice sends Bob a 64-unit coin. Bob
chooses a 32-unit and two 16-unit coins. The client module then generates
proto-coins, which are blinded but unsigned. It produces an output file
containing Alice's coins, and the new proto-coins.

Bob mails this to the server. The server counts up Alice's coins, checks
their signatures, and checks for double-spending. It puts the coins on the
cancelled list, signs the proto-coins, and mails them back to Bob. Bob runs
his client module on the reply message. It unblinds the signed coins and
adds them to his coin file. This completes the transfer.

The Magic Money server is a filter, accepting input from stdin and sending
output to stdout. To set up a server, you first compile the server program
and install it in its own directory. Dump some random junk in a file called
rand.dat. This and the system clock is hashed to generate random numbers.

Then execute "s i" to initialize the server. It will prompt you for some
information. For the denominations, I would use powers of 2 (1, 2, 4, 8,
16, 32, 64, 128...) because they minimize the number of coins needed to
transfer any amount. The server will create a key and an e/d list. An
ascii-armored copy of the server's public key is written to bank.asc. Users
must have this key to use the server, so however you publicize your server,
include the key.

Set up the system so that, when a message comes in, the server is executed
and the message (which need not be cleaned up first) is piped into stdin.
The output from the server should be mailed back to the user. The server
can be run through a remailer, if you don't want to reveal your location.
This would be easiest through a penet-style remailer. Operating through a
cypherpunks-style remailer would require an external mechanism to handle
reply headers. However you do it, just see to it that messages go into the
server and the output goes back to the right user.

If you just want to experiment on one machine, put the server and client in
different directories, to prevent their files from interfering with each
other. Set up a shell script/batch file to feed the client's output into
the server and return the server's reply.

The server has the ability to include a message to the client. If the file
msg.txt exists in the server's directory, it will be included in the
server's replies, and the clients will display it. The client will wait for
a keypress after displaying the message, so the last line should be "press
any key to continue" or something similar. The message should not be longer
than one screen, because there is no "more" in the client. The main use for
the message is to warn users of expirations (see below), but you can send
anything you want.

To set up a client, compile the client module (unless the server operator
was nice enough to provide a binary [hint]) and put it in its own
directory. Put some random junk (for random numbers) into rand.dat, and put
the server's ascii-armored key in bank.asc. Now execute "c -i" to
initialize your client. It will create a key and generate "output.asc"
which should be mailed to the server. When the reply comes back, save it
in a file and run "c <file>". This will initialize your e-list and coin
name files. If the server has a msg.txt, you will see it.

Now get another user to send you some coins. Coins are binary, not ascii-
armored, because we assume you will use a PGP message or other "envelope"
to transport them. Execute "c <file>" to process your coins. The client
will show the denominations as the signatures are checked. It will show the
total, and allow you to choose denominations for the new coins you want to
generate. Then it will generate a file "output.asc" which should be mailed
to the server. Take the server's reply and run "c <file>" on it. It will
extract and unblind the coins, displaying them as it does so. When it is
done, you will have some coins to spend.

To pay someone some coins, execute "c -p". The client will show a list of
coins you have, and allow you to choose values to extract. These will be
copied into "coins.dat", which you then mail to the person you want to pay.
He does as above to deposit them. Do not lose "coins.dat" because the coins
are removed from your file as they are extracted.

Server maintenance and expirations: the server must keep track of all the
coins which have ever been spent, at 16 bytes each. While the server uses
an efficient hash file to maintain speed, the file will eventually grow to
consume the entire filesystem of the host machine. There must be a way to
clear it out eventually.

The server operator executes "s n" to generate a new e/d list. The old list
will be renamed. Old coins are still valid at this point. The server
operator should put up a message warning users to exchange their old coins.
The next time a user interacts with the server, his elist will be updated
automatically, and the old one renamed. 

The user can (and should be warned to) execute "c -x" to automatically
exchange all his old coins for new ones. After a reasonable time, and
plenty of warning (!) the server operator executes "s d" to delete the old
spent list, efile, and dfile. Old coins are now worthless. The next time
a user interacts with the server, his old elist will be deleted
automatically by his client. Old coins will now show up as having zero
value, and a "c -x" will discard them as "expired coins". If the user was
dumb enough not to exchange his coins, too bad.

The server will only sign as much value as it receives, so the amount of
money in circulation remains constant. We have a chicken-and-egg problem:
how is value created? The server operator has the magical ability to create
new coins from thin air. He executes "s m <x> <x> <x>" where x is the
denomination of the coins he wants. The result is a coins.dat file, which
can be mailed to a user and processed by his client module. The server just
signs the coins directly, without any blinding.

Coins are represented by RSA integers in the normal PGP-signature format.
The coin is 16 bytes, padded in the same way that PGP 2.3a pads a
signature. The coin is stored signed, that is, raised to the d power. There
is no hashing involved; RSA is used directly.

To blind a coin, the client generates a blinding factor, a large random
number. The random number is raised to the appropriate e power, modulo the
server's n. It is then multiplied with the unsigned coin, generating a
blinded "proto-coin", which is sent to the server. The server signs the
blinded coin by raising to the power d. This "decrypts" the blinding factor
at the same time as it signs the coin, because RSA is multiplicative. Then
the client divides out the blinding factor, leaving the signed coin.

How big should the blinding factor be? I am not sure. Right now, it is set
to the modulus minus one byte. This is certainly secure, but it takes a
long time to unblind because mp_inv is a slow operation. If you know how
long it needs to be, feel free to change it.

Now, if you're still awake, comes the fun part: how do you introduce real
value into your digicash system? How, for that matter, do you even get
people to play with it?

What makes gold valuable? It has some useful properties: it is a good
conductor, is resistant to corrosion and chemicals, etc. But those have
only recently become important. Why has gold been valuable for thousands
of years? It's pretty, it's shiny, and most importantly, it is scarce.

Digicash is pretty and shiny. People have been talking about it for years,
but few have actually used it. You can make your cash more interesting by
giving your server a provocative name. Running it through a remailer could
give it an 'underground' feel, which would attract people.

Your digicash should be scarce. Don't give it away in large quantities. Get
some people to play with your server, passing coins back and forth. Have
a contest - the first person who (breaks this code, answers this question,
etc.) wins some digital money. Once people start getting interested, your
digital money will be in demand. Make sure demand always exceeds supply. 

If some people get servers up and running, and if there is any interest,
I can write an automatic client which will accept and pay out Magic Money
without human intervention. Please let me know if you have an application
for this, or any other ideas for the system.

                                              Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVChQcGoFIWXVYodAQFDhAQAlOdUdnZZxarfxIbACZlHv+Hza+lLkaQl
2eMBro4Bu/QV6wjnTPfw4AND8HbsgdCYjsh7B6XBkpLqVqSk0/fBkwrb4jmvG/bD
sU2ccYm2Da9qShHaYWSqApugVA+0bPc9LSHxpbbrAfXIkMQvYqKQMjde6VW4zecZ
fZAtf6J/7TY=
=N7Kb
-----END PGP SIGNATURE-----





From sdw at meaddata.com  Fri Feb  4 12:49:55 1994
From: sdw at meaddata.com (Stephen Williams)
Date: Fri, 4 Feb 94 12:49:55 PST
Subject: Running regularly
In-Reply-To: <ohIe6mW00awO8hvVIq@andrew.cmu.edu>
Message-ID: <9402042046.AA20030@jungle.meaddata.com>


> 
> Matthew Bernardini <matthew at gandalf.rutgers.edu> wrote:
> 
> > Why not make two shell scripts, one that sleeps for so long (say 20 minutes)
> > using the unix sleep command, and then calls the remailer scripts in an
> > infinite while loop.  This would work if you set it up as a background
...
> I tried this on the system here, but it killed off the process when I
> logged off.
> 
> As for starting too many processes, just don't start them...  leave it
> as one single process that just repeats itself indefinently with sleeps
> in between.

You did try to nohup it, right?

nohup script blabla...

sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw at lig.net sdw at meaddata.com
OO R&D Source Dist.  By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430
Comm. Consulting     ICBM: 39 34N 85 15W I love it when a plan comes together




From nobody at shell.portal.com  Fri Feb  4 13:29:54 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 13:29:54 PST
Subject: remailer delays
Message-ID: <199402042129.NAA11271@jobe.shell.portal.com>


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

Brian Beker asked,
"The last two messages I've sent through remailers have taken upwards of
two days to arrive at their destinations.  Parallel messages sent
directly arrived immediately.

The two remailers are Hal's and rebma.

What is making this happen?  Is it related to all the recent PGP FAQ
traffic?  Which remailers if any are not suffering from these lags?"

I am not using remba at all, not even pinging it. The last three days
have seen the "Bomb me!" request dwindle to about 5-6 a day. Hal's ("shell")
is working without a glitch. That leaves remba. If I can get my list of
remailer details completed, people like you with specific needs (today you
want speed) will be happier. The fast remailers that I am using and have
had NO problem with are:

@remailers = (
"catalyst at netcom.com",
"remailer at dis.org",
"ebrandt at jarthur.claremont.edu",
"remailer at merde.dis.org",
"elee7h5 at rosebud.ee.uh.edu",
"hfinney at shell.portal.com",
"hh at soda.berkeley.edu",
"qwerty at netcom.com"
);

These are not necessarily the most secure ones, but they are all pingable
with variable 5 minute to 1 hour delays for the pings to come back. If speed
is of concern, these are your remailers. cicada and pmantis are also quite
fast but are not meant for what I need them for. I am very sensitive to
kicking mailers off my list if I cause a problem, even once. The merde and
dis.org remailers often add an hour delay, seeming to batch things out.
jarthur is often ~10 minutes, but just as often an hour.

- From my incomplete List:

Remailer  Fast?  OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB
 -------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ----------
bsu-cs    +      ?      ?/?    +    ?    ?   ?  ?   ?   23a  ?
catalyst  +      N?    SM/MQ   -    -    ?   -  PA  M   23a  -
choas     +      ?      ?/?    +    ?    ?   ?  ?   ?   -    -
cicada    ++     ?      ?/?    -    -    -   -  ?   ?   -    -
dis.org   -/--   ?      ?/?    -    ?    ?   ?  ?   ?   23a  ?
extropia  +/?    ?      ?/?    +    ?    ?   ?  Pr? ?   23a  ?
jarthur   +/--   St    SM/MQ?  -    ?    ?   ?  Un  ?   23a  -
menudo    --     ?      ?/?    -    t1   ?   ?  ?   ?   -    ?
merde     -/--   ?      ?/?    -    ?    ?   ?  ?   ?   -    ?
penet.fi  --     St     ?/?    -    t?   24  +  Pr  H   -    -
pmantis   ++     ?      ?/?    -    ?    -   -  ?   ?   -    -
qwerty    +      C     SM/MQ   -    -    -   -  PA  M   23a  +
rosebud   ++/-   ?      ?/?    -    -    -   ?  ?   ?   23a  ?
remba       ?    ?      ?/?    ?    ?    ?   ?  ?   ?   23a  ?
shell     ++/+/- St     ?/?    -    ?    ?   ?  ?   ?   23a  -
soda      ++/-   St+?   ?/?    -    ?    ?   ?  ?   ?   -

Subj: Strips Subject header?
NL: Non-linear remailing? 123->231.
RD: Random delay added (max, in hours)?
Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages.
CPU: Pr = private. PA = account on public access machine. Un = university.
Phys: Physical security of the CPU, especially at night. H/M/L.
BitB: BitBucket feature?

Fast?:
++ <5 min
+   5-10 min.
 -  ~10-30 min delay
 --  pinging isn't practical due to long delays
+/- sometimes +, sometimes -
Normal internet mail delays are common, and are not equivalent in the two
directions between any two remailers. Mail still gets through.

OpLog:
F: full copies of all mail is archived. My large volume mailing should
   help put a stop to this.
St: Stats logs of when mail was remailed.
St+: Stats logs of when and where mail was remailed.
St-: simple counter.
N: operator keeps no logs.

SysLog:
SM: sendmail logs of when and where mail was exchanged. Root access.
MQ: mailqueue accessible by anyone on the site. Could make logs.

 -Nik (Xenon)

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVJ3RwSzG6zrQn1RAQEfFQP/Rkt6bVBWCetn4YH/dm7LJ+EhAia+NXDy
EutlgmKJKXPc2eh3pypVb0cxdlMr/dOidXrTY3LzCF4iHOc7/l1FNegkbrJltf9R
+rOHyh23FDnQZE8NIxq9KLr++iUxMFsq8UfmNy+Z5ojMh2Nc+54CBSHoAMMEryPG
oEOu5i3jK08=
=nfRB
-----END PGP SIGNATURE-----





From hfinney at shell.portal.com  Fri Feb  4 13:59:53 1994
From: hfinney at shell.portal.com (Hal)
Date: Fri, 4 Feb 94 13:59:53 PST
Subject: Magic Money Digicash System
Message-ID: <199402042158.NAA09840@jobe.shell.portal.com>


Wow!  Hot stuff!

I looked at csn.org, but I didn't find magic money.  The pgp_tools
has been there for a while, of course.  Somebody post when they find
it.

Hats off to Pr0duct Cypher!

Hal






From MIKEINGLE at delphi.com  Fri Feb  4 14:25:16 1994
From: MIKEINGLE at delphi.com (Mike Ingle)
Date: Fri, 4 Feb 94 14:25:16 PST
Subject: Prodigy snooping
Message-ID: <01H8GY0YK46W91W1I6@delphi.com>


>I heard from a friend that Prodigy was scanning user's hard drives. 
>Basically, when you logged on Prodigy made a complete directory of your
>hard drive and uploaded it.  Prodigy was using this to find out what
>applications you used so they could direct the appropriate advertising
>towards you.  Apparently, they're suffering several lawsuits now because
>of it.

This tale has been around for a while. Prodigy makes a huge file, over
1 MB, on your hard drive and stores information there to speed up the data
transfer. People started finding bits of their files in there. They
claimed that Prodigy was snooping into their systems. Prodigy denied it
and claimed that their software just didn't bother to clear the disk space
when it allocated it, so whatever was there, stayed there until the space
was used. They distributed a utility which would zero out that information.
Whether they were really snooping or not, who knows? If they were, they
were pretty stupid to leave clear text in the file.
 
>My friend heard this on the trailing end of a radio talk show.  If it was
>really happening, it sounds horrible.  Could Secure Drive be set up to
>stop this kind of attack?

Secure Drive would stop it if you weren't logged into the encrypted drive
when you ran Prodigy. Of course, if you were logged in and they knew about
Secure Drive, they could get your encryption key as well as your data...

--- Mike






From dave_taffs at rainbow.mentorg.com  Fri Feb  4 14:25:19 1994
From: dave_taffs at rainbow.mentorg.com (Dave Taffs)
Date: Fri, 4 Feb 94 14:25:19 PST
Subject: request for information
Message-ID: <199402042217.AA29743@fpd.MENTORG.COM>



I saw the following on imp-interest, and thought somebody here might
be interested in responding (perhaps?)...

PS: She has David Chaum's internet address by now, I'm certain...

to:     imp-interest at thumper.bellcore.com
from:   owner-imp-interest at thumper.bellcore.com
date:   Fri, 4 Feb 1994 10:29:56 -0500 (EST)
subj:   Digicash story/Internet Letter
sender: jayne levin <helen at access.digex.net>
sent:   02/04/1994  8:33 am (PDT)
---------                                                                    **|

I would like to explore the issue of digital cash in my next issue of The
Internet Letter. I am trying to contact David Chaum but don't have his
e-mail address, so I'd appreciate any help in making contact with him.

I'd also like to get a grip on some of the issues involved in developing
digital cash as well as the status of work in this area. Who else should I
talk to?

Jayne

Jayne Levin                                           Net Week Inc.
Editor                                  220 National Press Building
The Internet Letter                     Washington, D.C. 20045  USA
+1 202 638 6020                                Fax: +1 202 638 6019







From rcain at netcom.com  Fri Feb  4 14:25:20 1994
From: rcain at netcom.com (Robert Cain)
Date: Fri, 4 Feb 94 14:25:20 PST
Subject: Running regularly
In-Reply-To: <199402040708.XAA17954@jobe.shell.portal.com>
Message-ID: <199402042225.OAA24297@mail.netcom.com>


Hal sez:
> 
> > Before I start throwing out ideas that I'm sure aren't new to readers here,
> > I have a simple question that perhaps I should post to comp.unix.questions
> > or comp.lang.perl, but.... Can I, and how would I, get a perl script to
> > kick in and send out mail every few minutes when I am NOT logged in. Is this
> > possible on Netcom?
> 
> Most public Unix systems will not let you do this, in my experience.
> The two Unix commands which usually give you the ability to run programs
> at regular intervals are "at" and "crontab".  You can read the man pages
> and try running these to see if they are enabled for you.
> 

If you run into this, there is a sneaky way to do it if you have a
friend somewhere that doesn't restrict at or crontab and if your system
provides elm and will will honor a .forward file.  Have your friend set
up a crontab that mails you a short note with some header
characteristic that the filter program for elm can recognize via the
filter-rules file and kick off an invocation of whatever you want to do
each time it recieves one of these notes.  Sneaky but it works.  :-)


Peace,

Bob

-- 
Bob Cain    rcain at netcom.com   408-354-8021


           "I used to be different.  But now I'm the same."


--------------PGP 1.0 or 2.0 public key available on request.------------------




From mnemonic at eff.org  Fri Feb  4 14:59:57 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 14:59:57 PST
Subject: interagency_workgroup.notice (fwd)
Message-ID: <199402042256.RAA00559@eff.org>


Forwarded message:


From mbriceno at netcom.com  Fri Feb  4 15:00:17 1994
From: mbriceno at netcom.com (Marc Briceno)
Date: Fri, 4 Feb 94 15:00:17 PST
Subject: Running regularly
Message-ID: <199402042300.PAA18374@mail.netcom.com>


Xenon askend:
>> Before I start throwing out ideas that I'm sure aren't new to readers here,
>> I have a simple question that perhaps I should post to comp.unix.questions
>> or comp.lang.perl, but.... Can I, and how would I, get a perl script to
>> kick in and send out mail every few minutes when I am NOT logged in. Is this
>> possible on Netcom?

Hal answered:
>Most public Unix systems will not let you do this, in my experience.
>The two Unix commands which usually give you the ability to run programs
>at regular intervals are "at" and "crontab".  You can read the man pages
>and try running these to see if they are enabled for you.

Netcom has a "policy against detached processes because of the load they
put on the system and therfore 'crontab' and 'at' disabled for all
users.(Netcom support)" To make your life even harder they kill all your
processes upon hangup.
Here is (half) the workaround:

They forgot to disable "sleep" and they also didn't disable "nohup."
You can simply write a script that sleeps for 30 min, executes your program
and goes back to sleep. Call it with "nohup script &" and you're in
business.

The next problem that must be addressed is the auto-logout upon >14min of
inactivity on the modem level that Netcom imposes on you. There is a simple
2 line command that you can add to your .login file to disable the
auto-logout. I saw it once posted in one of the Netcom newsgroups, but I
lost it. Perhaps you might post the question there. I would not advise to
ask Netcom support for it... Some of the messages responding to the above
post talked about "supending the account for intentionally disabling, blah,
blah" 8-)

Good luck,

-- Marc Briceno <mbriceno at netcom.com>
   PGP public key by finger






From mnemonic at eff.org  Fri Feb  4 15:00:19 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:00:19 PST
Subject: reno_key_escrow.statement (fwd)
Message-ID: <199402042259.RAA00674@eff.org>


Forwarded message:


From mnemonic at eff.org  Fri Feb  4 15:05:17 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:05:17 PST
Subject: gore_crypto.statement (fwd)
Message-ID: <199402042301.SAA00879@eff.org>


Forwarded message:


From mnemonic at eff.org  Fri Feb  4 15:05:18 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:05:18 PST
Subject: harris.statement (fwd)
Message-ID: <199402042300.SAA00784@eff.org>


Forwarded message:


From mnemonic at eff.org  Fri Feb  4 15:05:21 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:05:21 PST
Subject: clipper_q-and-a.txt (fwd)
Message-ID: <199402042300.SAA00796@eff.org>


Forwarded message:


From mnemonic at eff.org  Fri Feb  4 15:09:57 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:09:57 PST
Subject: wh_press_secy.statement (fwd)
Message-ID: <199402042301.SAA00849@eff.org>


Forwarded message:


From mnemonic at eff.org  Fri Feb  4 15:10:17 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Fri, 4 Feb 94 15:10:17 PST
Subject: doj_escrow_intercept.procedures (fwd)
Message-ID: <199402042259.RAA00682@eff.org>


Forwarded message:


From mengel at dcdmwm.fnal.gov  Fri Feb  4 15:29:56 1994
From: mengel at dcdmwm.fnal.gov (Marc W. Mengel)
Date: Fri, 4 Feb 94 15:29:56 PST
Subject: CERT advisory
In-Reply-To: <9402041825.AA27913@media.mit.edu>
Message-ID: <9402042327.AA43567@dcdmwm.fnal.gov>



In <9402041825.AA27913 at media.mit.edu>  you write:
  [Some items of interest to C-punks include CERT's advocacy of stopping
  cleartext transmission of password (no shit sherlock), and their proposed
  solutions, including the use of one-time passwords which I had queried about
  on this list a few months back.  Of course they don't mention any sort of
  real encryption, let alone PGP.  How hard would it be to build in PGP
  security to the transmission layer of something like FTP?  Seems like a
  fairly simple problem, given that any site which supports anonymous FTP can
  publish a public key.  Even if we assume that encryption would slow down the
  file transmission too much, we could still use it for the
  login/authentication part of the session...  --AW]

Since the command channel is flat ascii, one could extend the protocol
with a pgp-password command, which would send the password encrypted in the
server's public key.  Similarly one could use the sort of convention that
the wu-ftpd does to request encrypted files... simply request file.pgp,
just like you request file.z, file.gz, etc.

Of course, there really *ought* to be an RFC for it, but I'm thinking
something like a command

 	666 PGPL
	-----BEGIN PGP MESSAGE-----
	...
	-----END PGP MESSAGE-----

which would send an encrypted login and password.

The other piece to hack up would be the ftp client, it would have to
ask for your login/password on the ftp server host, then crank that
through pgp, and send an ELOGIN command down the socket -- no problem.

The big issue, in my mind, is how the ftpd is going to get the key
to unlock the *system's* private key... Do you compile it into the
code?  Should ftpd ask for it when it comes up? 

Marc





From fnerd at smds.com  Fri Feb  4 15:45:17 1994
From: fnerd at smds.com (FutureNerd Steve Witham)
Date: Fri, 4 Feb 94 15:45:17 PST
Subject: STEG: a real-life use for steganography
Message-ID: <9402042330.AA14310@smds.com>


Eric talks about a hypothetical system S which he discussed with
real acquaintance X of country C (with repressive government G), 
for stegging information I in through exogenously-produced CDs of 
indigenous music M.

One problem is that S is proposed for use by lots of people in C.
That means the whole system won't be a secret for long.  Soon
G will know not only which records and which equipment to ban, but
also the passphrases for the records--so why encrypt or even
camoflage it?

Maybe making copies of existing popular records would help.
Classics that lots of people already have.  Are there already 
records produced for C but manufactured outside of C?  Do they 
import music popular outside C?

>  -- A facility to gather the data being put on the disks.  This by
> itself is no trivial task, since it involves the collection of many
> disparate sources.

Maybe the newsgroup you mention is just the thing for the second-to-
last step in the chain.  It can combine efforts of people who don't 
have to know each other.

>  -- An encryption system for the arranged data.  Such a system can't
> treat the data as one long stream, because of the segmented nature of
> the data.  

There's also the problem of recovering from errors on the CD.

> The ability to mount the CD as a file system would be good
> leverage for other programmers.

>  -- A decryption system to get the data off the CD.

Can most CR ROM drives read the raw music format?  Many?
If not, can the bit stream to the ADC in a CD player be intercepted?
Maybe the best hardware from a physical camoflage standpoint would be 
those little CDROM drives that double as "walkmen".

> A system to make rememberable sentences out of an
> arbitrary 128 bits (and the inverse) would be useful to facilitate
> word of mouth.

Isn't it good enough to always start with sentences invented by 
people and encode into bits?

> encoding and error correction systems used in CD's.  I do know that
> they are not simple, being much more than bit-correcting linear codes.

I think when they're not giving you exactly what you put in, they're
doing desparate things like repeating the last few milliseconds.  So
about all you can do is put CRCs and IDs on blocks (maybe small 
blocks?) and be able to deal with lost and misplaced blocks.
It might be useful to have signatures on block boundaries so you could
recognize them out of continuous streams.  Maybe you would just take
two blocks worth of data and slide your buffer along one byte at a
time till you got a good CRC...but by then you would have received
a lot more data.  Better have a long buffer.

>  -- A standard for the encoding of file system data onto these low
> bits.  This should be a separate document, even though the design of
> this will be influenced by the bit encoding standard.  Some adaptation
> of existing file system standards may be appropriate.

Here, too, you need to deal with lost blocks.  Having one copy of the
root of the index might not be great.  Also, assuming you're using
modified CD players instead of CDROM drives, you might want to take
advantage of the music track structure.

-fnerd
quote me

- -
skip sweet sweetbacks badass skipjack song, jack.  3x, fast.
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----





From nobody at shell.portal.com  Fri Feb  4 15:55:19 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 15:55:19 PST
Subject: For Pr0duct Cypher: faster mp_inv
Message-ID: <199402042353.PAA17274@jobe.shell.portal.com>


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

Pr0duct Cypher wrote:

> How big should the blinding factor be? I am not sure. Right now, it is set
> to the modulus minus one byte. This is certainly secure, but it takes a
> long time to unblind because mp_inv is a slow operation. If you know how
> long it needs to be, feel free to change it.

PGP's mp_inv is needlessly slow.  It works OK for the little numbers
they normally use ("e" exponents) but bogs down for big numbers.
Fortunately I wrote a fast version of mp_inv some time ago just for
this application (blinding).  You might say it is "blindingly" fast!

Here it is, from my private copy of pgp source.  With this you can
choose anything for your blinding.  You will probably want to change
it to use your safemalloc.


#ifdef OLD_MPINV
/* Replaced by a faster routine, below */
void mp_inv(unitptr x,unitptr a,unitptr n)
	/* Euclid's algorithm extended to compute multiplicative inverse.
	   Computes x such that a*x mod n = 1, where 0<a<n */
{
	/*	The variable u is unnecessary for the algorithm, but is 
		included in comments for mathematical clarity. 
	*/
	short i;
	unit y[MAX_UNIT_PRECISION], temp[MAX_UNIT_PRECISION];
	unit gcopies[3][MAX_UNIT_PRECISION], vcopies[3][MAX_UNIT_PRECISION];
#define g(i) (  &(gcopies[i][0])  )
#define v(i) (  &(vcopies[i][0])  )
/*	unit ucopies[3][MAX_UNIT_PRECISION]; */
/* #define u(i) (  &(ucopies[i][0])  ) */
	mp_move(g(0),n); mp_move(g(1),a);
/*	mp_init(u(0),1); mp_init(u(1),0); */
	mp_init(v(0),0); mp_init(v(1),1);
	i=1;
	while (testne(g(i),0))
	{	/* we know that at this point,  g(i) = u(i)*n + v(i)*a  */	
		mp_udiv( g(iplus1), y, g(iminus1), g(i) );
		mp_mult(temp,y,v(i)); mp_move(v(iplus1),v(iminus1)); mp_sub(v(iplus1),temp);
	/*	mp_mult(temp,y,u(i)); mp_move(u(iplus1),u(iminus1)); mp_sub(u(iplus1),temp); */
		i = iplus1;
	}
	mp_move(x,v(iminus1));
	if (mp_tstminus(x))
		mp_add(x,n);
	mp_burn(g(iminus1));	/* burn the evidence on the stack...*/
	mp_burn(g(iplus1));
	mp_burn(v(0));
	mp_burn(v(1));
	mp_burn(v(2));
	mp_burn(y);
	mp_burn(temp);
#undef g
#undef v
}	/* mp_inv */

#else /* OLD_MPINV */

/* Faster mp_inv, based on "Fast Multiplicative Inverse in Modular
 * Arithmetic", J. Gordon, in Cryptography and Coding, edited by
 * Henry J. Beker and F.C. Piper, 1989.
 * The mapping from the variables in that paper to our variables is,
 * roughly, M->n, X->a, HCF->u(iminus1), U->u(i), temp->u(iplus1),
 * INV->v(iminus1), V->v(i), temp->v(iplus1).  We rotate the assignment to temp
 * and INV in their 2nd block of code.
 */
void mp_inv(unitptr x,unitptr a,unitptr n)
	/* Euclid's algorithm extended to compute multiplicative inverse.
	   Computes x such that a*x mod n = 1, where 0<a<n */
{
	/*	The variable u is unnecessary for the algorithm, but is 
		included in comments for mathematical clarity. 
	*/
	int shifts;
	int i = 1;
	int enterloop;
	unit vcopies[3][MAX_UNIT_PRECISION], ucopies[3][MAX_UNIT_PRECISION];
#define u(i) (  &(ucopies[i][0])  )
#define v(i) (  &(vcopies[i][0])  )
/* Modify this to do one division at the beginning.  That makes it faster.
	mp_move(u(0),n); mp_move(u(1),a);
	mp_init(v(0),0); mp_init(v(1),1); mp_init(v(2),1);
 */
	mp_move(u(0),a); mp_init(v(0),1);
	/* Init U to n%a, V to -n/a. */
	mp_udiv(u(1), v(1), n, a); mp_neg(v(1)); mp_move(v(2),v(1));
	do {
		enterloop = 0;
		shifts = -1;
		if (mp_compare(u(i),u(iminus1)) > 0)	/* if U > HCF then */
			mp_init(u(iplus1),0);
		else {
			enterloop = 1;
			mp_move(u(iplus1),u(i));			/* temp := U */
			while (mp_compare(u(iplus1),u(iminus1)) <= 0) {	/* temp<=HCF */
				++shifts;
				mp_shift_left(u(iplus1));		/* leftshift(temp,1) */
			}
			mp_shift_right_bits(u(iplus1),1);	/* rightshift(temp,1) */
		}
		mp_sub(u(iminus1),u(iplus1));			/* temp := HCF - temp */
		mp_move(u(iplus1),u(iminus1));

		i = iplus1;		/* V := tempV, tempV := INV, INV := V, */
						/* U := tempU, tempU := HCF, HCF := U; */
						/* (All simultaneous) */

		if (enterloop) {
			while (shifts--)
				mp_shift_left(v(i));			/* leftshift(V,shifts) */
			mp_sub(v(iplus1),v(i));				/* temp = temp - V */
		}
		mp_move(v(i),v(iplus1));				/* V := temp */
	} while (testne(u(i),0) && mp_compare(u(i),u(iminus1))!=0);
	mp_move(x,v(iminus1));
	if (mp_tstminus(x))
		mp_add(x,n);
	mp_burn(u(0));	/* burn the evidence on the stack...*/
	mp_burn(u(1));
	mp_burn(u(2));
	mp_burn(v(0));
	mp_burn(v(1));
	mp_burn(v(2));
#undef u
#undef v
}	/* mp_inv */
#endif /* OLD_MPINV */

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

iQCVAgUBLVLeoArkCJ6S8691AQH9/QP+LRZ4oXiwNTUkpK7/4uJWhvJCLHPsCNsR
YXruZCgY1448DRpbNV4PCtFg/GhDqvJpsWtWOy3lFZIO9zxrDb/tsIfruIJJZr0w
lpWhhY+xUJNQYuqgu69EOY2IhJPiyZ+AyMuE4uYscuxEKmAEdLm/BAypX1zNplue
NdURpM+pPw4=
=f7BH
-----END PGP SIGNATURE-----





From matthew at gandalf.rutgers.edu  Fri Feb  4 16:09:57 1994
From: matthew at gandalf.rutgers.edu (Matthew Bernardini)
Date: Fri, 4 Feb 94 16:09:57 PST
Subject: Running regularly
Message-ID: <CMM-RU.1.3.760406745.matthew@gandalf.rutgers.edu>


> Matthew Bernardini <matthew at gandalf.rutgers.edu> wrote:
> 
> > Why not make two shell scripts, one that sleeps for so long (say 20 minutes)
> > using the unix sleep command, and then calls the remailer scripts in an
> > infinite while loop.  This would work if you set it up as a background
> > process,and you don't need to be root for it to work.  Only downsides are
> > that when the machine crashes you have to log back in and restart script,
> > your sleep command will always be in the top window if your sys-admin
> > is watching, and you have to be careful not to spawn to many processes and
> > bring the system down.
> 
> I tried this on the system here, but it killed off the process when I
> logged off.
> 
> As for starting too many processes, just don't start them...  leave it
> as one single process that just repeats itself indefinently with sleeps
> in between.
> 

Did the processes get killed BECAUSE you logged off ?
Or did they get killed because you left a single process runnning in the
background for an extended period of time and an automated script killed the
job.  Why not ask the sysadmin how to setup a long computational job for a
couple of days ?  I don't think any sysadmin would have a problem with that.
Then you could find out if the jobs are killed automatically somehow.

If it turns out that it was just the process that was automatically killed
on a time interval, then you could easily write a script that would spawn a
new process and then kill the parent.

Matt





From huntting at glarp.com  Fri Feb  4 16:19:57 1994
From: huntting at glarp.com (Brad Huntting)
Date: Fri, 4 Feb 94 16:19:57 PST
Subject: CERT advisory
In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov>
Message-ID: <199402050015.AA01939@misc.glarp.com>



> Since the command channel is flat ascii, one could extend the protocol
> with a pgp-password command, which would send the password encrypted in the
> server's public key.  Similarly one could use the sort of convention that
> the wu-ftpd does to request encrypted files... simply request file.pgp,
> just like you request file.z, file.gz, etc.

There is an Internet draft (draft-ietf-cat-ftpsec-03.txt) on ftp
encription and authentication extensions.  I dont recall if it
includes a public key method, but if not it would probably be easy
to incorporate.


brad





From nobody at soda.berkeley.edu  Fri Feb  4 16:25:18 1994
From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu)
Date: Fri, 4 Feb 94 16:25:18 PST
Subject: clipper_q-and-a.txt
Message-ID: <199402050021.QAA04630@soda.berkeley.edu>


Q.      Who will hold the escrowed keys?

A.      The government.






From nobody at shell.portal.com  Fri Feb  4 16:30:17 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 16:30:17 PST
Subject: wh_press_secy.statement
Message-ID: <199402050030.QAA21462@jobe.shell.portal.com>


The following is a self contradictory statement, if considered to apply for
the time period of the next 20 years as the govenment's policy, and it down
right PISSES ME OFF. Fuck you, government.

>The Administration believes that the steps being announced today
>will help provide Americans with the telecommunications security
>they need without compromising the capability of law enforcement
>agencies and national intelligence agencies. Today, any American can
>purchase and use any type of encryption product. The
>Administration does not intend to change that policy. Nor do we have
>any intention of restrictiog domestic encryption or mandating the use
>of a particular technology.





From pmetzger at lehman.com  Fri Feb  4 16:55:17 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Fri, 4 Feb 94 16:55:17 PST
Subject: Food for thought
Message-ID: <199402050052.TAA19116@snark>



In conjunction with the latest Big Brother Chip announcements, I've
dug up an article I wrote for the net a while back. Some of it seems a
bit weak now, but so much of it still feels current that I decided to
repost it here.

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

Newsgroups: sci.crypt
Subject: The Escrow Database.
Summary: 
Expires: 
References: <1993Apr18.034352.19470 at news.clarkson.edu> <strnlghtC5puor.704 at netcom.com> <bontchev.735230663 at fbihh>
Sender: 
Followup-To: 
Distribution: 
Organization: Partnership for an America Free Drug
Keywords: 

Here is a disturbing thought.

Now, we no longer live in the days of big filing cabinets. We live in
the electronic age. I asked myself, how big could the escrow database
get? How hard might it be to steal the whole thing, particularly were
I an NSA official operating with the tacit permission of the escrow
houses? (We can pretend that such will not happen, but thats naive.)

Well, lets see. Ten bytes of each escrow half. Lets asume ten bytes of
serial number -- in fact, I believe the serial number is smaller, but
this is an order of magnitude calculation. We assume 250*10^6 as the
population, and that each person has a key. I get five gigabytes for
each of the two escrow databases. Fits conveniently on a single very
valuable Exabyte tape. This can only get easier with time, but who
cares -- I can already hold all the clipper keys in the country in my
pocket on two 8mm tapes.

Admittely, they will think of safeguards. They won't put the whole
database on one disk, prehaps. Maybe they will throw stumbling blocks
in the way. This changes nothing -- they keys will be needed every day
by hundreds if not thousands of law enforcement types, so convenience
will dictate that the system permit quick electronic retrieval. At
some point, with or without collusion by the agencies, those exabyte
tapes are going to get cut. Dorothy Denning and David Sternlight will
doubtless claim this can't happen -- but we know that "can't" is a
prayer, not a word that in this instance connotes realism.

With two exabyte tapes in your pocket, you would hold the keys for
every person's conversations in the country in your hands. Yeah, you
need the "master key" two -- but thats just ten bytes of information
that have to be stored an awful lot of places.

Come to think of it, even if the NSA getting a copy of the database
isn't a threat to you because unlike me you have no contraversial
political views, consider foreign intelligence services. You know, the
ones that David Sternlight wants to protect us from because of the
evil industrial espionage that they do. The French apparently do have
a big spying operation in friendly countries to get industrial
secrets, so he isn't being completely irrational here (although why
our companies couldn't use cryptosystems without back doors is left
unexplained by those that point out this threat.) 

Presumably, foreign intelligence services can get moles into the NSA
and other agencies. We have proof by example of this: its happened
many times. Presumably, someday they will get their hands on some
fraction of the keys. You can't avoid that sort of thing.

Don't pretend that no one unauthorized will ever get their hands on
the escrow databases.

We crypto types are all taught something very important at the
beginning of intro to cryptography -- security must depend on the
easily changed key that you pick to run your system, and not on a
secret. The escrow databases aren't the sorts of secrets that our
teachers told us about, but they are the sort of big secrets they
would lump into this category. Imagine trying to replace 100 million
Clipper chips.

I cannot believe that the NSA or whomever it is thats doing this
doesn't realize all this already. They are too smart. There are too
many of them who have made their bones in the real world. I suspect
that they know precisely what they are doing -- and that what they are
doing is giving us the appearance of safety so that they can continue
to surveil in spite of the growth of strong cryptography. I suspect
that they realize that they can't put things off forever, but they can
try to delay things as long as possible.

Who knows. Maybe even some of the higher ups, the inevitable
bureaucratic types that rise in any organization, really do believe
that this scheme might give people some security, even as their
subordinates in Fort Meade wring their hands over the foolishness of
it all.






From hughes at ah.com  Fri Feb  4 16:59:57 1994
From: hughes at ah.com (Eric Hughes)
Date: Fri, 4 Feb 94 16:59:57 PST
Subject: CERT advisory
In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov>
Message-ID: <9402050055.AA22719@ah.com>


>The big issue, in my mind, is how the ftpd is going to get the key
>to unlock the *system's* private key... Do you compile it into the
>code?  Should ftpd ask for it when it comes up? 

Since active interception is not nearly so easy as passive listening,
it would be appropriate to use a Diffie-Hellman key exchange in this
situation.  This protocol has no persistent private keys, so the issue
of keeping a private key around securely is not an issue.

Eric





From hughes at ah.com  Fri Feb  4 17:05:18 1994
From: hughes at ah.com (Eric Hughes)
Date: Fri, 4 Feb 94 17:05:18 PST
Subject: Running regularly
In-Reply-To: <CMM-RU.1.3.760406745.matthew@gandalf.rutgers.edu>
Message-ID: <9402050100.AA22751@ah.com>


>If it turns out that it was just the process that was automatically killed
>on a time interval, then you could easily write a script that would spawn a
>new process and then kill the parent.

To continue the explanation, no single process would ever execute for
a long time, since it would, phoenix-like, periodically die and be
reborn.

A clever mail filter hack could also check to see if it was still
alive (say, with a socket) and then start it running again if it had
stopped.

Eric





From koontzd at lrcs.loral.com  Fri Feb  4 17:05:20 1994
From: koontzd at lrcs.loral.com (David Koontz )
Date: Fri, 4 Feb 94 17:05:20 PST
Subject: No Subject
Message-ID: <9402050102.AA08460@io.lrcs.loral.com>


Subject: clipper_q-and-a.txt
>Q.      Who will hold the escrowed keys?

>.      The government.

All this bullshit doesnot state that a court order is required, rather
'legal authorization', which means the NSA for foreign intellingence
purposes without a court order.

Perhaps what is needed is statuatory protection to prevent the NSA
from eavesdropping on U.S. Citizens, communicating domestically,
without a court order.

Lets close a loop hole - no more SHAMROCK





From jcook at pro-storm.metronet.com  Fri Feb  4 17:09:57 1994
From: jcook at pro-storm.metronet.com (Julian Cook)
Date: Fri, 4 Feb 94 17:09:57 PST
Subject: Unsubscribe
Message-ID: <b468211@pro-storm.metronet.com>


Unsubscribe me please






From smb at research.att.com  Fri Feb  4 17:39:57 1994
From: smb at research.att.com (smb at research.att.com)
Date: Fri, 4 Feb 94 17:39:57 PST
Subject: CERT advisory
Message-ID: <9402050138.AA04593@toad.com>


	 >The big issue, in my mind, is how the ftpd is going to get the key
	 >to unlock the *system's* private key... Do you compile it into the
	 >code?  Should ftpd ask for it when it comes up? 

	 Since active interception is not nearly so easy as passive listening,
	 it would be appropriate to use a Diffie-Hellman key exchange in this
	 situation.  This protocol has no persistent private keys, so the issue
	 of keeping a private key around securely is not an issue.

But you still have to type a password to a command that itself could
have been compromised.  (Not that D-H wouldn't be a tremendous help,
of course.)

All of the hand-held authenticators I'm familiar with require that
the host -- or a dedicated, trusted, security server -- keep a secret
key per user.  That's not a great idea.  Bellcore's S/Key doesn't,
but I don't know of any hardware devices that implement it.  Another
possibility would be hand-held digital signature boxes that could sign
a random challenge from the host.





From fb at cyberg.win.net  Fri Feb  4 17:45:17 1994
From: fb at cyberg.win.net (Francis Barrett)
Date: Fri, 4 Feb 94 17:45:17 PST
Subject: Magic Money Digicash System
Message-ID: <81@cyberg.win.net>



 > Magic Money is a digital cash system designed for use over
 > electronic mail. The system is online and untraceable. Online
 > means that each transaction involves an exchange with a server,
 > to prevent double-spending. Untraceable means that it is
 > impossible for anyone to trace transactions, or to match a
 > withdrawal with a deposit, or to match two coins in any way.

This is the neatest thing I have read in a long time.  Where can I get
one?

 > The client module then generates proto-coins, which are
 > blinded but unsigned. It produces an output file containing
 > Alice's coins, and the new proto-coins.

 > Bob mails this to the server. The server counts up Alice's
 > coins, checks their signatures, and checks for
 > double-spending. It puts the coins on the cancelled list,
 > signs the proto-coins, and mails them back to Bob. Bob runs
 > his client module on the reply message. It unblinds the
 > signed coins and adds them to his coin file. This completes
 > the transfer.

A few questions.  Since the client which generates the proto-coins is
under the control of the consumer, the bank has no way of making sure
that he is not running his own code, or that the RNG he is using is
cryptographically strong, or even that he is not distributing modified
client programs to other users.

How does the bank deal with collisions in the 16 byte values of coins?
What if the user picks the numeric values for the server to sign in a
way which leaks information about the banks private key?  RSA is much
more secure when signing random-esque data, like a message digest,
than it is when signing numbers provided to it by some outside party.

Similarly, how can the consumer trust the bank's representation that
money has already been spent?  Surely the bank should be required to
publish a list of cancelled coins and timestamps with a running MD5
hash periodically for inspection by the unwashed masses.

What do you do about lost messages from the server to the client.
Once coins have been recorded as spent, they cannot be redeemed again.
Yet the mail message containing the new coins may have been lost in
transit.


---------------------------------------------------------------
Francis Barrett, F.R.C. |  Thou canst not travel on the path  |
The Cybernetics Guild   |  before thou hast become the Path   |
fb at cyberg.win.net       |  itself.                            |
---------------------------------------------------------------






From brown  Fri Feb  4 14:47:38 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:38 -0500
Subject: clipper_q-and-a.txt
Message-ID: <199402042247.RAA00190@eff.org>

>From the White House   

*****************************************************************

Embargoed until 3:00 p.m. EST Feb. 4, 1994

QUESTIONS AND ANSWERS ABOUT THE
CLINTON ADMINISTRATION'S ENCRYPTION POLICY

Q. 	What were the findings of the encryption technology review?

A. 	The review confirmed that sound encryption technology is 
needed to help ensure that digital information in both computer 
and telecommunications systems is protected against unauthorized 
disclosure or tampering. It also verified the importance of 
preserving the ability of law enforcement to understand encrypted 
communications when conducting authorized wiretaps. Key escrow 
technology meets these objectives.

Specific decisions were made to enable federal agencies and the 
private sector to use the key escrow technology on a voluntary 
basis and to allow the export of key escrow encryption products.

In addition, the Department of State will streamline export 
licensing procedures for products that can be exported under 
current regulations in order to help U.S. companies to sell their 
products abroad.

To meet the critical need for ways to verify the author and sender 
of an electronic message -- something that is crucial to business 
applications for the National Information Infrastructure -- the 
federal government is committed to ensuring the availability of a 
royalty-free, public-domain Digital Signature Standard.

Finally, an interagency working group has been established to 
continue to address these issues and to maintain a dialogue with 
industry and public interest groups.

Q. 	 Who has been consulted during this review? The Congress? 
Industry? What mechanism is there for continuing consultation?

A.	 Following the President's directive announced on April 16, 
1993, extensive discussions have been held with Congress, 
industry, and privacy rights groups on encryption issues. Formal 
public comment was solicited on the Escrowed Encryption Standard 
and on a wide variety of issues related to the review through the 
Computer System Security and Privacy Advisory Board.

The White House Office of Science and Technology Policy and the 
National Security Council will chair the interagency working 
group. The group will seek input from the private sector both 
informally and through several existing advisory committees. It 
also will work closely with the Information Policy Committee of 
the Information Infrastructure Task Force, which is responsible 
for coordinating Administration telecommunications and information 
policy.

Q. 	If national security and law enforcement interests require 
continued export controls of encryption, what specific benefits 
can U.S. encryption manufacturers expect?

A.	The reforms will simplify encryption product export licensing 
and speed the review of encryption product exports. Among other 
benefits, manufacturers should see expedited delivery of products, 
reduced shipping and reporting costs, and fewer individual license 
requests -- especially for small businesses that cannot afford 
international distributors. A personal exemption for business 
travellers using encryption products will eliminate delays and 
inconvenience when they want to take encryption products out of 
the U.S. temporarily.

Q.	Why is the key escrow standard being adopted?

A.	The key escrow mechanism will provide Americans and 
government agencies with encryption products that are more secure, 
more convenient, and less expensive than others readily available 
today -- while at the same time meeting the legitimate needs of 
law enforcement.

Q. 	Will the standard be mandatory?

A. 	No. The Administration has repeatedly stressed that the key 
escrow technology, and this standard, is for voluntary use by 
federal and other government agencies and by the private sector. 
The standard that is being issued only applies to federal agencies 
-- and it is voluntary.

Does this approach expand the authority of government agencies to 
listen in on phone conversations?

No Key escrow technology provides government agencies with no 
[sic] new authorities to access the content of the private 
conversations of Americans.

Q.	Will the devices be exportable? Will other devices that use 
the government hardware?

A.	Yes. After an initial review of the product, the State 
Department will permit the export of devices incorporating key 
escrow technology to most end users. One of the attractions of 
this technology is the protection it can give to U.S. companies 
operating at home and abroad.

Q.	Suppose a law enforcement agency is conducting a wiretap on a 
drug smuggling ring and intercepts a conversation encrypted using 
the device. What would they have to do to decipher the message?

A.	They would have to obtain legal authorization, normally a 
court order, to do the wiretap in the first place. They would then 
present documentation, including a certification of this 
authorization, to the two entities responsible for safeguarding 
the keys. (The key is split into component parts, which are stored 
separately in order to ensure the security of the key escrow 
system.) They then obtain the components for the keys for the 
device being used by the drug smugglers. The components are then 
combined and the message can be read.

Q.	Who will hold the escrowed keys?

A.	The Attorney General has selected two U.S. agencies to hold 
the escrowed key components: the Treasury Department's Automated 
Systems Division and the Commerce Department's National Institute 
of Standards and Technology.

Q.	How strong is the security in the device? How can I be sure 
how strong the security is?

A.	This system is more secure than many other voice encryption 
system readily available today. While the algorithm upon which the 
Escrowed Encryption Standard is based will remain classified to 
protect the security of the system, an independent panel of 
cryptography experts found that the algorithm provides significant 
protection. In fact, the panel concluded that it will be 36 years 
until the cost of breaking the algorithm will be equal to the cost 
of breaking the current Data Encryption Standard now being used.

Q.	Is there a "trap door" that would allow unauthorized access 
to the keys?

A.	No. There is no trapdoor.

Q.	Whose decision was it to propose this product?

A.	The National Security Council, the Justice Department, the 
Commerce Department, and other key agencies were involved in this 
decision. The approach has been endorsed by the President, the 
Vice President, and appropriate Cabinet officials.





From brown  Fri Feb  4 14:47:39 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:39 -0500
Subject: doj_escrow_intercept.procedures
Message-ID: <199402042247.RAA00193@eff.org>

U.S. Department of Justice
Washington, D.C. 20530

February 4, 1994



AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS    
     IN CONJUNCTION WITH INTERCEPTS PURSUANT TO TITLE III

The following are the procedures for the release of escrowed key 
components in conjunction with lawfully authorized interception of 
communications encrypted with a key-escrow encryption method. 
These procedures cover all electronic surveillance conducted 
pursuant to Title III of the Omnibus crime Control and Safe 
Streets Act of 1968, as amended (Title III), Title 18, United 
States Code, Section 2510 et seq.

	1) In each case there shall be a legal authorization for the 
interception of wire and/or electronic communications.

	2) All electronic surveillance court orders under Title III 
shall contain provisions authorizing after-the-fact minimization, 
pursuant to 18 U.S.C. 2518(5), permitting the interception and 
retention of coded communications, including encrypted 
communications.

	3) In the event that federal law enforcement agents discover 
during the course of any lawfully authorized interception that 
communications encrypted with a key escrow encryption method are 
being utilized, they may obtain a certification from the 
investigative agency conducting the investigation, or the Attorney 
General of the United States or designee thereof. Such 
certification shall

		(a) identify the law enforcement agency or other 
authority conducting the interception and the person providing the 
certification; 

		(b) certify that necessary legal authorization has been 
obtained to conduct electronic surveillance regarding these 
communications; 

		(c) specify the termination date of the period for which 
interception has been authorized; 

		(d) identify by docket number or other suitable method 
of specification the source of the authorization;

		(e) certify that communications covered by that 
authorization are being encrypted with a key-escrow encryption 
method;

		(f) specify the identifier (ID) number of the key escrow 
encryption chip providing such encryption; and

		(g) specify the serial (ID) number of the key-escrow 
decryption device that will be used by the law enforcement agency 
or other authority for decryption of the intercepted 
communications.

	4) The agency conducting the interception shall submit this 
certification to each of the designated key component escrow 
agents. If the certification has been provided by an investigative 
agency, as soon thereafter as practicable, an attorney associated 
with the United States Attorney's Office supervising the 
investigation shall provide each of the key component escrow 
agents with written confirmation of the certification.

	5) Upon receiving the certification from the requesting 
investigative agency, each key component escrow agent shall 
release the necessary key component to the requesting agency. The 
key components shall be provided in a manner that assures they 
cannot be used other than in conjunction with the lawfully 
authorized electronic surveillance for which they were requested.

	6) Each of the key component escrow agents shall retain a 
copy of the certification of the requesting agency, as well as the 
subsequent confirmation of the United States Attorney's Office. In 
addition, the requesting agency shall retain a copy of the 
certification and provide copies to the following for retention in 
accordance with normal record keeping requirements:

		(a) the United States Attorney's Office supervising the 
investigation, and
		
		(b) the Department of Justice, Office of Enforcement 
Operations.

	7) Upon, or prior to, completion of the electronic 
surveillance phase of the investigation, the ability of the 
requesting agency to decrypt intercepted communications shall 
terminate, and the requesting agency may not retain the key 
components.

	8) The Department of Justice shall, in each such case,

		(a) ascertain the existence of authorizations for 
electronic surveillance in cases for which escrowed key components 
have been released;

		(b) ascertain that key components for a particular key 
escrow encryption chip are being used only by an investigative 
agency authorized to conduct electronic surveillance of 
communications encrypted with that chip; and 

		(c) ascertain that, no later than the completion of the 
electronic surveillance phase of the investigation, the ability of 
the requesting agency to decrypt intercepted communications is 
terminated.

	9) In reporting to the Administrative Office of the United 
States Courts pursuant to 18 U.S.C. Section 2519(2), the Assistant 
Attorney General for the Criminal Division shall, with respect to 
any order for authorized electronic surveillance for which 
escrowed encryption components were released and used for 
decryption, specifically note that fact.

These procedures do not create, and are not intended to create, 
any substantive rights for individuals intercepted through 
electronic surveillance, and noncompliance with these procedures 
shall not provide the basis for any motion to suppress or other 
objection to the introduction of electronic surveillance evidence 
lawfully acquired.

*************************************************************



U.S. Department of Justice
Washington, D.C. 20530

February 4, 1994



AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS
    IN CONJUNCTION WITH INTERCEPTS PURSUANT TO STATE STATUTES

Key component escrow agents may only release escrowed key 
components to law enforcement or prosecutorial authorities for use 
in conjunction with lawfully authorized interception of 
communications encrypted with a key-escrow encryption method. 
These procedures apply to the release of key components to State 
and local law enforcement or prosecutorial authorities for use in 
conjunction with interceptions conducted pursuant to relevant 
State statutes authorizing electronic surveillance, and Title III 
of the Omnibus crime Control and Safe Streets Act of 1968, as 
amended, Title 18, United States Code, Section 2510 et seq.

	1) The state or local law enforcement or prosecutorial 
authority must be conducting an interception of wire and/or 
electronic communications pursuant to lawful authorization.

	2) Requests for release of escrowed key components must be 
submitted to the key component escrow agents by the principal 
prosecuting attorney of the State, or of a political subdivision 
thereof, responsible for the lawfully authorized electronic 
surveillance.

	3) The principal prosecuting attorney of such State or 
political subdivision of such State shall submit with the request 
for escrowed key components a certification that shall

		(a) identify the law enforcement agency or other 
authority conducting the interception and the prosecuting attorney 
responsible therefor; 

		(b) certify that necessary legal authorization for 
interception has been obtained to conduct electronic surveillance 
regarding these communications; 

		(c) specify the termination date of the period for which 
interception has been authorize;

		(d) identify by docket number or other suitable method 
of specification the source of the authorization;

		(e) certify that communications covered by that 
authorization are being encrypted with a key-escrow encryption 
method;

		(f) specify the identifier (ID) number of the key escrow 
chip providing such encryption; and 

		(g) specify the serial (ID) number of the key-escrow 
decryption device that will be used by the law enforcement agency 
or other authority for decryption of the intercepted 
communications.

	4) Such certification must be submitted by the principal 
prosecuting attorney of that State or political subdivision to 
each of the designated key component escrow agents.

	5) Upon receiving the certification from the principal 
prosecuting attorney of the State or political subdivision, each 
key component escrow agent shall release the necessary key 
component to the intercepting State or local law enforcement 
agency or other authority. The key components shall be provided in 
a manner that assures they cannot be used other than in 
conjunction with the lawfully authorized electronic surveillance 
for which they were requested.

	6) Each of the key component escrow agents shall retain a 
copy of the certification of the principal prosecuting attorney of 
the State or political subdivision. In addition, such prosecuting 
attorney shall provide a copy of the certification to the 
Department of Justice, for retention in accordance with normal 
record keeping requirements.

	7) Upon, or prior to, completion of the electronic 
surveillance phase of the investigation, the ability of the 
intercepting law enforcement agency or other authority to decrypt 
intercepted communications shall terminate, and the intercepting 
law enforcement agency or other authority may not retain the key 
components.

	8) The Department of Justice may, in each such case, make 
inquiry to

		(a) ascertain the existence of authorizations for 
electronic surveillance in cases for which escrowed key components 
have been released;

		(b) ascertain that key components for a particular key 
escrow encryption chip are being used only by an investigative 
agency authorized to conduct electronic surveillance of 
communications encrypted with that chip; and

		(c) ascertain that, no later than the completion of the 
electronic surveillance phase of the investigation, the ability of 
the requesting agency to decrypt intercepted communications is 
terminated.

	9) In reporting to the Administrative Office of the United 
States Courts pursuant to 18 U.S.C. Section 2519(2), the principal 
prosecuting attorney of a State or of a political subdivision of a 
State may, with respect to any order for authorized electronic 
surveillance for which escrowed encryption components were 
released and used for decryption, desire to note that fact.

These procedures do not create, and are not intended to create, 
any substantive rights for individuals intercepted through 
electronic surveillance, and noncompliance with these procedures 
shall not provide the basis for any motion to suppress or other 
objection to the introduction of electronic surveillance evidence 
lawfully acquired.

*************************************************************



U.S. Department of Justice
Washington D.C. 20530

February 4, 1994



AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS
         IN CONJUNCTION WITH INTERCEPTS PURSUANT TO FISA

The following are the procedures for the release of escrowed key 
components in conjunction with lawfully authorized interception of 
communications encrypted with a key-escrow encryption method. 
These procedures cover all electronic surveillance conducted 
pursuant to the Foreign Intelligence Surveillance Act (FISA), Pub. 
L. 95-511, which appears at Title 50, U.S. Code, Section 1801 et 
seq.

	1 ) In each case there shall be a legal authorization for the 
interception of wire and/or electronic communications.

	2) In the event that federal authorities discover during the 
course of any lawfully authorized interception that communications 
encrypted with a key-escrow encryption method are being utilized, 
they may obtain a certification from an agency authorized to 
participate in the conduct of the interception, or from the 
Attorney General of the United States or designee thereof. Such 
certification shall

		(a) identify the agency participating in the conduct of 
the interception and the person providing the certification;

		to conduct electronic surveillance regarding these 
communications;

		(c) specify the termination date of the period for which 
interception has been authorized;

		(d) identify by docket number or other suitable method 
of specification the source of the authorization;

		(e) certify that communications covered by that 
authorization are being encrypted with a key-escrow encryption 
method;

		(f) specify the identifier (ID) number of the key escrow 
encryption chip providing such encryption; and

		(g) specify the serial (ID) number of the key-escrow 
decryption device that will be used by the agency participating in 
the conduct of the interception for decryption of the intercepted 
communications.

	4) This certification shall be submitted to each of the 
designated key component escrow agents. If the certification has 
been provided by an agency authorized to participate in the 
conduct of the interception, a copy shall be provided to the 
Department of Justice, Office of Intelligence Policy and Review. 
As soon as possible, an attorney associated with that office shall 
provide each of the key component escrow agents with written 
confirmation of the certification.

	5) Upon receiving the certification, each key component 
escrow agent shall release the necessary key component to the 
agency participating in the conduct of the interception. The key 
components shall be provided in a manner that assures they cannot 
be used other than in conjunction with the lawfully authorized 
electronic surveillance for which they were requested.

	6) Each of the key component escrow agents shall retain a 
copy of the certification, as well as the subsequent written 
confirmation of the Department of Justice, Office of Intelligence 
Policy and Review.

	7) Upon, or prior to, completion of the electronic 
surveillance phase of the investigation, the ability of the agency 
participating in the conduct of the interception to decrypt 
intercepted communications shall terminate, and such agency may 
not retain the key components.

	8)   The Department of Justice shall, in each such case,

		(a) ascertain the existence of authorizations for 
electronic surveillance in cases for which escrowed key components 
have been released;

		(b) ascertain that key components for a particular key 
escrow encryption chip are being used only by an agency authorized 
to participate in the conduct of the interception of 
communications encrypted with that chip; and 

		(c) ascertain that, no later than the completion of the 
electronic surveillance phase of the investigation, the ability of 
the agency participating in the conduct of the interception to 
decrypt intercepted communications is terminated.

	9) Reports to the House Permanent Select Committee on 
Intelligence and the Senate Select Committee on Intelligence, 
pursuant to Section 108 of FISA, shall, with respect to any order 
for authorized electronic surveillance for which escrowed 
encryption components were released and used for decryption, 
specifically note that fact.

These procedures do not create, and are not intended to create, 
any substantive rights for individuals intercepted through 
electronic surveillance, and noncompliance with these procedures 
shall not provide the basis for any motion to suppress or other 
objection to the introduction of electronic surveillance evidence 
lawfully acquired.






From brown  Fri Feb  4 14:47:40 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:40 -0500
Subject: gore_crypto.statement
Message-ID: <199402042247.RAA00195@eff.org>

THE WHITE HOUSE
OFFICE OF THE VICE PRESIDENT

EMBARGOED UNTIL, 3: 00 PM EST             CONTACT: 202/456-7035 
February 4, 1994


STATEMENT OF THE VICE PRESIDENT


Today's announcements on encryption represent important steps in 
the implementation of the Administration's policy on this critical 
issue. Our policy is designed to provide better encryption to 
individuals and businesses while ensuring that the needs of law 
enforcement and national security are met.

Encryption is a law and order issue since it can be used by criminals 
to thwart wiretaps and avoid detection and prosecution. It also has 
huge strategic value. Encryption technology and cryptoanalysis 
turned the tide in the Pacific and elsewhere during World War II.

[end of statement]





From brown  Fri Feb  4 14:47:41 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:41 -0500
Subject: interagency_workgroup.notice
Message-ID: <199402042247.RAA00199@eff.org>

>From the White House
Feb. 4, 1994

******************************************************************

WORKING GROUP ON DATA SECURITY



The Administration has created a new interagency working on data 
security to deal with issues like encryption and digital 
telephony. This group will be chaired by the White House Office of 
Science and Technology Policy and the National Security Council 
and will include representatives of the agencies that have 
participated in Presidential Review Directive 27, which called for 
a comprehensive review of the impact of encryption technology and 
advanced digital telecomrnunications systems. Agencies 
participating in the new working group include the Office of 
Management and Budget, FBI, Department of Justice, Department of 
Comrnerce, National Security Agency, the Department of Treasury, 
and the Department of State. The group will work closely with the 
Inforrnation Comrnittee of the Information Infrastructure Task 
Force, which is responsible for coordinating Administration 
telecommunications and inforrnation policy. It will seek input 
from the private sector both informally and through groups like 
the National Security Telecommunications Advisory Committee and 
the U.S. Advisory Committee on the National Information 
Infrastructure.

The working group will develop and irnplement Administration 
policies on encryption. Advanced encryption technology can provide 
better privacy protection for individuals, but can also thwart 
efforts by law enforcement agencies to use wiretaps to catch and 
prosecute criminals. The working group will attempt to reconcile 
the need of privacy and the needs of law enforcement. Last April, 
the Administration announced development of the Clipper chip, a 
new computer chip designed to provide better telecomrnunications 
security without compromising the ability of law enforcement to do 
wiretaps. The working group will work with industry to develop and 
apply technologies like the Clipper Chip, to evaluate possible 
alternatives to the Clipper Chip, and to review and refine 
Administration policies regarding encryption as developments 
warrant.

In addition, the working group will coordinate Administration 
policies regarding digital telephony. As more and more telephone 
companies install high-speed, digital communications links, it 
becomes more and more difficult for law enforcement agencies to 
conduct wiretaps. The working group will work with industry to 
ensure that new digital telecommunications systems are designed in 
a way that ensures that do not prevent courtauthorized wiretaps.

For more information on the interagency working group, contact 
Matt Heymann at NIST Public Affairs (301/975-2758), Mike Nelson at 
OSTP (202/395-6175), or Ray Mislock at NSC (202/395-4614).





From brown  Fri Feb  4 14:47:41 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:41 -0500
Subject: harris.statement
Message-ID: <199402042247.RAA00197@eff.org>

United States Department of State
Washington, D.C. 20520

EMBARGOED FOR RELEASE, 3:00 PM EST, FEB. 4, 1994



Statement of
Dr. Martha Harris
Deputy Assistant Secretary of State
for Political-Military Affairs
February 4, 1994


Encryption -- Export Control Reform


The Secretary of State is announcing today measures arising from 
the Administration's decision to reform export control procedures 
applicable to products incorporating encryption technology. These 
reforms are part of the Administration's effort to eliminate 
unnecessary controls and ensure efficient implementation. The 
reforms will simplify encryption product export licensing and 
speed the review of encryption product exports, thus helping U.S. 
manufacturers to compete more effectively in the global market. 
While there will be no changes in the types of equipment 
controlled by the Munitions List, we are announcing measures to 
expedite licensing.

Last year the President announced an initiative to encourage U.S. 
manufacturers and users of encryption to take advantage of a 
government technology (the key-escrow chip) that provides 
excellent security while ensuring that the Government has a means 
to decode the encryption when lawfully authorized, such as when 
executing a court-authorized warrant in connection with a criminal 
investigation. At the time he announced this initiative, the 
President directed a comprehensive review of U.S. policy regarding 
domestic use and export of encryption technology. The reforms we 
are announcing today result from that review.

The President has determined that vital U.S. national security and 
law enforcement interests compel maintaining appropriate control 
of encryption. Still, there is much that can be done to reform 
existing controls to ensure that they are efficiently implemented 
and to maintain U.S. leadership in the world market for encryption 
technology. Accordingly, the President has asked the Secretary of 
State to take immediate action to implement a number of procedural 
reforms. The reforms are:

* License Reform: Under new licensing arrangements, encryption 
manufacturers will be able to ship their products from the United 
States directly to customers within approved regions without 
obtaining individual licenses for each end user. This will improve 
the ability of our manufacturers to provide expedited delivery of 
products, and to reduce shipping and tracking costs. It should 
also reduce the number of individual license requests, especially 
for small businesses that cannot afford international 
distributors.

* Rapid review of export license applications: A significant 
number of encryption export license applications can be reviewed 
more quickly. For such exports, we have set a license turnaround 
goal of two working days.

* Personal use exemption: We will no longer require that U.S. 
citizens obtain an export license prior to taking encryption 
products out of the U.S. temporarily for their own personal use. 
In the past, this requirement caused delays and inconvenience for 
business travellers.

* Allow exports of key-escrow encryption: After initial review, 
key-escrow encryption products may now be exported to most end 
users. Additionally, key-escrow products will qualify for special 
licensing arrangements.

These reforms should have the effect of minimizing the impact of 
export controls on U.S. industry. The Department of State will 
take all appropriate actions to ensure that these reforms are 
implemented as quickly as possible. The Secretary of State asks 
that encryption product manufacturers evaluate the impact of these 
reforms over the next year and provide feedback both on how the 
reforms have worked out and on recommendations for additional 
procedural reforms.

The contact point for further information on these reforms is Rose 
Biancaniello, Office of Defense Trade Controls, Bureau of 
Political-Military Affairs, Department of State, (703) 875-6644.





From brown  Fri Feb  4 14:47:42 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:42 -0500
Subject: reno_key_escrow.statement
Message-ID: <199402042247.RAA00201@eff.org>

Department of Justice

EMBARGOED FOR 3 P.M. RELEASE                                   AG 
FRIDAY, FEBRUARY 4, 1994                           (202) 616-2771


ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS



Attorney General Janet Reno today announced selection of the two 
U.S. Government entities that will hold the escrowed key 
components for encryption using the key escrow encryption method. 
At the same time, the Attorney General made public procedures 
under which encryption key components will be released to 
government agencies for decrypting communications subject to 
lawful wiretaps.

Key Escrow Encryption (formerly referred to as Clipper Chip ) 
strikes an excellent balance between protection of communications 
privacy and protection of society. It permits the use in 
commercial telecommunications products of chips that provide 
extremely strong encryption, but can be decrypted, when necessary, 
by government agencies conducting legally authorized wiretaps. 
Decryption is accomplished by use of keys--80-bit binary numbers--
that are unique to each individual encryption chip. Each unique 
key is in turn split into two components, which must be recombined 
in order to decrypt communications. Knowing one component does not 
make decryption any more feasible than not knowing either one.

The two escrow agents are the National Institute of Standards and 
Technology (NIST), a part of the Department of Commerce, and the 
Automated Systems Division of the Department of the Treasury. The 
two escrow agents were chosen because of their abilities to 
safeguard sensitive information, while at the same time being able 
to respond in a timely fashion when wiretaps encounter encrypted 
communications. In addition, NIST is responsible for establishing 
standards for protection of sensitive, unclassified information in 
Federal computer systems.

The escrow agents will act under strict procedures, which are 
being made public today, that will ensure the security of the key 
components and govern their release for use in conjunction with 
lawful wiretaps. They will be responsible for holding the key 
components: for each chip, one agent will hold one of the key 
components, and the second agent will hold the other. Neither will 
release a key component, except to a government agency with a 
requirement to obtain it in connection with a lawfully authorized 
wiretap. The system does not change the rules under which 
government agencies are authorized to conduct wiretaps.

When an authorized government agency encounters suspected key-
escrow encryption, a written request will have to be submitted to 
the two escrow agents. The request will, among other things, have 
to identify the responsible agency and the individuals involved; 
certify that the agency is involved in a lawfully authorized 
wiretap; specify the wiretap's source of authorization and its 
duration; and specify the serial number of the key-escrow 
encryption chip being used. In every case, an attorney involved in 
the investigation will have to provide the escrow agents assurance 
that a validly authorized wiretap is being conducted.

Upon receipt of a proper request, the escrow agents will transmit 
their respective key components to the appropriate agency. The 
components will be combined within a decrypt device, which only 
then will be able to decrypt communications protected by key-
escrow encryption. When the wiretap authorization ends, the device 
s ability to decrypt communications using that particular chip 
will also be ended.

The Department of Justice will, at the various stages of the 
process, take steps to monitor compliance with the procedures.





From brown  Fri Feb  4 14:47:44 1994
From: brown (Dan Brown)
Date: Fri, 4 Feb 1994 17:47:44 -0500
Subject: wh_press_secy.statement
Message-ID: <199402042247.RAA00203@eff.org>

THE WHITE HOUSE                                 CONTACT: 202 156-7035
OFFlCE OF THE PRESS SECRETARY

EMBARGOED UNTIL 3 PM (EST) FRIDAY, February 4, 1994


STATEMENT OF THE PRESS SECRETARY


Last April, the Administration announced a comprehensive 
interagency review of encryption technology, to be overseen by the 
National Security Council. Today, the Administration is taking a 
number of steps to implement the recommendations resulting from 
that review.

Advanced encryption technology offers individuals and businesses 
an inexpensive and easy way to encode data and telephone 
conversations. Unfortunately, the same encryption technology that 
can help Americans protect business secrets and personal privacy 
can also be used by terrorists, drug dealers, and other criminals.

In the past, Federal policies on encryption have reflected primarily 
the needs of law enforcement and national security. The Clinton 
Administration has sought to balance these needs with the needs of 
businesses and individuals for security and privacy. That is why, 
today the National Institute of Standards ant Technology (NIST) is 
committing to ensure a royalty-free, public-domain Digital Signature 
Standard. Over many years, NIST has been developing digital 
signature technology that would provide a way to verify the author 
and sender of an electronic message. Such technology will be critical 
for a wide range of business applications for the National 
Information Infrastructure. A digital signature standard will enable 
individuals to transact business electronically rather than having to 
exchange signed paper contracts. The Administration has determined 
that such technology should not be subject to private royalty 
payments, and it will be taking steps to ensure that royalties are not 
required for use of a digital signature. Had digital signatures been in 
widespread use, the recent security problems with the Intemet 
would have been avoided.

Last April, the Administration released the Key Escrow chip (also 
known as the "Clipper Chip") that would provide Americans with 
secure telecommunications without compromising the ability of law 
enforcement agencies to carry out legally authorized wiretaps. Today, 
the Department of Commerce and the Department of Justice are 
taking steps to enable the use of such technology both in the U.S. and 
overseas. At the same time, the Administration is announcing its 
intent to work with industry to develop other key escrow products 
that might better meet the needs of individuals and industry, 
particularly the American computer and telecommunications 
industry. Specific steps being announced today include:

-  Approval by the Commerce Secretary of the Escrowed Encryption     
   Standard (EES) as a voluntary Federal Informahon Processing    
   Standard, which will enable govemment gencies to purchase the  
   Key Escrow chip for use with telephones nd modems. The 
   department's National Institute of Standards and Technology   
   (NIST) will publish the standard.

-  Publication by the Department of Justice of procedurs for the     
   release of escrowed keys and the announcement of NIST and the 
   Automated Services Division of the Treasury Department as the 
   escrow agents that will store the keys needed for decryption of 
   communications using the Key Escrow chip. Nothing in these 
   procedures will diminish tne existing legal and procedural 
   requirements that protect Americans from unauthorized wiretaps.

-  New procedures to allow export of products containing the Key 
   Escrow chip to most countries.

In addition, the Department of State will streamline export licensing 
procedures for encryption products that can be exported under 
current export regulations in order to help American companies sell 
their products overseas. In the past, it could take weeks for a 
company to obtain an export license for encryption products, and 
each shipment might require a separate license. The new procedures 
announced today will substantially reduce administrative delays and 
paperwork for encryption exports.

To implement the Administration's encryption policy, an interagency 
Working Group on Encryption and Telecommunications has been 
established. It will be chaired by the White House Office of Science 
and Technology Policy and the National Security Council and will 
include representatives of the Departments of Commerce, Justice, 
State, and Treasury as well as the FBI, the National Security Agency, 
the Office of Management and Budget, and the National Economic 
Council. This group will work with industry and public-interest 
groups to develop new encryption technologies and to review and 
refine Administration policies regarding encryption, as needed.

The Administration is expanding its efforts to work with industry to 
improve on the Key Escrow chip, to develop key-escrow software, 
and to examine alternatives to the Key Escrow chip. NIST will lead 
these efforts and will request additional staff and resources for this 
purpose.

We understand that many in industry would like to see all 
encryption products exportable. However, if encryption technology is 
made freely available worldwide, it would no doubt be usod 
extensively by terrorists, drug dealers, and other criminals to harm 
Americans both in the U.S. and abroad. For this reason, the 
Administration will continue to restrict export of the most 
sophisticated encryption devices, both to preserve our own foreign 
intelligence gathering capability and because of the concerns of our 
allies who fear that strong encryption technology would inhibit their 
law enforcement capabilities.

At the same time, the Administration understands the benefits that 
encryption and related technologies can provide to users of 
computers and telecommunications networks. Indeed, many of the 
applications of the evolving National Information Infrastructure will 
require some form of encryption. That is why the Administration 
plans to work more closely with the private sector to develop new 
forms of encryption that can protect privacy and corporate secrets 
without undermining the ability of law-enforcement agencies to 
conduct legally authorized wiretaps. That is also why the 
Administration is committed to make available free of charge a 
Digital Signature Standard.

The Administration believes that the steps being announced today 
will help provide Americans with the telecommunications security 
they need without compromising the capability of law enforcement 
agencies and national intelligence agencies. Today, any American can 
purchase and use any type of encryption product. The 
Administration does not intend to change that policy. Nor do we have 
any intention of restrictiog domestic encryption or mandating the use 
of a particular technology.






From smb at research.att.com  Fri Feb  4 17:49:56 1994
From: smb at research.att.com (smb at research.att.com)
Date: Fri, 4 Feb 94 17:49:56 PST
Subject: No Subject
Message-ID: <9402050149.AA05059@toad.com>


	 Subject: clipper_q-and-a.txt
	 >Q.      Who will hold the escrowed keys?

	 >.      The government.

	 All this bullshit doesnot state that a court order is required, rather
	 'legal authorization', which means the NSA for foreign intellingence
	 purposes without a court order.

	 Perhaps what is needed is statuatory protection to prevent the NSA
	 from eavesdropping on U.S. Citizens, communicating domestically,
	 without a court order.

The law already says that.  The government's right to spy on non-Americans
is spelled out in the Foreign Intelligence Surveillance Act, 50 USC 1801.
Enforcing it is another matter, of course.

I saw an AP wire story today that's illuminating.  It seems that for
years, members of the Tennessee Highway Patrol have been subpoenaing
phone company records without proper authority.  They've been using
a rubber stamp with the commissioner's signature, apparently without
his knowledge or consent -- which he probably wouldn't have given, since
under Tennessee law the Highway Patrol can deal with crimes committed
on a highway, car theft, odometer tampering, or (of course) drug
dealing.  The only state police agency that has such subpoena authority
is the Tennessee Bureau of Investigation -- and even they're limited;
the D.A. is supposed to do such things after authorization by the grand
jury.

And the phone company -- they complied, of course; they had no idea
(they said) that the subpoenas were illegal.





From nobody at shell.portal.com  Fri Feb  4 18:55:19 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Fri, 4 Feb 94 18:55:19 PST
Subject: KERT Advisory
Message-ID: <199402050251.SAA12755@jobe.shell.portal.com>


From: KERT Advisory <kert-advisory-request at kremvax.su>
Date: Fri, 4 Feb 94 21:14:40 EST
To: kert-advisory at kremvax.su
Subject: KERT Advisory - Ongoing Network Monitoring Attacks
Organization: Komputer Emergency Response Team : 714-731-0699

=============================================================================
KA-94:01                         KERT Advisory
                               February 4, 1994
                      Ongoing Network Monitoring Attacks
-----------------------------------------------------------------------------
                                   

In the past week, KERT has observed a dramatic increase in reports of
intruders wishing to monitor network traffic.  Systems of some service
providers have been compromised, and all systems that offer remote
access through normal channels are at risk.  The intruders have
already captured information from tens of thousands of users
outside the political boundaries of the United States.

The current attacks involve a network monitoring tool that uses the
promiscuous mode of a specific network interface, the telephone, to
capture host and user identities and data on newly established
telephone sessions.

In the short-term, CERT recommends that all users at all sites that offer
remote access resist attempts by any persons or organizations to
install Trojan-horse devices which purport to "enhance" privacy but in
fact are designed to provide unauthorized access to sensitive information.

While the current attack is specific to /dev/Clipper, the short-term
workaround does not constitute a solution.  The best long-term
solution currently available for this attack is to reduce or eliminate
the transmission of user data in clear-text over the network, and to
reduce or eliminate the access of the intruders to the network
interface design and specification process.

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






From mech  Fri Feb  4 16:01:34 1994
From: mech (Stanton McCandlish)
Date: Fri, 4 Feb 1994 19:01:34 -0500 (EST)
Subject: Alert--Admin. names escrow agents, no compromise on Clipper - 7 files
Message-ID: <199402050001.TAA02297@eff.org>

EFF Press Release            04/04/94             * DISTRIBUTE WIDELY *

At two briefings, Feb. 4, 1994, the Clinton Administration and various
agencies gave statements before a Congressional committee, and later
representatives of civil liberties organizations, industry spokespersons
and privacy advocates.  The Electronic Frontier Foundation's position,
based on what we have seen and heard from the Administration today, is
that the White House is set on a course that pursues Cold War national
security and law enforcement interests to the detriment of individual
privacy and civil liberties.

The news is grim.  The Administration is:

 * not backing down on Clipper
 * not backing down on key escrow
 * not backing down on selection of escrow agents
 * already adamant on escrowed key access procedures
 * not willing to elminate ITAR restrictions
 * hiding behind exaggerated threats of "drug dealers" and "terrorists"

The material released to the industry and advocacy version of the briefing
have been placed online at ftp.eff.org (long before their online
availability from goverment access sites, one might add).  See below for
specific details.

No information regarding the Congressional committee version of the briefing
has been announced.  EFF Director Jerry Berman, who attended the private
sector meeting, reported the following:

"The White House and other officials briefed industry on its Clipper chip
and encryption review. While the review is not yet complete, they have
reached several policy conclusions.  First, Clipper will be proposed as
a new Federal Information Processing Standard (FIPS) next Wednesday. [Feb.
9]  It will be "vountary" for government agencies and the private sector
to use. They are actively asking other vendors to jump in to make the
market a Clipper market. Export licensing processes will be speeded up but
export restrictions will not be lifted in the interests of national
security. The reason was stated bluntly at the briefing : to frustrate
competition with clipper by other powerful encryption schemes by making
them  difficult to market, and to "prevent" strong encryption from leaving
the country thus supposedly making the job of law enforcement and
intelligence more difficult.  Again in the interest of national security. Of
course, Clipper will be exportable but they would not comment on how other
governments will view this.  Treasury and NIST will be the escrow agents
and Justice asserted that there was no necessity for legislation to
implement the escrow procedures.

"I asked if there would be a report to explain the rationale for choosing
these results - we have no explanation of the Administration's thinking, or
any brief in support of the results. They replied that there would be no
report because they have been unable to write one, due to the complexity of
the issue.

"One Administation spokesperson said this was the Bosnia of
Telecommunications. I asked, if this was so, how, in the absense of some
policy explanation, could we know if our policy here will be as successful
as our policy in Bosnia?"

The announcements, authorization procedures for release of escrowed keys,
and q-and-a documents from the private sector briefing are online at EFF.

They are:

"Statement of the [White House] Press Secretary" [White House]
file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_press_secy.statement

"Statement of the Vice President" [very short - WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/gore_crypto.statement

"Attorney General Makes Key Escrow Encryption Announcements" [Dept. of Just.]
file://ftp.eff.org/pub/EFF/Policy/Crypto/reno_key_escrow.statement

"Authorization Procedures for Release pf Emcryption Key Components in
Conjunction with Intercepts Pursuant to Title III/State Statutes/FISA"
[3 docs. in one file - DoJ]
file://ftp.eff.org/pub/EFF/Policy/Crypto/doj_escrow_intercept.rules

"Working Group on Data Security" [WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/interagency_workgroup.announce

"Statement of Dr. Martha Harris Dep. Asst. Secy. of State for Polit.-Mil.
Affairs: Encryption - Export Control Reform" [Dept. of State]
file://ftp.eff.org/pub/EFF/Policy/Crypto/harris_export.statement

"Questions and Answers about the Clinton Administration's Encryption 
Policy" [WH]
file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_crypto.q-a

These files are available via anonymous ftp, or via WWW at:
http://www.eff.org/ in the "EFF ftp site" menu off the front page.

Gopher access:
gopher://gopher.eff.org/
Look in "EFF Files"/"Papers and Testimony"/"Crypto"

All 7 of these documents will be posted widely on the net immediately
following this notice. 

-- 
Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist
F O R   M O R E   I N F O,    E - M A I L    T O:     I N F O @ E F F . O R G 
O  P  E  N    P  L  A  T  F  O  R  M     O  N  L  I  N  E    R  I  G  H  T  S
V  I   R   T   U   A   L   C  U   L   T   U   R   E      C  R   Y   P   T   O





From chris.replogle at ledge.com  Fri Feb  4 21:15:21 1994
From: chris.replogle at ledge.com (Chris Replogle)
Date: Fri, 4 Feb 94 21:15:21 PST
Subject: UNSUB
In-Reply-To: <01H8HO3DOA2Q95N79W@ccmail.sunysb.edu>
Message-ID: <cf.3792.51.0C2EE163@ledge.com>


Subject: UNSUB

UNSUBSCRIBE





From wex at media.mit.edu  Fri Feb  4 21:35:20 1994
From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat)
Date: Fri, 4 Feb 94 21:35:20 PST
Subject: CERT advisory
In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov>
Message-ID: <9402050532.AA24459@media.mit.edu>


My instant opinion is that the private key for a site/machine has to be held
by that site/machine's administrator.  Therefore, the ftpd would need to get
the private key entered at startup time.

--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group	wex at media.mit.edu
Voice: 617-258-9168 Page: 617-945-1842		an53607 at anon.penet.fi
All the world's a stage and most of us are desperately unrehearsed.





From hughes at ah.com  Fri Feb  4 21:35:22 1994
From: hughes at ah.com (Eric Hughes)
Date: Fri, 4 Feb 94 21:35:22 PST
Subject: IMPORTANT: unsubscription
Message-ID: <9402050534.AA23137@ah.com>


This is the mail I send to everyone who tries to unsubscribe by
sending to the list.  After I send this message, I delete it from my
inbox and take no further action to that piece of mail.

Read it.

Eric
-----------------------------------------------------------------------------
The cypherpunks list is for discussions on implementing cryptography.
To mail to the whole list, send mail to

	cypherpunks at toad.com

Every mail message sent to this address will be forwarded to everyone
on the list.  Make sure that the message you wish to send is
appropriate for such a broad delivery.


If you want to be added or removed from the cypherpunks list, or have
any other questions which pertain to list management, send mail to

	cypherpunks-request at toad.com

I don't manage the list from my regular account, so such mail which
ends up in my ah.com account will just get you another copy of this
file.

Eric Hughes 
   maintainer of the lists cypherpunks at toad.com and
   cypherpunks-announce at toad.com







From Seth.Morris at lambada.oit.unc.edu  Fri Feb  4 21:55:20 1994
From: Seth.Morris at lambada.oit.unc.edu (Seth Morris)
Date: Fri, 4 Feb 94 21:55:20 PST
Subject: Hughes' "real-life use for steganography"
Message-ID: <9402050552.AA21327@lambada.oit.unc.edu>


 [Eric Hughes described a situation where data smuggling is required,
and asks for discussion on practicle and practicable mechanisms (with
appropriate and far too rare here emphasis on practicable). This is
the sort of real-worldish issue I've been on this list for, so,
despite my opinion that this doesn't sound like a real case, I'd like
to add my thoughts.]

 What is needed here is not encryption, by steg, of course. Why worry
about key distribution at all? If the data is being sent in bulk, it
will find itself into the hands of the local Big Bro, and the transport
medium will be exposed and (presumable) confiscated. This will get the 
M industry into trouble, and lose the transport medium. 
 This seems more like a case for point-to-point transport to several
distribution sites withis the country, where more anonymous transport
must be arranged. At the very least, no industry should be placed at risk
without the means to protect itself.
 Maybe DAT tapes of "bootleg" recordings of music M? Like Grateful Dead
tapes, only edited to contain the data. This way, only certain tapes have
data, and the tapes can find their way into the hands of those who can 
decode and distribute.
 Is there, within the country, a suitable transport medium that is transient
and frequent? Someone suggested weather maps (sorry I forgot someone's name)
 but these don't seem perfect. What about scanned in art GIFs on a ntionally
available network? Hmmm....... Compuserve?

 The problem I have with using steg as the mass-transport (other than loss
of transport medium once it is discovered and loss of a cultural industry)
is that it only reaches those with CD-ROMs. This is generally a small
percentage of people. Some in-country transport to the technologically 
uneducated is necessary. This may be out of the scope of this discussion.

 For the initial transport, why be cross-platform? If MS-DOS machines
with CD-ROM or DAT readers are acailable (or PIC's can be brought in...
hmmm... anyone know how to encode a Photo-CD? "Tourist shots...
Grand Canyon, Yosemite Nat'l Prak..."), there is some program on
comp.binaries.ibm.pc that can encode some .com files as readable text
(Not uuencode, the text IS the .com file). A simple de-stegger could be
sent in this way written on a sheet of paper. Something similar could
be worked out for other platforms (maybe not this simle, though).


 They key problem I see is regular, bulk transport of data to be distributed
to a mass of people at random containing cantraband information is 
unlikely to sustain an information revolution. Distribution of the data
to a few people who can make use of it while remaining anonymous seems
more effective. Better still would be to find some way that anyone could
receive ALL the information easily and untraceably, which is what I think
the CD scheme was aimed at.  Unfortunately, it is risky and only gets data
to the privedledged few.

 Sorry if this rambled, I'm doing this off the top of my head and with
a fever.

 Seth Morris (Seth.Morris at LaUNChpad.unc.edu)




From mbriceno at netcom.com  Fri Feb  4 22:20:00 1994
From: mbriceno at netcom.com (Marc Briceno)
Date: Fri, 4 Feb 94 22:20:00 PST
Subject: Running regularly
Message-ID: <199402050618.WAA20365@mail.netcom.com>


I wrote:
>> The next problem that must be addressed is the auto-logout upon >14min of
>> inactivity on the modem level that Netcom imposes on you. There is a simple
>> 2 line command that you can add to your .login file to disable the
>> auto-logout. I saw it once posted in one of the Netcom newsgroups, but I
>> lost it. Perhaps you might post the question there. I would not advise to

Ed Carp wrote:
>Did you ever get an answer to this one???  I know that TMOUT in bash controls
>the shell timeout - does this have an effect??

I don't know if TMOUT has anything to do with it. I posted the queston in
the appropriate Netcom newsgroups and hope that the original poster will
see it and send me his script. Once he does I will post it to the list.
After all,there is no reason why one shouldn't be able to use one's
computer for other purposes while Netcom's machine is factoring that 50
digit number ;-)


-- Marc Briceno <mbriceno at netcom.com>
   PGP public key by finger






From matthew at gandalf.rutgers.edu  Fri Feb  4 22:45:20 1994
From: matthew at gandalf.rutgers.edu (Matthew Bernardini)
Date: Fri, 4 Feb 94 22:45:20 PST
Subject: Stego for Video ?
Message-ID: <CMM-RU.1.3.760430533.matthew@gandalf.rutgers.edu>



Have any programs been written that would allow for three dimensional stego
in moving pictures ?  I think this would make it a little more difficult to
detect.

How about more advanced graphical techniques like using a stego file as a map
in a renderer ?  The person who received the picture would know for instance
that all the vertical walls, or all the brick surfaces, etc were stego
encrypted messages.  It would take some sophistication to reverse engineer
the rendered picture, but necessity is the mother of invention.  The actual
image would not contain any specific information, but would be a disguised
"envelope" for other pictures within the picture.

Matt

-----------------------------------------------------------------------------
                        |               Rutgers University Computing Services
Matthew Bernardini      |               Hill Micro/Graphics Center
7804 McCormick          |               Site-Manager
(908) 878-0946          |               017 Hill Center
                        |               (908) 932-3129  (908) 932-4921
-----------------------------------------------------------------------------







From MIKEINGLE at delphi.com  Fri Feb  4 22:45:23 1994
From: MIKEINGLE at delphi.com (Mike Ingle)
Date: Fri, 4 Feb 94 22:45:23 PST
Subject: ViaCrypt Encryption Hardware
Message-ID: <01H8IA4ZZZBC8ZF180@delphi.com>


Some interesting flyers for ViaCrypt hardware encryption devices:

There are three of them. The DigiSig+ D350 is an external device which
hooks up to a parallel port. The D355 is similar but hooks up to a serial
port. Both of these are flat boxes that look like external modems. The
D360 is an internal board, and the D150 is a software emulator. All of
them do the same things: RSA, DES, and DSS. The hardware devices have
tamper-resistant memory to store secret keys, which can be generated
internally. ViaCrypt says the hardware boxes will support PGP soon.
All of the devices are controlled by a script language. The hardware
units take ISO Memory Cards. ViaCrypt PGP is also selling for $99.
ViaCrypt's number is 1-800-536-2664 or 602-944-0773

--- Mike

For the person who requested my PGP key:

Type bits/keyID   Date       User ID
pub  1024/569A09 1993/07/31  Mike Ingle <mikeingle at delphi.com>
sig       87C0C7               Edgar W. Swank <edgar at spectrx.saigon.com>
sig       9C0865               W.Meredith <Genie w.meredith at genic.geis.com>
Key fingerprint =  AB B7 D7 70 4D 32 72 64  79 63 7F 05 07 1D 62 5D 

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

mQCNAixa6xEAAAEEAN0a4+5zXcAbvGCkhWMowzko1fjc+9Q/kWsPXPABJ1H12wmZ
fvsTOlIZKsYVG9oulz6N928btkP+CBWAKEyykDSaD3/HQBpg5T3/T6CVQCCkfGJx
qvdJa6OdY0f7d83o2MX2P58veYqgXuiDSL0BUtqXcF1GNeV+ra2f+EADVpoJAAUR
tCFNaWtlIEluZ2xlIDxtaWtlaW5nbGVAZGVscGhpLmNvbT6JAJUCBRAtTrsZ3ic1
/dqHwMcBAYXmBACRfSLCOBa3VfIMf4IhwqqxBToNqzJuD1g9N97A6SJ7/7E4/ux+
gulv3EsQJl2SXA6tnKPaZVPdDEOwW0+I+/YyT4YkeXiu7y7bgQSjeGdiElJaMboO
vNcdNUaDWBn0t3+h1B9UGE29/CyHXPGVzkh8W+mK1J+3GrrCxoIZch9RTIkAlQIF
EC0hm4Q+dhgw+ZwIZQEBXxcEAKw8CGgLbYjmPPeFSvc9KGnPn10ky8ltuFwRg5zu
tLN70WpkQtivHA74d4CTYroklOj//HiBlVAb04Pl31Ypug6F3PUiEZC4thlJ4BeF
3q4LJSHvD70gYZ3uzwEn/ZOqfAn79ehsVpsiCfh6haZN0oJfJpz7Tr5c1eVAyl99
ZAdb
=/VCZ
-----END PGP PUBLIC KEY BLOCK-----





From MIKEINGLE at delphi.com  Fri Feb  4 23:30:03 1994
From: MIKEINGLE at delphi.com (Mike Ingle)
Date: Fri, 4 Feb 94 23:30:03 PST
Subject: Looking for lost mail
Message-ID: <01H8IA420KRM8ZF180@delphi.com>


I lost some list mail today. Could someone please forward me the missing
messages? These are the last ones I got. Everything between this and the
"KERT Advisory" joke is what I lost. Thanks, Mike

Some people have been asking how to run background tasks on Netcom.
How about this: have your task run, then send a ping to a remailer.
When the ping comes back, your .forward file will start the task back
up and it can run, then ping the remailer again.

From:   IN%"mech at eff.org"  "Stanton McCandlish"  4-FEB-1994 20:44:29.91
To:     IN%"eff-board at eff.org"
CC:     IN%"eff-staff at eff.org", IN%"comp-org-eff-talk at cs.utexas.edu", 
           [ everywhere ]
Subj:   White House crypto briefings: Clipper, FIPS, escrow agents, export

From:   IN%"smb at research.att.com"  4-FEB-1994 21:03:12.11
To:     IN%"hughes at ah.com"
CC:     IN%"cypherpunks at toad.com"
Subj:   RE: CERT advisory

From:   IN%"fb at cyberg.win.net"  4-FEB-1994 21:08:15.44
To:     IN%"cypherpunks at toad.com"
Subj:   RE: Magic Money Digicash System






From hfinney at shell.portal.com  Fri Feb  4 23:40:06 1994
From: hfinney at shell.portal.com (Hal)
Date: Fri, 4 Feb 94 23:40:06 PST
Subject: Magic Money Digicash System
Message-ID: <199402050738.XAA07723@jobe.shell.portal.com>


From: fb at cyberg.win.net (Francis Barrett)
>  > Magic Money is a digital cash system designed for use over
>  > electronic mail.
> This is the neatest thing I have read in a long time.  Where can I get
> one?

FTP to csn.org, cd to /mpj, read the file README.MPJ which will tell you
a directory to switch to, do that, cd to pgp-tools (or pgp_tools, or
pgptools, I forget which), and get magicmny.zip.  Then unzip and build it.

> A few questions.  Since the client which generates the proto-coins is
> under the control of the consumer, the bank has no way of making sure
> that he is not running his own code, or that the RNG he is using is
> cryptographically strong, or even that he is not distributing modified
> client programs to other users.

None of these things should cause major problems.  At worst useless coins
would be generated.  Initially, users might send their coins in right away
to confirm that they are OK until they get some confidence in the program.

> How does the bank deal with collisions in the 16 byte values of coins?

This will practially never happen if they are chosen randomly.  Bad
randomness could produce coins which match ones which have already been
spent (if somehow your RNG got into exactly the same state as someone
else's), so they would be valueless.  I think the program makes you
initialize a random file before using it, so just make sure you put
something random there!

> What if the user picks the numeric values for the server to sign in a
> way which leaks information about the banks private key?  RSA is much
> more secure when signing random-esque data, like a message digest,
> than it is when signing numbers provided to it by some outside party.

I don't think there are any values you can sign which would give away a
private key.  Even signing "1" or "2" should be safe, I think, since the
secret key is the size of the modulus.

I ftp'd a paper recently mentioned on imp-interest (on "anonymous
credit cards") which claimed that new cash could be generated from sets
of old cash in Chaum's scheme.  I don't believe this, and the ref was
to a paper "in preparation" by the authors.  I'll try sending them
email to ask about this.

> Similarly, how can the consumer trust the bank's representation that
> money has already been spent?  Surely the bank should be required to
> publish a list of cancelled coins and timestamps with a running MD5
> hash periodically for inspection by the unwashed masses.

Here is how this problem would arise.  Alice has some cash, which she
sends to Bob to buy something.  Bob sends it to the bank to be verified
and turned into fresh cash before he will send the goods to Alice.  But
the bank says the cash has been spent before, and Bob reports this to
Alice.  Alice insists that she has never spent this cash before.

Now, this is like a mystery story.  Who is telling the truth?  Maybe Alice
is lying.  Maybe the bank is lying.  Maybe they are both telling the truth
and someone broke in and stole Alice's cash while she was sleeping, copying
it from her computer and spending it before she could.

Ignoring that last possibility for a minute, it is basically Alice's word
against the bank's.  In general, in situations like this, we often go by
the reputation of the parties involved.  If the bank really is cheating,
there will be lots of other people like Alice, people with good reputations,
who are making similar charges.  This will make people stop trusting the
bank.  On the other hand, if Alice is cheating, this is probably not the first
time.  In time she will get a reputation for being untrustworthy.

The idea of publishing lists of used coins is interesting but I'm not sure
it helps.  Double-spending could easily occur close together in time, between
publication of lists.  A cheating bank could claim a coin had been spent
just before the actual coin came in.

> What do you do about lost messages from the server to the client.
> Once coins have been recorded as spent, they cannot be redeemed again.
> Yet the mail message containing the new coins may have been lost in
> transit.

The server should re-transmit the message if it does not arive.  We
discussed this a while back and it appears safe for everyone in these
protocols to re-transmit messages freely if the other person claims
never to have gotten them.  Even if they are lying, what is the harm -
you are just sending them information they already have.

Good questions.

Hal





From ld231782 at longs.lance.colostate.edu  Sat Feb  5 00:45:22 1994
From: ld231782 at longs.lance.colostate.edu (L. Detweiler)
Date: Sat, 5 Feb 94 00:45:22 PST
Subject: SQUISH II, the SEQUEL
Message-ID: <199402050840.BAA18743@longs.lance.colostate.edu>


Hello, my mailbox has been awfully quiet lately from cypherpunk rants,
and I need a bit of a massage at the moment, so I wanted to ask you a
question. Have you considered what I was saying about preventing
`abuse' of remailers? I have given you some time to formulate a plan. 
 
so-- could someone email me your new official Cypherpunk ethical
guidelines for anonymous posting, involving your opinions and
procedures on libel, harassment, and `violent death threats'?

what's that? you don't have an official policy or any safeguards?

I guess that means that `anything goes' (quite literally!)

kind of a disturbing policy, because someone simultaneously very
ingenious and malicious could create some major annoyances. I guess you
already know that. but even the past `operations' could pale in
comparison to future ones. the possibilities are really limitless.
imagine what can be accomplished when no one is held accountable for
what they post! why, it is a recipe for Utopia. cypherpunks, I so
admire your vision of the future.

BTW, I want to commend you anonymous site operators for your
resilience. it does appear that the remailers are fairly secure, at
least, that is the picture portrayed to `outsiders'. of course, with
insiders, it is a different story. but in a certain interesting
application of anonymous remailers, e.g. an enemy attacking the
remailers themselves, the confidentiality of identity among `insiders'
is not critical. in fact, it can be very satisfying for an enemy to
strike his foe, even while the foe sees his face, but can do nothing
about it because of his own predicament. even more delightful (for the
attacker, that is!) is the situation where the `predicament' is not
even due to the attacker, but entirely the enemy himself. in other
words, the most effective and devastating tactic of guerilla warfare is
to twist technology to get your enemy to shoot *himself*.





From remailer at merde.dis.org  Sat Feb  5 01:35:22 1994
From: remailer at merde.dis.org (remailer bogus account)
Date: Sat, 5 Feb 94 01:35:22 PST
Subject: He's baaaaack!
Message-ID: <9402050930.AA02620@merde.dis.org>


Just when you thought it was safe to go back on the internet...
He's baaaaack! Remailer operators, please lock him out now, before he
does whatever he is getting ready to do. Better yet, set it up so when
he sends to a remailer, he gets back a hundred copies, and one gets
forwarded to his sysadmin with his name on it.
 





From catalyst-remailer at netcom.com  Sat Feb  5 03:15:25 1994
From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com)
Date: Sat, 5 Feb 94 03:15:25 PST
Subject: Magic Money questions
Message-ID: <199402051111.DAA11286@mail.netcom.com>


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

Magic Money is available from csn.org in the same directory as pgptools.
Be sure to add in the fast mp_inv posted here. It speeds up the unblinding
of a 1024-bit coin from 2 minutes to 3 seconds. Thanks to whoever posted
that code. I will include it in the next release, as soon as some people
shake down the current one for bugs.

fb at cyberg.win.net wrote:

>A few questions.  Since the client which generates the proto-coins is
>under the control of the consumer, the bank has no way of making sure
>that he is not running his own code, or that the RNG he is using is
>cryptographically strong, or even that he is not distributing modified
>client programs to other users.

If his RNG is bad, he is only hurting himself. If he gets the same coin
as another person, and that coin has already been spent, his coins will
bounce, costing him money. Same is true if he corrupts his packets - 
the server looks for the ASN string, and if it's not there, bounces the
transaction. He can run his own code if he wants to.

>How does the bank deal with collisions in the 16 byte values of coins?

There shouldn't be any, except for deliberate double-spending. The coins
are 128-bits, so you'd need 2^64 of them before the odds favor a collision.
The odds of a coin collision are equal to the odds of two messages having
the same PGP signature.

>What if the user picks the numeric values for the server to sign in a
>way which leaks information about the banks private key?  RSA is much
>more secure when signing random-esque data, like a message digest,
>than it is when signing numbers provided to it by some outside party.

This is a problem, if this attack is feasible. The coins won't spend if
they don't have the proper ASN string in them, but the server has no way
to see what it is signing. Can someone produce values which will reveal the
private key?

I've heard of attacks which involve getting signatures on factors of a
message, and multiplying them to get a forged signature. These won't work
here, because each coin value is signed with a different d. All you could do
is multiply several invalid coins of value x to get one valid coin of the
same value. But a signature leaking the private key - that is a new one for
me. Please tell me about this attack. How would one prevent it without using
a cut-and-choose protocol?

Applied Cryptography suggests (page 106) that it is okay to dispense with the
cut-and-choose portion of a blind signature in cases (such as this one) where
the user is motivated not to provide a corrupted coin. The coins use different
e's from the bank's PGP key, so a coin could not be used to forge a message
from the bank.

>Similarly, how can the consumer trust the bank's representation that
>money has already been spent?  Surely the bank should be required to
>publish a list of cancelled coins and timestamps with a running MD5
>hash periodically for inspection by the unwashed masses.

There is no punishment for double-spending. The transaction is simply thrown
out. The bank, in fact, has no way to identify the customer. What could the
bank hope to accomplish by claiming that a coin was already spent? It can
print more coins at any time, so it has no reason to cheat. A server will
have to protect its reputation by not printing too much money or otherwise
making its users angry. If you want to put in an MD5, it wouldn't be hard.

>What do you do about lost messages from the server to the client.
>Once coins have been recorded as spent, they cannot be redeemed again.
>Yet the mail message containing the new coins may have been lost in
>transit.

What can be done? The server can hold onto outgoing messages for a while,
and can have a means of remailing those which are lost. Or the message can
be mailed back to the user through two different routes, to increase the
reliability of the system. But one cash-like property of digital money is
that, if you lose the data, you're SOL.

I don't claim the system is perfect. But it's a start, and in my opinion,
that is what digicash needs right now: a start.

These Clipper postings have me worried. It seems as though the government is
in a big hurry to get Clipper on the market. They only have one shot at this.
What needs coded now? A menu-driven PGP? Any ideas for new projects?

                                                   Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVNAjcGoFIWXVYodAQHtgwP+OTFcxAbZL8uvVeBbwwn4/N1jnLGeHFRB
lw7U3Y3ciESs0PBRDu1JO4hOqzpW7Ch+GkY1z+ueWD8m4+EoroacJMcTI28EKGm3
+2eV0KpQsKfcfsPCfMFVKhqBRAzcwJhFdziFbPvG9g4CU9/Huz4ff8KiSud8zdWO
n8odZHk5zTs=
=6Yw2
-----END PGP SIGNATURE-----





From nobody at shell.portal.com  Sat Feb  5 03:20:09 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sat, 5 Feb 94 03:20:09 PST
Subject: Encrypted Snail Remailer.
Message-ID: <199402051120.DAA15779@jobe.shell.portal.com>


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

Disclaimer: Please take this as a work of science fiction, a short
monologue by the character in a novel. It is meant to stimulate discussion
and to express concerns that have recently turned from vague to clear, in
my mind. I have great respect for the people out here, but I can not help
myself. I very much want a secure network of remailers, but I fear the
problem is the design, inflexible and non-private, of the internet itself.
This is dedicated to those such as Phil Zimmerman and Pr0duct Cypher,
individuals who seem to see the larger picture, that which involves
humanity, not just internet culture 1994.

              -=New Secure Remailer Service Announcement=-

For discussion purposes only until I post my mailbox address and buy that
128/256MB drive ;-) !

Ultimate in remailer technology. Only slightly slower than many Cypher
remailers, but much less traceable. Up to 250MB at once. Encrypt your
message with the (possibly anonymous) public key of a friend or contact,
signing it with your anonymous secret key. Encrypt that, along with the
friend's postal address, with my public key. Put it on a new DOS or Mac
floppy, or 128/256MB Optical Disk, avoiding finger prints and DNA on the
postage stamp. Send it with a fake return address from a pubic mailbox to
my yet to be announced post office box. I will decrypt the forwarding
address on my PowerBook, not at home, and mail it from various Manhattan
street mailboxes, with no return address (or one you send me). I will then
securely overwrite the file from my hard disk. Of course, you can include
an anonymous encrypted return address as part of your message to the
recipient. The cost is $5 cash, plus $1/MB of encrypted message to cover
the CPU time. 

Express mail would in fact be AS fast as the serious Cypher remailers, but
would cost you $20 since I have to pay in cash at a post office, or get a
money order to use FedEx, and then make up a fake return address if you
leave one out. Until a new generation of internet remailers are produced, I
make claim to my remailer service being much more secure. There is also no
need keeping logs to protect my liability, since no one knows that my
remailer was where it came from.

One of the most serious weakness of any internet remailer is that you tell
someone spying on the recipient exactly which remailer site a piece of mail
came from, as well as when. I asked about faking internet mail but was told
that this was "frowned upon" for internet mail. Too bad. REALLY too bad.
With mine, it could be any individual in NYC, and the time of day doesn't
mean much. It thus involves a lot more than a few keystrokes on the assumed
NSA internet logging database to trace it back to the sender. Fairly
obvious and fairly illegal spying on me and the other manual remailers out
there would be required, as well as opening mailboxes before the mailman
arrived. A TEMPEST attack on a PowerBook in public in different locations
just isn't going to happen very often. Bugging my PowerBook isn't possible
since I always carry it with me (and know what it's insides look like in
detail).

Secure encryption being available to the common man is what will change the
world. I'm not yet convinced that internet remailers will have a similar
influence unless they are able to resist the presence of full site-to-site
monitoring by the government and hackers, a thing which should thus be
assumed by their designers. Cryptoanarchy doesn't mean the internet. It
means encryption.

Given that snail mail encrypted remailing is already possible, the reason
for a new, secure remailer generation isn't really security but is speed,
convenience, flexibility, and cost. The same reasons for ANY use of the
internet. But current serious remailers are neither fast nor convenient,
and they don't have a BILLION messages going through them a day to mix your
secret messages into, like postal mail DOES. They tag mail as having BEEN
remailed as well. Even when ALL e-mail is encrypted you haven't done
anything for anonymity until all e-mail is also REMAILED, with no logs or
remailer sites appearing in the headers. E-mail is free now. Remailing
needs to be free too, or what advantage has it over snail mail, given that
it does the same thing? The only way I can see all mail being remailed,
assuming it is already all encrypted, is if every personal e-mail account
was itself a remailer. I don't see this happening unless the Cypherpunks
themselves write the software for the "data highway". Otherwise I will
never trust remailers since as I've said to others, I can't SEE the wires.

PGP is what's happening. Digital money too. But the INTERNET, even with
(centralized) remailers is just a Big Brother nationwide wiretap. So don't
use wires.

What is my liability, if I am a remailer and the authorities intercept a
message to a gangster? None, since they don't know I remailed it. Can any
internet remailer be so lucky? I could say I don't KNOW if I remailed it
(no logs), even if they find a return address as encrypted in my public
key; "Any one of dozens of Manhattan snail remailers could have sent it."
However, if your return address IS encrypted with my public key, law
enforcement can, most likely LEGALLY, demand my pass phrase. Of course
they'll only know the return address using the pass phrase and secret key
of the receiver.

Again though, this situation is BETTER security than internet remailers,
since the pass phrase for the remailer is in my head, not plain text in a
perl code. They can't secretly download my memory, or at least not YET ;-).
Breaking into your remailer site without a trace is conceivable though. I'd
find it similarly attractive but more rewarding than dumpster diving.
Commercial sites are easiest, especially small high tech companies.

Are these sites TEMPEST secure? Tempest based on simple radio receivers is
primitive compared to what modern spectroscopy could conceivably do, even
at a distance. I'd imagine ACTIVE spectrosopies could do much more or you
could actively induce a current in a given direction at a given frequency.
How about having your CPU mail me its secret key and pass phrase? Things
like this are only getting easier, fast. VERY fast. Another reason to not
trust fixed-location centralized remailers. I don't even like the idea of
personal accounts on a Unix machine. Every laptop should be an internet
node, and an encrypted remailer. Only when central remailers are no longer
there to attack will we have safe anonymity without using snail remailing.
Hell I can't even get more than three fucking e-mails in response when I
ask for INFORMATION about the existing remailers. I thank Eli and Hal, but
I guess the NSA doesn't hand out info on the dozen Cypherpunk remailers IT
is running. Zero knowledge (yup), reputations (lowsy or non existent except
for anon.penet.fi), information markets (selling remailer pass phrases and
sendmail logs), anonymous networks (snail mail only), collapse of
governments (yes, but not using the existing nationwide wiretap, er...
internet). Fuck, I'm sounding like Detweiler. But I'm ranting for MORE
cryptoanarchy.

Another internet-like standardization such as that of e-mail headers, has
very sadly crept into PGP itself, weakening it as the secure encryptor. PGP
2.3a still has no "random data block" output format, in which the ONLY way
to even KNOW it's a PGP message is to successfully decrypt it. I asked
about this on alt.security.pgp, generated little interest, but was told a
future version may have this option (just gossip). I say it should be the
STANDARD. Internet-like standards should NOT be the guiding force behind
CRYPTOGRAPHIC standards. Get the fuck off the internet, and write me a real
encryptor. How can steganography work if it's so easy to figure out if what
is extracted is an encrypted message? Given the upcoming non-voluntary
second generation Clipper, steg will have to become the norm.

And don't port PGP to the Mac and Windows, port it FROM them; over 100
million strong and growing. "Five to one baby." News of the revolution will
not be posted. Thanks for PGP. Thanks for the CPU. Like those Cypherpunk
T-shirts though! Boot up and slam dance. Kewl! Nice sig!

If my remailer, the ONLY acceptably secure encrypted remailer that exists,
catches on, I may add a modem feature, involving pay phones. I've already
written the needed secure code (none). And remember, security begins with
people, not technology, always has, always will.

 -=Xenon=-

P.S. gosub disclaimer.

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVM1wwSzG6zrQn1RAQF8kwP/YetocN9urSgB4X9u70ZABFeLawEkwu56
jFDWZgDG+Z/81vFkVWTC7gvfDDB4Rjy0qeEhuq187zeRJ3fKCRPkkHz7swDV3V+o
RA9waKWz7tdxglkW98bJIKpC9rYp4lvtxPWgtAsLTs6b9tJqvXmp2S+OcjcyV6sE
gKI25vPg5Ww=
=zjED
-----END PGP SIGNATURE-----






From garet.jax at nitelog.com  Sat Feb  5 05:45:29 1994
From: garet.jax at nitelog.com (Garet Jax)
Date: Sat, 5 Feb 94 05:45:29 PST
Subject: Remailers Revisited
In-Reply-To: <9401230638.AA05002@terminus.us.dell.com>
Message-ID: <cb.61523.10.0CD03BEC@nitelog.com>



Why not set up a mailgroup (such as cypherpunks.pgp) wherein ALL
messages are PGP encrypted?  Once one subscribes to the group, she would
receive a message containing both the standard further information about
the group as well as public and PRIVATE PGP for the mail group keys to
add to her PGP key ring.

Then whenever she sent a message to the group remailer
(cypherpunks.pgp at toad.com) it would already be PGP encrypted with the
group key.  And anyone who received that message would be able to open
and read it because they would already have the private key for the
group.

The remailer could check the messages before forwarding them to the list
subscribers to make sure that they are PGP encrypted.  If they aren't
then they wouldn't be sent... a nice side effect of this would be that
the list subscribers would no longer receive those 'unsubscribe user'
messages as most likely these would not have been encrypted before
mailing.

-Garet          {Garet.Jax at nitelog.com}





From garet.jax at nitelog.com  Sat Feb  5 05:45:33 1994
From: garet.jax at nitelog.com (Garet Jax)
Date: Sat, 5 Feb 94 05:45:33 PST
Subject: how to solve this prob.
In-Reply-To: <9401272306.AA26581@toad.com>
Message-ID: <cb.61524.10.0CD03BED@nitelog.com>



There MUST be some way that the LISTSERV software can be modified
so that a user can send an unsubscribe message to the -request line
for another user.

Take this Detweiler for example.  If he forgets where to send his
unsubscribe message and sends it to the list instead, someone could send
an unsubscribe message to the proper address for him. ex:

   'unsubscribe [ listname ] user at e-mail.addr'

The system would note that the name of the person sending the
unsubscribe message ( user1 ) was different from the one who was being
unsubscribed ( user2 ) , and would, after unsubscribing user2 send a
message to user2 telling him that he had been unsubscribed from the list
by user1. ex:

   'Dear user2, you have been unsubscribed from the Cypherpunks
   list by user1.  If you wish to resubscribe, send a message
   containing...'

That way, instead of the list readers bombarding the folks who send
the unsubscribe requests to the list, they could simply forward the
request to the proper place.

Now, how do we get it implemented?






From mnemonic at eff.org  Sat Feb  5 07:05:37 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Sat, 5 Feb 94 07:05:37 PST
Subject: Alert--Admin. names escrow agents, no compromise on Clipper - 7 files (fwd)
Message-ID: <199402051502.KAA07424@eff.org>


Forwarded message:


From ravage at wixer.bga.com  Sat Feb  5 07:10:14 1994
From: ravage at wixer.bga.com (Jim choate)
Date: Sat, 5 Feb 94 07:10:14 PST
Subject: how to solve this prob.
In-Reply-To: <cb.61524.10.0CD03BED@nitelog.com>
Message-ID: <9402051453.AA02769@wixer>


>
>
> There MUST be some way that the LISTSERV software can be modified
> so that a user can send an unsubscribe message to the -request line
> for another user.
>
> Take this Detweiler for example.  If he forgets where to send his
> unsubscribe message and sends it to the list instead, someone could send
> an unsubscribe message to the proper address for him. ex:
>
>    'unsubscribe [ listname ] user at e-mail.addr'
>
> The system would note that the name of the person sending the
> unsubscribe message ( user1 ) was different from the one who was being
> unsubscribed ( user2 ) , and would, after unsubscribing user2 send a
> message to user2 telling him that he had been unsubscribed from the list
> by user1. ex:
>
>    'Dear user2, you have been unsubscribed from the Cypherpunks
>    list by user1.  If you wish to resubscribe, send a message
>    containing...'
>
> That way, instead of the list readers bombarding the folks who send
> the unsubscribe requests to the list, they could simply forward the
> request to the proper place.
>
> Now, how do we get it implemented?
>

To keep this type of service from being abused there would need to be some
kind of validation. At the very least the listproc should receive some form
of 'ok' from the user being deleted in absentia. Otherwise the list would
desolve into a morass of people unsubscribing others who annoyed them for no
other reason than agravated neurosis. In general it would do nothing but
double the load, further reducing bandwidth.






From mnemonic at eff.org  Sat Feb  5 07:40:15 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Sat, 5 Feb 94 07:40:15 PST
Subject: your mail
In-Reply-To: <9402050102.AA08460@io.lrcs.loral.com>
Message-ID: <199402051538.KAA07593@eff.org>


 
David Koontz writes:

> All this bullshit doesnot state that a court order is required, rather
> 'legal authorization', which means the NSA for foreign intellingence
> purposes without a court order.

The Foreign Intelligence Surveillance Act (FISA) requires a court order
for such taps.


--Mike







From frissell at panix.com  Sat Feb  5 08:15:34 1994
From: frissell at panix.com (Duncan Frissell)
Date: Sat, 5 Feb 94 08:15:34 PST
Subject: Clipper "Above the Fold"
Message-ID: <199402051611.AA02906@panix.com>


Clipper and the Admin decision to adopt same is reported in a front page 
(above the fold) article in the Saturday New York Times.

Usual errors about how the "backdoor" would work and about how warrants 
would be required to get the keys.

All the usual suspects.  Good placement though.

DCF 
--- WinQwk 2.0b#1165                                                                     





From bgold at tlcnet.aps.muohio.edu  Sat Feb  5 09:10:15 1994
From: bgold at tlcnet.aps.muohio.edu (Bruce Goldflies)
Date: Sat, 5 Feb 94 09:10:15 PST
Subject: unsubscribe
Message-ID: <9402051708.AA05261@tlcnet.aps.muohio.edu>


unsubscribe





From klbarrus at owlnet.rice.edu  Sat Feb  5 09:10:36 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Sat, 5 Feb 94 09:10:36 PST
Subject: MAIL: tearlines, policies
Message-ID: <9402051708.AA05317@arcadien.owlnet.rice.edu>


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

Fellow cypherpunks,

Hm... I'm falling further behind list mail; the day after the security
situation at Rice was fixed (~2 weeks off internet) the hard disk
crashed.

* About remailer policies:

Try to gopher site (chaos.bsu.edu) in "Anonymous Mail"/"Remailer
Policies" I can only really describe what goes on at elee7h5 at rosebud,
elee6ue at rosebud, and elee9sf at menudo.uh.edu.

* About tearlines:

There is no standard I'm aware of, although a quick and dirty trick is
to place a single period in the first column.  Most remailers pipe to
/usr/lib/sendmail (and not "/usr/lib/sendmail -oi") so a single period
will end a mail message.  Try it before you rely on it to strip the
rest of your message.  I beleive Miron Cuperman (extropia remailer)
invokes sendmail with -oi.

* About old discontinued remailers:

I remember another discontinued remailer ?@cs.buffalo.edu.  I don't
remember the name, but the student was forced to shut it down because
the university said that running an anonymous remailer basically made
computing resources available to non-students.

* About the remailers I started/run:

Remailer  Fast?  OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB
- --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ----------
menudo    --     N      SM    -    t1    ?   Y  Un   H   23a  ?
rosebud   ++/-   N      MQ    -    -     -   N  Un   M   23a  ?

elee9sf at menudo also accepts RIPEM encryption
elee6ue at rosebud requires "digital cash" (basically random strings I made)

Errors on elee9sf at menudo are forwarded klbarrus at owlnet.rice.edu where
they are deleted.  I still get mail at that address which is why I
have it forwarded and not just dropped.

Errors on rosebud are dropped

Karl Barrus
klbarrus at owlnet.rice.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVPSY4OA7OpLWtYzAQHDCgQAphyqkkgHtXblB1C5OlyCPZQD2/6IQ7YD
FaYOHBG+NmnUMKl1bz8T9LcDKGvUKFSLW9SmI64MOqv78HF7QIXLILPG4mQ/Yn3j
+zv5WyIEMofyMWUxkkWl8G/eIdCT2nB6vGNgQ8/hvhdG4DvGSpgNlwSB8itRTRwK
j5DOz+wdQeM=
=u1Y6
-----END PGP SIGNATURE-----





From klbarrus at owlnet.rice.edu  Sat Feb  5 09:25:39 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Sat, 5 Feb 94 09:25:39 PST
Subject: MAIL: questionnaire
Message-ID: <9402051721.AA05442@arcadien.owlnet.rice.edu>


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

bsu-cs:
Run by Chael Hall.
Contact at same address

chaos:
Run by Chael Hall.
Contact at same address

dis.org/merde:
Run by Peter Shipley

extropia:
Run by Miron Cuperman
Comments: not directly connected, introduces some delay

menudo:
Run by Karl Barrus
Maching: University machine
Problems policy: see policy at gopher site.
Contact elee9sf at menudo.uh.edu or klbarrus at owlnet.rice.edu
Software: Hal's remailer code with a few modifications by myself
Security: batches incoming message, sends them out randomly at midnight.
Comments: also accepts RIPEM, pads messages to 1K with random stuff
(an experimental approach, Hal has code to pad inside PGP messages).
History: ??

penet.fi:
Run by Julf (Johan Helsingus)

rebma:
Run by Bill (O'Hanlon?  not quite sure)
Machine: privately owned
Comments: not directly connected, introduces some delay
History: 2nd oldest remailer

rosebud: (elee7h5 at rosebud.ee.uh.edu)
Run by Karl Barrus.
Machine: univerisity
Problems policy: see gopher site
Contact klbarrus at owlnet.rice.edu
Software: standard scripts
Security: syslog file can be read
Comments: errors are dropped
History: 3rd oldest remailer

rosebud: (elee6ue at rosebud.ee.uh.edu)
Run by Karl Barrus.
Machine: univerisity
Problems policy: see gopher site
Contact klbarrus at owlnet.rice.edu
Software: standard scripts modified to accept cash strings
Security: syslog file can be read
Comments: errors are dropped

Karl Barrus
klbarrus at owlnet.rice.edu


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVPVe4OA7OpLWtYzAQFWmAP+KnsEAO+EnOvDNZQ1+leUiFz+rDheosD/
7XaM26uMWfrCQuXaWmVtxsTPOuU1Qw3qyqCz5ah6X2mzC1GvaDd+SXGwr9LH2/3x
+v/7y+PDfi7SMZluLX6qumXi5k9NPztBrbcdTWEbu04PAahshlKNWbGU/XAzc+b+
jgwUBudWPZA=
=SfIz
-----END PGP SIGNATURE-----





From aa377 at cleveland.Freenet.Edu  Sat Feb  5 09:55:37 1994
From: aa377 at cleveland.Freenet.Edu (Ken Kopin)
Date: Sat, 5 Feb 94 09:55:37 PST
Subject: how to solve this prob.
Message-ID: <9402051752.AA09134@slc8.INS.CWRU.Edu>


>
>
>There MUST be some way that the LISTSERV software can be modified
>so that a user can send an unsubscribe message to the -request line
>for another user.
>
>Take this Detweiler for example.  If he forgets where to send his
>unsubscribe message and sends it to the list instead, someone could send
>an unsubscribe message to the proper address for him. ex:
>
>   'unsubscribe [ listname ] user at e-mail.addr'
>
>The system would note that the name of the person sending the
>unsubscribe message ( user1 ) was different from the one who was being
>unsubscribed ( user2 ) , and would, after unsubscribing user2 send a
>message to user2 telling him that he had been unsubscribed from the list
>by user1. ex:
>
>   'Dear user2, you have been unsubscribed from the Cypherpunks
>   list by user1.  If you wish to resubscribe, send a message
>   containing...'
>
>That way, instead of the list readers bombarding the folks who send
>the unsubscribe requests to the list, they could simply forward the
>request to the proper place.
>
>Now, how do we get it implemented?
>
>
>
    EEEEEEEEK! You've got to be kidding! Take this L. Detweiler guy.
He sets up a script and every name that comes from toad.com gets deleted
from the list. Good way to destroy the list. How many times do YOU
want to resubscribe?

                           Ken Kopin -JAFL (Just a F****** lurker)

--
      *** I Buy KOOL-AID Points ***     |Internet: aa377 at Cleveland.Freenet.Edu
         1-499    1/3 cent each.        |
         500-1499 1/2 cent each.        |Disclaimer: It'll never stand up
         1500-?    1 cent each.         |            in court.





From rcain at netcom.com  Sat Feb  5 10:20:14 1994
From: rcain at netcom.com (Robert Cain)
Date: Sat, 5 Feb 94 10:20:14 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
Message-ID: <199402051816.KAA28356@mail.netcom.com>



In the Diffie-Hellman exchange there is a well-known-prime, w, and a
well-knwon-modulus, m.  For those interested that don't know I think
it then proceeds as follows (don't have notes in front of me so please
someone correct me if I'm misremembering it) where ** is the power or
exponentiation operator and % is the modulus operator:

	1) Bob generates a one time random prime, b, then computes
		B = (w ** b) % m
	   and sends B to Carol.

	2) Carol generates a one time random prime, c, then computes
		C = (w ** c) % m
	   and sends C to Bob.

	3) Bob generates a session key:
		K = (B ** c) % m

	4) Carol generates a session key:
		K = (C ** b) % m

Carol and Bob have the same K because:
	K == (C ** b) % m == (B ** c) % m == (w ** (b * c)) % m

>From just the knowledge of B and C a snoop cannot determine
b from B, within computational reason (the root modulus being as
difficult as factoring), nor c from C, and because K cannot be 
determined from B and C without knowing b or c, she is screwed.

Now, the tutorial over :-), the question is; is there a "standard"
well-known-prime, w, and a "standard" well-known-modulus, m, and if
not, let's define one.  I suppose that PGP uses a well known pair but
they are big and not easy to hand around without going through media (I
think.)  When defined algorithmically they might be easier to actually
incorporate in a program or a product than great big numbers.  If this
has not been done, I propose a simply stated algorithm for finding a
"standard" w and m that will allow interoperation among all future
implementations of D-H as follows:

	Let "standard" w be the first prime found probing from the
	starting point w' = n!, with a well-known n that should be
	small. I am not sure what n should be to generate a large
	enough w'.  Let's just say the smallest n that generates a 1000
	digit number.  There is a well known primality testing
	algorithm by Lenstra that is pretty agreed upon by the number
	theory crowd (I have it coded by Lenstra and more on that
	later.) So, let w be the first number larger than w' that
	passes Lenstra's primality test.  Any program or device
	employing D-H will have this algorithm in it somewhere for
	generating each session specific b and c so all we need to
	agree on is 1000 (or whatever is decided to be a large enough
	prime for all practical purposes.)

I leave a "standard" for m up for discussion because I don't have
the material in front of me that tells the criterion for selecting
strong m's and there are some considerations.  I would like it to
be algoritmically defined though using standard long modulus, long
integer arthmetic and some small, easy to remember number.

Whatcha think?

Oh, for those of you that actually code this stuff like me, I have
Lenstra's long integer function package in C that I "ported" from K&R
to ANSI and edited and reorganized the documentation in the process.  I
interacted with him in that process and it is a stable and reliable
package.  This was a year ago so he has most likely added to it by now
but this snapshot I have is very complete and has way more than is
needed to do nearly anything in crypto.  And it is by Lenstra himself!
A cool guy BTW.  The problem:  I did have to make some changes to
macros and sundry things to ANSIfy it and may have introduced errors.
It runs his demonstration programs that are part of the package and
gives the correct results and these programs exercise a good part of
it, especially the areas I had to mess with.  BUT: I have not had the
time to sit down and look hard at a true verification suite and he
doesn't have one either. So, caveat emptor, I offer this package (and
the original from which it was derived) to *one* person that can put it
in a relevant ftp site.  Is that you, Sameer?

BTW, D-H is useless across a medium in which there can be an active
snoop or spoof as I guess we call him.  Whit, Marty and Ron agree as of
a discussion a year ago.  The spoof just has a pair of boxes and
separately negotiates a session with Bob and one with Carol so that
clear text passes between his pair.  There is no way in theory to
detect the presence of our friendly spoof.  :-)

I've found a solution to this that is more than sufficiently secure in
practice and even theoretically secure in most practical situations.
I'm not sure what to do with it.  I would like to retire on it though
(and get a couple "voluntary income tax" liens off my back :-) and
perhaps even endow some kind of institute.  Actually I worry more about
being retired because of it if you get my paranoid drift.  I guess that
is why I'm lettin' y'all know about it here first.  I am also curious
about how you folks here feel about someone wanting to personally
benefit financially from an algorithm/protocol invention/discovery like
this but I don't want nor will get into any flame war.  :-(


Peace,

Bob

-- 
Bob Cain    rcain at netcom.com   408-354-8021

 "Morality is largely a rationalization of the  point you happen to occupy
  in the power pattern at a given time.  If you're a *Have-Not* you're out
  to *get*, and   your morality is an appeal to a law higher than man-made
  laws--the noblest  ideals of  justice and  equality.  When you  become a 
  *Have* then you are out to *keep* and your morality is one of law, order
  and the rights of property over other rights."

                                                       Saul D. Alinsky
                                                          1909-1972

--------------PGP 1.0 or 2.0 public key available on request.------------------




From klbarrus at owlnet.rice.edu  Sat Feb  5 10:25:38 1994
From: klbarrus at owlnet.rice.edu (Karl Lui Barrus)
Date: Sat, 5 Feb 94 10:25:38 PST
Subject: MAIL: Re: remailers revisted
Message-ID: <9402051823.AA06395@arcadien.owlnet.rice.edu>


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

- From a few weeks ago (recently for me :-)

>Given that my understanding is basically correct, why couldn't
>the remailer system be set up similarly to the way IRC is?

Your system sounds great.  However, don't you have to be root to run
the server side of things (put it in /etc/inetd.conf)?  Or the
alternative is to leave a process continually running listening for
connections, right?  Leaving a process running isn't feasible for me,
even if it forks all the time (especially now with the recent security
problem on owlnet).

Or is there another way that an ordinary user can pull this off?  If
so I'd like to hear about it and work on an idea I've had for a while.

Karl Barrus
<klbarrus at owlnet.rice.edu>


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVPkGoOA7OpLWtYzAQGa0wQAnh38YhoBl8fPemQRf79y44FgEVkRXHZX
eNGNkNQ28Hy7aa21ni0FDViGLtauZO2akaYncL5GLEu6LYgr+pMjHThU0li16LQL
ADOO8W1xUCyLu/hrNXKmlw+fQ0UoPPm8h10tTn+6D8XFzDDPGvKglRKpTkKVMHoa
geMLZSbC8yI=
=sBov
-----END PGP SIGNATURE-----





From 73772.2614 at CompuServe.COM  Sat Feb  5 10:40:15 1994
From: 73772.2614 at CompuServe.COM (Arlene Zeichner)
Date: Sat, 5 Feb 94 10:40:15 PST
Subject: unsub,add to announce pls
Message-ID: <940205183542_73772.2614_FHC115-1@CompuServe.COM>


Please unsubscribe. It's great but too technical for me.






From rcain at netcom.com  Sat Feb  5 10:50:16 1994
From: rcain at netcom.com (Robert Cain)
Date: Sat, 5 Feb 94 10:50:16 PST
Subject: doj_escrow_intercept.procedures (fwd)
In-Reply-To: <199402042259.RAA00682@eff.org>
Message-ID: <199402051847.KAA02401@mail.netcom.com>



Wow! That procedure, if it could be verified to be followed, is almost
good enough to satisfy my queasy feeling that some *very dificult* and
*very publicly* accessable means of opening a back door might just not
be appropriate.  Even though this goes strongly against my personal
interest I can envision situations where I would want them to have that
ability.  Imagine that it is your city that gets a terrorist nuke built
in one of its basements.  Truly secure and easy communication makes
that a whole lot easier but then since a truly secure box is real
simple to make, it sort of obviates the reasoning for trying to do the
standardization anyway.  Anybody who really wants absolute security
will be able to get it at some price that won't be too high.  :-)

I would like to propose us the challenge to come up with a way
utilizing this crypto technology and signatures and such to guarantee a
verifiable trail whenever it is done that is available to any court
of law.  The implication is clear that other forms will be outlawed
if this package is sold.  No point in even doing it otherwise.  So
in case they win this one I suggest that, as Tom Lehrer talks about
on his album Revisited, we "Be Prepared."  :-)


Peace,

Bob

-- 
Bob Cain    rcain at netcom.com   408-354-8021


           "I used to be different.  But now I'm the same."


--------------PGP 1.0 or 2.0 public key available on request.------------------




From arthurc at crl.com  Sat Feb  5 10:50:38 1994
From: arthurc at crl.com (Arthur Chandler)
Date: Sat, 5 Feb 94 10:50:38 PST
Subject: FIRST CYPHERPUNKS VIRTUAL MEETING
In-Reply-To: <9402032319.AA20066@ah.com>
Message-ID: <Pine.3.87.9402051000.A18297-0100000@crl2.crl.com>


              FIRST CYPHERPUNKS VIRTUAL MEETING AT BAYMOO

     The first cypherpunks virtual conference will be held at BayMOO on
Wednesday, February 9, at 8pm PST (11 EST).  To get there:
       telnet (or use a client) mud.crl.com 8888
 Follow instructions for login. Type help for any topic when you get into
the MOO.  @go Cypherpunk Central to get to the main room, then type HALL
to get to the conference hall. 
   One of the virtues of this hall is that there can be large scale AND
small scale discussions going on at the same time. Here, briefly, is how
it works: 
  A. People login and go the Cypherpunk Hall
  B. One person can assume the facilitator's chair. This allows the
facilitator to set several options for the room's function.
  C. In one mode, the facilitator allows open conversation: any can speak,
and all can be heard. 
  D. In another mode, the facilitator sets the allowable number of
speakers. Those wishing to speak must request permission from the
facilitator, who can set the number anywhere from one on up.  Those
wishing to speak must request, and are given a place in line; when any of
the current speakers yield, the next in line move up automatically to
speaker status.
 E. BUT -- and here is the ingenious feature of this
conference room-- folks can sit in any of 8 rows.  If they speak while
sitting in those rows and the room is in facilitated mode, only those
sitting in their row can hear them.  The net effect is that small
conversations can take place within the larger room, but they do not
interrupt the main course of the moderated discussion. 
   F. In addition, the virtual meeting room also has a built-in [about]
function. This feature allows all participants to indicate, by a bracketed
phrase in front of their names, the topic under discussion. In this way,
if the subject begins to drift, explicit acknowledgement of the change
can be made in the [about] header. Example: 
 
   agore [about clipperchips]: So you see, we really have your
                               welfare at heart.
   hthoreau [about clipperchips]: I decline your help.
   agore [about help]: Are you arguing that the government should 
                       just let illicit operations take place unmonitored?
  hthoreau [about interference]: That depends...


  This conference hall is still beta, so be patient if buglets appear. 
  I'll also try to put in a virtual bar for more laid-back chat.  The bar 
will be connected to Cypherpunk Central. Just examine the bartender to 
see how to order drinks -- or to concoct your own.
  Hope to see you there! 








From nobody at pmantis.berkeley.edu  Sat Feb  5 11:15:39 1994
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Sat, 5 Feb 94 11:15:39 PST
Subject: Military & dependants
Message-ID: <9402051912.AA21376@pmantis.berkeley.edu>


Can American Military members or their family take copies of PGP
or other encryption programs with them when being stationed at
overseas bases?  Aren't the overseas installations considered to
be American soil while occupied, thus permitting such transfers?

---
There can be only one!





From garet.jax at nitelog.com  Sat Feb  5 11:15:40 1994
From: garet.jax at nitelog.com (Garet Jax)
Date: Sat, 5 Feb 94 11:15:40 PST
Subject: Remailer Tearline Variant
In-Reply-To: <9401312103.AA02297@toad.com>
Message-ID: <cb.61665.10.0CD03BF5@nitelog.com>



Eli ebrandt at jarthur.claremont.edu said:
>Bill Stewart said:
>> Julf's anon.penet.fi remailer  cuts off anything resembling a signature,
>> using the convention that a -- line (or maybe an all-dash line?)
>> is a signature, since some of the common mail and news programs use that,

>Picking any fixed sig marker is likely to cause problems -- notice
>how often anon.penet.fi messages show up truncated due to a line of
>hyphens.  A more flexible possibility: allow an X-Sig-Marker: header,
>which specifies a pattern/regexp to strip after.  Actually, the
>sig marker line itself should be stripped as well, in case it
>contains identifying information.

>> formal and mimeish, or a simpler '--truncate here--' sort of line
>> that gets retained across remailing so additional junk doesn't accrete.

>I don't see the problem you're guarding against.  Could you explain?
>Seems that sig elision needs to be done once, by the first hop, and
>then you're home free.

Actually a variation on this '--truncate here--' scheme might solve the
user-selected multiple-remailer scheme that we're trying to get up here.
Place the 'truncate' or '::'  line at the beginning of your message,
just after the last local header line.  Then add routing instructions
for the remailer.  Then maybe another 'truncate' message followed by
more routing instructions for the next remailer chosen.  Then a blank
line and your message.

BEGIN example:

From: [me]
Message-Id: <[number]@[mysite]>
To: hh at cicada.berkeley.edu
Subject: Hi there!

::

Request-Remailing-To: hh at pmantis.berkeley.edu

::

Request-Remailing-To: elee7h5 at rosebud.ee.uh.edu

::

Request-Remailing-To: cypherpunks at toad.com

Eli ebrandt at jarthur.claremont.edu said:
>Bill Stewart said:
>> Julf's anon.penet.fi remailer  cuts off anything resembling a signature,
>> using the convention that a -- line (or maybe an all-dash line?)
>> is a signature, since some of the common mail and news programs use that,
...

END example

Each remailer would only strip off the first 'Request-Remailing-To:'
instruction in the message.  The remailer would assume that anything
following that was part of the message, until it reached the signature,
which it would truncate.  Then it would remail the new 'message' as
requested.






From m5 at vail.tivoli.com  Sat Feb  5 11:30:19 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Sat, 5 Feb 94 11:30:19 PST
Subject: doj_escrow_intercept.procedures (fwd)
In-Reply-To: <199402042259.RAA00682@eff.org>
Message-ID: <9402051926.AA10212@vail.tivoli.com>



Robert Cain writes:
 > Wow! That procedure...

I'm having great difficulty extracting meaning from your prose, but I
think you're saying that you like that the government has escrowed
keys to Clipper phones for use in "national emergencies".

 > Imagine that it is your city that gets a terrorist nuke built
 > in one of its basements.

We don't have many basements in Austin.

 > Truly secure and easy communication makes
 > that a whole lot easier 

Makes *what* a whole lot easier, building the bomb or catching the
bombers?

 > but then since a truly secure box is real
 > simple to make, 

Really?

 > it sort of obviates the reasoning for trying to do the
 > standardization anyway.

Obviates the reasoning?  I'm confused.

 > Anybody who really wants absolute security
 > will be able to get it at some price that won't be too high.  :-)

So what exactly are you talking about?  Sounds like you're happy the
government introduced Clipper because it's so easy for anyone to build
secure cryptographic devices.  I'm having trouble understanding this.

 > I would like to propose us the challenge to come up with a way
 > utilizing this crypto technology and signatures and such to guarantee a
 > verifiable trail whenever it is done that is available to any court
 > of law.

Whenever *what* is done?  Whenever somebody builds a nuclear bomb?

 > The implication is clear ... I suggest that, as Tom Lehrer talks about
 > on his album Revisited, we "Be Prepared."  :-)

I think we should start with, "Be Lucid."

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From rcain at netcom.com  Sat Feb  5 11:35:40 1994
From: rcain at netcom.com (Robert Cain)
Date: Sat, 5 Feb 94 11:35:40 PST
Subject: Crypto Regulation Reform
Message-ID: <199402051934.LAA08528@mail.netcom.com>




Mr. President,

I am watching with great interest the activity with regard to cyrpto
regulation and have an observation I would like to share.  The
following was excerpted from the Harris statement:

> 
> The President has determined that vital U.S. national security and 
> law enforcement interests compel maintaining appropriate control 
> of encryption. Still, there is much that can be done to reform 
> existing controls to ensure that they are efficiently implemented 
> and to maintain U.S. leadership in the world market for encryption 
> technology. Accordingly, the President has asked the Secretary of 
> State to take immediate action to implement a number of procedural 
> reforms. The reforms are:
> 

While I totally understand the concern here and am in sympathy with the
reasoning, assuming benign adherence to the procedures, I think you are
in effect jousting windmills with this attempt to control or regulate
crypto.  It is simply too easy to build and distribute inexpensive
devices that are *truly secure*, without back doors to make it other
than delusional to think that the people that we would not want to have
this technology won't.  A device can be made right now at lower cost
than a computer modem, much lower, that could be inserted between any
phone and the wall that would make it impossible, no matter what laws
are in place, to tap either passively or acitively, communication that
passes between two of these devices.  I know how to do it, could do it
and probably will just for the fun of it at least.  If I can there are
many others that can also.  In fact I personally know several.  These
devices can be credit card size and even fit in a wallet.  They can
easily be smuggled in and will be.  A black market will flourish and
nothing will have been accomplished except the expenditure of a lot of
futile money and creation of more crime in an inflated, lucrative
market.

We simply must accept that point-to-point secure communication is a
part of our electronic environment and swallow the bitter pill that no
matter what the valid arguments are for regulation, it is effectively
not possible, so that national security and law enforcement are going
to be denied, in the near future, a tool in their arsenel and will have
to come up with new ways of gathering this intelligence.

Please abandon this effort before we throw good money after bad and
create a worse situation than we will have without it.

I would like whoever processes this email to forward a copy to the
following contact.

> The contact point for further information on these reforms is Rose 
> Biancaniello, Office of Defense Trade Controls, Bureau of 
> Political-Military Affairs, Department of State, (703) 875-6644.

Sincerely,

Bob Cain

-- 
Bob Cain    rcain at netcom.com   408-354-8021




From FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU  Sat Feb  5 11:45:40 1994
From: FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU (FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU)
Date: Sat, 5 Feb 94 11:45:40 PST
Subject: Apologies, but . . .
Message-ID: <01H8J3B5YJFK8Y56KS@SNYFARVA.BITNET>


        I read Eric's "welcome" file several times after signing on and *know*
that I sent a request to unsubscribe to the correct address; I also recall his
stating that sending an unsub message here would tar and feather me as a
"newbie," but . . . two attempts to unsub via the prescribed route have yielded
nothing more than an additional 75 or more files from this list.

        I respect the effort being made but can recognize it when I'm over my
head:  I'm a poet not a programmer.  And I need help extricating myself from
this web.

        Thanks.

Cordially,
***************
Charles Fishman





From rcain at netcom.com  Sat Feb  5 11:45:41 1994
From: rcain at netcom.com (Robert Cain)
Date: Sat, 5 Feb 94 11:45:41 PST
Subject: CERT advisory
In-Reply-To: <9402050055.AA22719@ah.com>
Message-ID: <199402051944.LAA09776@mail.netcom.com>


Eric Hughes sez:
> 
> Since active interception is not nearly so easy as passive listening,

This isn't true of anything but the aether itself or a point to point
wire with integrity.  In any switched or networked system with routing,
active interception is trivial.  That is why D-H has a lower level
of applicability than generally considered.

> it would be appropriate to use a Diffie-Hellman key exchange in this
> situation.  This protocol has no persistent private keys, so the issue
> of keeping a private key around securely is not an issue.

Yes, the one time key usage is an important factor in the D-H.
Nothing can be determined from one session that will help in
breaking another.


Peace,

Bob

-- 
Bob Cain    rcain at netcom.com   408-354-8021


           "I used to be different.  But now I'm the same."


--------------PGP 1.0 or 2.0 public key available on request.------------------




From m5 at vail.tivoli.com  Sat Feb  5 12:20:19 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Sat, 5 Feb 94 12:20:19 PST
Subject: Crypto Regulation Reform
In-Reply-To: <199402051934.LAA08528@mail.netcom.com>
Message-ID: <9402052019.AA10570@vail.tivoli.com>



Robert Cain writes:
 > A device can be made right now at lower cost
 > than a computer modem, much lower, that could be inserted between any
 > phone and the wall that would make it impossible, no matter what laws
 > are in place, to tap either passively or acitively, communication that
 > passes between two of these devices.  I know how to do it, could do it
 > and probably will just for the fun of it at least.  

Uhh, could you tell us?  Sounds like quite a breakthrough.  Credit
card sized?  Much cheaper than a modem, like $50 maybe?  And it
digititizes and securely encrypts speech (full duplex?) on the fly?

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From rcain at netcom.com  Sat Feb  5 12:20:41 1994
From: rcain at netcom.com (Robert Cain)
Date: Sat, 5 Feb 94 12:20:41 PST
Subject: doj_escrow_intercept.procedures (fwd)
In-Reply-To: <9402051926.AA10212@vail.tivoli.com>
Message-ID: <199402052018.MAA14027@mail.netcom.com>



Mike McNally sez:
> 
> 
> Robert Cain writes:
>  > Wow! That procedure...
> 
> I'm having great difficulty extracting meaning from your prose, but I

Hmmm, others have been having that problem lately.  :-)

> think you're saying that you like that the government has escrowed
> keys to Clipper phones for use in "national emergencies".

Yes, after long consideration that, that as I said runs counter to my
self interest, I had to come to the conclusion first that is was in
fact desirable to have a means to tap.  It should be very difficult
though and verifiable.

> 
>  > Imagine that it is your city that gets a terrorist nuke built
>  > in one of its basements.
> 
> We don't have many basements in Austin.

:-)

> 
>  > Truly secure and easy communication makes
>  > that a whole lot easier 
> 
> Makes *what* a whole lot easier, building the bomb or catching the
> bombers?

It makes it easier for any clandestine plan to be established and
carried out.  This is the greatest fear they have.  Arbitrary networks
of people with arbitrary purposes can be securely formed world wide
within the limits of the trust inherent in the people.  Can you spell
r e v o l u t i o n?  It's not me that's paranoid, it's them.  :-)

> 
>  > but then since a truly secure box is real
>  > simple to make, 
> 
> Really?

Yep.  It would take me about three months of full time effort and
would be almost a single chip.  I am not the only one by any means.

> 
>  > it sort of obviates the reasoning for trying to do the
>  > standardization anyway.
> 
> Obviates the reasoning?  I'm confused.

Well, if it is as easy as I contend to make devices that are truly
secure all the people that they would want to be able to monitor
would undoubtedly have one.

> 
>  > Anybody who really wants absolute security
>  > will be able to get it at some price that won't be too high.  :-)
> 
> So what exactly are you talking about?  Sounds like you're happy the
> government introduced Clipper because it's so easy for anyone to build
> secure cryptographic devices.  I'm having trouble understanding this.

No, I think now that Clipper is ultimately stupid.  I do think that if
it were *not* possible to easily get around it (black market probably,
remember the "blue boxes" of yore :-) and not possible probably to even
detect the illegal device's use (just use it as a front end to a
Clipper :-), then an escrow system which was benign (I realize some
think that an oxymoron) would be a good idea.

> 
>  > I would like to propose us the challenge to come up with a way
>  > utilizing this crypto technology and signatures and such to guarantee a
>  > verifiable trail whenever it is done that is available to any court
>  > of law.
> 
> Whenever *what* is done?  Whenever somebody builds a nuclear bomb?

Whenever they use whatever process they may set up to allow back
door entry.  I'm wondering if something analogous to a paper
trail could be guaranteed using our technology.  I don't know
if that is possible but have an inkling that it is.

> 
>  > The implication is clear ... I suggest that, as Tom Lehrer talks about
>  > on his album Revisited, we "Be Prepared."  :-)
> 
> I think we should start with, "Be Lucid."

Or learn to write better.  I'm workin' on it.  :-)

Peace,

Bob

-- 
Bob Cain    rcain at netcom.com   408-354-8021


           "I used to be different.  But now I'm the same."


--------------PGP 1.0 or 2.0 public key available on request.------------------




From mg5n+ at andrew.cmu.edu  Sat Feb  5 12:25:41 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Sat, 5 Feb 94 12:25:41 PST
Subject: Info on anonymous remailers
Message-ID: <MhIzyyC00VpD4VDkYS@andrew.cmu.edu>


I am pleased to report on the performance of our two newest remailers,
qwerty at netcom.com and nate at vis.colostate.edu.  Both remailers had a very
good response time.

Here are the latest ping-times:
Ping messages sent at Thu, 3 Feb 1994 17:49:24 -0500 (EST).
Replies received:

nobody at shell.portal.com          17:50:19 (+0:00:55)
nobody at vangogh.VIS.ColoState.EDU 17:50:29 (+0:01:05)
nobody at rosebud.ee.uh.edu         17:50:31 (+0:01:07)
qwerty-remailer at netcom.com       17:50:33 (+0:01:09)
catalyst-remailer at netcom.com     17:50:33 (+0:01:09)
nowhere at bsu-cs.bsu.edu           17:50:40 (+0:01:16)
remailer-admin at chaos.bsu.edu     17:50:48 (+0:01:24)
nobody at pmantis.berkeley.edu      17:51:08 (+0:01:44)
nobody at soda.berkeley.edu         17:51:26 (+0:02:02)
remailer at dis.org                 18:27:51 (+0:38:27)
nobody at cicada.berkeley.edu       18:28:05 (+0:38:41)
nobody at jarthur.Claremont.EDU     20:54:25 (+3:05:01)


The addresses of the above remailers are:

hfinney at shell.portal.com
catalyst at netcom.com
elee7h5 at rosebud.ee.uh.edu
nowhere at bsu-cs.bsu.edu
remailer at chaos.bsu.edu
hh at cicada.berkeley.edu
hh at pmantis.berkeley.edu
hh at soda.berkeley.edu
ebrandt at jarthur.claremont.edu
remailer at merde.dis.org
qwerty at netcom.com
nate at vis.colostate.edu


This test did not include any of the special-purpose anonymous
remailers.  For a complete list of remailers, send mail to
mg5n+remailers at andrew.cmu.edu.  You will receive an automated reply.





From hayden at krypton.mankato.msus.edu  Sat Feb  5 13:35:46 1994
From: hayden at krypton.mankato.msus.edu (Robert A. Hayden)
Date: Sat, 5 Feb 94 13:35:46 PST
Subject: FIRST CYPHERPUNKS VIRTUAL MEETING
In-Reply-To: <Pine.3.87.9402051000.A18297-0100000@crl2.crl.com>
Message-ID: <Pine.3.89.9402051512.B5579-0100000@krypton.mankato.msus.edu>


Is a MOO really the best method to carry out the virtual meeting?  My 
expierience has been that they are most unfriendly, espicially if you are 
clientless.

I'd think a series of IRC channels would work better, but maybe I'm wrong.

____        Robert A. Hayden          <=> hayden at krypton.mankato.msus.edu
\  /__          -=-=-=-=-             <=>          -=-=-=-=-
 \/  /   Finger for Geek Code Info    <=> In the United States, they
   \/  Finger for PGP 2.3a Public Key <=> first came for us in Colorado...
-=-=-=-=-=-=-=-
(GEEK CODE 1.0.1)  GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
		       n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)






From hfinney at shell.portal.com  Sat Feb  5 14:05:45 1994
From: hfinney at shell.portal.com (Hal)
Date: Sat, 5 Feb 94 14:05:45 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
Message-ID: <199402052205.OAA06854@jobe.shell.portal.com>


Quite a few misconceptions here, I'm afraid:

From: rcain at netcom.com (Robert Cain)
> In the Diffie-Hellman exchange there is a well-known-prime, w, and a
> well-knwon-modulus, m.

w is supposed to be a "generator" of the group of integers mod m.  It does
not have to be prime.  It is supposed to be such that the series w**0, w**1,
w**2,...,w**m-1 does not repeat but goes through all the integers less than m.
Testing for such w's is pretty easy if you know the factorization of m,
involving a few arithmetic tests.

> For those interested that don't know I think
> it then proceeds as follows (don't have notes in front of me so please
> someone correct me if I'm misremembering it) where ** is the power or
> exponentiation operator and % is the modulus operator:
> 
> 	1) Bob generates a one time random prime, b, then computes

b does not have to be prime; it is a random number less than m.

> 		B = (w ** b) % m
> 	   and sends B to Carol.
> 
> 	2) Carol generates a one time random prime, c, then computes

Likewise, c does not have to be prime; it is a random number less than m.

> 		C = (w ** c) % m
> 	   and sends C to Bob.
> 
> 	3) Bob generates a session key:

Carol does this, not Bob.

> 		K = (B ** c) % m
> 
> 	4) Carol generates a session key:

Bob does this, not Carol.

> 		K = (C ** b) % m
>[...]
> Now, the tutorial over :-), the question is; is there a "standard"
> well-known-prime, w, and a "standard" well-known-modulus, m, and if
             ^^^^^-- generator
> not, let's define one.

I don't think there is a need for this.  The two sides need to agree on
a pair but they could just pick it at the beginning.  If everyone uses
the same m,w it would help attackers of the scheme to focus their efforts
on these numbers.  I believe there was some discussion of using well-known
numbers in the Digital Signature Standard (which is based on the same
problem as DH) but I don't know what the resolution was.

> I suppose that PGP uses a well known pair but
> they are big and not easy to hand around without going through media (I
> think.)

PGP does not uses DH and has no well known numbers.

If you do want well known numbers, I really think it will not be that bad
just to put them into the program.  Coming up with an algorithm to choose
and test a generator from scratch is probably going to be larger and
certainly going to be far slower than just hard-wiring the number in.

Hal





From smb at research.att.com  Sat Feb  5 14:35:45 1994
From: smb at research.att.com (smb at research.att.com)
Date: Sat, 5 Feb 94 14:35:45 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
Message-ID: <9402052233.AA04867@toad.com>


	 
	 In the Diffie-Hellman exchange there is a well-known-prime, w, and a
	 well-knwon-modulus, m.  For those interested that don't know I think
	 it then proceeds as follows (don't have notes in front of me so please
	 someone correct me if I'm misremembering it) where ** is the power or
	 exponentiation operator and % is the modulus operator:

	 	1) Bob generates a one time random prime, b, then computes
	 		B = (w ** b) % m
	 	   and sends B to Carol.

	 	2) Carol generates a one time random prime, c, then computes
	 		C = (w ** c) % m
	 	   and sends C to Bob.

	 	3) Bob generates a session key:
	 		K = (B ** c) % m

	 	4) Carol generates a session key:
	 		K = (C ** b) % m

	 Carol and Bob have the same K because:
	 	K == (C ** b) % m == (B ** c) % m == (w ** (b * c)) % m

	 >From just the knowledge of B and C a snoop cannot determine
	 b from B, within computational reason (the root modulus being as
	 difficult as factoring), nor c from C, and because K cannot be 
	 determined from B and C without knowing b or c, she is screwed.

Close, but not quite.  The modulus m should be primed for best results.
Some folks have used a power of 2 for m, since that makes the modulus
operation easier, but it also makes cracking it easier, for comparable
sizes.  Next, the base w should be a primitive root of the group GF(m).

More seriously, your equations are subtly wrong -- Bob and Carol can't
do the calculations you've given.  Bob should calculate (C**b)%m -- he
knows b and C, but doesn't know c.  Similarly, Carol calculates (B**c)%m.

	 Now, the tutorial over :-), the question is; is there a "standard"
	 well-known-prime, w, and a "standard" well-known-modulus, m, and if
	 not, let's define one.  I suppose that PGP uses a well known pair but
	 they are big and not easy to hand around without going through media (I
	 think.)  When defined algorithmically they might be easier to actually
	 incorporate in a program or a product than great big numbers.  If this
	 has not been done, I propose a simply stated algorithm for finding a
	 "standard" w and m that will allow interoperation among all future
	 implementations of D-H as follows:

(deleted)

Two problems...  First, many attacks on the discrete log problem are
based on massive precomputation for a known modulus.  That probably
isn't an issue when you get to ~1K bits (*not* digits!).  Second, you
need to specify things far more concretely, and in particular define
the random number generation process.  You can't pick w till you know m.

	 I've found a solution to this that is more than sufficiently secure in
	 practice and even theoretically secure in most practical situations.

Well, I'd certainly be interested in hearing about it...  There have
been a number of mechanisms for preventing eavesdropping with DH;
a lot depends on what assumptions you want to make.  My attempts --
which involve the two parties sharing a weak (i.e., PIN- or password-grade
secret) can be found in /dist/smb/{neke,aeke}.ps on research.att.com.
There's also Rivest and Shamir's Interlock Protocol (April '84 CACM).
Davies and Price suggest using it for authentication, but Mike Merritt
and I showed that that doesn't work under certain circumstances.

		--Steve Bellovin





From nobody at shell.portal.com  Sat Feb  5 15:05:47 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sat, 5 Feb 94 15:05:47 PST
Subject: CypherPUNKS. Not!
Message-ID: <199402052302.PAA13278@jobe.shell.portal.com>


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

Disclaimer: In this essay, I explore the "punk" aspect of "Cypherpunk".
I wish to provoke, but not disrespect. I am trying to learn and stir things
up, and fend off a certain boredom and inertia that seems to set in when
new ideas seem to be scarce, or worse, shunned. I am a fool throwing
out ideas. You can learn a lot from a fool.

Dedicated to Nikola Tesla and Buckminster Fuller.

You ain't punks. Light rock and Muzak for you. Wouldn't want to upset an
RFC standard. Oh no no, that would be FROWNED upon! We might loose our
Netcom accounts. How can we download Wired and Mondo articles then? Are you
crazy? Detweiler and Sternlight might narc on us, and get us in fearful
trouble. We don't want trouble we just want to fit in and cruise for babes
with our e-money and bOING bOING ties. Please send more e-postage; your
remailer account's gone dry.

You got a problem; the problem is YOU. -Sid Vicious/Sex Pistols

When will all remailers forge mail headers so no one knows which site's
sendmail logs to subpoena or hack into? Forge Message-ID's too. Forge
everything. You can do it with postal mail, legally. When will every
account be a remailer? The internet SUCKS. What's the flag for PGP to
output its "random data block" format? Get off the internet. Message up, to
satellite, from remailer, message down to the world. No one knows who's
decrypting. And besides, "What encrypted message?" God doesn't give out His
sendmail logs. Wires, you can't see them. You can't trust them. If you rely
on technology for your security, stop using wires. And once your remailers
ARE more secure, old Uncle Sam's comin' t' pull the plug, 'cause they know
where to find that CPU. I'm comin' too. Sounds like fun. I wonder what sort
of sexy pass phrase you're using. What's your address? I want to send you
$1. Oh, here's the address in the Thomas Register. You're out a $1.

 * WWW - World Wide Wiretap *
Get Off the Internet and Write Us a Real Encryptor.
Get Off the Internet and Write Us a Real Encryptor.
Oh glee, the net loonies are sending megajoules not megabytes.
Real addresses not e-addresses. Can I still hit 'd' for "diffuse"?
I can't see you; I can't touch you.
I want privacy.
I want real friends.
I want off the internet.
Get Off the Internet and Write Us a Real Encryptor.

 -=Xenon=-

Dead Kennedys / Bedtime for Democracy and other works:

@SONG: Anarchy for Sale

Step right up folks

Anarchy for sale!
T-shirts only 10 dollars
Badges only 3.50
I nicked the design, never asked the band
I never listen to them either

Buy buy buy from Circle A
Like hula hoops, it's a disposable craze
Another fast-food fad to throw away

CHORUS
Get your anarchy for sale
Anarchy for sale
Anarchy for sale

Sheep unite!
Get your cuddly boots and studs
Be sure to rebel in proper style
Rebel along the paths we pick
Out of fear of peer pressure we create

Hey you!-
Get those flyers off my wall
No commie peace shit in my boutique
No one here cares what that all means

CHORUS

Our town sucks
Our scene rules
To belong you must buy into it
So we sold you metal spike bracelets....

C'mon let's see a good fight

CHORUS

@SONG: Chickenshit Conformist

Punk's not dead
It just deserves to die
When it becomes another stale cartoon
A close-minded, self-centered social club
Ideas don't matter, it's who you know

If the music's gotten boring
It's because of the people
Who want everyone to sound the same

Who drive bright people out
Of our so-called scene
'Til all that's left
Is just a meaningless fad

Hardcore formulas are dogshit
Change and caring are what's real
Is this a state of mind
Or just another label

The joy and hope of an alternative
Have become its own cliche
A hairstyle's not a lifestyle
Imagine Sid Vicious at 35

Who needs a scene
Scared to love and to feel
Judging everythng
By loud fast rules appeal

Who played last night?
"I don't know, I forgot.
But diving off the stage
Was a lot of fun."

CHORUS
So eager to please
Peer pressure decrees
So eager to please
Peer pressure decrees
Make the same old mistakes
Again and again,
Chickenshit conformist
Like your parents

What's ripped us apart even more than drugs
Are the thieves and the goddamn liars
Flipping people off when they share their stuff
When someone falls are there any friends?

Harder core than thou for a year or two
Then it's time to get a real job
Others stay home, it's no fun to go out
When the gigs are wrecked by gangs and thugs

When the thugs form bands, look who gets record deals
>From New York metal labels looking to scam
Who sign the most racist queerbashing bands they can find
To make a buck revving kids up for war

Walk tall, act small
Only as tough as gang approval
Unity is bullshit
When it's under someone's fat boot

Where's the common cause
Too many factions
Safely sulk in their shells
Agree with us on everything
Or we won't help with anythng
That kind of attitude
JUst makes a split grow wider

Guess who's laughing while the world explodes
When we're all crybabies
Who fight best among ouselves

CHORUS

That farty old rock and roll attitude's back
"It's competition, man, we wanna break big."
Who needs friends when the money's good
That's right, the '70s are back.

Cock-rock metal's like a bad laxative
It just don't move me, ya know?
The music's OK when there's more ideas than solos
Do we rally need the attitude too?

Shedding thin skin too quickly
As a fan it disappoints me
Same old stupid sexist lyrics
Or is Satan all you can think of?

Crossover is just another word
For lack of ideas
Maybe what we need
Are more trolls under the bridge
Wil the metalheads finally learn something-
Or will the punks throw away their education?

No one's ever the best
Once they believe their own press
"Maturing" don't mean rehashing
Mistakes of the past

CHORUS

The more things change
The more they stay the same
We can't grow
When we won't criticize ourselves
The '60s weren't all failure
It's the '70s that stunk
As the clock ticks we dig the same hole

Music scenes ain't real life
They won't get rid of the bomb
Won't eliminate rape
Or bring down the banks
Any kind of real change
Takes more time and work
Than changing channels on a TV set

CHORUS

@SONG: Fleshdunce

We're world industry's thoughtlords
The entertainment wing
We keep you all in line

By fixing your free will
Surround you with pop fantasies
Just slightly out of reach
To soften all the blows
Of your forced daily routine

We strip-mine your underground culture
Take the bite out and rinse it clean
Give ourselves credit for creating it
Then sell it back to you
At twice the price

Our pool of talent vampires
Has blown into your town
To dazzle, sign and milk you
All strictly on our own terms

You think you've got a lot to say
We'll change that real soon
You're not a person anymore
We've made you a cartoon

By the time we're through remolding you
You won't even recognize your face
There's no end to the eager beavers
Drawn the moths to our Babylon's mirage

Conveyor belt of fleshdunce
They all want to do the fleshdunce
Conveyor belt of fleshdunce
Who all want to do the fleshdance

@SONG: Where Do Ya Draw the Line

Seems like the more I think I know
The more I find I don't
Every answer opens up so many questions

anarchy sounds good to me
Then someone asks, "Who'd fix the sewers?"
"Would the rednecks just play king
Of the neighborhood?"

How many liberators
Really want to be dictators
Every theory has its holes
When real life steps in

So how do we feed
And make room for
All the people crowded on our earth
And transfer all that wealth
>From the rich to those who need it

CHORUS
Where do ya draw the line
Where do ya draw the line
I'm not telling you
I'm asking you

Ever notice hard line radicals
Can go on start trips too
Where no one's pure and right
Except themselves

"I'm cleansed of the system."
('Cept when my amp needs electric power)
Or-"The Party Line says no.
Feminists can't wear fishnets."

You wanna help stop war?
Well, we reject your application
You crack too many jokes
And you eat meat

What better way to turn people off
Than to twist ideas for change
Into one more church
That forgets we're all human beings
Where do ya draw the line?

In Toronto someone blew up
A cruise missile warhead plant
10 slightly hurt, 4 million dollars damage

Why not destroy private property
When it's used against you and me
Is that violence
Or self-defence
You tell me

CHORUS

Turn on
Tune in
Cop out

@SONG: PULL MY STRINGS

I'm tired of self-respect
I can't afford a car
I wanna be a prefab superstar

I wanna be a tool
Don't need no soul
Wanna make big money
Playing rock and roll

I'll make my music boring
I'll play my music slow
I ain't no artist I'm a businessman
No ideas of my own

I won't offend
Or rock the boat
Just sex and drugs
And rock and roll

Drool, drool, drool, drool, drool (etc.)
My payola!
Drool, drool, drool, drool, drool (etc.)
My payola!

You'll pay ten bucks to see me
On a fifteen foot high stage
Fatass bouncers kick the shit
Out of kids who try to dance

If my friends say
I''ve lost my guts
I'll laugh and say
That's rock and roll

But there's just one problem...

Is my cock big enough
Is my brain small enough
For you to make me a star
Give me a toot,
I'll sell you my soul
Pull my strings and I'll go far

And when I'm rich
And meet Bob Hope
We'll shoot some golf
And shoot some dope

Is my cock big enough
Is my brain small enough
For you to make me a star
Give me a toot,
I'll sell you my soul
Pull my strings and I'll go far

@SONG: SHORT SONGS

I love short songs.

@SONG: Stealing People's Mail
  Words and Music by Biafra

We ain't going to the party
We ain't going to the game
We ain't going to the disco
Ain't gonna cruise down main
We're stealing people's mail
      stealing people's mail
      stealing people's mail
On a friday night
Drivin' in the mountains
Winding round and round
Rummage thru your mailboxes
Take your mail back to town
And we got license plates, wedding gifts, tax returns
Checks to politicians from real estate firms,
Money, bills and cancelled checks,
Pretty funny pictures of your kids
We're stealing peopl's mail
On a Friday night
We're stealing people's mail
By the pale moonlight
We got grocery sackful after grocery sackful
Grocery sackful after grocery sackful
Grocery sackful after grocery sackful
Of the private lives of you
Ha Ha
People say we're crazy
We're sick and all alone
But when we read your letters
We're rolling on the floor
We got more license plates, wedding gifts, tax returns
Checks to politicians from real estate firms,
Money, bills and cancelled checks
We cut relationships with your friends
We're gonna steal your mail
By the pale moonlight
We better not get caught
We'll be drugged and shocked
'Til we come out born-again christians....

@SONG: NAZI PUNKS FUCK OFF

Punk ain't no religious cult
Punk means thinking for yourself
You ain't hardcore cos you spike your hair
When a jock still lives inside your head

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

If you've come to fight, get outa here
You ain't no better than the bouncers
We ain't trying to be police
When you ape the cops it ain't anarchy

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

Ten guys jump one, what a man
You fight each other, the police state wins
Stab your backs when you trash our halls
Trash a bank if you've got real balls

You still think swastikas look cool
The real nazis run your schools
They're coaches, businessmen and cops
In a real fourth reich you'll be the first to go

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

Nazi punks
Nazi punks
Nazi punks - Fuck Off!

You'll be the first to go
You'll be the first to go
You'll be the first to go
Unless you think...

@SONG: TERMINAL PREPPIE

         I go to college
         That makes me so cool
         I live in a dorm
         And show off by the pool
         I join the right clubs
         Just to make an impression
         I block out thinking
         It won't get me ahead

         My ambition in life
         Is to look good on paper
         All I want is a slot
         In some big corporation

         John Belushi's my hero
         I Lampoon and ape him
         My news of the world
         Comes from Sports Illustrated

         I'm proud of my trophies
         Like my empty beer cans
         Stacked in rows up the wall
         To impress all my friends

         No, I'm not here to learn
         I just want to get drunk
         And major in business
         And be taught how to fuck

         Win!  Win!
         I always play to win
         Wanna fit in like a cog
         In the faceless machine

         (chorus)
         I'm a terminal terminal terminal preppie
         Terminal terminal terminal preppie
         Terminal terminal terminal terminal
         Terminal terminal terminal terminal

         I want a wife with tits
         Who just smiles all the time
         In my centerfold world
         Filled with Springsteen and wine

         Some day I'll have power
         Some day I'll have boats
         A tract in some suburb
         With Thanksgivings to host

         (chorus)
         I'm a terminal terminal terminal preppie
         Terminal terminal terminal preppie
         Terminal terminal terminal preppie

@SONG: I AM THE OWL

         I am your plumber
         No I never went away
         I still bug your bedrooms
         And pick up everything you say
         It can be a boring job
         To monitor all day your excess talk

         I hear when you're drinking
         And cheating on your lonely wife
         I play tape recordings
         Of you to my friends at night

         We've got our girl in bed with you
         You're on candid camera
         We just un-elected you

         (chorus)
         I am the owl
         I seek out the fowl
         Wipe 'em away
         Keep America free
         For clean livin' folks like me

         If you demonstrate
         Angainst somebody we like
         I'll slip on a wig
         And see if I can start a riot
         Transform you to an angry mob
         All your leaders go to jail for my job


         But we aren't the russians
         Political trials are taboo
         We've got our secret
         Ways of getting rid of you
         Fill you full of LSD
         Turn you loose on a freeway

         (chorus)

         Send you spinning
         Send you spinning
         Send you spinning all over the freeway
         Spinning on the crowded freeway
         Spinning on the freeway
         Spinning on the freeway
         Spin...
         Spin...
         Spin - Lookout

         The Press, they never even cared
         Why a youth leader walked into a speeding car
         In ten years we'll leek the truth
         By then it's only so much paper

         Watergate hurt
         But nothing really ever changed
         A teeny bit quieter
         But we still play our little games
         We still play our little games
         We still play our little games
         We still play our little games
         We still play a lot of games
         I am the owl

         (chorus)

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVPbtQSzG6zrQn1RAQHIwAP/VW6tak/NGsOeHdD57Aj1NgsGaRkJaojQ
R96d91Kdh7f9n0QQiC+l3FRb+utKB6Clf2EIjnWLbG1ZGesKpRLAaKaaL3lcwHrT
8yNGuVDk4nmCHzBbI/uC+z9U6qrY7HWwjSU6fq5Gd9EpirBtmFHO8AyZtF+ZgiZe
xSL7rwOdJ4U=
=lMsr
-----END PGP SIGNATURE-----





From koontzd at lrcs.loral.com  Sat Feb  5 16:05:48 1994
From: koontzd at lrcs.loral.com (David Koontz )
Date: Sat, 5 Feb 94 16:05:48 PST
Subject: your mail
Message-ID: <9402060000.AA09012@io.lrcs.loral.com>


>David Koontz writes:

>> All this bullshit doesnot state that a court order is required, rather
>> 'legal authorization', which means the NSA for foreign intellingence
>> purposes without a court order.

>The Foreign Intelligence Surveillance Act (FISA) requires a court order
>The Foreign Intelligence Surveillance Act (FISA) requires a court order
>for such taps.

>--Mike

>From a secret court that has never (NEVER), turned down a request.





From wcs at anchor.ho.att.com  Sat Feb  5 18:25:48 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Sat, 5 Feb 94 18:25:48 PST
Subject: Problem with some digicash applications
Message-ID: <9402060224.AA04502@anchor.ho.att.com>


One security hole in online digicash systems of the Chaum variety is
that you _do_ need to make sure the money is only transmitted in
encrypted forms not susceptible to playback attacks.
(I haven't read the magic-money code yet...)
The threat scenarios look like this:
             cash                cash
Alice--------------------->Bob---fast_net-----slow_net--------->Bank
         \                       \                      /
          \_______________________\___Eve_____________/

If Eve can read the cash either before Bob gets it or before Bob's
message gets from his fast LAN across the slow part of the net
to the bank, then she can occasionally spend it before Bob can.
(This is especially likely if she's Bob's favorite remailer
or network provider.)  (On-line validation through slow remailers???)

It's probably not much of a problem for radio-tollbooths,
since the tollbooth(=Bob=bank) gets it as fast as Eve does.
It's also not a problem if Eve can't find the cash part of a message
between Alice and Bob or Bob and the bank.  
Unencrypted messages might let Eve subsitute her bank account for Bob's.

But consider fixed-format messages of the form:
	RSA(Key), IDEACBC[Key](Cash,Account#)
which might be commonly used by a Teller Machine or the digicash
equivalent of a credit card authorization box.
If Eve stomps on the Account-number bits, even though she can't
break the encryption to substitute her account number for Bob's,
she can substitute a random account number for Bob's.
This acts as a denial-of-service attack against Bob.

As a defense, either the message has to contain signatures or at least
MACs for validation, and be rejected if invalid, or the format
needs to make it impossible to find the account number field
or to modify it without trashing the cash as well.

A solution that's probably _not_ acceptible is for the Bank
to return a message of the form
	Sign[Bank](OK,Cash,Account#)
since this reveals the account number, which loses some privacy.
It maybe ok to use a hash of the account number, or a nonce + the
account number encrypted with the account-owner's public key.
# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465





From qwerty-remailer at netcom.com  Sat Feb  5 19:10:23 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Sat, 5 Feb 94 19:10:23 PST
Subject: Military & dependants
Message-ID: <199402060308.TAA28240@mail.netcom.com>


Nobody asks:
> Can American Military members or their family take copies of PGP
> or other encryption programs with them when being stationed at
> overseas bases?  Aren't the overseas installations considered to
> be American soil while occupied, thus permitting such transfers?

I'm not sure what the ITAR rules say about export of armaments by
the military; it would be nice if it were illegal :-)

Also don't know if sending to American military bases overseas
counts as export, especially if it involves going through
non-US territory (if there is such a thing any more :-()

Use of encryption technology by the military is probably subject to
all sorts of rules; use for official purposes certainly is.
You could probably get in major trouble for doing so without authorization,
and I doubt PGP is officially approved; it's certainly not approved
for classified information.

Patent issues are also involved; the government is allowed to use
RSA as part of the terms of the funding deals for their research,
but this presumably doesn't apply to private use by government
employees.  On the other hand, IDEA wasn't developed with US funds,
and its patent probably doesn't give the government any rights 
to use it.  Ascom Tech probably could try to restrict it if they wanted.





From wcs at anchor.ho.att.com  Sat Feb  5 19:35:48 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Sat, 5 Feb 94 19:35:48 PST
Subject: Magic Money questions
Message-ID: <9402060330.AA05021@anchor.ho.att.com>


>What does the bank hope to accomplish by claiming a coin was already spent?
>It can print more coins any time, so it has no reason to cheat.

If the bank issues coins in return for real money, and then refuses to
accept them back, it's gained the amount of money it just ripped off.
Doing this often enough to be noticed loses reputation, of course;
you can sometimes get away with it if you're a government central bank
and get a law made saying you no longer have to pay back silver for those
paper dollar notes.  On the other hand, printing extra coins doesn't
get you anything, since nobody gave you any real money for them.

Of course, if you can start up a big bank in remailer-space,
and get lots of depositors, but nobody knows where you are,
you can ignore the damage to your reputation by ripping off
all your depositors at once and forwarding your email to Argentina,
just as bank-embezzlers occasionally abscond with the whole pile.





From hughes at ah.com  Sat Feb  5 19:45:48 1994
From: hughes at ah.com (Eric Hughes)
Date: Sat, 5 Feb 94 19:45:48 PST
Subject: Apologies, but . . .
In-Reply-To: <01H8J3B5YJFK8Y56KS@SNYFARVA.BITNET>
Message-ID: <9402060344.AA17504@ah.com>


Had you read the message closely, you would have read that I maintain
the list by hand and do not immediately get to all requests.

Eric
-----------------------------------------------------------------------------
The cypherpunks list is for discussions on implementing cryptography.
To mail to the whole list, send mail to

	cypherpunks at toad.com

Every mail message sent to this address will be forwarded to everyone
on the list.  Make sure that the message you wish to send is
appropriate for such a broad delivery.


If you want to be added or removed from the cypherpunks list, or have
any other questions which pertain to list management, send mail to

	cypherpunks-request at toad.com

I don't manage the list from my regular account, so such mail which
ends up in my ah.com account will just get you another copy of this
file.

Eric Hughes 
   maintainer of the lists cypherpunks at toad.com and
   cypherpunks-announce at toad.com








From hughes at ah.com  Sat Feb  5 19:45:49 1994
From: hughes at ah.com (Eric Hughes)
Date: Sat, 5 Feb 94 19:45:49 PST
Subject: CERT advisory
In-Reply-To: <199402051944.LAA09776@mail.netcom.com>
Message-ID: <9402060343.AA17498@ah.com>


>> Since active interception is not nearly so easy as passive listening,

>This isn't true of anything but the aether itself or a point to point
>wire with integrity.  In any switched or networked system with routing,
>active interception is trivial.  

Possible?  Yes.

Trivial?  Bullshit.

It's all economics, and the resources required to intercept packets
and spoof protocols is significantly greater than that merely to watch
packets go by.  There are many fewer people with these greater
resources, which include access to routers.

Both active and passive attacks are possible in a packet forwarding
system.  Merely because both are possible does not mean that they are
the same.

D-H is not a panacea, but its use for password transmission would
completely solve the Ethernet sniffing problem.  That alone indicates
that active and passive attacks are different in nature and in the
defences appropriate.

D-H doesn't require any prearranged keying material, which is its
primary advantage against passive attacks.  Since distribution and
storage of keying material is an as-yet pragmatically unsolved
problem, it is unwise to insist upon prearranged keys when a partial
solution, D-H, is available immediately.

Eric





From jdwilson at gold.chem.hawaii.edu  Sat Feb  5 20:35:48 1994
From: jdwilson at gold.chem.hawaii.edu (Jim Wilson VA)
Date: Sat, 5 Feb 94 20:35:48 PST
Subject: Soap Boxx's Brother??
Message-ID: <9402060430.AA14604@gold.chem.hawaii.edu>


Taken from paperboy a briefing given by Mr. Dennix Boxx - any relation to
Soap? <hehehe>



Forwarded message:
> From paperboy at tecnet2.jcte.jcs.mil Thu Feb  3 17:01:04 1994
> Date: Fri, 4 Feb 94 02:26:12 GMT
> Message-Id: <9402040226.AA01090 at tecnet2.jcte.jcs.mil>
> To: jdwilson at gold.chem.hawaii.edu
> From: paperboy at tecnet2.jcte.jcs.mil
> Posted: Fri Feb  4 02:26:10 GMT 1994
> Subject: News Briefing 02/03/94
> 
> DoD News Briefing
> Thursday, February 3, 1994 - 1:00 p.m.
> Mr. Dennis Boxx, Deputy ATSD, Public Affairs
> 
> 
>      Mr. Boxx:  Good afternoon.  I've got a couple of
> announcements.
> 
>      Today we have a Memorandum for Correspondents, which
> announces that Secretary of Defense-Designate William Perry will
> leave Washington, Friday evening, to attend the Munich Conference
> on Security Policy '94.  Deputy Secretary Perry is scheduled to
> deliver the U.S. address at the conference on Sunday morning.
> Throughout the weekend he will also hold bilateral meetings with

 -Jim






From nate at VIS.ColoState.EDU  Sat Feb  5 21:00:22 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Sat, 5 Feb 94 21:00:22 PST
Subject: Please, please write to your reps!
Message-ID: <9402060500.AA02903@vangogh.VIS.ColoState.EDU>



In light of recent news from the EFF concerning the Clipper/
SkipJack/Key Escrow/Rape of Privacy issues (see
comp.org.eff.news), I would like to ask everyone out there
to take the time (a few minutes, maybe an hour if you really take
time) to write to your Congress-unit and Senator, as well as
the President, Vice President, etc... and voice your
strong opposition to the recent policy decisions about
Clipper.
 
Also, write to CNN and any other news agencies (ABC,
NBC, CBS, BBC, etc) and tell them that they should get
their act together and start to cover this issue, as it
certainly is "newsworthy"
  
Thanks for your time, and please write.
   
-nate sammons
    
-- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From nobody at pmantis.berkeley.edu  Sat Feb  5 21:10:23 1994
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Sat, 5 Feb 94 21:10:23 PST
Subject: Remailer Security
Message-ID: <9402060508.AA24108@pmantis.berkeley.edu>


Just a qucik question.

How safe am I from being traced if I use a remailer?  If I hop it through 
say three of them?





From nate at VIS.ColoState.EDU  Sat Feb  5 21:20:22 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Sat, 5 Feb 94 21:20:22 PST
Subject: bounce from <MAILER-DAEMON@rosedale.org> ??
Message-ID: <9402060519.AA02971@vangogh.VIS.ColoState.EDU>



I just posted to the list about writing to congress-units, etc,
and was sent a bounce from <MAILER-DAEMON at rosedale.org> that the
recipient's mailbox was full...  anyone else get this?

-nate

-- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From nobody at shell.portal.com  Sat Feb  5 21:40:22 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sat, 5 Feb 94 21:40:22 PST
Subject: Remailer security.
Message-ID: <199402060537.VAA12987@jobe.shell.portal.com>


Mr. Someone asked,
>Just a qucik question.

>How safe am I from being traced if I use a remailer?  If I hop it through
>say three of them?

Depends on how much they are willing to pay for the extropia secret key and
pass phrase that I am selling. Too bad they don't guard their company at
night, and don't use rotary locks instead of six pin tumblers. How much do
you think your enemy is willing to offer?

The point is.... Decide for yourself. No one knows.

-Citizen #487-22-3398/C class.





From hughes at ah.com  Sat Feb  5 21:50:22 1994
From: hughes at ah.com (Eric Hughes)
Date: Sat, 5 Feb 94 21:50:22 PST
Subject: ADMIN: bounce from <MAILER-DAEMON@rosedale.org> ??
In-Reply-To: <9402060519.AA02971@vangogh.VIS.ColoState.EDU>
Message-ID: <9402060546.AA17852@ah.com>


I've removed the relevant bouncing address from the list.

In the future, such question can be directed to me at hughes at ah.com,
since this kind of list problem is best dealt with quicker than normal
requests.

Eric





From nate at VIS.ColoState.EDU  Sat Feb  5 23:05:49 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Sat, 5 Feb 94 23:05:49 PST
Subject: a little information, please...
Message-ID: <9402060704.AA03216@vangogh.VIS.ColoState.EDU>


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



Could some kind sole out there please tell me a few things?

1)  How many legal wiretaps are conducted each year?

2)  How much will it cost to implement the key escrow system,
    specifically, how much startup cost and how much per year
    to maintain?

3)  How much money is lost per year as a result of strict export
    controls on encryption technology?  (Lost from business
    revinue, that is)

4)  How much money has it cost to design the Clipper Chip and
    the DSS?

Thanks,

- -nate

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From nobody at shell.portal.com  Sat Feb  5 23:40:22 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sat, 5 Feb 94 23:40:22 PST
Subject: Magic Money Update
Message-ID: <199402060740.XAA24069@jobe.shell.portal.com>


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

<mmnyfast.zip update sent to csn.org>

This is an update for Magic Money. The PGPKGEN.C here contains a very fast
mp_inv function, provided by an anonymous poster on the Cypherpunks list,
which reduces the time to unblind a 1024-bit coin from minutes to a few
seconds. 

The C.C contains a new -r option which generates a blank message,
similar to the -i option, without generating a new key. This should be used
by infrequent server users, to update their elists and make sure they do not
miss an expiration. The message generated by -r has no coins, but causes the
server to reply.

Blinding is now fast enough to use a 1024-bit server key. A server operator
should re-integrate the assembly-language speedups from PGP, or the server
will be very slow in signing coins. The PGP makefile might help you do this.

                                           Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVSTlsGoFIWXVYodAQGIVgP/aU0rqTccbAonRO2Mv4O3Z9WAXswy1BkN
VY1psOyNTgT+C7Uvet1dm92rlRgvShAEcF5CK7crrO+hjhp7QgU6rnCY5ZrAN/i5
Oavn8CZcjxGb7nSkMhPQIIO7yoeKJoV+zaIYJ8uhGwSI6s7L/sDRsqebpxqoN4Bv
EMAIK3BZ8Zg=
=uahV
-----END PGP SIGNATURE-----





From mgream at acacia.itd.uts.edu.au  Sun Feb  6 00:10:24 1994
From: mgream at acacia.itd.uts.edu.au (Matthew Gream)
Date: Sun, 6 Feb 94 00:10:24 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
In-Reply-To: <9402052233.AA04867@toad.com>
Message-ID: <9402060811.AA24965@acacia.itd.uts.EDU.AU>


Earlier, smb at research.att.com wrote:

> There's also Rivest and Shamir's Interlock Protocol (April '84 CACM).
> Davies and Price suggest using it for authentication, but Mike Merritt
> and I showed that that doesn't work under certain circumstances.

Diffie, Wiener et al in "Authentication and Authenticated Key Exchanges"
(Designs, Codes and Cryptography, 2, 1992) discuss the need to combine key 
exchange and authentication, amongst other things. Anyway, the upshot is 
that a Station To Station protocol is developed and discussed which is 
based on the original D-H system. Damn, I don't have the paper which me,
so I'm not sure whether third party certification is needed.

The accompanying discussion, relating to secure protocol requirements and 
so on struck me as quite good at the time IMHO.

Matthew.
-- 
Matthew Gream, ph: (02)-821-2043
	M.Gream at uts.edu.au.





From karn at qualcomm.com  Sun Feb  6 00:10:50 1994
From: karn at qualcomm.com (Phil Karn)
Date: Sun, 6 Feb 94 00:10:50 PST
Subject: archiving on inet
In-Reply-To: <199402021222.HAA05404@snark>
Message-ID: <199402060805.AAA19940@servo.qualcomm.com>


>Anyway, people who want to use the law to restrict distribution of
>their news articles are extremely foolish. Your words are out there
>and they WILL be read. Forever. You can't help it. If you find your
>words embarassing, don't say them.

Yeah. You guys should lighten up. You won't be able to keep your posts
off of CD-ROM collections, but you might still have some fun with the
vendors.

The next release of my KA9Q NOS software, prior versions of which have
already appeared on quite a few CD-ROMs, will contain a copyright
notice that explicitly grants permission to CD-ROM publishers to carry
it for free -- on the condition that they send me a free copy of the
disk.

Most already do, as a courtesy, usually when I show up at their booths
at the Dayton Hamvention. My new notice should take care of the
rest. Heck, each one probably costs them no more than a buck to make,
so how could they object? Seems like a win-win situation to me. They
enhance their sales and I build up a nice CD-ROM collection quite
cheaply...

By the way, there's a very good reason why you should *welcome* the
availability of USENET archives on CD-ROM. Imagine that one day you
toss out on the net a clever little idea in the hope that someone may
find it useful. You don't think much of it at the time. Several years
later, much to your dismay, you discover that some slimeball has
stolen and been granted a patent on your idea. You're convinced they
got it from your original USENET article, but how do you prove it?
Simple -- if your original comments were preserved for posterity on a
commercial CD-ROM, complete with silk-screen label showing the dates
of the articles it contains.

Don't laugh - this has already happened to me. Fortunately, I had also
published my idea in a ham radio journal more than a year before the
bogus patent application was filed. But if I hadn't, I'd now be
frantically looking around for 5-year-old USENET archives.

Phil





From nobody at shell.portal.com  Sun Feb  6 00:10:50 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sun, 6 Feb 94 00:10:50 PST
Subject: Magic Money vulnerabilities?
Message-ID: <199402060810.AAA25213@jobe.shell.portal.com>


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

People have mentioned possible attacks against Magic Money.

I don't think it is possible to send the server a value to sign which
would reveal the server's secret key. The server signs your message x by
raising x to the power d. If you know x^d and x, finding d would seem to be
a discrete-logarithm problem, which is just as intractible as factoring.
Can a small or otherwise rigged x help you to find d? If so, participating
in any blind signature protocol is very dangerous, but I don't think that
you can find d this way.

wcs at anchor.ho.att.com wrote: (some deleted) 

(attack 1)

>One security hole in online digicash systems of the Chaum variety is
>that you _do_ need to make sure the money is only transmitted in
>encrypted forms not susceptible to playback attacks.

>If Eve can read the cash either before Bob gets it or before Bob's
>message gets from his fast LAN across the slow part of the net
>to the bank, then she can occasionally spend it before Bob can.

(attack 2)

>If Eve stomps on the Account-number bits, even though she can't
>break the encryption to substitute her account number for Bob's,
>she can substitute a random account number for Bob's.
>This acts as a denial-of-service attack against Bob.

>As a defense, either the message has to contain signatures or at least
>MACs for validation, and be rejected if invalid, or the format
>needs to make it impossible to find the account number field
>or to modify it without trashing the cash as well.

Magic Money is not susceptible to the first (intercept) attack, because
the coins are encrypted with the server's public key. The reply is also
encrypted with a response key sent to the server inside the encrypted
packet. The server signs its responses, so you couldn't send someone some
bogus coins and then fake the server's response to fool the person into
believing that the coins were good.

Magic Money has no account numbers; the server just exchanges old coins 
for new coins immediately. A version of the second attack is a problem. The
message from the user to the server has no authentication. It is just an
encrypted PGP message to the server. There is an RSA packet and an IDEA
packet, and the data is directly inside the IDEA packet. 

If you were to dearmor the message and garble something near the end, then 
re-armor it, the server would bounce the garbled coins with a bad signature. 
Some of the first coins would already have been cancelled, and their value 
would be lost. To prevent this, the next version will MD5 the data packet 
before encrypting it, and include the MD5 value. This will be checked, and 
if it is bad, the message will be thrown out before processing any of the 
coins. This is not a pressing problem. Who would go to all the trouble to
make a remailer detect and corrupt certain messages? The person doing the
corrupting would not have anything to gain.

A while ago I read of a program in alpha-test called Nautilus. This was
specifically designed to compress speech for modem transmission. The author
said that the beta, when it was ready, would be Copylefted. PGP Tools, if
combined with Nautilus, has everything you need to do a secure phone. With
the Clipper push, we need one badly, and now. It should use PGP keys for
authentication, but either DH or a one-shot RSA key for key exchange. That
way they can't record the session and demand your key later, as they could
if you used your regular PGP key for the key exchange.

                                             Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVSdtMGoFIWXVYodAQHC9AQApMjaIF2+h0k6Zb2YSwjkFL1/zAgCXJU+
Dm+kS0us9kusKMc2wr2pc4cEzQow9apM/Od2CisXAaRtHZNUyE8tN3mYWEPxAdcd
6qG03ZekvTqQB+do2HBGRAH3KXGscPIDCyjuh9iIKp9bB7/GWLNoAYm7fPjxpIYz
gnWTuRyBme4=
=wOox
-----END PGP SIGNATURE-----





From cknight at crl.com  Sun Feb  6 00:50:23 1994
From: cknight at crl.com (Chris Knight)
Date: Sun, 6 Feb 94 00:50:23 PST
Subject: archiving on inet
In-Reply-To: <199402060805.AAA19940@servo.qualcomm.com>
Message-ID: <Pine.3.87.9402060033.A15279-0100000@crl2.crl.com>




On Sun, 6 Feb 1994, Phil Karn wrote:

> The next release of my KA9Q NOS software, prior versions of which have
> already appeared on quite a few CD-ROMs, will contain a copyright
> notice that explicitly grants permission to CD-ROM publishers to carry
> it for free -- on the condition that they send me a free copy of the
> disk.

It's a good idea...  But can you see a CD-ROM publisher sending a free CD 
to everyone who puts that in a disclaimer?  Still... It's more likely 
than calculating royalties!


-ck







From julf at penet.fi  Sun Feb  6 02:35:51 1994
From: julf at penet.fi (Johan Helsingius)
Date: Sun, 6 Feb 94 02:35:51 PST
Subject: FIRST CYPHERPUNKS VIRTUAL MEETING
In-Reply-To: <Pine.3.89.9402051512.B5579-0100000@krypton.mankato.msus.edu>
Message-ID: <199402061035.AA19075@lassie.eunet.fi>



> Is a MOO really the best method to carry out the virtual meeting?  My 
> expierience has been that they are most unfriendly, espicially if you are 
> clientless.
> 
> I'd think a series of IRC channels would work better, but maybe I'm wrong.

Have to agree 100%.

	Julf






From hughes at ah.com  Sun Feb  6 03:55:55 1994
From: hughes at ah.com (Eric Hughes)
Date: Sun, 6 Feb 94 03:55:55 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
In-Reply-To: <9402060811.AA24965@acacia.itd.uts.EDU.AU>
Message-ID: <9402061151.AA19462@ah.com>


>Anyway, the upshot is 
>that a Station To Station protocol is developed and discussed which is 
>based on the original D-H system. 

The STS protocol is a regular D-H followed by a (delicately designed)
exchange of signatures on the key exchange parameters.  The signatures
in the second exchange that they can't be separated from the original
parameters.

>Damn, I don't have the paper which me,
>so I'm not sure whether third party certification is needed.

There is a digital signature required, so what is at root required is
a trusted public key of the other party.  One can use a certificate to
establish this trust and transmit it at session time, but any other
method of communicating a public key will work, include a trusted web
of trust or direct previous transmission.

STS is a well-thought out protocol, with many subtleties already
arranged for.  For the issue at hand, though, which is Ethernet
sniffing, it's authentication aspects are not required now, even
though they certainly will be in the near future.

Eric





From wcs at anchor.ho.att.com  Sun Feb  6 04:50:29 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Sun, 6 Feb 94 04:50:29 PST
Subject: Government Policy makes Internet breakins easier
Message-ID: <9402061248.AA09213@anchor.ho.att.com>


Newsgroups: comp.org.eff.talk,comp.security.misc,talk.politics.crypto,alt.security,alt.activism
Subject: Government Encryption Policies Simplify Internet Break-ins
Distribution: 

[Sure would be nice if the EFF or CPSR would put out a press release
along these lines.  Anybody?]

The news from the Information Superhighway hasn't been good this week.
Major breakins have been occurring from someone who's been stealing
users' passwords as they log in across the net, using them to break
into their machines, and using their machines to watch the net for
more passwords.  It's not really that hard to stop - encryption
technology has been available for several years that sends passwords
across the net in encrypted form the eavesdroppers can't use - but
most people haven't deployed encryption.  Why not?

Well, part of it's just laziness, but in large part the use of
encryption has been restricted by the government's Cold War era
policies against developing, using, or distributing encryption software.
Encryption is the mathematical privacy coding that lets people
send their passwords and conversations privately.
If you want to sell encryption software overseas, you have to get a
munitions export license, just as you would for exporting assault
rifles or nuclear weapon parts, and they'll only give you a license
for crippled software that the NSA can break easily, unless you're a
bank or selling to a "friendly" government's military.
If you want to sell encryption software in the US, you can't export it,
which means you have to sell separate US and export versions.

And if you want to give it away free, like lots of university and
public domain software, you can't just post it to the net or make it
available for ftp (the Internet version of the public library),
without risking years in jail or at least having your computers
confiscated while the government tries to decide whether to indict you -
and you'd better be able to afford some *very* good lawyers.
Can this sort of free speech really be illegal?  Nobody's really sure,
the government won't give you permission and few people want to risk
the jail time to find out if they'll give you forgiveness.

Meanwhile, most computer systems have simple password systems that
can't protect against wiretappers.  It's especially a problem on
international long-distance circuits, where the connections are more
exposed, because export rules say your business can't ship it the
package you use on your US computers to your foreign branches.

The Clinton Administration has announced that they're going to relax
the export rules a bit, if you use their new Escrow Encryption Chip
(which has built-in wiretapping capabilities) or simple encryption
systems with short, easy-to-guess keys.  The paperwork will be simpler,
and you won't need an arms dealer license to carry your cellular phone
or laptop computer on a business trip, but the NSA still retains
control over what technology you can use.  Proposed legislation in
Congress would transfer control of crypto exports to the Commerce
Department, which handles most other export licensing.  

Without the Communist Party to kick around, U.S. Administration press
releases bring up spectres of drug dealers, terrorists, and pornographers,
but some of the major applications for the wiretapping capabilities of
the new Escrow Chip appear to be financial transactions and tax evasion,
since banks will need to replace their current encryption systems with
something newer, as faster generations of computer technology will
make the present systems insecure over the next 5-10 years.
Because the Escrow Chip is a hardware-only approach,
it's adequate for automatic teller machines, but you'd need to buy a
government encryption module if you want to do your banking over the
Information Superhighway - more secure encryption can be done cheaply,
in software, but the NSA's 55 mph speed limit won't let you - for now.

On the other hand, the Cold War's over and you can get good encryption software
from Finland, Moscow, Bulgaria, Switzerland, or Australia, often free,
and it's becoming widely used by political activists in post-Communist
countries.  


---------
The preceding has been the personal opinion of Bill Stewart,
and does not necessarily represent the views of the EFF, CPSR,
Cypherpunks, or my employer, but I'll be happy to have my rhetoric stolen :-)
---------
Bill Stewart billstewart at attmail.com





From julf at penet.fi  Sun Feb  6 05:40:28 1994
From: julf at penet.fi (Johan Helsingius)
Date: Sun, 6 Feb 94 05:40:28 PST
Subject: FIRST CYPHERPUNKS VIRTUAL MEETING
In-Reply-To: <Pine.3.87.9402051000.A18297-0100000@crl2.crl.com>
Message-ID: <199402061337.AA20812@lassie.eunet.fi>



>      The first cypherpunks virtual conference will be held at BayMOO on
> Wednesday, February 9, at 8pm PST (11 EST).  To get there:

Count me out. Yes, I like to participate in physical Cypherpunks
meetings. Yes, I like to participate over e-mail. If I really have
to, I can waste time using IRC. But I do *not* have enough patience
to hang out in any cute virtual restroom line in some virtual bar
in some virtual game... We already have enough of the dreaded
freenet virtual cafe stuff around - it's like using virtual punched
cards.... Ack!

	Julf






From BOBES_PIERRE at delphi.com  Sun Feb  6 06:00:29 1994
From: BOBES_PIERRE at delphi.com (BOBES_PIERRE at delphi.com)
Date: Sun, 6 Feb 94 06:00:29 PST
Subject: signoff list
Message-ID: <01H8K5MKMKVM90NSU2@delphi.com>


Pleas remove me from the list
bob





From huntting at glarp.com  Sun Feb  6 09:06:06 1994
From: huntting at glarp.com (Brad Huntting)
Date: Sun, 6 Feb 94 09:06:06 PST
Subject: doj_escrow_intercept.procedures (fwd)
In-Reply-To: <199402052018.MAA14027@mail.netcom.com>
Message-ID: <199402061700.AA04889@misc.glarp.com>



>> Makes *what* a whole lot easier, building the bomb or catching the
>> bombers?

> It makes it easier for any clandestine plan to be established and
> carried out.  This is the greatest fear they have.  Arbitrary
> networks of people with arbitrary purposes can be securely formed
> world wide within the limits of the trust inherent in the people.
> Can you spell r e v o l u t i o n?  It's not me that's paranoid,
> it's them.  :-)

While stopping terrorists may be easier in a country with pre-taped
communications, and organizing otherwise undetected insurrection
will be a little closer to possible, this is not the main purpose
of wiretaps today or in the future.

The real targets of wiretaps (now and in the future) are political
activists.  Anyone who poses a serious threat to large corporate
profits is a target for a wire tap.  This includes organizations
like Greanpeace, the communist party, CISPES, and even libertarians
who oppose superfluous military intervention.

Sure, blowing up the world trade center costs money, but cutting
arms sales to Indonesia just because of some little genocide on an
island with only a few hundred thousand inhabitants...  That cuts
into profits; especially if it catches on.

In the past, if Dow wants to put a tap on my friend's mom's phone
(a prominent anti-pesticide activist), they can just hire a private
investigator to climb the poll and sift through the conversations.
No, they never found out who was taping the line, for some reason
they didn't think to ask the guy who came around once a week to
change the tapes on top of the pole (go figure).

In the world where Clipper is predominant, the government will have
a monopoly on this sort of activity.  Two things are clear to
follow:  First, there will be fewer PIs able to do wiretaps.  People
chasing after abducted children or forgoten alimony cheques will
be out of luck.

Second, the government will be pressured into taking on the activities
that are now done by PIs (at a substantially greater cost of course).
This will force some relaxing of the rules governing obtaining
escrowed keys.

Since anyone purchasing the key escrow devices will have implicitly
agreed to (amongst other things) wave any expectation of privacy
associated with using the device, they probably wont have to much
legal ground to stand on when they discover the their phone
conversations have been sold to Exon.


brad





From nobody at jarthur.Claremont.EDU  Sun Feb  6 09:30:31 1994
From: nobody at jarthur.Claremont.EDU (nobody at jarthur.Claremont.EDU)
Date: Sun, 6 Feb 94 09:30:31 PST
Subject: For Pr0duct Cypher
Message-ID: <9402061726.AA20879@toad.com>


-----BEGIN PGP MESSAGE-----
Version: 2.1e

hIwCwagUhZdVih0BA/9PNJuwQk/HvaEgKPCWrkH4+f5ZCPVIdskqCloJC2DV2eMi
Zcad567Ff8AJVsJ4l4u+i17d9oBNK+VbFar4uxu5OVvhugKGd2bCp1xAD/peWa+9
SNeCGamNEHZCA+kOZe4Dj8AN+tTrMfcCEYmkNdgoJjYLGxYVp6uUFrnr3fXFRqYA
AApfo1NAYylYWjPGE/QHXSvXhwp4v8HLFzYh3Ye+AZozqKoak5QfcCL6THMEHOLq
TXsbgdru52RrU7kKFd/keOtqkrpB+XUeO5P36tCteO3w6kSpWNzPVujqccIWiXHR
t/lo70SJDUFXAVaj0DYJjCTSvbLWplbv3Cake8NLmyW1ayFqpA8go2Z3TOPZkofv
rxq3PAInJT9flG/fsRTUlv8ELmkB9fhSiKhFx5u1tvZ25dc6AFqleHtNP/685bxI
5WDGlTE5lOAe4FiUDTzFx7Lp9yA4cFJvzfartdyUYVM3shQTbWRGcvEArNvHVoGO
/iEWxLcRne//B8xy8StAER95KF8vBrl4r3JE7OSaQgIZc7399g2pkEALOGAIo2ZY
G6ucg8CpNtQXnVm1pHGuaiPQjGIOTT0EWRXWtwfMafGBqPR1bw2FzeLA3Jc04+Js
did5u0mUwNMVVPDj+wTRcUHMQ51tzT5kKDrCFqKsMvAy1bJq5hKU9EOgX8g50DRR
d1EVsp2SufK9VQms9B8ptgVmiaMj/WRoX+XtJqtVvGZg4cv8UNrRXQS9PtsX9M+I
L+7iG9roBKpHJGLutU2uLkAYbojGiSsrlDzq2iQWcSqeI3HXjhlO3pDjcDiz18DN
AQuSJaBJloqkpRiDLLRvPbNLAERFyOjiDA1dYDprmp80XEUxTBMrSjmutWuh0sgS
p2SRvStimRQTMTzIiQVyJkTv86zPVRLvNCZEaE1nCAtdgrIdaIjgJQ+wpORrEGB5
yTympGUQAJn7n4c841WupkmbTxjlY1kcllyrZ9Y8aCzNCEagmAqayElZ2lww64cl
MWMm0aedA4F5D8VpI/5/JQdbuGSrSj7sVm4s0AmTCxTuq+Ww05PWbMTGtPd6fIVG
xaRPVMmeoMaw1T2HMpAeDIEvc1Ab5X3dJWPeKn6X47scvKMgoDpEglE+ydx0UeUo
wzi+/gZBz5TZ8sO0aBZB0Hn0Whso/LeXkqSRVWdwH8hWJz0+Z/EpsVE/sWnvzaT2
GOARq+GmedHi0d3AMvmJuTAd6BE5RczSrWZe2yQMrtybPZ1H1wYoSW05zeIgTg6H
mlqA44fOlSV1/wH398cyXim/mikvfmBkbEswAAfL1L1iHTPkkgXGHucmUmvwVcrk
UEyI8OcAr02o51iOp99cM16N9F7dQFhucxNxbE0KCjGHPn+UPELDucPyAC7gzOqN
sKcGx8ptLtyCCu7j10PRLkt27QsBjsF7iceYIDPsjx/T3+qELOb2+t1iaJmPHW1E
BiB9shLEAgmyLcCrtbvEyx0ayzYQPPw+4GyJZGtyzGwYJhKmKOUcav76Pb7vEX0R
NWxf+15rNv6Ns3SoWFYmLmCrJJ4jReGus7VVIvwBBNn5+TcLATuPyWGj+kIQlgIf
l25iNsjtpQ+LBeQYzRLZYG9w8oJNUllnAkf3WMgWL03txjeJ4XtfX/Gb9Lnz/6nJ
wctT5sKldp2etq0nk/yQyCLW44bV7DP0cqaSlDuZABzHqoaHkqVlvIHKiC7Qg0TP
UVeFJWKcAN1dr6lDmBf2VU+S5u+6TNGHWgrZ662H9vrIw5iVOpd5/LmJYVCdcWlL
Lsy8XI/d3SQMbzZde0Frw/eqRHgtJrXHksf1jkxRLDoZHZQiHWPLHbWGgxoxptha
baBu3Lkkpi8xFzlGwksQqaP1tN1wAF+OelZ8IpOqlJy199nScUn04wyvEd3FlhPK
N4LBcHEYpRHKbdvMICyzOEwiKGuJ9l3hVV8rOtgDbJWxLsnt5XenldqvbvMb0mTy
y50l1MXXi8CmncSp6YBXDWWshqCYqksOgRiErqYOxdIHzn1Xg9Z/7S8XXVr7oGup
DF4521egG/0/siVHJa44vGXyc0n0mwLaWcviUoxeTZ+lFb4lkmY8s3SE4vZIz4Tt
NAjmCcqpnsMScDHsSR19jPlZ9ayFMH/x0UtE3Y0COdcfvlgF3J705RrFl3CxU0SY
2gMmlL7An5K8a9hcrwpAwTWbB6yMJnD3AiE8hteIVru+2QfdPS68M0kGhcToHx57
cmrAVaCU2ywz0yBERA+SvQluTPnPuT9vQaVrh6EE7OuWhg4SG+fzAnIkJvSuPRRK
gOjCj0aoM+iYD+RXzPPKIMC3gYrjq8byrj5Q0+TjJpcKSYpw1KTllL9+xgptSNlT
SIrrvAYpK1SPY+GPOXwfvjx/Cud3jb7LHI7ZYmEfEAub7gVzsbbBG5ZWlrZc9rmR
IQi94oZ6cXTDjuAD1eoL9nh0KlfDKsPYyW1UNuxEKfXfjPMcvEFya8pvJRBYVaDD
p5GfOqn4QzeH3iGcO4w+zInroB1NWNxgnyToRoC0W1qPRgoB4xhv7gw/T7CASjmN
dMzO0anYxdCHUrGpH458MB9i8eJAlu3JV87tIldasXF8B9LAICu+emW5M7f03YA6
a5Qcfqpzc4a2YQEhjqc8Lddu/9Jc6lo4ufEia2DcnG7LHak3aGR8R9RyISK58gRp
CG9b6NOC14x3pYzBThZAg65HbECGdtRToN5GgT7PpXCv92FQVX3UxJryCPlELO+q
L/vqXHIfmWdXW8kkr23H3tC1AXB1k6H7/hgmD21LOQNpo17JmZXAxpCENQ5oBhc1
9BabRKvzUQAhhTaADwfrSIhG/dHFhzFTrAx6qmkWJPuy+2G9nPgO+pn66DTDAhK0
SSh5MbzFjTCH3AvmkFa4yZuvdZMm3VRM9VmTkfhBiyS2wRxnACMNsCD+3zVPKp81
hg7xrMH6rvDhY0shDecEzGiC1Q1TfCLjWISTYNdxFPOXB40pQbzPqd/Hn9NGf8wR
xFCfjj9ybPMJZCxUWG5bJml8TKbYjIvimpsBRfJ0+XK832aY4RFCWmu2Y8Xv1tuz
ruk6hNuCA+D4ogUZVBYoeUyll/K67Ym1H3SzR2sBEddnSoBb9wPxQxYzJrCMDeNm
i9wryIYlPS1kOjKprSWuC+EXSY7f5vKX6mOSuYL3GSsqAejCbgWmjvpubi/xNIry
+m4NDeGkuUtA2fuBg0ehePDvRBDnG2iZJX8cv7IX90wy1HNzlcuvVwJvObvW51OL
ayA67AiUwW/ufyjI76/nRRZQBXrde4cgsvD8doYHgBJybheEVshkYmLvq/yQGxX2
WDLlSmXvLvdaDsr3MBRX3LsFs2vi7GQDWi7VJeAPOOpBnDtKqKX60FLi3wPUHN+7
moL2eVPgGVGdvYSvKrCDfxjNTAb2zItsWplWYtg/j2dThtxsl96H3vw521A5l7VR
83Fr8u9I+kBRF1CR1yjiQ8iKdpJBSnmnaEmr8ebvZeObpWicNpICzNkSZ8z0nq4M
jR5KTrT9vUV2Y6yycskNrva/XnFR+KmyrJBXV3Gedjyg2ExFjbTJnLj2DcWxY16F
T3XwpM+NNH58vnlNvt8Sy5b1FqmuOKC/ehwpaYVJkKxFchbjXtsGLFzcIEsMd6mB
ndn0478oeFh/vFzArIIqBcRf73B+qkeJ4ijSZiThvXWlRk/Sxtu9J0uTVlixNsUY
FRaaRRwrfps++XBw1O21bY4v
=mMHl
-----END PGP MESSAGE-----





From tcmay at netcom.com  Sun Feb  6 11:11:08 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 6 Feb 94 11:11:08 PST
Subject: A Nice Summary of Motives for Clipper
Message-ID: <199402061911.LAA20333@mail.netcom.com>



This fellow has written a nice summary of the "carrot and stick"
motivations on Clipper. Nothing we haven't seen discussed, but a nice
synopsis.

His analysis is accurate:

- the government will make Clipper use very easy to export, and to use
(perhaps by subsidizing production costs of the MYK-xx chip for some
time)

- the government will make non-Clipper use very hard to export, may
harrass those who post code to ftp sites (a la PGP, Moby Crypt, etc.),
and will do other things to throw roadblocks up

- the result will probably be that in 5 years mosts crypto use is of
the key escrow sort, with all that that implies

Comment from TCM: Yes, we've "already won" in some sense, in that
strong crypto can't be completely eliminated. But if 99% of all crypto
users are using key escrow in 1999, for practical reasons, then in
some sense we have lost.

I'm curious about what RSA Data Security Inc. thinks of all this, as
this carrot-and-stick move worsens the export situation immmensely:
key escrow technologies get a "pass," while non key escrow
technologies get scrutinized, delayed, and generally told not to
bother to try to export (this is my interpretation). Could be real bad
news for Bidzos and Company. (Don't flame me for urging an alliance
with RSADSI! I'm just speculating on who will be hit hard here. Could
have some implications for what Cypherpunks support.)

Here's the article:


Newsgroups: alt.activism,alt.politics.datahighway,alt.privacy,alt.privacy.clipper,alt.security.pgp,alt.wired,comp.org.eff.talk,talk.politics.crypto
From: shephard at fraser.sfu.ca (Gordon Shephard)
Subject: Re: CRYPTO: DoJ's new rules for access to Clipper keys
Message-ID: <shephard.760538361 at sfu.ca>
Sender: news at sfu.ca (seymour news)
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: inet
Date: Sun, 6 Feb 1994 12:39:21 GMT
Lines: 107

strnlght at netcom.com (David Sternlight) writes:

>You still don't get it. Clipper is a system for the private sector with good
>security except for the escrow. The escrow is there to prevent the bad guys
>from using what would otherwise be a very hard to break system.

This reveals some of the mindset behind Government encryption policy.  For 
the past year or so, I've been discussing the "Clipper Concept", and have
constantly bewildered myself and others with the question:

   Why on earth would the black hats use a system which can be compromised
	by law enforcement agencies?

The conclusion which we normally came to was that after the introduction of
Clipper technology, the United States Government would work towards making
it illegal for cryptographic systems other than Clipper (or some other
Government controlled Key Escrow system) to be sold or produced in the
United States.

Now, Mr. Sternlight's view that Government is not attempting to prevent black 
hats from using non-clipper technology, and that they simply do not wish 
to allow criminals to use the Governments strong encryption system,
contrasts somewhat with the current dialogue on the subject.

And it makes sense - Clipper is going to dominate the market.  We may
all strut about and swear up and down how we will never use a cryptographic
system which the Government can break, but, given that commerical providers
will probably have huge incentives to develop clipper chip systems, (Govt.
Contracts and such :) this is the system that you and I will probably be 
purchasing.

A careful re-reading of the Press Releases provides supporting evidence. 

In particular, the administration will allow export of key escrow technologies,
and their new policies will result in:
	 - expedited delivery of products
	 - reduced shipping and reporting costs
	 - fewer individual licenses
	 - personal exemptions for the use of encryption technology taken
		out of the country by business persons.

The administration is going to also work with industry, with the NIST leading
these efforts.  Mention was made of money being tossed into this effort (Staff
will be hired....)     

So, that's the carrot, now for the stick:

"The Administration will continue to restrict export of the most
 sophisticated  encryption devices."

So, picture in your mind a Company such as AT&T, or U.S. Robotics, that
is about to start selling an encrypting modem/telephone:

They can either provide to Joe Public a Key Escrow technology, or they
can put together their own proprietary encryption system.

The Key Escrow technology system can be sold to the U.S. Government (Big
Bucks, How much would you like to bet that in the next 3 or 4 years, 
numerous government departments will be allocated large sums of money
to purchase encryption devices, regardless of whether they need it or
not - The press releases reveal that All Govt. Purchases will be Key Escrow - 
Never underestimate the impact of Government contracts)

The Key Escrow technology system will be free of Red Tape, can be exported,
will not require individual licensing for each country, can be taken
out of the country by business persons (The vast majority of which could care
less whether the Govt. can crack their communications, it's the competition 
they are concerned about), etc, etc....

Or, they can create a proprietary system and face the mother of all red
tape trying to sell the damn thing (At a significantly increased cost.)

The Result:

	1) Commerical Companies will not produce Non Key Escrow Technology.
	2) The few that do, will have their lives made so difficult by the
		Administration, it will be difficult to find their product.

And this is an issue that Nobody seems to discuss:  

	Encryption is only useful if BOTH ends of the communciation line 
	are using the same encryption technology.

Who will you be able to talk to if you are using a proprietary 
encryption system.  (A technically alert member of the press should
ask the following question: Will the administration seek to prevent
encryption systems which incorporate the clipper chip from having secondary
encryption technolgies embedded (I.E. Imagine if the modem you manufactured
could only talk V.32terbo, and not V.32/V.32bis - Nobody would buy it
because everyone else has a V.32bis modem. ) 

And here is where the Government may have made a strategic error though;
by not revealing their encryption algorithm, they may have opened up
a market for people who are concerned about the strength of the
encryption algorithm.  E.G. AT&T can come along and market their 
encrypting telephones with multiple levels of security, standard
"Clipper" encryption, or new and improved AT&T laboratory technology
which has been attacked by every encryption researcher on the planet.
Of course this device would still face the Red tape which the government
will be using as its primary weapon against non key escrow technology
in the coming years.

You heard it here first.  (Well, maybe not.  Anyone hear how the
Government has been treating PGP lately? :)

| Gordon Harry Shephard, shephard at sfu.ca,(message)252-4387, (res)524-8622 
| In No Way am I speaking for my Employers or Simon Fraser University.

--







From qwerty-remailer at netcom.com  Sun Feb  6 11:30:31 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Sun, 6 Feb 94 11:30:31 PST
Subject: CypherPUNKS. Not!
Message-ID: <199402061927.LAA06782@mail.netcom.com>


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

Anthony Garcia wrote,
">   Get Off the Internet and Write Us a Real Encryptor.

Get a copy of Schneier's "Applied Crypto" and write it yourself.
Don't expect other people to provide encryption technology for you,
because they probably won't."

You sadly misunderstand. "Us" means US. All of us. Humanity. You also didn't
understand the point of the Dead Kennedy's "Anarchy For Sale." Fortunately
Phil Zimmerman and a few others do, and hopefully they will also give PGP a
"random data block" format output. If we (all of us using PGP on this planet),
don't get PGP off the internet and into the hands of MOST Mac and Windows
users, as well as in hardware form in devices like phones, then as the last
song I quoted said, "You'll (Cypherpunk activists) be the first to go." I
don't code. I make molecules, and soon I will be using standing waves made
by lasers to deposit atoms on surfaces, working at Harvard, Bell Labs, and
NIST to help develop the next next generation of CPUs, sensors and other
devices. If you want something to write code for, 10 years from now, don't
disrespect those who do sciences other than programming.

Your answer is what the government WANTS the programmers to be like, like this:

"You want bulk vitamin C powder which has been rumored to cure that new
AIDS strain that started spreading by air? Well that wouldn't make me or
anyone else any cash, and since the FDA has banned vitamin supplements,
you better go pick up a book on synthesis. I think you start with glucose.
Oh, and include organometallics, since it's only  certain mixed oxidation
state Copper complex dimers that seems to work. Fairly complex stuff. Hurry
up though, I hear that AIDS (Clipper) virus kicks in pretty fast! But don't
expect chemists to give you any, well since you see, that would be altruistic
and that is not logical, since my value system is selfishness. As long as I
can cure myself, and you aren't paying me large sums, well, bye bye."

And making PGP better and posting it anonymously or not, is no where as illegal
as if I were to offer an unapproved medicinal to patients in need, something
that would immediately put me in handcuffs. Happily, drugs that are truly
effective become available to terminal patients, since of course that makes
money. I'm going into crystal and surface chemistry anyway, and the FDA
seems to be failing in its ongoing attempts to take away my legal vitamin C
powder. I fear though that they may succeed in 10 years, and the Clipper's
going to send my e-mail into the FDA's "bad guy" files, as being a person who
takes more vitamin C than can be found in a can of Coca Cola. I just want
privacy and to be left alone. And research funds ;-).

 -=Xenon=-

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVT86QSzG6zrQn1RAQGNgwP/YONeGygK20IMXXL96hgu6MKDqZToslzK
BLgaWOYAvCz9e48aR6AemamQ3R7Dm9ZdqTyf2QIIgV/2VliARX4+9ADBiS3BUtET
Kck3gALq88weWfysdrxkc433b+sP9s28GOdMK2sHAjWaf9PImmoeqsaVBaAi9DzN
rTMRSKnp6ko=
=JKEA
-----END PGP SIGNATURE-----





From hughes at ah.com  Sun Feb  6 11:50:30 1994
From: hughes at ah.com (Eric Hughes)
Date: Sun, 6 Feb 94 11:50:30 PST
Subject: a reference to STS
In-Reply-To: <51436.pfarrell@netcom.com>
Message-ID: <9402061948.AA20879@ah.com>


Here's the reference for the STS paper.  STS is the Station-to-Station
protocol.

_Authentication and Authenticated Key Exchanges_
by Diffie, Oorschot, Wiener
_Designs, Codes and Cryptography 2_, 
pp 107-125
1992


Eric





From nobody at shell.portal.com  Sun Feb  6 11:56:08 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sun, 6 Feb 94 11:56:08 PST
Subject: No Subject
Message-ID: <199402061953.LAA08152@jobe.shell.portal.com>


I'm moving to Oceania.






From nowhere at bsu-cs.bsu.edu  Sun Feb  6 13:51:07 1994
From: nowhere at bsu-cs.bsu.edu (Anonymous)
Date: Sun, 6 Feb 94 13:51:07 PST
Subject: No Subject
In-Reply-To: <199402061953.LAA08152@jobe.shell.portal.com>
Message-ID: <9402062151.AA08195@bsu-cs.bsu.edu>


> I'm moving to Oceania.

Yeah, let's hope it gets built first...





From mg5n+ at andrew.cmu.edu  Sun Feb  6 13:56:07 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Sun, 6 Feb 94 13:56:07 PST
Subject: Fwd: More on remailers
In-Reply-To: <9402062051.AA26116@relay2.geis.com>
Message-ID: <MhJKO4_00awL07XVQv@andrew.cmu.edu>


Does anyone know what this is???

----------

Return-path: <genie-postmaster at geis.com>
Received: from po2.andrew.cmu.edu via trymail
          ID </afs/andrew.cmu.edu/usr12/mg5n/Mailbox/UhJJW=O00UdaEa=k5z>;
          Sun,  6 Feb 1994 15:52:27 -0500 (EST)
Received: from relay2.geis.com (relay2.geis.com [192.77.188.3]) by
po2.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id PAA09729 for
<mg5n+ at andrew.cmu.edu>; Sun, 6 Feb 1994 15:51:36 -0500
From: genie-postmaster at geis.com
Received: by relay2.geis.com
	(1.37.109.4/15.6) id AA26116; Sun, 6 Feb 94 20:51:28 GMT
Message-Id: <9402062051.AA26116 at relay2.geis.com>
Date: Fri,  4 Feb 94 00:51:00 BST
To: mg5n+ at andrew.cmu.edu
Subject: More on remailers

Original Msg Id: Not Found
genie-postmaster response to your message

    Subject: More on remailers
    System:  QUIK-COMM
    Date:    Fri  4-Feb-94  0:51

Status: 5   Message picked up by receiving system and
            delivered to all recipients with NO exceptions.

----------





From R.O.Jackson-SE1 at computer-science.birmingham.ac.uk  Sun Feb  6 14:46:08 1994
From: R.O.Jackson-SE1 at computer-science.birmingham.ac.uk (R.O.Jackson-SE1 at computer-science.birmingham.ac.uk)
Date: Sun, 6 Feb 94 14:46:08 PST
Subject: TEMPEST - Electronic eavesdropping
Message-ID: <13893.9402062244@heffalump.cs.bham.ac.uk>


Transient Electromagnetic Pulse Emanation Standard (TEMPEST) is the
US standard defining the amount of electromagnetic radiation that a
device may emit without compromising the information it is 
processing.

In the US it not illegal to posess TEMPEST-surveillance equipment but
it is illegal to take appropriate counter-measures to prevent 
surveillance. The US government has refused to release details of its
TEMPEST research and has restricted the dissemination of independent 
research by classifying it.

The US Drug Enforcement Agency (DEA) makes use of TEMPEST secured
electronics and computers as they believe that the drug cartels may
possess surveillance equipment.

I am interested in gathering comments on the social, legal, ethical,
and technical aspects of use of TEMPEST surveillance equipment in
the US and Europe with the aim of including it in a discussion
of the threats to computer/digital systems.



Please reply by E-mail. I will provide a summary to anybody who
requests one.

thanks, 	- Rob Jackson

(more information on TEMPEST can be found in the paper
 "Eavesdropping On the Electromagnetic Emanations of Digital
  Equipment: The Laws of Canada, England, and the US" by
  Cristopher Seline - available on FTP from csrc.ncsl.nist.gov)





From hughes at ah.com  Sun Feb  6 15:16:08 1994
From: hughes at ah.com (Eric Hughes)
Date: Sun, 6 Feb 94 15:16:08 PST
Subject: TEMPEST - Electronic eavesdropping
In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk>
Message-ID: <9402062314.AA21234@ah.com>


>In the US it not illegal to posess TEMPEST-surveillance equipment but
>it is illegal to take appropriate counter-measures to prevent 
>surveillance. 

Can we get the urban folklore set clued into this one?

Electromagnetic shielding is not illegal.  On the contrary, in the
USA, the FCC finds shielding highly desirable.

Eric





From mech at eff.org  Sun Feb  6 15:36:07 1994
From: mech at eff.org (Stanton McCandlish)
Date: Sun, 6 Feb 94 15:36:07 PST
Subject: NIST - PKP settlements not over yet
Message-ID: <199402062335.SAA20726@eff.org>


[from Gregory Aharonian's Internet Patent News Service]

A hostile response to a tentative agreement to settle a patent dispute
over the proposed Digital Signature Standard has forced the National Institute
of Standards and Technology to return to negotiations.  Last summer, NIST
officials thought they finally settled the DSS public key patent dispute by
granting Public Key Partners (PKP) of Sunnyvale, California, an exclusive
worldwide license for the Digital Signature Algorithm (DSA) on which the DSS
is built.

In exchange for sublicensing rights, the PKP group agreed to endorse
NIST's DSS proposal.  But F. Lynn McNulty, associate director for computer
security with NIST's Computer System Laboratory, said a majority of potential
DSS users balked at the deal.  NIST published the settlement terms for
comment, and McNulty said all but 10 of the 270 comments were critical.
[as many of you may remember, EFF coordinated the transmission of these
comments to NIST, who did not widely announce the request for comment at all.
The uncharitable might call that an attempt to sweep the matter under the rug.
The naive might call it an oversight.  At any rate almost all of the comments
NIST received were routed via EFF, who were happy to publicize it "for" NIST.]
Many DSS critics have argued that another algorithm promulgated by RSA
Data Security (Redwood City, CA), is a de facto industry digital signature
standard and that it would cost too much to comply with a separate government
standard.

Now NIST is attempting to hammer out a new settlement based on the
comments, McNulty said.  "The real hang-up continues to be the patent issue",
McNulty said.  "We're still trying to resolve it".

Scientists at CSL designed the CSS to serve as a standard agency tool for
verifying the senders and contents of messages transmitted electronically.
CSL also prescribed the public key Digital Signature Algorithm (DSA).

But PKP, which holds the rights to public key patents on behalf of
Stanford University, MIT, and most recently, German professor Claus Schnorr,
charged that CSL's proposed algorithm infringed upon these patents.  NIST
originally sponsored DSA research, and agencies are exempt from any licensing
fees.  PKP, however, has maintained that vendors that incorporate the
standard into their products should pay royalties.
[Government Computer News 1/24/94, 58]

-- 
Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist
F O R   M O R E   I N F O,    E - M A I L    T O:     I N F O @ E F F . O R G 
O  P  E  N    P  L  A  T  F  O  R  M     O  N  L  I  N  E    R  I  G  H  T  S
V  I   R   T   U   A   L   C  U   L   T   U   R   E      C  R   Y   P   T   O




From tcmay at netcom.com  Sun Feb  6 16:00:30 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 6 Feb 94 16:00:30 PST
Subject: TEMPEST - Electronic eavesdropping
In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk>
Message-ID: <199402062359.PAA20879@mail.netcom.com>



> In the US it not illegal to posess TEMPEST-surveillance equipment but
> it is illegal to take appropriate counter-measures to prevent 
> surveillance. The US government has refused to release details of its

Please provide a reference for this. We've discussed this _many_ times
on this List, and the consensus is that no such law exists, nor is it
plausible that folks could be told they cannot "shield" their
computers.

(In fact, FCC regulations call for various levels of RF shielding, as
we all know. Is there a law which says "You must shield--but not _too_
much"? Of course not.)

I don't want to sound rude, but saying it is illegal to take
appropriate counter-measures to prevent surveillance is a serious
statement, requiring some support. (I'll look for the ftp paper
you cite later...do you have a pathname handy in the nist ftp site?)

I can believe that _certain_ countermeasures, like active jamming with
RF signals, may be somewhat restricted, but mainly for FCC reasons. I
cannot believe that shielding a keyboard or computer, or using LCD
displays to reduce Van Eck emissions, or even putting one's computer
in a Faraday cage, could be illegal. 

> TEMPEST research and has restricted the dissemination of independent 
> research by classifying it.

Parts of the TEMPEST spec (and TEMPEST is not an acronym for anything,
I understand) are classified, for various reasons, but this does not
mean shielding or other countermeasures are forbidden. In fact,
shielding supplies and TEMPEST-related supplies can be bought from
several companies. Every time this thread comes up, someone cites the
suppliers.
 
> The US Drug Enforcement Agency (DEA) makes use of TEMPEST secured
> electronics and computers as they believe that the drug cartels may
> possess surveillance equipment.

I'll phone Pablo Escobar and ask him.

> I am interested in gathering comments on the social, legal, ethical,
> and technical aspects of use of TEMPEST surveillance equipment in
> the US and Europe with the aim of including it in a discussion
> of the threats to computer/digital systems.
> 
> thanks, 	- Rob Jackson
> 
> (more information on TEMPEST can be found in the paper
>  "Eavesdropping On the Electromagnetic Emanations of Digital
>   Equipment: The Laws of Canada, England, and the US" by
>   Cristopher Seline - available on FTP from csrc.ncsl.nist.gov)

Lots of interesting stuff there. But where is the paper you cite? A
pathname would be appreciated.

--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.




From miron at extropia.wimsey.com  Sun Feb  6 16:06:07 1994
From: miron at extropia.wimsey.com (Miron Cuperman)
Date: Sun, 6 Feb 94 16:06:07 PST
Subject: remailer delays
In-Reply-To: <199402042129.NAA11271@jobe.shell.portal.com>
Message-ID: <1994Feb6.232301.2234@extropia.wimsey.com>


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

Xenon, you should add my machine to your list:

xtropia   -      PGP    SM     +    -    -   -  Pr  M   23a  -

The address is remail at extropia.wimey.com.  Encryption is required.
I keep logs, encrypted with my public key.
- -- 
        Miron Cuperman <miron at extropia.wimsey.com> | NeXTmail/Mime ok
        Unix/C++/DSP,  consulting/contracting      | Public key avail
        AMIX: MCuperman                            |

Cryptocosmology: sufficiently advanced communication is indistinguishable
from noise - god is in the least significant bits.
		 - fnerd


-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVV7ppNxvvA36ONDAQHDcQP9H3lpdKOF2TobH8fuZDjNQGjxh2LKKbc4
eiN961fMn0hfQaXA6TLioAyvZsvGe10CRWaTzW2tgVAL6RDgZLKji7ng87jzIfat
2O/w0uV2wNd6EWWMWdtQwkQ+J7adKNMj5IUjpYlvM5v0jicuPVotgQLMLgwQHoXA
4c5n2XLsurU=
=5Re6
-----END PGP SIGNATURE-----





From qwerty-remailer at netcom.com  Sun Feb  6 17:30:32 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Sun, 6 Feb 94 17:30:32 PST
Subject: remailer delays
Message-ID: <199402070130.RAA12616@mail.netcom.com>


It's half done :-) ! Unfortunately the NSA run remailers haven't been
handing out info, but this should help people know which blanks are still
blanks ;-). God I hate these little sideways smileys!

               oooooooooooooooooooooooooooooooooooooooooooooo
      ooo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ooo
     $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
    o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o
    $$$$$   $$$"    "$$$$$"    "$     $     $  "$  $$$$$"    "$  "$  $$$
    $$$$"   "$$  $$oo$$$$$  $$oo$  $$$$  $$$$   "  $$$$$  $$  $   "  $$$
   o$$$$  $  $$o    "$$$$$o    "$    $$     $      $$$$$  $$  $      $$$o
   $$$$   o   $""$$  $$$$$""$$  $  $$$$  $$$$  o   $$$$$  $$  $  o   $$$$
   $$$$  $$$  $o    o$$$$$o    o$     $     $  $o  $$$$$o    o$  $o  $$$$
   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
   $$$$""""""""""""""""""""""""""""""""""""""$$$$$$$$$$$$""""""""""""$$$$
   $$$$                                      "$$$$$$$$$$"           o$$$$
   $$$$                                       "$$$$$$$$"           o$$$$$
   $$$$                                        $$$$$$$$            $$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$            $$$$$$            $$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$            $$$$            $$$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$$           "$$"           $$$$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$$o           ""           o$$$$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$$$o                      o$$$$$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$$$$o                    o$$$$$$$$$$$
   $$$$$$$$$$$$$           $$$$$$$$$$$$$$o                  o$$$$$$$$$$$$
   "$$$$$$$$$$$$           $$$$$$$$$$$$$$$                  $$$$$$$$$$$$"
    $$$$$$$$$$$$           $$$$$$$$$$$$$$$$                $$$$$$$$$$$$$
    $$$$$$$$$$$$           $$$$$$$$$$$$$$$$$              $$$$$$$$$$$$$$
    "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$"
     $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
      """$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$"""
               """"""""""""""""""""""""""""""""""""""""""""""

Xenon's Full Disclosure Remailer List.

Remailer  Fast?  OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ...and?
--------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ----------
bsu-cs    +      ?      ?/?    +    ?    ?   ?  ?   ?   23a  -
catalyst  +      N?    SM/MQ   -    -    ?   -  PA  M   23a  -
choas     +      ?      ?/?    +    ?    ?   ?  ?   ?   -    -
cicada    ++     ?      ?/?    -    -    -   -  ?   ?   -    -
colostate ++     ?     SM/MQ   ?    -    ?   ?  Un  M   ?    -
dis.org   -/--   ?      ?/?    -    ?    ?   ?  ?   ?   23a  -
extropia  +/-    ?      SM     +    -    -   -  Pr  M   23a  -
jarthur   +/--   St    SM/MQ   -   -/+   ?   ?  Un  ?   23a  -
menudo    --     N      SM     -    t1  "?"  Y  Un  H   23a  -
merde     -/--   ?      ?/?    -    ?    ?   ?  ?   ?   -    -
penet.fi  --     St    SM      -    t?   24  +  Pr  H   -    -
pmantis   ++     ?      ?/?    -    ?    -   -  ?   ?   -    -
qwerty    +      C     SM/MQ   -    -    -   -  PA  M   23a  +
rosebud   ++/-   N      MQ     -    -    -   N  Un  M   23a  -
remba      --    ?      ?/?    ?    ?    ?   ?  ?   ?   23a  -
shell     ++/+/- St     ?/?    -    ?    ?   ?  ?   ?   23a  -
soda      ++/-   St+?   ?/?    -    ?    ?   ?  ?   ?   -

Subj: Strips Subject header?
NL: Non-linear remailing? 123->231.
RD: Random delay added (max, in hours)?
Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages.
CPU: Pr = private. PA = account on public access machine. Un = university.
Phys: Physical security of the CPU, especially at night. H/M/L.
BitB: BitBucket feature?

Fast?:
++ <5 min
+   5-10 min.
-  ~10-30 min delay
--  Pinging isn't practical due to long delays. Probably reliable though.
+/- Sometimes +, sometimes -.
Normal internet mail delays are common, and are not equivalent in the two
directions between any two remailers. Mail still gets through.

OpLog:
F: full copies of all mail is archived. My large volume mailing should
   help put a stop to this.
St: Stats logs of when mail was remailed.
St+: Stats logs of when and where mail was remailed.
St-: simple counter.
N: operator keeps no logs.
C: Simple counter.

SysLog:
SM: sendmail logs of when and where mail was exchanged. Root access needed.
MQ: mailqueue accessible by anyone on the site. Could make logs.

I have chosen nicknames based on a string common to both the outgoing
address and to the address you see on an incoming message from the remailer.

bsu-cs    nowhere at bsu-cs.bsu.edu
catalyst  catalyst at netcom.com
chaos     remailer at chaos.bsu.edu
cicada    hh at cicada.berkeley.edu
colostate nate at vis.colostate.edu
dis.org   remailer at dis.org
extropia  remail at extropia.wimsey.com
jarthur   ebrandt at jarthur.claremont.edu
menudo    nobody at Menudo.UH.EDU
merde     remailer at merde.dis.org
penet.fi  anon.penet.fi
pmantis   hh at pmantis.berkeley.edu
qwerty    qwerty at netcom.com
rosebud   elee7h5 at rosebud.ee.uh.edu
          (elee6ue at rosebud.ee.uh.edu)
shell     hfinney at shell.portal.com
soda      hh at soda.berkeley.edu

Discontinued remailers still on some lists out there:

phantom at mead.u.washington.edu
remail at tamaix.tamu.edu
sameer at netcom.com
sameer at berkeley.edu (spelling?)
cdodhner at indirect.com
remailer at entropy.linet.org??
00x at uclink.berkeley.edu?
remail at tamaix.tamu.edu?

Background on each remailer:

bsu-cs:
Run by Chael Hall.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

catalyst:
Run by Scott Collins.
Machine: personal dial-up account on Netcom.
Problems policy: Outgoing address blocking, with proof of ID.
         Contact catalyst at netcom.com.
Software: Customized Hal's ?
Security: Netcom keeps sendmail logs, which root at netcom.com can read.
          Any Netcom user could also compile his own sendmail logs, by
          constantly logging mail as it arrives and leaves.
Comments:
History: ??

chaos:
Run by Chael Hall.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security:
Comments: finger remailer.help at chaos.bsu.edu for info using any remailer. ??
          gopher chaos.bsu.edu for a collection of info about Cypherpunks.
Comments:
History: ??

cicada:
Run by Eric Hollander.
Machine: ???
Problems policy: ?? Contact ??
Software: ??
Security: Tread lightly. Being "phased out".

colostate:
Run by ??
Machine: ???
Problems policy: ?? Contact ??
Software: ??
Security: ??

dis.org:
Run by Peter Shipley.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

extropia:
Run by Miron Cuperman.
Machine: ??
Problems policy: ??  Contact ??
Software: ??
Security: ??
Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional.
          Privately owned, in Canada.
          Not directly connected (delays possible).
History: ??

jarthur:
Run by Eli Brandt.
Machine: Sequent Symmetry.
Problems policy: Destination blocking is available w/ sufficient ID.
                 Contact ebrandt at jarthur.claremont.edu.
Software: The usual, tweaked for MMDF. Hal's.
Security: jarthur keeps sendmail logs.
Comments: Although jarthur doesn't batch, its connection often results in
          outgoing mail getting batched out anyway (1-3 hours delay).
History: Set up late '92.  PGP added mid '93.

menudo:
Run by Karl Barrus.
Machine: University machine.
Problems policy: see policy at gopher site. Contact klbarrus at owlnet.rice.edu
                 or elee9sf at menudo.uh.edu.
Software: Modified Hal's.
Security: Stores messages and sends them out randomly at midnight.
          Pads messages to 1K with random stuff. (?)
Comments: elee9sf at menudo accepts RIPEM encryption.
          elee6ue at rosebud requires "digital cash" (basically random
          strings I made).
          Errors on elee9sf at menudo are forwarded klbarrus at owlnet.rice.edu
          where they are deleted.  I still get mail at that address which is
          why I have it forwarded and not just dropped.
History: No comment.

merde:
Run by Peter Shipley.
Maching: ??
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments:
History: ??

penet.fi:
Run by Julf (Johan Helsingus).
Machine: ?? Operator owned.
Problems policy: Account revokation. Contact ??@anon.penet.fi.
Software: custom.
Security:
Comments: By far the most popular remailer, dwarfing in a day what the
          entire Cypherpunk remailers combined carry in a month. Supports
          easy return addresses as well as non-anonymous mailing to
          someone's anonymous address (na1234... instead of an1234...).
          Your real address is kept on Julf's hard disk, but is fairly safe
          there, especially if you do not abuse your anonymity to harass
          someone. On a bad day your mail and especially Usenet posts may
          be delayed up to a day. Very reliable though. Sends error
          messages back to you for failed mail. Limited to 48K mail.
History: ??

pmantis:
Run by Eric Hollander.
Machine: ??
Problems policy: ?? Contact ??
Software: ??
Security: Tread lightly. Being "phased out".
Comments:
History: ??

qwerty:
Run by Xenon.
Machine: dial-up account on Netcom.
Problems policy: "What problems?". Contact qwerty at netcom.com.
Software: Hal's remailer.
Security: Netcom keeps sendmail logs, which root at netcom.com can read.
          Any Netcom user could also compile his own sendmail logs, by
          constantly logging mail as it arrives and leaves.
          Operator often logs in using telnet.
Comments: You must use na1234 at anon.penet.fi not an1234 at anon.penet.fi.
          Finger qwerty at netcom.com for a blurb on the remailer and updates
          on its software.
          Request-Remailing-To: /dev/null is a bit bucket.
          whitehouse.gov gets blocked and fully logged.
History: Up 2/94. Set up by Xenon who needed more remailers to use to send
         PGP info to people with, since anon.penet.fi was overloaded.

rembe:
Run by Bill (O'Hanlon?).
Machine: ? Privately owned.
Problems policy: ?? Contact ??
Software: ??
Security: ??
Comments: Not directly connected (delays?).
History: Second oldest remailer.

rosebud:(elee7h5 at rosebud.ee.uh.edu)
Run by Karl Barrus.
Machine: University.
Problems policy: See gopher site.  Contact klbarrus at owlnet.rice.edu.
Software: Hal's.
Security: "syslog file can be read"
Comments: Errors are "dropped".
History: Third oldest remailer.

rosebud: (elee6ue at rosebud.ee.uh.edu)
Run by Karl Barrus.
Machine: univerisity
Problems policy: see gopher site. Contact klbarrus at owlnet.rice.edu.
Software: standard scripts (Hal's) modified to accept cash strings.
Security: "Syslog file can be read."
Comments: Errors are "dropped".

shell:
Run by Hal Finney.
Machine: ??
Problems policy: ?? Contact ??
Software: Hal's Remailer.
Security: ??
Comments: whitehouse.gov blocked and fully logged.
          hal at alumni.caltech.edu forwards all mail to shell.
History: ??

soda:
Run by Eric Hollander.
Run by: ??
Machine: ??
Problems policy: ?? Blocking of addresses. Mail sent to problem causer.
                 Contact ??
Software: custom. ??
Security: Was keeping full logs till Xenon's bulk mailing venture. ??
Comments:
History: ??

Remailer Public Keys:
(I've got these).





From nate at VIS.ColoState.EDU  Sun Feb  6 17:56:08 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Sun, 6 Feb 94 17:56:08 PST
Subject: FOR Xenon (what's his email?)
Message-ID: <9402070153.AA08461@vangogh.VIS.ColoState.EDU>


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


Info on the nate at vis.colstate.edu remailer


colostate:
Run by Nate Sammons nate at vis.colostate.edu
Machine: Sun 4/280 - direct ethernet connection to the 
         Colorado State University backbone.  Getewayed to
         CU/BOulder, and then into the Net backbone.
Problems policy: No problems yet.  Nobody at CSU really
                 knows about it yet ;-)
Contact Nate Sammons nate at vis.colostate.edu
Software: Hal's Remailer software, modified
Security: What do you want to know?

- -nate

BTW, thanks for the work!

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From qwerty-remailer at netcom.com  Sun Feb  6 18:16:08 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Sun, 6 Feb 94 18:16:08 PST
Subject: FOR Xenon (what's his email?)
Message-ID: <199402070215.SAA16858@mail.netcom.com>


na38138 at anon.penet.fi or faster, qwerty at netcom.com.

 -=Xenon=-

P.S. I'm e-mailing you separately.





From tcmay at netcom.com  Sun Feb  6 18:20:32 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Sun, 6 Feb 94 18:20:32 PST
Subject: TEMPEST - Electronic eavesdropping
In-Reply-To: <199402062359.PAA20879@mail.netcom.com>
Message-ID: <199402070218.SAA06728@mail.netcom.com>


OK, I've just reread the Seline paper Rob Jackson was referring to
(available by ftpat csrc.ncls.nist.gov::/pub/secpubs/tempest.txt--my
thanks to Rob for providing the pathname to me). I say "reread"
because this is the same 1990 paper that's been reposted several times
to sci.crypt and here to the Cypherpunks list.

Earlier I said, quoting Rob:

> 
> > In the US it not illegal to posess TEMPEST-surveillance equipment but
> > it is illegal to take appropriate counter-measures to prevent 
> > surveillance. The US government has refused to release details of its
> 
> Please provide a reference for this. We've discussed this _many_ times
> on this List, and the consensus is that no such law exists, nor is it
> plausible that folks could be told they cannot "shield" their
> computers.
...stuff elided...

Indeed, most of the Seline paper is devoted to the fact that the
TEMPEST spec itself is classified, which is undoubtedly true. And the
(unconfirmed) assertion that mere possession of RF intercepting gear
that could be used to defeat TEMPEST is illegal.

(I have doubts about this, given the various types of RF receivers,
old television sets with manual tuners, etc. I suppose that if one
were caught with an antenna, a tunable CRT able to "tune in" the
emissions of a nearby--or distant--computer or CRT and display them
the way the NSA's ELINT gadgets undoubtedly do, then this might be
considered evidence of criminal intent--like burglar tools,
password-cracking tools, etc. [And we've had this debate many times as
well, with some saying possession of lockpicking tools is legal,
others saying it's not, etc.])

However, nothing in the Seline report, flawed as it is (IMO), says "it
is illegal to take appropriate counter-measures to prevent
surveillance." That is, go ahead and shield away!

What I think the government is saying is this, and I have no idea if
this is in fact law or if it would hold up in court:

* First, we (the government) have a TEMPEST spec we use to build
equipment to. It tells our vendors how good their stuff has to be. We
don't tell the public this spec, because this would help the Russkies
and the Yellow Hordes, not to mention the French.

* Second, we (your public servants) have our own tricks and techniques
and dislosing the TEMPEST specs would provide damaging information to
our opponents (the Mob, the Serbs, the Cypherpunks, and the
Republicans)--so we aren't talking. And we insist TEMPEST contractors
also keep their mouths shut.

* Third, we (us again) will not allow _eavesdropping_ equipment to be
publically sold, whether for intercepting cellular phone calls, CRT
emissions, whatever. You may find loopholes (telephoto lenses and
giant parabolic mikes, so beloved of dicks), but we've basically
outlawed this stuff.

(sorry if my irreverent tone and change of point of view is confusing
here)

So, nothing about shielding or monitoring emissions (commercial RF
leakage equipment is widely available and measures stuff down many dB
from the unshielded level). Just don't build a Van Eck gadget and let
others know about it (though, again, it's not clear how the courts
would rule on this). And don't disclose TEMPEST specs.

For Cypherpunks, not too much to worry about. We don't want or need to
play at being spooks by monitoring nearby systems, and shielding is
available.

That it's not used much, that we are "soft targets" for determined
surveillance teams, and that we use PGP on insecure machines, etc., is
all well-known. Everything has a cost, and most of us don't perceive a
direct enough threat to our communications and computers to warrant
working inside a local, Faraday-caged machine, keeping passwords in a
separate laptop we carry with us at all times, etc. What's important
for us is to get crypto tools spread ubiquitously. The rest can come later.


--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.




From nobody at shell.portal.com  Sun Feb  6 18:26:08 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sun, 6 Feb 94 18:26:08 PST
Subject: PGP Tools & Magic Money Update
Message-ID: <199402070226.SAA05321@jobe.shell.portal.com>


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

PGP Tools and Magic Money would not run on a big-endian machine. This did
not surprise me, because I don't have one to test it on. I sent a new 
version to csn.org which fixes a bug in fifo_moven, and includes a #define
to force the precision to maximum on a big-endian machine. This should make
it work, but will slow it down. The new version, when it shows up, should
be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell
you how to get into the crypto section. Check the file dates to see if the
new version is there yet. I sent them on 2/6.

Is there anyone who would like to fix it so it will run properly? The files
pgptools.c and ptd.c in the toolkit, and mm.c, s.c, and c.c in the Magic
Money system, need to be changed. There is a function called rescale which
has to be run on mpi's after set_precision is called. I have no way to test
any changes, so I can't write this.

                                          Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVWRMcGoFIWXVYodAQHSCwQAhA8gZTKDEnzdFyC5UbB0HpvSe299w4F0
bmAA+vplPWNIuFx+RswN6UeCqr9v32tPHTopU4y8twWWJ6p+sA0laqfPVsubtuKK
0bJkasrhIYZDfh4X+RaXgiv50hrcqm87Str0asUOiv1sA7Mv9G5cTxQPwvm0Wiq1
BEjeR5cYn8M=
=6VZI
-----END PGP SIGNATURE-----





From mg5n+ at andrew.cmu.edu  Sun Feb  6 18:51:08 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Sun, 6 Feb 94 18:51:08 PST
Subject: FOR Xenon (what's his email?)
In-Reply-To: <199402070215.SAA16858@mail.netcom.com>
Message-ID: <YhJOkWe00WAuMTmUtT@andrew.cmu.edu>


qwerty at netcom.com writes:

> na38138 at anon.penet.fi or faster, qwerty at netcom.com.
> 
>  -=Xenon=-

I thought it was na48138 ... ???

That's what it said on your earlier posts.





From qwerty-remailer at netcom.com  Sun Feb  6 19:40:32 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Sun, 6 Feb 94 19:40:32 PST
Subject: FOR Xenon (address?)
Message-ID: <199402070338.TAA25281@mail.netcom.com>


Gee, someone must have snuck into my account and changed all the 48s to
38s. I stand corrected. na48138 at anon.penet.fi. Mister 38138 must be rather
confused due to the "Bomb me!"s he's been getting :-). I'll send him a note
to tell him. Maybe I can convince HIM to take over this project even!

 -=Xenon=-





From hfinney at shell.portal.com  Sun Feb  6 20:00:32 1994
From: hfinney at shell.portal.com (Hal)
Date: Sun, 6 Feb 94 20:00:32 PST
Subject: Attack on Magic Money and Chaum cash
Message-ID: <199402070359.TAA19748@jobe.shell.portal.com>


I think there may be a security weakness in Magic Money coins, and in
Chaum's "online" cash system from the Chaum/Fiat/Naor paper.

Magic Money coins are numbers of a particular form, RSA-signed by the
bank.  They look like Y^(1/e) where Y is the number and e is the
bank's public exponent corresponding to the particular denomination of
the coin.

The structure of Y is a 0, a 1, a string of bytes of 0xff, then
a defined 18-byte string of bytes, then 16 random bytes.  This Y is
generated by the user, and is then blinded by multiplying by some
random r^e, and sent to the bank.  The bank RSA-signs Y*r^e to get
r*Y^(1/e), and the user divides by r to get Y^(1/e).  This is the
coin.

The coin is checked by raising it to the power e, to get Y, then
checking to see if it is of the proper form.  Actually, the Magic
Money code only checks the 18-byte special string (just above the 16
random bytes) to make sure it matches the exact byte sequence that is
always supposed to be there.  In addition the bank checks the 16
random bytes against a list of spent coins to make sure this coin
hasn't been spent before.

The other relevant point is that the bank has to sign everything you
give to it (with payment) - it can't check the bit pattern for
legality, since what it is signing is blinded.  So you can really get
the bank to sign anything.

Yesterday I opined that this would be safe, but now I don't think so.
The danger I would see is an attacker who gets the bank to sign 2, 3,
5, 7, 11, 13, 17, 19, ....  The bank won't know it is signing these
special numbers because they are blinded.  If someone gets a lot of low
primes signed he may be able to forge money, especially with the
incomplete checks in the Magic Money program.

The idea would be for him to try to factor a legal Y using just the
primes he has.  If he can find a factorization using only small primes
of a number which holds the magic 18-byte sequence in the right place,
he can multiply together the signed forms of the primes to produce a
signed version of that number.  This would be a successfully forged coin.

So, the question is whether it would be feasible to collect enough
signed small primes to be able to generate more valid coins than you
have primes.  (It costs you a coin each time you get the bank to sign
something, so for this to be a money-making venture you want to get
more out of it than you put into it!)  I think there are a reasonable
fraction of numbers factorable by only small primes.  Since there are
2^128 possible money values (based on the 16 random bytes) there
should be quite a lot which are factorable by only small primes.

Magic Money could help by checking the high bytes as well as the magic
18; it would be take more time to factor 1024 bit numbers than 272 bit
ones ((18+16)*8), and there would be fewer that are factorable by
small primes.  But the problem would still exist.  The attacker can run
a fast sieve to identify numbers which are factorable in his set.

The same attack would apply to Chaum's online cash.  His cash is of the
form, (x,f(x)^(1/e)), where f() is a one-way function like MD5.  To forge
this you would again get signed forms of the small primes, then keep
picking random x's, until you got a f(x) which could be factored by your
set.  Presto, you can create a fake coin.

I don't know how this attack can be prevented.

Hal






From hfinney at shell.portal.com  Sun Feb  6 20:36:08 1994
From: hfinney at shell.portal.com (Hal)
Date: Sun, 6 Feb 94 20:36:08 PST
Subject: Attack on Magic Money and Chaum cash
Message-ID: <199402070432.UAA21889@jobe.shell.portal.com>


A quick follow-up: I suppose a cut-and-choose protocol in the withdrawal
would prevent this attack.  Instead of sending in one blinded coin to be
signed you'd send in 100 blinded candidates, then the bank would pick 99
and you'd reveal the r's for the others (remember, they are blinded with
r^e) so the bank can verify they are of the proper form.  The bank would
then sign the one remaining one and return it to you.

What a pain!  I hope someone can come up with something better, or show that
the attack doesn't work.

Hal





From nobody at rosebud.ee.uh.edu  Sun Feb  6 21:16:09 1994
From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu)
Date: Sun, 6 Feb 94 21:16:09 PST
Subject: CRYPTA PLUS W/ RSA
Message-ID: <9402070514.AA03925@toad.com>


01/31 0936  ( BW)(TELEQUIP)
   Business Editors  
   HOLLIS, N.H. (JAN. 31) BUSINESS WIRE - January 31, 1994--Telequip
Corp. today announced the first available PCMCIA compatible flash
memory card with high-level embedded security functions.  
   The credit card sized Crypta Plus is targeted at companies
implementing secure tokens for mobile computer users.  These tokens
will allow users to conveniently communicate and access confidential
data across public computer and telecommunications networks.  
   Industry experts predict widespread use of secure tokens for
corporate and customer communications, database access, electronic
funds transfer, defense and government programs, and any other
activity involving confidential electronic information transfer. Sales
professionals will be able to travel with proprietary information and
communicate securely with the home office. Physicians will be able to
use tokens, loaded with patient files, to perform rounds, order tests
and even write prescriptions that can be signed with a digital
signature.  It will be possible to process and pay insurance claims
directly from the field.  Mobile computer users will conveniently
carry and securely communicate large amounts of confidential
information.  
   Crypta Plus cards have up to 20 Megabytes of solid-state,
nonvolatile memory and require no batteries.  The memory capacity will
increase in conjunction with technological advancements in the flash
chip industry.  The patent- pending card consists of a data storage
unit, storage-access locking circuitry, and a tamper-proof key
information substorage unit in the form of a smartcard integrated
circuit.  A stored program within the smart card integrated circuit
allows an access password to be programmed directly into the silicon
from an external source.  The locking circuitry prevents access to the
data stored on the memory card unless the user inputs the identifying 
password.  The smartcard integrated circuit can be used to perform 
cryptographic functions, including digital signatures.  It also
provides secure storage for the keys necessary to perform those
functions. The Crypta Plus card satisfies three vital needs of mobile
computer users: 
    
o   It can securely store private information in a compact, easily 
transportable storage device. 
o   It protects electronically stored data against unauthorized access
if theCrypta Plus card is lost or stolen. 
o   It makes cryptographic functions and secure key storage readily
availableto allow protection and authentication of data being sent to
remote sites.

   Several important technology trends have converged to make the
development of the Crypta Plus card possible.  The PCMCIA standard has
been swiftly adopted by the industry leaders in personal computing.
This allows the Crypta Plus card to operate cross-platform in most
mobile computing devices.  The explosive implementation of distributed
networks and wireless communication now makes data security a vital
tool for insuring and protecting personal and corporate interests. 
The rapid growth of Public-key cryptography and digital signature
standards is creating secure environments for access, transmission and
authentication of private information.  
   Along with U.S. Government standards for digital signatures and
encryption, Telequip will embed RSA, the popular Public-key
cryptosystem into the Crypta Plus card.  "We're excited about
Telequip's Crypta Plus technology - it's a perfect match for
distributed, robust security systems such as RSA," said Jim Bidzos,
president of RSA Data Security Inc.  The Crypta Plus card will also 
fully comply to the soon-to-be published PKCS 11 specification, which
will be the first open, published standard for use of Public-key
cryptography with tokens and smart cards.  PKCS, or the Public Key
Cryptography Standards, were established early in 1991 by a consortium
of RSA Data Security and its major licensees, including Microsoft,
Apple, Sun, Lotus, Digital, National Semiconductor, and many others.
The backing of the PKCS consortium members will make PKCS  11 the most
important standard for secure tokens and smartcards in the world.  
   Michael F. Jones, president of Telequip Corp., points out that
"Public-key cryptography and digital signatures are central to the
future of electronic commerce.  These techniques depend on
successfully keeping the private key and its operations secure.  The
company believes the Crypta Plus card is an ideal personal token for
performing private-key operations and implementing cross-platform
security.  It can be thought of as a portable object in which data,
applications and security all travel together in one convenient
package. Users will carry Crypta Plus cards with them to run
applications, store data, configure systems, sign documents and access
network resources."  
   --30--ed/bos  
   CONTACT:  Telequip Corp.  
   Greg Dunne, 603/881-5616





From remailer at merde.dis.org  Sun Feb  6 21:30:32 1994
From: remailer at merde.dis.org (remailer bogus account)
Date: Sun, 6 Feb 94 21:30:32 PST
Subject: PGP Tools tester needed
Message-ID: <9402070527.AA09890@merde.dis.org>


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

I tested PGP Tools with the #define in place to force all set_precisions
to max unit precision. There didn't seem to be any speed difference, even
with a 384-bit key. If this works okay, it could probably be left the way
it is. Someone with a big-endian machine, please compile the new version 
when it arrives, and see if it works. Thank you.

                                            Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVWv78GoFIWXVYodAQElbwP+NDsswe8MDnbHhnsZaWdVsb8Nv+cRuyQ4
q1L6isffXz7CJ0I2CnS/guY7yp13qaJPJiiGCoBe+/6E1uwCKj0ePIwP2ifDxf1A
1pQ17Rc11atph4NKIRlvoLbX1xs4qyHfda9CEpccOgdNuq45KZ0d/zFxN+5XvIy8
Bp3N/K00TDM=
=GmjR
-----END PGP SIGNATURE-----





From nobody at shell.portal.com  Sun Feb  6 21:46:09 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sun, 6 Feb 94 21:46:09 PST
Subject: Magic Money attack
Message-ID: <199402070541.VAA25288@jobe.shell.portal.com>


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

hfinney at shell.portal.com wrote:

I think there may be a security weakness in Magic Money coins, and in
Chaum's "online" cash system from the Chaum/Fiat/Naor paper.

[ describes the Magic Money coins ]

[ only 18 bytes are checked ]

Easy enough to fix. Will code this. I just sent new PGP Tools and Magic
Money updates to MPJ. He must be getting tired of me sending him new code
all the time. :-) The latest version does protect against garbling of the
message from client to server.

>The other relevant point is that the bank has to sign everything you
>give to it (with payment) - it can't check the bit pattern for
>legality, since what it is signing is blinded.  So you can really get
>the bank to sign anything.

Any way to avoid this, other than a cumbersome cut-and-choose?

[ attacker gets a bunch of small primes signed ]

>The idea would be for him to try to factor a legal Y using just the
>primes he has.  If he can find a factorization using only small primes
>of a number which holds the magic 18-byte sequence in the right place,
>he can multiply together the signed forms of the primes to produce a
>signed version of that number.  This would be a successfully forged coin.

How many small primes would it take? How would he know what numbers to
multiply to get the coins? Just create random coins and look for one which
is made of all small factors? I should try this and see if I can find one.
Not being an expert in the math, would most coins have a large factor, or
would there be a fair number with only small factors?

>So, the question is whether it would be feasible to collect enough
>signed small primes to be able to generate more valid coins than you
>have primes.  (It costs you a coin each time you get the bank to sign
>something, so for this to be a money-making venture you want to get
>more out of it than you put into it!)  I think there are a reasonable
>fraction of numbers factorable by only small primes.  Since there are
>2^128 possible money values (based on the 16 random bytes) there
>should be quite a lot which are factorable by only small primes.

Any math whizzes out there care to run these numbers?

>Magic Money could help by checking the high bytes as well as the magic
>18; it would be take more time to factor 1024 bit numbers than 272 bit
>ones ((18+16)*8), and there would be fewer that are factorable by
>small primes.  But the problem would still exist.  The attacker can run
>a fast sieve to identify numbers which are factorable in his set.

The high-byte check I will code up right now, but I'll wait until we figure 
out what to do about this problem, before dumping any more code on MPJ.
Is anyone going to start up a server, when the program is debugged?

>The same attack would apply to Chaum's online cash.  His cash is of the
>form, (x,f(x)^(1/e)), where f() is a one-way function like MD5.  To forge
>this you would again get signed forms of the small primes, then keep
>picking random x's, until you got a f(x) which could be factored by your
>set.  Presto, you can create a fake coin.

Anyone know Chaum's email address? We could ask him...

>I don't know how this attack can be prevented.

I can think of one way. Redefine the coin format so the last 2 bytes or so
can be anything you want. Now when the user generates a coin, he sets these
last two bytes to 0001 and then tests for primality. He keeps adding 2 and 
checking until he finds a coin which is prime, or at least doesn't have any 
small factors.

When the server gets a coin, it checks it for primality, and only accepts
coins that pass the prime test. This way any coin made out of small factors
will not be accepted.

The small-factor sieve is fast, and with the proper #defines, it checks 
all primes below 8192 decimal. The slowtest() PGP uses is slow even for the
512-bit primes used to make 1024 bit PGP keys. It would be useless for a
full 1024-bit number. Would eliminating coins with factors below 8192 be
enough? Or how could one more quickly check the coin for primality?

                                          Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVXKf8GoFIWXVYodAQHCsgQAmeUjeqb3utFdW2AwPU7a2Bs7dxRtVOPi
wzS3Jcp+QVZ4GgGLJpr2ZLW4EenX/kAkF5cLBeBebt+6RHD7jel2SxbXxeZ8Ab64
o45oibcrvN9xEnBUkEinfDfH9rkAobYFgNPfGDEs1ajDzw8ISwUDOmA+glm01xzg
XBZFLdyQWwM=
=H+UC
-----END PGP SIGNATURE-----





From nobody at shell.portal.com  Sun Feb  6 22:20:31 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Sun, 6 Feb 94 22:20:31 PST
Subject: RE Magic Money Attack
Message-ID: <199402070620.WAA27121@jobe.shell.portal.com>


Pr0duct Cypher wrote,
"Easy enough to fix. Will code this. I just sent new PGP Tools and Magic
Money updates to MPJ. He must be getting tired of me sending him new code
all the time. :-) The latest version does protect against garbling of the
message from client to server."

Tired of new code? NEVER.





From hfinney at shell.portal.com  Sun Feb  6 22:41:09 1994
From: hfinney at shell.portal.com (Hal)
Date: Sun, 6 Feb 94 22:41:09 PST
Subject: Magic Money attack
Message-ID: <199402070641.WAA27913@jobe.shell.portal.com>


>From Pr0duct Cypher:

> [ only 18 bytes are checked ]
> 
> Easy enough to fix. Will code this. I just sent new PGP Tools and Magic
> Money updates to MPJ. He must be getting tired of me sending him new code
> all the time. :-) The latest version does protect against garbling of the
> message from client to server.

I think it's great that you are able to fix these things so quickly.
It's natural that there will be a lot of shaking out in any initial
release.

> How many small primes would it take? How would he know what numbers to
> multiply to get the coins? Just create random coins and look for one which
> is made of all small factors? I should try this and see if I can find one.
> Not being an expert in the math, would most coins have a large factor, or
> would there be a fair number with only small factors?

Knuth has some discussion of this in Seminumerical Algorithms.  The term
for numbers which have only small factors is that they are "smooth".  He
has some formulas for what fraction of numbers are smooth based on the
size of the largest allowed prime and the size of the numbers.  Unfortunately
I won't have access to my copy until Tuesday.  Perhaps someone else can
look it up.

> >I don't know how this attack can be prevented.
> 
> I can think of one way. Redefine the coin format so the last 2 bytes or so
> can be anything you want. Now when the user generates a coin, he sets these
> last two bytes to 0001 and then tests for primality. He keeps adding 2 and 
> checking until he finds a coin which is prime, or at least doesn't have any 
> small factors.

Clever idea.  If only it wouldn't be so slow.

> The small-factor sieve is fast, and with the proper #defines, it checks 
> all primes below 8192 decimal. The slowtest() PGP uses is slow even for the
> 512-bit primes used to make 1024 bit PGP keys. It would be useless for a
> full 1024-bit number. Would eliminating coins with factors below 8192 be
> enough? Or how could one more quickly check the coin for primality?

The 8192 cutoff might work.  We would have to check it out, but it
could be that finding 1024-bit numbers in a relatively narrow range of
+/- 2^64 which are composed solely of factors in the range, say, 8192
to 16384 would be infeasible.  I don't recall whether Knuth considers the
problem in this form.  This would be a great save if it works.

Hal





From qwerty at netcom.com  Sun Feb  6 23:10:32 1994
From: qwerty at netcom.com (Xenon / Qwerty Remailer)
Date: Sun, 6 Feb 94 23:10:32 PST
Subject: Qwerty/Xenon update.
Message-ID: <199402070708.XAA17393@mail.netcom.com>


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

"I am not a number!" - The Prisoner

Though na48138 at anon.penet.fi is still forwarded to me, I have decided to change
the PGP Info Clearing House address to qwerty at netcom.com. When I first got
an anon.penet.fi nickname I figured (wrongly) that people could mail me at
Xenon at anon.penet.fi. Oh well. So now the qwerty-account/remailer will be
receiving mail from basically random addresses out there. This is a fun twist,
being a unique partial solution to the traffic analysis problem. All the
remailers are now sending to other than the Cypherpunks now as well. And the
people wanting PGP info will get it without anon.penet.fi delays. No more of
their forgetting to use na instead of an too.

So how hard is that to remember?: Send mail to QWERTY at NETCOM.COM with
Subject "Bomb me!" for Gary Edstrom's PGP FAQ and Xenon's "Here's How to
MacPGP!".

Finger qwerty at netcom.com for info on the remailer there. It would be nice
if every remailer gained a standardized BitBucket. To keep things simple, I
suggest nothing more complicated than what qwerty uses; just request
remailing to /dev/null. I'm using Hal's remailer, with a few updated
files, and have used his outgoing address filter. These lines thus appear in my
maildelivery file:

# Blocked outgoing addresses
Request-Remailing-To    whitehouse.gov    file A  LOG.BLOCKED
Request-Remailing-To    /dev/null         file R  /dev/null
Request-Remailing-To    /dev/null         pipe A "/usr/bin/echo BB >> LOG"

The A means after the "BB" has been appended to my counter file, the mail
is considered delivered.

 -=Xenon=-

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVWh4QSzG6zrQn1RAQHnUAQAxyr390k7jkQFKm6YK6DPCINifAwwDAQA
Kg+TA5fctD2ggU2l9DiZC7IJZPK+Kwv3u1Kz/NlpheO9vMQaDSCxad0fFl7V8LYm
QUMW+vRn8h3/OTMlqMSEOC3Xry9A9n1RAmpmZpQtwSWIoSBaAt8M9KClm8NBdkgC
KWghYDHhGTk=
=pKJn
-----END PGP SIGNATURE-----





From Rolf.Michelsen at delab.sintef.no  Mon Feb  7 00:41:11 1994
From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen)
Date: Mon, 7 Feb 94 00:41:11 PST
Subject: Magic Money questions
In-Reply-To: <199402051111.DAA11286@mail.netcom.com>
Message-ID: <Pine.3.88.9402070917.C18201-0100000@pluto.er.sintef.no>


On Sat, 5 Feb 1994 catalyst-remailer at netcom.com wrote:

[ Stuff deleted ]

> >Similarly, how can the consumer trust the bank's representation that
> >money has already been spent?  Surely the bank should be required to
> >publish a list of cancelled coins and timestamps with a running MD5
> >hash periodically for inspection by the unwashed masses.
> 
> There is no punishment for double-spending. The transaction is simply thrown
> out. The bank, in fact, has no way to identify the customer. What could the
> bank hope to accomplish by claiming that a coin was already spent? It can
> print more coins at any time, so it has no reason to cheat. A server will
> have to protect its reputation by not printing too much money or otherwise
> making its users angry. If you want to put in an MD5, it wouldn't be hard.
> 

[ more stuff deleted ]

False!  If digital coins represent some kind of value the bank will 
"earn" something by not accepting a coin presented for deposit.  The bank 
will not have to provide the value or the service the depositor is 
entitled to.  This was also pointed out by someone else posting to this list.

I haven't studied the maths and protocols of the original post to 
closely, but just to show that it is possible to *prove* double spending 
I present a deposit protocol.  I don't know if this protocol fits in the 
implementation discussed here.

If I remember correctly, some of Chaum's (?) digital coin systems proved 
double spending by using a protocol resembling the one below:
   1)  Depositor presents a part of the coin to the bank and asks "Is 
       this coin already deposited?"
   2)  The bank answers "yes" and proves this by revealing some 
       information about the coin which it should now know unless the 
       coin has already been deposited.  The "no" answer together with 
       the information presented by the depositor is signed by the bank 
       and is a *commitment* by the bank to accept the coin when the 
       "real" deposit takes place.
   3)  The depositor sends the rest of the coin to the bank if the answer 
       was a "no".
This is taken from memory -- I could probably produce some references if 
someone is interested.

By the way -- I don't think you should use the "digicash" word to 
describe this implementation.  David Chaum's company carries that name!
   


-- Rolf


----------------------------------------------------------------------
Rolf Michelsen         Phone:  +47 73 59 87 33
SINTEF DELAB           Email:  rolf.michelsen at delab.sintef.no
7034 Trondheim         Office: C339
Norway
----------------------------------------------------------------------






From nobody at shell.portal.com  Mon Feb  7 01:16:12 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Mon, 7 Feb 94 01:16:12 PST
Subject: Magic Money attack feasible?
Message-ID: <199402070913.BAA09983@jobe.shell.portal.com>


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

I've done some experiments with this factor-multiplication problem. I think
the solution is to check the whole coin rather than just the ASN string, 
and possibly to make sure the coin has no small factors. Doing a slowtest() 
on a 1024-bit number takes slightly under a minute on a fast PC, so that is 
too slow. But the sieve is fast, and if you #define BIGSIEVE, it catches all 
factors below 8192.

I tried making some coins and trial-dividing them by the small primes in 
the primetable[] (up to 8191). There were a few factors being found, mostly
8-bit ones, but the remaining coin, when all the factors were divided out, 
wasn't much smaller. I think finding coins with all small factors will be 
pretty intractible.

The paper refers to Chaum's digicash, using x and f(x). If f(x) were only
16 bytes, and not padded, this attack would be a serious problem. But the
padding (01 and then repeat FF until the last 34 bytes) makes the attack
much harder and probably impractical. The PKCS-format signature was, after
all, designed to break up the multiplicativity of RSA. What exactly does
the ASN string (those magic 18 bytes) do, other than pad out the MPI? Does
it have some special mathematical properties?

Personally, I think the padding gets rid of the problem. A 1024-bit number,
padded with FF's to make it as big as possible, is very likely to have two
or more fairly large factors (more than 16 bits or so). Since you would 
have to get two or more signatures to forge one, you lose money instead 
of gaining it. You are unlikely to find two coins which have the same large 
factors, so you can't re-use signed primes - the whole key to this attack.

It is possible to move everything up, and leave the last 16 bits open. Then 
you could sieve the coin, and add 2 until you found one which had no 
factors below 8192, making the attack even harder. I don't think this is 
necessary, but I hope someone will work out the math. And if it turns out 
to be necessary, it is at least possible to make all the coins prime, 
making this attack completely impossible.

For now, I will modify the code to check the whole number, and to make sure
that the coin is as long as the modulus it's signed with. If the other
change is necessary, let me know. I'm not going to post any more code to
csn.org until someone (1) checks the existing (sent today) code on a big-
endian machine, and (2) figures out if this attack is a problem. It should 
be mathematically possible to find the probability that a number of size m 
is composed only of primes smaller than size n, but I don't know how to do 
it. Does anyone?

                                                  Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVXwJsGoFIWXVYodAQEZ4gP/QOGoZgRcR1CJkaWErSesMCzsEAu1fCVB
OAhLGXI8hIErDuMy9f395agFxjPK3EgSWF6nnoze+BbfZDF0nTAgbgdEroHPy3k7
Pp/FV0jES3BqPFOX/0JCWHx8LRm4n2tMqUgLsX0125xywU9tk097DJTPxrAh9Xbs
zrEVlsJuGRs=
=akie
-----END PGP SIGNATURE-----





From remailer at merde.dis.org  Mon Feb  7 01:30:32 1994
From: remailer at merde.dis.org (remailer bogus account)
Date: Mon, 7 Feb 94 01:30:32 PST
Subject: More on Magic Money attack
Message-ID: <9402070928.AA10499@merde.dis.org>


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

(I sent that last message before receiving Hal's response)

hfinney at shell.portal.com wrote:

>I think it's great that you are able to fix these things so quickly.
>It's natural that there will be a lot of shaking out in any initial
>release.

But what does MPJ think of getting a 400K mailbomb? If you object, MPJ,
feel free to flame me and I'll stop sending them.

>>How many small primes would it take? How would he know what numbers to
>>multiply to get the coins? Just create random coins and look for one which
>>is made of all small factors? I should try this and see if I can find one.
>>Not being an expert in the math, would most coins have a large factor, or
>>would there be a fair number with only small factors?

>Knuth has some discussion of this in Seminumerical Algorithms.  The term
>for numbers which have only small factors is that they are "smooth".  He
>has some formulas for what fraction of numbers are smooth based on the
>size of the largest allowed prime and the size of the numbers.
>Unfortunately I won't have access to my copy until Tuesday.  Perhaps 
>someone else can look it up.

Someone please do. I can make the changes as needed tomorrow, if someone
posts the math results. I am anxious to play with a real live digicash
system, and transferring money between two directories on my hard drive
does not count.

>>The small-factor sieve is fast, and with the proper #defines, it checks 
>>all primes below 8192 decimal. The slowtest() PGP uses is slow even for
>>the 512-bit primes used to make 1024 bit PGP keys. It would be useless 
>>for a full 1024-bit number. Would eliminating coins with factors below 
>>8192 be enough? Or how could one more quickly check the coin for 
>>primality?

>The 8192 cutoff might work.  We would have to check it out, but it
>could be that finding 1024-bit numbers in a relatively narrow range of
>+/- 2^64 which are composed solely of factors in the range, say, 8192
>to 16384 would be infeasible.  I don't recall whether Knuth considers the
>problem in this form.  This would be a great save if it works.

Whoever has the Knuth book, please check this out. Maybe we should patent
this solution, if it works, and make Chaum pay us, since he patented his
blind signature protocol. :-)

                                                Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVX0s8GoFIWXVYodAQG2TwP/Qa2Ql5JGu3aaYTvyfMLXeICCSQTWH2al
Mx4XxAEMgsh31JH18McVwltla6I33hndYfLyFwRKetPaNW5EKO/ypzZFPHIN6m5k
J9iiYDUk/FsKxScR//yjUTEsOu/3UQwczk3qRadJkNOBZQBo+qDpXewASJlVEewH
0oCWeXmqoZU=
=beCP
-----END PGP SIGNATURE-----





From nobody at shell.portal.com  Mon Feb  7 02:26:14 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Mon, 7 Feb 94 02:26:14 PST
Subject: PGPTOOLS and Magic Money
Message-ID: <199402071025.CAA13685@jobe.shell.portal.com>


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

I've got the code written to check the whole coin, and I found another
subtle bug caused by precision setting. Since setting precision does not
seem to affect the speed of the decryption (I think the mpi library sets
it internally during modexp) I'm just going to fix it at MAX_UNIT_PRECISION
and leave it there. Tomorrow I will strip out all of these damn things.

                                           Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVYNRcGoFIWXVYodAQHdCAP/WZwBMm5NFUzYHaYXhE+d3OAXSlNKpGxD
ttHtNJCI1gIZGBc2chDrMxdAa7/3xx+WdAAQ20pM/MLF44S2JVHcxnlum7oSsC9r
O04uzdNGprZ1v/K/rZtc8o/xkUAUjctVY0qPGO5hK+Cyl9lABtwBeBPRslUCPYgv
A1DjN0E6QNc=
=HR0H
-----END PGP SIGNATURE-----





From jkreznar at ininx.com  Mon Feb  7 03:06:15 1994
From: jkreznar at ininx.com (John E. Kreznar)
Date: Mon, 7 Feb 94 03:06:15 PST
Subject: Magic Money attack
In-Reply-To: <199402070541.VAA25288@jobe.shell.portal.com>
Message-ID: <9402071101.AA08570@ininx>


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

> >The idea would be for him to try to factor a legal Y using just the
> >primes he has.  If he can find a factorization using only small primes
> >of a number which holds the magic 18-byte sequence in the right place,
> >he can multiply together the signed forms of the primes to produce a
> >signed version of that number.  This would be a successfully forged coin.

> How many small primes would it take? How would he know what numbers to
> multiply to get the coins? Just create random coins and look for one which
> is made of all small factors? I should try this and see if I can find one.
> Not being an expert in the math, would most coins have a large factor, or
> would there be a fair number with only small factors?

> >So, the question is whether it would be feasible to collect enough
> >signed small primes to be able to generate more valid coins than you
> >have primes.  (It costs you a coin each time you get the bank to sign
> >something, so for this to be a money-making venture you want to get
> >more out of it than you put into it!)  I think there are a reasonable
> >fraction of numbers factorable by only small primes.  Since there are
> >2^128 possible money values (based on the 16 random bytes) there
> >should be quite a lot which are factorable by only small primes.

> Any math whizzes out there care to run these numbers?

A useful and delightful reference on this subject (and many others) is
_Number Theory in Science and Communication_ by M.R.~Schroeder,
Springer-Verlag, 1984.

Let me quote the first few paragraphs of Chapter 11, ``The Prime Divisor
Functions''.  I use LaTeX coding.

	Here we consider only {\em prime\/} divisors of $n$ and ask, for
	given order of magnitude of $n$. ``how many prime divisors are
	there typically?'' and ``how many {\em different\/} ones are
	there?''  Some of the answers will be rather counterintuitive.
	Thus, a 50-digit number ($10^{21}$ times the age of our universe
	measured in picoseconds) has only about 5 different prime
	factors on average and --- even more surprisingly --- 50-digit
	numbers have typically fewer than 6 prime factors in all, even
	counting repeated occurrences of the same prime factor as
	separate factors.

	We will also learn something about the distribution of the
	number of prime factors and its implications for the important
	factoring problem.  Thus, we discover that even for numbers as
	large as $10^{50}$, the two smallest primes, 2 and 3, account
	for about 25\% of all prime factors!

	{\large\bf 11.1 The Number of Different Prime Divisors}

	In connection with encrypting messages by means of Euler's
	theorem, the number of distinct {\em prime\/} divisors of a given
	integer $n$, $\omega(n)$, is of prime importance.  Its
	definition is similar to that of the divisor function $d(n)$,
	except that the sum is extended --- as the name implies --- only
	over the prime divisors of $n$:

	$$ \omega(n) := \sum_{p_i \mid n} 1 . $$

	It is easily seen that $\omega(n)$ is additive, i.e., for $(n,m)
	= 1$,

	$$ \omega(nm) = \sum_{p_i \mid nm} 1
		      = \sum_{p_i \mid n} 1 + \sum_{p_i \mid m} 1
		      = \omega(n) + \omega(m) . $$

	Of particular interest to our encrypting desires will be the
	behavior of $\omega(n)$ for large $n$, i.e., its asymptotic
	behavior.  We shall try to get an idea of this behavior by means
	of our usual ``dirty tricks.''

...and so on.  It seems unlikely that this development would be useless in
answering the question at hand.  I don't have time now to study further.

	John E. Kreznar		| Relations among people to be by
	jkreznar at ininx.com	| mutual consent, or not at all.

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVYddsDhz44ugybJAQHpZAP/azfOzvVEkymO3rh/4HbTc537zuEajoW+
Kz+03iRenJh/Xe7906t9EmxqK9Bx2Zu28AbGonUfBSg39agrGfSyCqMltvapIbhw
m2MCf25UIn5q69WB6pbIA0/V77xNFx1YEm7CtTeuBO9vqrtYW7DirJKk29brAd4d
6FlX6+nbyd8=
=JuTg
-----END PGP SIGNATURE-----





From O.Nwosu at cs.ucl.ac.uk  Mon Feb  7 03:10:34 1994
From: O.Nwosu at cs.ucl.ac.uk (Obi)
Date: Mon, 7 Feb 94 03:10:34 PST
Subject: unsubscribe
Message-ID: <9402071109.AA09100@toad.com>


Please unsubscribe me.  Thank You.

Obi.
====





From warlord at MIT.EDU  Mon Feb  7 03:26:15 1994
From: warlord at MIT.EDU (Derek Atkins)
Date: Mon, 7 Feb 94 03:26:15 PST
Subject: PGPTOOLS and Magic Money
In-Reply-To: <199402071025.CAA13685@jobe.shell.portal.com>
Message-ID: <9402071121.AA04510@toxicwaste.media.mit.edu>


PC> 
> I've got the code written to check the whole coin, and I found another
> subtle bug caused by precision setting. Since setting precision does not
> seem to affect the speed of the decryption (I think the mpi library sets
> it internally during modexp) I'm just going to fix it at MAX_UNIT_PRECISION
> and leave it there. Tomorrow I will strip out all of these damn things.

Yea, MPI lets the precision.  This is not a bug -- the MPI library
needs to know how big the number is.  (The bug is that its done in a
global variable and not as a part of the number internally, but thats
a different matter).  The reason it needs to know is so that it
doesn't need to perform large operations for small numebers.  For
example, there is no reason to perform a 1024-bit modexp when you are
dealing with 384-bit numbers!

FYI: I have both big-endian and little-endian machines at my disposal.
Also, I was having problems building PGP Tools under mips-ultrix --
you have some global variables in ptd that you expect from time.h
which don't exist.  In particular, timezone and daylight.

-derek

-----BEGIN PGP MESSAGE-----
Version: 2.3a

hIwCwagUhZdVih0BA/0XHyUO7jSVHijFk98o3X3YK+pYZNQxmg+QfiNKvVXjPk6B
HqM2kKTZXMngoBBl1dC+ps1jFdFI5Anxwdb/Sjg3VpQVvv/fsiK6G9V7Om6xp3Li
5v7xQ6dPRtcgmvI9WHje9OM2fhdgNsgPePEOj4odfuoYHp+9b2qlmyPYY4lChqYA
AAIYLZFtfA3yFO8Lq719Jh5oIGS+JfLG6VA2Q3Tzkf7iGob17yN9poa4GvnQZP23
m1nsBYAajPKp0Odvrs3yrb1LrQAxDRNqV4hj/YTbIITqDCqdXYrUYf64JyWjaqXS
lMBQG0hHDgWYLewtYEtS7VDI/yOGk4/qrJxN39xcYNVhkiD6ETTi6/wUnWCLL6aW
EIM0rjwIyydaeqQmAPsj+AP+qZioyuqXNibMg95tLs5HVsDUIO7BLqhIFcnrX0Vj
EIO4qBXRT2fxCnM0sxFN+vsbE+8ZNx8l1Y4dWjOQCQVpzU11IBr3Gs0Ql9U5BUAc
lgD3qjf4zTTMDniTRf+r/h8PUVyj10T9C2LOylDDJ0H/uRKpMUrliA3xFvUjThc5
ORVdp1BEhnxDViArn5+MfUm37L8J81bTUMYvFBz5BLsxjznnfZoactQ6x1al3tgF
1k/c7mjIUSGA1Btxo+zkS140Jd3lJ+alXQkCOr6Zgg/nPy1nQa+vdVPN38zzzhUn
fkRbvgFb9Eq5QYZTuhcXg4gsQIKT519zMVgx4LnJWyGhxKM01YA3jr7XFZ9apKfE
Ot4ry1P7mR2oPykKENucWRAqgzc91YvNw471wANcbbyJkIgZxeWg/oXidocfWonR
gyZLGxfyOB+9LbVIOxHJc+wskPUAQhdN+BEdp+Y3uBjJGRJalAWwLdcAPrNmvnyX
DELrdVfLGFZ3xwE=
=uBDq
-----END PGP MESSAGE-----





From edgar at spectrx.saigon.com  Mon Feb  7 04:31:17 1994
From: edgar at spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 7 Feb 94 04:31:17 PST
Subject: Remailer Tearline Conventions
Message-ID: <4XLDHc12w165w@spectrx.saigon.com>


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

Anonymous (not me again) posted this reply to my msg:

   Uu> At the time I brought this up, the attitude of most remailer operators
   Uu> (Chael Hall and Miron Cuperman notably excepted) was that anyone who
   Uu> couldn't figure out how and remember to turn off their auto sig didn't
   Uu> deserve any privacy.

  An astonishing bit of Internet provincial fuckheadedness, I must say!

Well, you're at least 1/3 right! (:}

   Uu> I recommend that you always use the wimsey (extropia) remailer as the
   Uu> first (or only) leg of a remailer chain.  It is also the only
   Uu> Cypherpunks remailer outside the USA (it's in Canada) which will make
   Uu> tracing msgs a little more difficult for USA authorities.

  That remail at extropia.wimsey.com is in Canada specifically makes
  communications with it fair game for NSA interception, however.

Good luck, NSA. Better warm up those Crays. Wimsey is also the
only remailer to -require- the entire incoming msg to be encrypted
with a strong PGP key

  pub  1024/B5A32F 1992/12/13  Remailer <remail at extropia.wimsey.com>

Note this feature doesn't allow the encrypted SASE supported by other
Cypherpunks remailers which -allow- encryption but remail any
unencrypted text following the encrypted portion (which often includes
the auto sig, our original topic).  Instead, wimsey supports a pool
address:

   pool0 at extropia.wimsey.com

which is essentially a mailing list devoted to broadcasting to its
list of subscribers anything mailed to it. You join the mailing list
by sending a request to

   pool0-request at extropia.wimsey.com

Typically reply mail would be encrypted to a pseudonymous key you sent
via the conventional forward remiler method, so although everyone
on the list would receive the message, only the intended recipient
could read it.  Note that even if the authorities learn you are on the
mailing list, you have absolute deniability that you are the intended
recipient of any particular message.  (But keep the pseudonymous
secret key encrypted when not in use).

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVYke94nNf3ah8DHAQHyCgP+N2c32DsO96vUB/bacRqJ0srqKwN7ioJj
1fGT5iNfdYpoXUr/JaDgMs3dX/wjJmA0v7j7GypN7Cla/qmekhRyKqglOmI+U2W4
jsfMO1DfV0MpezyOpQlSjoO1q7cXMjMmbZQl9rQfiRKcaWKT2MeuwF1JQj7ZD3jE
YzMlzaC5AsU=
=ujoi
-----END PGP SIGNATURE-----

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






From dmandl at lehman.com  Mon Feb  7 05:46:19 1994
From: dmandl at lehman.com (David Mandl)
Date: Mon, 7 Feb 94 05:46:19 PST
Subject: Clipper "Above the Fold"
Message-ID: <9402071342.AA22956@disvnm2.lehman.com>


> From: Duncan Frissell <frissell at panix.com>
> 
> Clipper and the Admin decision to adopt same is reported in a front page 
> (above the fold) article in the Saturday New York Times.
> 
> Usual errors about how the "backdoor" would work and about how warrants 
> would be required to get the keys.
> 
> All the usual suspects.  Good placement though.
> 
> DCF 

Unfortunately, though, it was pretty soft on Clipper.  Significantly,
the piece was not written by John Markoff, who's been covering cypherpunk-
and crypto-related issues for the Times for a while now.  Markoff has been
very friendly to "our side."  This other guy (sorry, name escapes me)
seemed to swallow the USG's line much more uncritically.  I wonder why
Markoff didn't write Saturday's piece? 

I'm not subtly suggesting conspiracy theories here, though I'm certainly
open-minded about them.  Mainly, I'm noting the difference between the two
guys' approaches and how strongly they affect the coverage.  I did a mini-
rant about the piece on my radio show Saturday.

   --Dave.





From mnemonic at eff.org  Mon Feb  7 06:26:23 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 06:26:23 PST
Subject: Clipper "Above the Fold"
In-Reply-To: <9402071342.AA22956@disvnm2.lehman.com>
Message-ID: <199402071423.JAA26318@eff.org>


 
David Mandl writes:

> I wonder why
> Markoff didn't write Saturday's piece? 

Markoff's on vacation.



--Mike







From danisch at ira.uka.de  Mon Feb  7 06:51:35 1994
From: danisch at ira.uka.de (Hadmut Danisch)
Date: Mon, 7 Feb 94 06:51:35 PST
Subject: ADMIN: list statistics
Message-ID: <9402071205.AA05885@deathstar.iaks.ira.uka.de>


>    4 de		Denmark

       ^^^


.de is Germany , it stands for 'Deutschland,' the
german word for 'Germany'. Don't know what is the
sign of Denmark...

Hadmut  ( danisch at ira.uka.de  sitting in Karlsruhe, Germany)





From nate at VIS.ColoState.EDU  Mon Feb  7 07:11:22 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Mon, 7 Feb 94 07:11:22 PST
Subject: some assmunch
Message-ID: <9402071510.AA12125@vangogh.VIS.ColoState.EDU>



Some assmunch out there sent information on my remailer to
a mailing list of list managers of subnets at CSU.  This
was uncalled for.  The list has about 71 people on it,
and they really have better things to do.

-nate

-- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From adam at bwh.harvard.edu  Mon Feb  7 07:31:39 1994
From: adam at bwh.harvard.edu (Adam Shostack)
Date: Mon, 7 Feb 94 07:31:39 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de>
Message-ID: <199402071531.KAA16820@duke.bwh.harvard.edu>


Hadmut wrote:

| >    4 de		Denmark
| 
|        ^^^
| .de is Germany , it stands for 'Deutschland,' the
| german word for 'Germany'. Don't know what is the
| sign of Denmark...

	Its nl, for (I think) Netherlands.

Adam





From mpjohnso at nyx10.cs.du.edu  Mon Feb  7 07:36:23 1994
From: mpjohnso at nyx10.cs.du.edu (Michael Johnson)
Date: Mon, 7 Feb 94 07:36:23 PST
Subject: PGP Tools & Magic Money Update
Message-ID: <9402071530.AA17018@nyx10.cs.du.edu>


> it work, but will slow it down. The new version, when it shows up, should
> be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell
> you how to get into the crypto section. Check the file dates to see if the
> new version is there yet. I sent them on 2/6.

Sorry, I fumbled reception of the pgptools.zip update... tried an mv to a
full disk.  The magic money update is there, but the pgptools.zip update
will be delayed while I wait for retransmission via some slow remailers.

                                           mpj at csn.org





From Rolf.Michelsen at delab.sintef.no  Mon Feb  7 07:36:26 1994
From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen)
Date: Mon, 7 Feb 94 07:36:26 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de>
Message-ID: <Pine.3.88.9402071639.B18272-0100000@pluto.er.sintef.no>


On Mon, 7 Feb 1994, Hadmut Danisch wrote:

> >    4 de		Denmark
> 
>        ^^^
> 
> 
> .de is Germany , it stands for 'Deutschland,' the
> german word for 'Germany'. Don't know what is the
> sign of Denmark...
> 
> Hadmut  ( danisch at ira.uka.de  sitting in Karlsruhe, Germany)
> 

Denmark is ".dk".

-- Rolf



----------------------------------------------------------------------
Rolf Michelsen         Phone:  +47 73 59 87 33
SINTEF DELAB           Email:  rolf.michelsen at delab.sintef.no
7034 Trondheim         Office: C339
Norway
----------------------------------------------------------------------






From pmetzger at lehman.com  Mon Feb  7 07:36:37 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 07:36:37 PST
Subject: your mail
In-Reply-To: <199402051538.KAA07593@eff.org>
Message-ID: <199402071535.KAA04605@snark>



Mike Godwin says:
>  
> David Koontz writes:
> 
> > All this bullshit doesnot state that a court order is required, rather
> > 'legal authorization', which means the NSA for foreign intellingence
> > purposes without a court order.
> 
> The Foreign Intelligence Surveillance Act (FISA) requires a court order
> for such taps.

I seem to remember something about this from The Puzzle Palace. Am I
mistaken, or are such orders not made by a special court, which holds
secret proceedings and which, so far as is known, has never denied a
request?

Perry





From warlord at MIT.EDU  Mon Feb  7 07:46:22 1994
From: warlord at MIT.EDU (Derek Atkins)
Date: Mon, 7 Feb 94 07:46:22 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de>
Message-ID: <9402071543.AA05472@toxicwaste.media.mit.edu>


Denmark is dk

-derek





From pmetzger at lehman.com  Mon Feb  7 07:51:37 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 07:51:37 PST
Subject: Crypto Regulation Reform
In-Reply-To: <9402052019.AA10570@vail.tivoli.com>
Message-ID: <199402071551.KAA04645@snark>



Mike McNally says:
> 
> Robert Cain writes:
>  > A device can be made right now at lower cost
>  > than a computer modem, much lower, that could be inserted between any
>  > phone and the wall that would make it impossible, no matter what laws
>  > are in place, to tap either passively or acitively, communication that
>  > passes between two of these devices.  I know how to do it, could do it
>  > and probably will just for the fun of it at least.  
> 
> Uhh, could you tell us?  Sounds like quite a breakthrough.  Credit
> card sized?  Much cheaper than a modem, like $50 maybe?  And it
> digititizes and securely encrypts speech (full duplex?) on the fly?

By definition anything that does this in the digital domain needs a
modem, so it can't be cheaper than a modem. None of the analogue
methods are going to be terribly secure.

.pm





From pmetzger at lehman.com  Mon Feb  7 07:56:22 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 07:56:22 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
In-Reply-To: <199402052205.OAA06854@jobe.shell.portal.com>
Message-ID: <199402071555.KAA04653@snark>



Hal says:
>From: rcain at netcom.com (Robert Cain)
> > Now, the tutorial over :-), the question is; is there a "standard"
> > well-known-prime, w, and a "standard" well-known-modulus, m, and if
>              ^^^^^-- generator
> > not, let's define one.
> 
> I don't think there is a need for this.  The two sides need to agree on
> a pair but they could just pick it at the beginning.  If everyone uses
> the same m,w it would help attackers of the scheme to focus their efforts
> on these numbers.

Indeed, a paper has been published on how to break Sun Secure RPC
based on the idiotic decision by someone at Sun to standardise the
modulus used. It is basically a matter of precomputing a lot of data
based on the numbers which allows you to break any particular discrete
log in that field on the fly. The suggestion by Mr. Cain to use a
single generator and modulus for all traffic is astonishingly naive.

Perry





From frissell at panix.com  Mon Feb  7 08:06:22 1994
From: frissell at panix.com (Duncan Frissell)
Date: Mon, 7 Feb 94 08:06:22 PST
Subject: Safire Mentions NSA
Message-ID: <199402071604.AA18104@panix.com>


In a column explaining (to the uninitiated) what the networked 
transformation of human society means (your own Genie sans bottle) William 
Safire mentioned the wiretap controversy.  He has done this before.

"Dangers abound:  President Clinton has cravenly allowed N.S.A. (No Such 
Agency) to bug the info highway.  Futurethicists wonder if 
virtuous-reality love can compete with virtual-reality porn.  And the big 
one: how to get our personal genies back in the bottle."

DCF



--- WinQwk 2.0b#1165
        





From mnemonic at eff.org  Mon Feb  7 08:10:37 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 08:10:37 PST
Subject: your mail
In-Reply-To: <199402071535.KAA04605@snark>
Message-ID: <199402071608.LAA27625@eff.org>


 
Perry writes:

> Mike Godwin says:
> >  
> > David Koontz writes:
> > 
> > > All this bullshit doesnot state that a court order is required, rather
> > > 'legal authorization', which means the NSA for foreign intellingence
> > > purposes without a court order.
> > 
> > The Foreign Intelligence Surveillance Act (FISA) requires a court order
> > for such taps.
> 
> I seem to remember something about this from The Puzzle Palace. Am I
> mistaken, or are such orders not made by a special court, which holds
> secret proceedings and which, so far as is known, has never denied a
> request?

You remember it correctly.


--Mike







From cfrye at ciis.mitre.org  Mon Feb  7 08:16:22 1994
From: cfrye at ciis.mitre.org (Curtis D. Frye)
Date: Mon, 7 Feb 94 08:16:22 PST
Subject: ADMIN:  list statistics
Message-ID: <9402071620.AA24015@ciis.mitre.org>


Hadmut wrote:

>    4 de               Denmark

       ^^^


.de is Germany , it stands for 'Deutschland,' the
german word for 'Germany'. Don't know what is the
sign of Denmark...

Hadmut  ( danisch at ira.uka.de  sitting in Karlsruhe, Germany)
***

The abbreviation for Denmark is ".dk".

--
Best regards,

Curtis D. Frye - Economic Analyst, Software Alchemist, Aspiring Author
cfrye at ciis.mitre.org
"If you think I speak for MITRE, I'll tell you how much they
 pay me and make you feel foolish."







From pmetzger at lehman.com  Mon Feb  7 08:16:26 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 08:16:26 PST
Subject: No Subject
In-Reply-To: <199402061953.LAA08152@jobe.shell.portal.com>
Message-ID: <199402071615.LAA04694@snark>



nobody at shell.portal.com says:
> I'm moving to Oceania.

Not all of us have the luxury of moving to non-existant places -- most
of us are stuck living in real ones.

.pm





From andrewl at wtg20.wiltel.com  Mon Feb  7 08:20:36 1994
From: andrewl at wtg20.wiltel.com (Andrew Loewenstern)
Date: Mon, 7 Feb 94 08:20:36 PST
Subject: Magic Money on Big Endian
Message-ID: <9402071617.AA28202@wtg20>


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

I retrieved the latest version of Magic Money from the mpj archive
and compiled it on a big-endian machine (a 68k NeXT).  It seems
to work now...  I was able to setup the server and client and
move a little cash around whereas before the server would never
sucessfully find a q....


andrew

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVZpUXIOIr9VPTMNAQHhjwP/faQUinjX7MxfW84rRfFKhf1TgZcveaPM
AjVO8uws3aLv2mhvKl2kYdxLj9LAOzzidZE8bw5RSG6cD4ox90MHjZao9ZOfwvyz
VfpWAvWGirrKSGLrrvEXOZnnIk+R2m4ZPFV+duLNjmN6Aw3sa89VLqkiK4me3y1w
1MosXdYtocU=
=rdbz
-----END PGP SIGNATURE-----





From pmetzger at lehman.com  Mon Feb  7 08:21:22 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 08:21:22 PST
Subject: TEMPEST - Electronic eavesdropping
In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk>
Message-ID: <199402071617.LAA04702@snark>



R.O.Jackson-SE1 at computer-science.birmingham.ac.uk says:
> In the US it not illegal to posess TEMPEST-surveillance equipment but
> it is illegal to take appropriate counter-measures to prevent 
> surveillance.

This is not true. This is an urban legend that doesn's of fools keep
posting over and over again. There is nothing illegal against
shielding your equipment -- in fact you are legally obliged to reduce
emmissions so as not to interfere with radio and TV signals.

Perry





From julf at penet.fi  Mon Feb  7 08:26:22 1994
From: julf at penet.fi (Johan Helsingius)
Date: Mon, 7 Feb 94 08:26:22 PST
Subject: ADMIN: list statistics
In-Reply-To: <199402071531.KAA16820@duke.bwh.harvard.edu>
Message-ID: <199402071622.AA02209@lassie.eunet.fi>



> | .de is Germany , it stands for 'Deutschland,' the
> | german word for 'Germany'. Don't know what is the
> | sign of Denmark...
> 
> 	Its nl, for (I think) Netherlands.

Sigh. Yes. .nl is for The Netherlands. Holland, that is. Denmark
is .dk.

	Julf






From mnemonic at eff.org  Mon Feb  7 08:26:26 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 08:26:26 PST
Subject: DOJ procedures relating to Clipper Chips and key escrow
Message-ID: <199402071624.LAA27967@eff.org>




One of the interesting passages comes at the end of the DOJ memo
about obtaining Clipper keys pursuant to an interception:

"These procedures do not create, and are not intended to create,
any substantive rights for individuals intercepted through
electronic surveillance, and noncompliance with these procedures
shall not provide the basis for any motion to suppress or other
objection to the introduction of electronic surveillance evidence
lawfully acquired."

What this means, apparently, is that keys or communications obtained
through noncompliance with these procedures are nevertheless considered
to be "lawfully acquired." No suppression of evidence. No civil suit.

In other words, "if we break our rules, tough."


--Mike








From m5 at vail.tivoli.com  Mon Feb  7 08:41:22 1994
From: m5 at vail.tivoli.com (Mike McNally)
Date: Mon, 7 Feb 94 08:41:22 PST
Subject: ADMIN: list statistics
In-Reply-To: <199402071531.KAA16820@duke.bwh.harvard.edu>
Message-ID: <9402071640.AA23668@vail.tivoli.com>



Adam Shostack writes: 
 > > Don't know what is the sign of Denmark...
 >
 > 	Its nl, for (I think) Netherlands.

Gee, that's odd.  Oh, I get it!  It's a code, explaining the relevance
to cypherpunks!

--
| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5 at tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |





From m1tca00 at FRB.GOV  Mon Feb  7 08:46:22 1994
From: m1tca00 at FRB.GOV (Tom Allard)
Date: Mon, 7 Feb 94 08:46:22 PST
Subject: A serious question of ethics
Message-ID: <9402071643.AA25305@mass6.FRB.GOV>


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

nobody at pmantis.berkeley.edu wrote:

> Ok, I'm in a bit of a quandry.  While surfing the net last week, I
> happened across an address addached to a machine that belongs the the 
> federal reserve.  No big deal.  I telnetted there on a lark, and entered 
> 'guest' for the account.  It dropped me into a shell.  It didn't ask for 
> a password.  Intrigued, I did a little looking around.  Nothing special, 
> a CDRom and about 80 accounts.  But(!!), /etc/passwd was there and 
> available and not using shadows.  No, I didn't snatch a copy.

- ------- Forwarded Message

Date:    Mon, 07 Feb 94 11:10:05 -0500 
From:    m1rcd00
To:      m1tca00
Subject: Cypherpunk...

Guest login was denied this morning...

Well, since someone seems to be home now at Minneapolis, if you wanted
to send something back to that list, I suppose it would be OK. If you
happened to mention in such a missive that the technical contact here
at the Board has no responsibility for or involvement with the Bank
machine or network involved, did not fuck up, and was not amused, the
technical contact would probably not mind.

- - --Bob


- ------- End of Forwarded Message
              

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVZFT6AudFplx0TNAQGZqgP/f8NOdlitIfBV/pAVTBviJ6IOvBArS42L
Ntq1+hiXkUbavx3FOdoQCjiQ7IGPHOsH053nY+7YnwECU/Wyatfle2d0JHVNDyxZ
ZX1DIKBT+Pkck9fa1xVkdXp86ZTJofNfbykOou+vNqENanTtDeglU9ytzNTA1/fP
1ptoUYFmoGM=
=ppC+
-----END PGP SIGNATURE-----





From hughes at ah.com  Mon Feb  7 08:56:22 1994
From: hughes at ah.com (Eric Hughes)
Date: Mon, 7 Feb 94 08:56:22 PST
Subject: ADMIN: list statistics
In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de>
Message-ID: <9402071655.AA23516@ah.com>


I got .de wrong in the stats.

.de is Germany (Deutschland)
.dk is Denmark (the incorrect identification for .de)

Eric





From hughes at ah.com  Mon Feb  7 09:06:21 1994
From: hughes at ah.com (Eric Hughes)
Date: Mon, 7 Feb 94 09:06:21 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
In-Reply-To: <199402071555.KAA04653@snark>
Message-ID: <9402071704.AA23562@ah.com>


>Indeed, a paper has been published on how to break Sun Secure RPC
>based on the idiotic decision by someone at Sun to standardise the
>modulus used. 

It wasn't standardization that was the problem.  The Sun modulus was
just too small.  My take on the idiocy was that the designers were
assuming that because they didn't know how to break such a large
modulus, that no one else did either.

>The suggestion by Mr. Cain to use a
>single generator and modulus for all traffic is astonishingly naive.

It's not naive (as such), it's just that any such modulus must be chosen with
extreme care.

Here are some very basic rules of thumb:

-- Don't use a 2^k modulus.  In addition to the exponentiation taking
place faster, they're much easier to break.

-- Use a single large prime p for the modulus of size > 600 bits.

-- Make sure that you can prove that your generator actually generates
the group.  This requires knowing the factors of p-1.

Burt Kaliski told me that he picked a D-H modulus by searching for a
pair of primes < q, p=2q+1 >.  It took a _long_, _long_ time, but it
was then easy to show that the element 2 generated the group.  It may
be that there is a clever attack based on the generator 2, but I
haven't seen one published.

Eric





From hfinney at shell.portal.com  Mon Feb  7 09:10:36 1994
From: hfinney at shell.portal.com (Hal)
Date: Mon, 7 Feb 94 09:10:36 PST
Subject: A Nice Summary of Motives for Clipper
Message-ID: <199402071710.JAA29030@jobe.shell.portal.com>


Several people on sci.crypt have pointed to the following paragraph
in Matt Blaze's report of the NSA briefing on Clipper, posted here and
in the newsgroups:

> Clipper chips should be available (to product vendors) in June.  You
> can't just buy loose chips - they have to be installed in approved
> products.  Your application interface has to be approved by NIST for
> you to get your hands on the chips.

This could explain a lot.  In particular, if they can enforce this, it
could put an end to the dreams of multiple encryption.  For months people
have been saying, "Clipper?  No problem.  I'll just encrypt with PGP then
pass it through Clipper and the Feds won't ever guess!  Ha, ha, ha!"

Maybe this won't be so easy.  From Blaze's description it sounds like
such devices wouldn't be approved.  It could be the only Clipper phones
will be ones that don't do anything to keep the Feds from picking up the
conversation.

People could still build non-Clipper encrypting phones (assuming that
the constant rumors of threatening midnight visits from NSA agents are
false), but the users of those phones could no longer blend in with the
Clipper traffic.

Hal





From mnemonic at eff.org  Mon Feb  7 09:36:22 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 09:36:22 PST
Subject: Safire Mentions NSA
In-Reply-To: <199402071604.AA18104@panix.com>
Message-ID: <199402071731.MAA00969@eff.org>


 
Duncan writes:

> In a column explaining (to the uninitiated) what the networked 
> transformation of human society means (your own Genie sans bottle) William 
> Safire mentioned the wiretap controversy.  He has done this before.
 
What's the date on this column?


--Mike







From freeman at MasPar.COM  Mon Feb  7 09:40:37 1994
From: freeman at MasPar.COM (Jay R. Freeman)
Date: Mon, 7 Feb 94 09:40:37 PST
Subject: Cryptographic funnies...
Message-ID: <9402071741.AA00535@cleo.MasPar.Com>


The 7 Feb. '94 Doonesbury involves encyphered electronic communications...





From frissell at panix.com  Mon Feb  7 09:41:22 1994
From: frissell at panix.com (Duncan Frissell)
Date: Mon, 7 Feb 94 09:41:22 PST
Subject: Safire Mentions NSA
In-Reply-To: <199402071731.MAA00969@eff.org>
Message-ID: <Pine.3.05.9402071201.A3443-9100000@panix.com>




On Mon, 7 Feb 1994, Mike Godwin wrote:

>  
> Duncan writes:
> 
> > In a column explaining (to the uninitiated) what the networked 
> > transformation of human society means (your own Genie sans bottle) William 
> > Safire mentioned the wiretap controversy.  He has done this before.
>  
> What's the date on this column?
> 
> 
> --Mike
> 
> 
Sorry, I should have been clearer.  The column I quoted appeared in
today's NYT.  07 Feb 1994.

DCF

 








From dm at hri.com  Mon Feb  7 09:46:26 1994
From: dm at hri.com (dm at hri.com)
Date: Mon, 7 Feb 94 09:46:26 PST
Subject: STEG: a real-life use for steganography
In-Reply-To: <9402041840.AA21942@ah.com>
Message-ID: <9402071745.AA01363@sparc31.hri.com>



I think the proposed scheme is a little top-heavy.  What's wrong with
clear text?

When the Shah still governed Iran, the followers of Khomeini would
smuggle his speeches into the country (in clear-text) on cassette tapes
of Western popular music.  I guess you could call this steganography
--- so many ``legitimate'' copies of the tapes were pouring into the
country, that the ``subversive'' ones were hard to find among them.  

I think the tapes actually held a few minutes' worth of the original
music, to discourage those zealous customs agents who would actually
listen to part of the tape to make sure it is authentic.

Similar things existed in the Soviet Union, where they were known as
``Magnetizdat''.

And, well, if the police have already gone to the length of
confiscating your tapes and listening to them all to find the ones
which contain Khomeini's speeches, they've also probably already got
you on the train for the Gulag, no matter what they find.





From tcmay at netcom.com  Mon Feb  7 10:00:36 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 7 Feb 94 10:00:36 PST
Subject: Defeating Clipper and Skipjack is Still Possible
In-Reply-To: <199402071710.JAA29030@jobe.shell.portal.com>
Message-ID: <199402071757.JAA17170@mail.netcom.com>


(I've changed the article title to reflect my point here.)

Hal Finney writes:

...
> This could explain a lot.  In particular, if they can enforce this, it
> could put an end to the dreams of multiple encryption.  For months people
> have been saying, "Clipper?  No problem.  I'll just encrypt with PGP then
> pass it through Clipper and the Feds won't ever guess!  Ha, ha, ha!"
> 
> Maybe this won't be so easy.  From Blaze's description it sounds like
> such devices wouldn't be approved.  It could be the only Clipper phones
> will be ones that don't do anything to keep the Feds from picking up the
> conversation.
> 
> People could still build non-Clipper encrypting phones (assuming that
> the constant rumors of threatening midnight visits from NSA agents are
> false), but the users of those phones could no longer blend in with the
> Clipper traffic.

For voice use, this may be so (but I think pre-encryption before
Clipper is still possible....see discussion at the end). But for the
forthcoming _data encryption_ use (Skipjack, etc.), I don't see how
"pre-encryption" can be detected, much less blocked, banned, or
otherwise interfered with.  After all, "data are data."

Frankly, it has always been the (presumably) impending restrictions on
data encryption that have worried me the most, because it is the
application of strong crypto to data encryption that holds the most
promise (in such things as digital money, remailers, all the stuff we
deal with here on this list). Voice scrambling has never been a high
priority for me, personally.

Requiring Skipjack encryption for all packets entering the Federal
Interstate Dataway (tm) could be a constraining hassle, but what's
_inside_ those Skipjacked packets could be arbitrary. (Even an
"entropy" filter as part of Skipjack--an implausible
complication--could easily be defeated.)

If the government requires Skipjack, I can't see any way of preventing
pre-encryption, short of "random searches" (analogous to random
searches of cargo to detect contraband, etc.). 

And I suspect some clever work could allow pre-encryption even with
Clipper. After all, if the canonical (expected) mode is for two
Clipper users to be speaking English to each other, and they start to
speak Croation, this is a crude form of encryption (security through
obscurity, for a few minutes at least). Even more so if they started
speaking their own private code. Clipper would just take the audio
signal, manipulate it as it is supposed to, send it, etc.

Thus, putting one's own cipher system in _front_ of Clipper (and
_after_ it at the receiving end, of course) should work, providing the
output of the cipher system is standard audio (constrained by the
phone system(s) used). But isn't this exactly what existing secure
phones are (like the STU-III)?

That is, nothing inside the Clipperphone need be touched or interfaced
with. Just use the Clipperphone as usual, but speak in a "language"
that cannot be deciphered by the surveillors, even if they get a
warrant to look at the Clipper keys.

Am I missing something?

--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.




From nate at VIS.ColoState.EDU  Mon Feb  7 10:10:36 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Mon, 7 Feb 94 10:10:36 PST
Subject: nate@vis.colostate.edu remailer *GONE*
Message-ID: <9402071806.AA12892@vangogh.VIS.ColoState.EDU>


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



Everyone out there, plese listen up!  The remailer at nate at vis.colostate.edu
has been taken down as a result of the posting by some anonymous
person to a local list of administrators.

I will also be taking down my GUI in Mosaic for the remailer,
but the software is still available at:
ftp://vangogh.vis.colostate.edu/pub/nate/remailer-GUI/cpremailer.tar.Z

thanks for the support, and could someone send me info about netcom
accounts?  

Thanks,

- -nate

- -- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From pmetzger at lehman.com  Mon Feb  7 10:11:23 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Mon, 7 Feb 94 10:11:23 PST
Subject: Some stuff about Diffie-Hellman (and more :-)
In-Reply-To: <9402071704.AA23562@ah.com>
Message-ID: <199402071810.NAA04869@snark>



Eric Hughes says:
> >Indeed, a paper has been published on how to break Sun Secure RPC
> >based on the idiotic decision by someone at Sun to standardise the
> >modulus used. 
> 
> It wasn't standardization that was the problem.  The Sun modulus was
> just too small.  My take on the idiocy was that the designers were
> assuming that because they didn't know how to break such a large
> modulus, that no one else did either.

Standardization was also a problem. It meant that the effort to break
one exchange could be used to break all of them at once. This seems
like a very bad thing.

Perry





From tcmay at netcom.com  Mon Feb  7 10:36:25 1994
From: tcmay at netcom.com (Timothy C. May)
Date: Mon, 7 Feb 94 10:36:25 PST
Subject: Defeating Clipper and Skipjack is Still Possible
In-Reply-To: <199402071757.JAA17170@mail.netcom.com>
Message-ID: <199402071833.KAA22964@mail.netcom.com>


Let me briefly elaborate on a point I made in my last post:

> For voice use, this may be so (but I think pre-encryption before
> Clipper is still possible....see discussion at the end). But for the
> forthcoming _data encryption_ use (Skipjack, etc.), I don't see how
> "pre-encryption" can be detected, much less blocked, banned, or
> otherwise interfered with.  After all, "data are data."

In both this data case and the Clipper voice case, I am assuming the
keys for the pre-encryption are negotiated by either prearrangement or
by some back-channel, and don't involve D-H or any other such protocol
through the Skipjack or Clipper system.

(Perhaps this situation, where a bunch of key exchange protocols must
be gone through before communication takes place, is what Hal Finney
was referring to when he said that the Clipper proposal looks like it
will make multiple encryption impossible.)

Most of my (few) encrypted communications are by this kind of
prearrangement, with PGP being the most obvious case of this, and so a
multiple encryption scheme is workable. With voice encryption, I guess
the Clipper system will not be very cooperative with D-H and similar
protocols. 

But it will still be possible:

1. Use the Clipperphone to establish who one is communicating with.
Alice and Bob thus start talking to each other.

2. Alice says: "Switch to PGP-Voice with my P-K" (and so on).

3. Bob and Alice are thus communicating with PG-Voice, with Clipper
doing a further encryption.

If the Feds get a warrant to get the Clipper keys, then all they get
is PGP-Voice-encrypted junk.

Clipper then serves the admirable purpose of _covering_ the further
use of encryption!


--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.




From nobody at pmantis.berkeley.edu  Mon Feb  7 10:40:37 1994
From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu)
Date: Mon, 7 Feb 94 10:40:37 PST
Subject: A serious question of ethics
Message-ID: <9402071839.AA15102@pmantis.berkeley.edu>


On Mon, 7 Feb 1994, Tom Allard wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> nobody at pmantis.berkeley.edu wrote:
> 
> > Ok, I'm in a bit of a quandry.  While surfing the net last week, I
> > happened across an address addached to a machine that belongs the the 
> > federal reserve.  No big deal.  I telnetted there on a lark, and entered 
> > 'guest' for the account.  It dropped me into a shell.  It didn't ask for 
> > a password.  Intrigued, I did a little looking around.  Nothing special, 
> > a CDRom and about 80 accounts.  But(!!), /etc/passwd was there and 
> > available and not using shadows.  No, I didn't snatch a copy.
> 
> - ------- Forwarded Message
> 
> Date:    Mon, 07 Feb 94 11:10:05 -0500 
> From:    m1rcd00
> To:      m1tca00
> Subject: Cypherpunk...
> 
> Guest login was denied this morning...
> 
> Well, since someone seems to be home now at Minneapolis, if you wanted
> to send something back to that list, I suppose it would be OK. If you
> happened to mention in such a missive that the technical contact here
> at the Board has no responsibility for or involvement with the Bank
> machine or network involved, did not fuck up, and was not amused, the
> technical contact would probably not mind.
> 
> - - --Bob
> 
> 
> - ------- End of Forwarded Message

Does that mean that I no longer should report the open system (I don't 
dare telnet there to find out if it is the same one)?

Also, and I'm purely curious, what actually became of my anonymous 
report, and do I need to be worried about SS agents in dark sunglasses 
coming to my home and dragging me away?  (Truely worried and scared)





From mg5n+ at andrew.cmu.edu  Mon Feb  7 10:46:24 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Mon, 7 Feb 94 10:46:24 PST
Subject: 
In-Reply-To: <199402071615.LAA04694@snark>
Message-ID: <0hJciae00VojIMAkQt@andrew.cmu.edu>


"Perry E. Metzger" <pmetzger at lehman.com> wrote:

> nobody at shell.portal.com says:
> > I'm moving to Oceania.
>
> Not all of us have the luxury of moving to non-existant places --
> most of us are stuck living in real ones.

Yep...  but if the Atlantis Project succeeds, I would probably move
there, assuming I could find a good source of income...





From schneier at chinet.com  Mon Feb  7 11:16:25 1994
From: schneier at chinet.com (Bruce Schneier)
Date: Mon, 7 Feb 94 11:16:25 PST
Subject: Applied Cryptography - Errata Version 1.5.5
Message-ID: <m0pTbMC-0006J5C@chinet.chinet.com>



                  APPLIED CRYPTOGRAPHY

                         ERRATA
              Version 1.5.5 - February 7, 1994


This errata includes all errors I have found in the first and
second printings of the book, including minor spelling and
grammatical errors.  Please distribute this errata sheet to
anyone else who owns a copy of the book.


Page xvii:  Third paragraph, first line:  "Part IV" should be
"Part III".

Page 1:  First paragraph, fourth line:  "receiver cannot
intercept" should be "intermediary cannot intercept".

Page 6:  Sixth and seventh lines:  "against symmetric" should be
"against a symmetric".

Page 8:  Second paragraph, first line:  "q code" should be "a
code".

Page 10:  Second paragraph, fifth line:  Reference "[744]" should
be "[774]".

Page 11:  Second paragraph:  "The rotations of the rotors are a
Caesar Cipher" should be "Each rotor is an arbitrary permutation
of the alphabet".

Page 13:  Third paragraph:  Delete parenthetical remark.  

Page 13:  Fifth paragraph, first line:  "Shift the key" should be
"shift the ciphertext".

Page 15:  Section 1.3, first line:  "Throughout the book use"
should be "Throughout the book I use".

Page 25:  "Attacks Against Protocols," first paragraph:  "the
protocol iself" should be "the protocol itself".

Page 28:  Third paragraph, third and fourth sentences should be
"How to put mail in a mailbox is public knowledge.  How to open
the mailbox is not public knowledge."

Page 30:  Fourth line:  "symmetric cryptosystems: by distributing
the key" should be "symmetric cryptosystems: distributing the
key".

Page 30:  "Attacks Against Public Key Cryptography," second
paragraph:  "The database also has to be protected from access by
anyone" should be "The database also has to be protected from
write access by anyone".  Also:  "substitute a key of his
choosing for Alice's" should be "substitute a key of his own
choosing for Bob's".

Page 30:  Last line:  "substitute that key for his own public
key" should be "substitute his own key for that public key".

Page 32:  Ninth line:  Delete the word "encrypted".

Page 34"  "Signing Documents with..."  First sentence:  "too
inefficient to encrypt long documents" should be "too inefficient
to sign long documents".  

Page 36:  Second line:  "document encrypted with" should be
"document signed with".

Page 36:  "Multiple Signatures," step (2):  "Alice or Bob sends"
should be "Alice sends".

Page 38:  Fifth paragraph:  "V_X = E_X and that S_X = D_X" should
be "V_X = E_X and S_X = D_X".

Page 40:  Third line:  "computer can exist" should be "computer
can be".

Page 40:  Second paragraph:  Delete "should be runs of zeros and
the other half should be runs of ones; half the runs".

Page 50:  Step (3):  "With Alice's public key" should be "with
"Alice's" public key."

Page 51:  Step 5:  "with what he received from Bob" should be
"with what he received from Alice".

Page 55:  Step (2):  At the end of the step, add:  "He sends both
encrypted messages to Alice."

Page 69:  Last line:  "tried to recover her private key" should
be "tries to recover Alice's private key".

Page 73:  "Bit Commitment Using One-Way Functions," last
paragraph:  Second and third sentences should be "Alice cannot
cheat and find another message (R_1,R_2',b'), such that
H(R_1,R_2',b') = H(R_1,R_2,b).  If Alice didn't send Bob R_1,
then she could change the value of both R_1 and R_2 and then the
value of the bit."

Page 77:  "Flipping Coins into a Well," first line:  "neither
party learns the result" should be "Alice and Bob don't learn the
result".  Third line:  parenthetical remark should be:  "Alice in
all three protocols".

Page 78:  Step (1):  "Alice, Bob, and Carol all generate" should
be "Alice, Bob, and Carol each generate".

Page 90:  Last paragraph:  "step (3)" should be "step (4)".

Page 91:  Second line:  "step (3)" should be "step (4)".

Page 93:  "Blind Signatures," first line:  "An essential in all"
should be "An essential feature in all".

Page 98:  First paragraph after protocol, fourth line:  "to
determine the DES key with the other encrypted message" should be
"to determine the DES key that the other encrypted message was
encrypted in."

Page 115:  "Protocol #2," third paragraph:  "together determine
if f(a,b)" should be "together determine f(a,b)".

Page 131:  Fifth paragraph:  "each capable of checking 265
million keys" should be "each capable of checking 256 million
keys".

Page 133:  Table 7.2:  Third number in third column, "1.2308"
should be "0.2308".

Page 134:  Table 7.3:  "1027" should be "10^27".

Page 139:  Indented paragraph:  "could break the system" should
be "could break the system within one year".

Page 141:  "Reduced Keyspaces," last sentence:  "don't expect
your keys to stand up" should be "don't expect short keys to
stand up".

Page 148:  Eighth line:  "2^24" should be "2^32".

Page 156:  Second paragraph:  "blocks 5 through 10" should be
"blocks 5 through 12".

Page 157:  Figure 8.2:  "IO" should be "IV".

Page 159:  Figure 8.3:  "IO" should be "IV".

Page 161:  Figure 8.5:  "Decrypt" should be "Encrypt".

Page 162:  Figure 8.6:  "Encipherment" diagram:  "Decrypt" should
be "Encrypt".  Input should be "p_i" instead of "b_i", and output
should be "c_i" instead of "p_i".

Page 164:  Figure 8.7:  "IO" should be "IV".

Page 165:  Last equation:  There should be a "(P)" at the end of
that equation.

Page 167:  Second paragraph, last line:  "2^(2n-1)" should be
"2^(2n-14)".

Page 168:  Figure 8.8:  This figure is wrong.  The encryption
blocks in the second row should be off-centered from the
encryption blocks in the first and third row by half a block
length.

Page 174:  Middle of page:  Equations should be:
   k_2 = c'_2 XOR p', and then p_2 = c_2 XOR k_2
   k_3 = c'_3 XOR p_2, and then p_3 = c_3 XOR k_3
   k_4 = c'_4 XOR p_3, and then p_4 = c_4 XOR k_4

Page 175:  Last paragraph, second line:  "acting as the output
function" should be "acting as the next-state function".

Page 177:  Diffie's quote, second to last line:  "proposal to
built" should be "proposal to build".

Page 178:  Figure 8.20:  In "Node 2", the subscripts should be
"D_2" and "E_3".

Page 191:  First paragraph:  "3.5" should be "6.8".  "0.56"
should be "0.15".  "EBCDIC (Extended Binary-Coded Decimal
Interchange Code)" should be "BAUDOT".  "0.30" should be "0.76". 
"0.70" should be "0.24".

Page 193:  Second sentence:  "Unicity distance guarantees
insecurity if it's too small, but does guarantee security if it's
high" should be "Unicity distance guarantees insecurity if it's
too small, but does not guarantee security if it's high."

Page 198:  Fourth paragraph from bottom, second sentence:  "If a
and b are positive and a is less than n, you can think of a as
the remainder of b when divided by n" should be "If a and b are
positive and b is less than n, you can think of b as the
remainder of a when divided by n".

Page 199:  Middle of the page:  In the sentence "Calculating the
power of a number modulo a number", a should not be italicized.

Page 201:  First line of code:  Remove "assuming x and y are >
0".

Page 202:  Middle of the page:  In the sentence "Now, how do you
go about finding the inverse of a modulo n?" "a" should be
italicized.

Page 207:  "Jacobi Symbol: formula:  Variable "h" should be "a".

Page 209:  Fourth paragraph:  "If that value does not equal q"
should be "If that value does not equal 1".

Page 214:  Last line:  "n" should be "p".  Lines 29, 30, and 31: 
"r" should be "a", and "gcd(p,r)" should be gcd(a,p)".

Page 215:  Lehman test, step 5:  All three "(n-1)/2" should be
exponents.

Page 217:  There should be an open parenthesis in front of the
second "ln" in both exponents.  Sixth paragraph:  "Guassian"
should be "Gaussian".

Page 222:  "Validation and Certification of DES Equipment," first
line:  "As part of the standard, the DES NIST" should be "As part
of the DES standard, NIST".

Page 223:  Second to last paragraph, last line.  Reference
"[472]" should be "[473]".

Page 225:  Figure 10.2:  L_i is taken from R_(i-1) before
expansion, not after.  And "L_(i)-1" should be "L_(i-1)".

Page 228:  Fourth paragraph, last line:  "0 to 16" should be 0 to
15".

Page 228:  Fifth paragraph should read:  "For example, assume
that the input to the sixth S-box (that is, bits 31 through 36 of
the XOR function) are 110010.  The first and last bits combine to
form 10, which corresponds to row 3 of the sixth S-box.  The
middle four bits combine to form 1001, which corresponds to
column 9 of the same S-box.  The entry under row 3, column 9 of
S-box 6 is 0.  (Remember, we count rows and columns from 0, and
not from 1.)  The value 0000 is substituted for 110010.

Page 233:  The second two weak keys should be:
   1F1F 1F1F 0E0E 0E0E     00000000 FFFFFFFF
   E0E0 E0E0 F1F1 F1F1     FFFFFFFF 00000000

Page 238:  Next to last line before "Additional Results": 
"NSA's" should be "IBM's".

Page 238:  "Differential Cryptanalysis," third paragraph: 
"(1/16)^2" should be "(14/64)^2".

Page 239:  Figure 10.4:  "14/16" should be "14/64".

Page 242:  Table 10.14:  In "XORs by additions" line, "2^39,2^3"
should be "2^39,2^31".  In "Random" line, "2^21" should be"2^18-
2^20".  In "Random permutations" line, "2^44-2^48" should
be"2^33-2^41".

Page 245:  Line 11"  "8 bits is" should be "8 bits was".

Page 247:  Section heading, "Cryptanalysis of the Madryga" should
be "Cryptanalysis of Madryga".

Page 250:  The two functions should be:
   S_0(a,b) = rotate left 2 bits ((a+b) mod 256)
   S_1(a,b) = rotate left 2 bits ((a+b+1) mod 256)
Note the difference in parentheses.

Page 250:  Figure 11.4:  Note that a is broken up into four 8-bit
substrings, a_0, a_1, a_2, and a_3.

Page 251:  Figure 11.6:  The definitions for S_0 and S_1 are
incorrect ("Y = S_0" and "Y = S_1").  See corrections from
previous page.  Also, "S1" should be "S_1".

Page 254:  "Security of REDOC III," second sentence. Delete
clause after comma:  "even though it looks fairly weak."

Page 262:  Figure 11.9:  There is a line missing.  It should run
from the symbol where Z_5 is multiplied with the intermediate
result to the addition symbol directly to the right.

Page 263:  Table 11.1:  The decryption key sub-blocks that are
Z_n^(m)-1 should be Z_n^((m)-1).

Page 265:  Figure 11.10:  There is a line missing.  It should run
from the symbol where Z_5 is multiplied with the intermediate
result to the addition symbol directly to the right.

Pages 266-7:  Since the publication of this book, MMB has been
broken.  Do not use this algorithm.

Page 267:  Sixth line from bottom:  Reference should be "[256]".

Page 269:  "Skipjack."  First paragraph.  Reference should be
"[654]".

Page 270:  "Karn."  Third paragraph.  Last sentence:  "append C_r
to C to produce" should be "append C_r to C_l to produce".

Page 271:  Middle of the page:  "(for example, MD2, MD5, Snefru"
should be "(for example, MD2, MD4, Snefru".

Page 272:  Second to last line:  "But it is be analyzed" should
be "but it is being analyzed".

Page 275:  Second to last paragraph:  "Using 1028 bits" should be
"using 1024 bits".

Page 277:  First lines:  The correct street address is "310 N
Mary Avenue" and the correct telephone number is "(408)
735-5893".

Page 281:  Third paragraph:  The correct street address is "310 N
Mary Avenue" and the correct telephone number is "(408)
735-5893".

Page 286:  Second to last line:  "Eve wants to Alice to" should
be "Eve wants Alice to".

Page 287:  Last line:  Wiener's attack is misstated.  If d is
less than one-quarter the length of the modulus, then the attack
can use e and n to find d quickly.

Page 288:  The correct street address is "310 N Mary Avenue" and
the correct telephone number is "(408) 735-5893".

Page 289:  The correct street address is "310 N Mary Avenue" and
the correct telephone number is "(408) 735-5893".

Page 295:  First line:  "t random integers fewer than n" should
be "t random numbers less than n".

Page 301:  Middle of the page:  Delete the sentence "Since the
math is all correct, they do this step."

Page 302:  Fourth line from bottom:  "a" should be in italics.

Page 305:  Third paragraph, parenthetical remark:  "NIST claimed
that having DES meant that both that both the algorithm and the
standard were too confusing" should be "NIST claimed that having
DES mean both the algorithm and the standard was too confusing".

Page 306:  Eighth line:  "cryptographers' paranoia" should be
"paranoia".

Page 307:  "Description of the Algorithm":  "p = a prime number
2^L bits long" should be "p = a prime number L bits long".

Page 309:  Third line:  "random k values and then precompute r
values" should be "random k-values and then precompute r-values".

Page 314:  Protocol, step (1):  "when" should be "where".

Page 319:  There should be a blank line before "discrete
logarithm:" and another before "factoring:".

Page 322:  Second paragraph:  "over 500 pairs of people" should
be "253 pairs of people".

Page 330:  Definitions of FF, GG, HH, and II are wrong.  These
are correct:
   FF:  "a = b + ((a + F(b,c,d) + M_j + t_i) <<< s)"
   GG:  "a = b + ((a + G(b,c,d) + M_j + t_i) <<< s)"
   HH:  "a = b + ((a + H(b,c,d) + M_j + t_i) <<< s)"
   II:  "a = b + ((a + I(b,c,d) + M_j + t_i) <<< s)"

Page 336:  "HAVAL," sixth line:  "160, 92, 224" should be "160,
192, 224".

Page 339:  "LOKI Single Block":  In computation of Hi, drop final
"XOR M_i". 

Page 340:  "Modified Davies-Meyer":  In computation of H_i, "M_i"
should be subscripted.

Page 342:  "Tandem Davies-Meyer":  In computation of W_i, "M_i"
should be subscripted.

Page 345:  "Stream Cipher Mac", first line:"  "A truly elegant
MDC" should be "A truly elegant MAC".

Page 347:  Formula:  "aX_(n1)" should be "aX_(n-1)".

Page 347:  Second paragraph:  "(For example, m should be chosen
to be a prime number.)" should be "(For example, b and m should
be relatively prime.)"

Page 351:  Second line of text:  "they hold current" should be
"they hold the current".

Page 353:  Tenth line (in source code):  "< 31" should be "<<
31".

Page 353:  Second paragraph:  "are often used from stream-cipher"
should be "are often used for stream-cipher".

Page 356:  Source code:  "ShiftRegister = (ShiftRegister ^ (mask
>> 1))" should be "ShiftRegister = ((ShiftRegister ^ mask) >>
1)".

Page 360:  Equation should not be "l(2^1-1)^(n-1)", but "l(2^l-
1)^(n-1)".

Page 362:  Figure 15.10:  "LFSR-B" should be "LFSR-A" and vice
versa.  The second "a(t+n-1)" should be "a(t+n-2)", and the
second "b(t+n-1)" should be "b(t+n-2)".

Page 363:  Fourth paragraph: "cellular automaton, such as an
CSPRNG" should be "cellular automaton as a CSPRNG".

Page 365:  "Blum-Micali Generator":  In the equation, "x_i"
should be an exponent of a, not a subscript.

Page 367:  Paragraph 5:  "Ingmar" should be "Ingemar".

Page 370:  "Using "Random Noise," first paragraph, last line: 
"output 2 as the event" should be "output 0 as the event".

Page 371:  Sixth line:  "access/modify times of/del/tty" should
be "access/modify times of /dev/tty".

Page 371:  "Biases and Correlations," third line:  "but there
many types" should be "but there are many types".

Page 391:  Second protocol, step (1):  "in his implementation of
DES" should be "in his implementation of DSS".  Next sentence: 
"such that r is either q quadratic" should be "such that r is
either a quadratic".

Page 402:  Line 18:  "2^t" should be "2^(-t)".

Page 407:  Step (5):  "i<j" should be i>j".

Page 417:  Last paragraph:  "Kerberos is a service Kerberos on
the network" should be "Kerberos is a service on the network".

Page 421:  Figure 17.2:  In the top message "C" should be lower
case.

Page 435:  "RIPEM":  "Mark Riorden" should be "Mark Riordan".

Page 436:  "Pretty Good Privacy," third paragraph:  Delete fourth
sentence:  "After verifying the signature...."

Page 436:  Pretty Good Privacy is not in the public domain.  It
is copyrighted by Philip Zimmermann and available for free under
the "Copyleft" General Public License from the Free Software
Foundation.

Page 437:  Fifth line:  Delete "assess your own trust level".

Page 437:  "Clipper,"  Second paragraph:  reference should be
"[473]".  Fourth paragraph:  references should be
"[473,654,876,271,57]".

Page 438:  Middle of page:  reference should be "[654]". 
"Capstone," first paragraph:  reference should be "[655]".

Page 445:  The IACR is not the "International Association of
Cryptographic Research," but the "International Association for
Cryptologic Research."  This is also wrong in the table of
contents.

Source Code:  The decrement operator, "--", was inadvertently
typesetted as an m-dash, "-".  This error is on pages 496, 510,
511, 523, 527, 528, 540, and 541.  There may be other places as
well.

Page 472:  "for( i = 0; i<<16; i++ )" should be "for( i = 0;
i<16; i++ )"

Page 473:  Function "cpkey(into)". "while (from endp)" should be
"while (from < endp)".

Page 508:  Line 8:  "union U_INITseed" should be "union U_INIT
seed".

Page 558:  "#defineBOOLEAN int" should be "#define BOOLEAN int",
"#defineFALSE0" should be "#define FALSE 0", and
"#defineTRUE(1==1)" should be "#define TRUE (1==1)".

Page 564:  "#define BOOLEANint" should be "#define BOOLEAN int",
"#define FALSE0" should be "#define FALSE 0", and
"#defineTRUE(1==1)" should be "#define TRUE (1==1)".

Page 569:  "rand() > 11" should be "rand() >> 11".

Page 569:  In "G13.H", "#define G13int" should be "#define G13
int".

Page 572:  Reference [45]:  "Haglen" should be "Hagelin".

Page 576:  References [136] and [137]:  "Branstead" should be
"Branstad."

Page 578:  Reference [184]  "Proof that DES Is Not a Group"
should be "DES Is Not a Group."  The correct page numbers are
512-520.

Page 589:  Reference [475]:  The publisher should be E.S. Mittler
und Sohn, and the publication date should be 1863.

Page 601:  References [835] and [836]:  "Branstead" should be
"Branstad."

Page 602:  Reference [842]:  "Solvay" should be "Solovay".

Page 603:  Reference [878]:  "Weiner" should be "Wiener."


For a current errata sheet, send a self-addressed stamped
envelope to:  Bruce Schneier, Counterpane Systems, 730 Fair Oaks
Ave., Oak Park, IL  60302; or send electronic mail to:
schneier at chinet.com.


From mnemonic at eff.org  Mon Feb  7 12:16:26 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 12:16:26 PST
Subject: Newspaper coverage of Administration encryption announcements (fwd)
Message-ID: <199402072012.PAA04958@eff.org>


Forwarded message:


From hughes at ah.com  Mon Feb  7 12:31:28 1994
From: hughes at ah.com (Eric Hughes)
Date: Mon, 7 Feb 94 12:31:28 PST
Subject: DOJ procedures relating to Clipper Chips and key escrow
In-Reply-To: <199402071624.LAA27967@eff.org>
Message-ID: <9402072025.AA23949@ah.com>


>"These procedures do not create, and are not intended to create,
>any substantive rights for individuals intercepted through
>electronic surveillance, and noncompliance with these procedures
>shall not provide the basis for any motion to suppress or other
>objection to the introduction of electronic surveillance evidence
>lawfully acquired."

This reminds me a lot of the language used when describing the changes
in FOIA policy, which was something like "The agencies are supposed to
be good, but if they're not, this change doesn't change your ability
to do anything about it."

Is this a Clinton administration policy to make such feel-good,
govern-bad pronouncements?

Eric





From nowhere at bsu-cs.bsu.edu  Mon Feb  7 12:36:27 1994
From: nowhere at bsu-cs.bsu.edu (Chael Hall)
Date: Mon, 7 Feb 94 12:36:27 PST
Subject: MAIL: questionnaire
In-Reply-To: <9402051721.AA05442@arcadien.owlnet.rice.edu>
Message-ID: <9402072035.AA22679@bsu-cs.bsu.edu>


Karl Barrus writes:

>bsu-cs:
>Run by Chael Hall.
>Contact at same address
Machine:  University departmental machine (fairly secure)
Security:  syslog file can be read

>chaos:
>Run by Chael Hall.
>Contact at same address
Machine:  Privately owned (secure)
Security:  syslog file can only be read by root (me) [used for statistics]
Contact nowhere at chaos.bsu.edu or remailer-admin at chaos.bsu.edu

(both)
Software:  C program written by myself.  Source available upon request.
Policy:  Under construction

Chael

--
Chael Hall
nowhere at bsu-cs.bsu.edu
nowhere at chaos.bsu.edu





From wcs at anchor.ho.att.com  Mon Feb  7 12:40:37 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Mon, 7 Feb 94 12:40:37 PST
Subject: DOJ procedures relating to Clipper Chips and key escrow
Message-ID: <9402072039.AA26355@anchor.ho.att.com>


Mike Godwin writes:
> One of the interesting passages comes at the end of the DOJ memo
> about obtaining Clipper keys pursuant to an interception:
> 
> "These procedures do not create, and are not intended to create,
> any substantive rights for individuals intercepted through
> electronic surveillance, and noncompliance with these procedures
> shall not provide the basis for any motion to suppress or other
> objection to the introduction of electronic surveillance evidence
> lawfully acquired."
> 
> What this means, apparently, is that keys or communications obtained
> through noncompliance with these procedures are nevertheless considered
> to be "lawfully acquired." No suppression of evidence. No civil suit.
> 
> In other words, "if we break our rules, tough."

I thought that was particularly amusing as well.
On the other hand, the mere fact that it says it doesn't mean
it invalidates any other privacy laws or rules about illegal 
surveillance or exclusion of evidence, though it does mean you
need to argue a lot harder to get a judge to agree.

# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465





From mnemonic at eff.org  Mon Feb  7 12:41:44 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 12:41:44 PST
Subject: DOJ procedures relating to Clipper Chips and key escrow
In-Reply-To: <9402072025.AA23949@ah.com>
Message-ID: <199402072040.PAA05318@eff.org>


 
Eric writes:

> This reminds me a lot of the language used when describing the changes
> in FOIA policy, which was something like "The agencies are supposed to
> be good, but if they're not, this change doesn't change your ability
> to do anything about it."
> 
> Is this a Clinton administration policy to make such feel-good,
> govern-bad pronouncements?

If anything, the Clinton announcements are far more generous than those of
Reagan and Bush.


--Mike







From wcs at anchor.ho.att.com  Mon Feb  7 12:50:37 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Mon, 7 Feb 94 12:50:37 PST
Subject: Bogus paper on TEMPEST floating around
Message-ID: <9402072047.AA26538@anchor.ho.att.com>


This bogus paper with lots of misinformation about TEMPEST is still around,
though I'm surprised to see it on a NIST machine.  (FTP didn't want to
connect this morning, so I can't be sure it's still there.)
Papers by the fictitious Hagbard Celine can't always be trusted,
though they make good rolling papers if you print them out :-)
But it's clearly a bunch of Discordian Disinformation.

Yes, some of the TEMPEST specs are classified,  it's perfectly legal
to disseminate the publicly available information and technology,
apply it, and use it, and do anything you want to make your equipment quiet.
Even the expansion of the acronym given in the paper was bogus,
and it went downhill from there.

# Bill Stewart  AT&T Global Information Solutions, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465





From gnu  Mon Feb  7 13:14:48 1994
From: gnu (John Gilmore)
Date: Mon, 07 Feb 94 13:14:48 -0800
Subject: [whitfield.diffie@Eng.Sun.COM: Preliminary remarks]
Message-ID: <9402072114.AA20669@toad.com>

------- Forwarded Message

To: gnu at toad.com
From: whitfield.diffie at Eng.Sun.COM




From koontzd at lrcs.loral.com  Mon Feb  7 13:20:37 1994
From: koontzd at lrcs.loral.com (David Koontz )
Date: Mon, 7 Feb 94 13:20:37 PST
Subject: DOJ procedures relating to Clipper Chips and key escrow
Message-ID: <9402072119.AA10397@io.lrcs.loral.com>



> From: hughes at ah.com (Eric Hughes)

>Is this a Clinton administration policy to make such feel-good,
>govern-bad pronouncements?

Double plus ++ungood.

Needless to say, I had trouble parsing this.





From mg5n+ at andrew.cmu.edu  Mon Feb  7 13:36:29 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Mon, 7 Feb 94 13:36:29 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <199402072012.OAA10440@alpha1.csd.uwm.edu>
Message-ID: <AhJfDLi00awF4FbkxC@andrew.cmu.edu>


Since the subject came up, I'll explain it to those of you who hadn't
heard of the Atlantis Project:

The Atlantis Project is a group in Las Vegas which is trying to build a
floating city in the Caribbean sea.  Their new city would be an
independant nation called Oceania.  The country would have a limited
government, and their constitution outlines many specific rights given
to the people, among them, the right to use cryptography.  You can email
them at oceania at world.std.com and ask for more info.





From mnemonic at eff.org  Mon Feb  7 14:06:30 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 14:06:30 PST
Subject: EFF Wants You (to add your voice to the crypto fight)
Message-ID: <199402072201.RAA06559@eff.org>


Forwarded message:


From hayden at krypton.mankato.msus.edu  Mon Feb  7 14:16:29 1994
From: hayden at krypton.mankato.msus.edu (Robert A. Hayden)
Date: Mon, 7 Feb 94 14:16:29 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <AhJfDLi00awF4FbkxC@andrew.cmu.edu>
Message-ID: <Pine.3.89.9402071653.A16185-0100000@krypton.mankato.msus.edu>


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

On Mon, 7 Feb 1994, Matthew J Ghio wrote:

> Since the subject came up, I'll explain it to those of you who hadn't
> heard of the Atlantis Project:
> 
> The Atlantis Project is a group in Las Vegas which is trying to build a
> floating city in the Caribbean sea.  Their new city would be an
> independant nation called Oceania.  The country would have a limited
> government, and their constitution outlines many specific rights given
> to the people, among them, the right to use cryptography.  You can email
> them at oceania at world.std.com and ask for more info.

Sounds kool, in a utopian sort of way.

Of course, the U.S. will immediately declare they a national threat and 
bomb them back to the stone age.  :-)

____        Robert A. Hayden          <=> hayden at krypton.mankato.msus.edu
\  /__          -=-=-=-=-             <=>          -=-=-=-=-
 \/  /   Finger for Geek Code Info    <=> In the United States, they
   \/  Finger for PGP 2.3a Public Key <=> first came for us in Colorado...
- -=-=-=-=-=-=-=-
(GEEK CODE 1.0.1)  GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
		       n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVa94p3BsrEqkf9NAQF9gQP/f71hQtnsZUYA8sxABa69RItyA8pOQ2QQ
F9y9cuk0QKzabfEo6uColYpdtk0AVt57pFh+bSivUNjrOYfdj42J6MZf2eT2mDt9
O7JhmdP9hSPIMx2IdfEq+aCOF0SO47lSmJsqct51o5TUvCx0mC9SLTBqWT3ZCbcS
Ho7lrI4b0SY=
=k2vE
-----END PGP SIGNATURE-----





From qwerty at netcom.com  Mon Feb  7 14:30:40 1994
From: qwerty at netcom.com (Xenon)
Date: Mon, 7 Feb 94 14:30:40 PST
Subject: Nate's Remailer Shutdown.
Message-ID: <199402072231.OAA10521@mail.netcom.com>


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

I am responding publicly to a letter I got from Nate about his wanting to
know who sent the naughty mail to the subnet-
managers at yuma.acns.colostate.edu. It was remailed from somewhere to qwerty,
and then through Nate's remailer. For gossip's sake, I'd sure like to see
what it said :-).

Sorry to hear about your remailer. It's good for all of us to have such
"minor" problems come up and be dealt with. I am keeping no logs except a
counter. This isn't a policy, it's just a decision for now. However, if the
70 people on the list care to they can certainly contact Netcom and ask for
a copy of their sendmail logs for that day. I'm sure if the mail was sent
to a police address saying "Nah nah you can't find me I'm selling guns to
little kids." then this would happen. I know that with my software (Hal's
updated), once such a problem happens, I can just block that outgoing
address. This isn't exactly a perfect solution, but I don't WANT a perfect
solution. This isn't IRAQ, no matter how global the internet is. I'm not
sure how to block an incoming address from say Detweiler.

My model is  based on the postal service. Why is e-mail supposed to be so
much more accountable? With snail mail someone can send a real bomb, not a
wimpy mail bomb. And yet it is perfectly legal to leave out a return
address. Qwerty is a mailbox. An inanimate object. I do not like the
internet. I like the postal service. You NEVER see someone like Detweiler
abusing snail mail anonymity with the purpose of trying to shut down or
change the policy of the US Postal Service! I think remailers should be
able to strip the From line completely, but as I pointed out, this would be
"frowned upon", and may not even be feasible to do vigorously. I thought
the internet was anarchic and free. Fun and creative. Oops. Oh well. Again,
"You ain't PUNKS, if you timidly play by the rules of others." I'm not
talking illegality. In fact, I'm talking life, liberty, and pursuit of
happiness. Insert constituion and Bill of Rights buzzwords here.

I think it might be nice for the remailers to block certain outgoing
address TYPES, such as "subnet-manager", but I don't know which others
since I'm new around here.

The information is available on Netcom's logs. It probably just points to
another remailer. Welcome to the postal service. Same as it ever was. Don't
blame the mailman, and especially not the mailbox. The day all mailboxes
have cameras atop them and require retinal ID before they take your logged
mail is the day people realize how bad it is out here in cyberspace.

    8,      8      ,8     8,      8      ,8    8,      8      ,8
    Yb     d8b     dY     Yb     d8b     dY    Yb     d8b     dY
    `8,   ,8'8,   ,8'     `8,   ,8'8,   ,8'    `8,   ,8'8,   ,8'
     Yb   dY Yb   dY       Yb   dY Yb   dY      Yb   dY Yb   dY
     `8, ,8' `8, ,8        `8, ,8' `8, ,8'      `8, ,8' `8, ,8'
      Y8 8Y   Y8 8Y         Y8 8Y   Y8 8Y        Y8 8Y   Y8 8Y
       YaY     YaY           YaY     YaY          YaY     YaY
       `8'     `8' O R L D   `8'     `8' I D E    `8'     `8' I R E T A P

  -=Xenon=-

P.S. "Get Off the Internet and Write Us a Real Encryptor." Your species
desires PGP to have a random data block output format. Now.

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVZ5vASzG6zrQn1RAQEEMwQAwejxfCFLdKy/jsggYfU1qANBXYe17oTt
o31cMzEsFeS1cSyrexEObohZM6HKZefM34SMj5saaxn0HsR+sT3Xk2i+VIqPfBJf
K17wa1jnOQDc77UYGy+f3KulNkHstCeE05D2GGA471NirwW8/YrC2tGKe4TqrFLP
XEtvD9mPO2M=
=huRE
-----END PGP SIGNATURE-----





From mnemonic at eff.org  Mon Feb  7 14:31:29 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 14:31:29 PST
Subject: reno_key_escrow.statement (fwd)
In-Reply-To: <9402071501.AA11306@mail.wm.edu>
Message-ID: <199402072231.RAA07108@eff.org>


 
Trotter writes:

> Thanks to Mike Godwin for forwarding the announcement about the
> Clipper chip stuff.  I am not a Constitutional law person or
> criminal preceedure person, but if I understand this proposal
> correctly, it does not require a member of the judiciary to be
> involved.

Not at the key-escrow phase, no. But you have to have a valid search
warrant or authorization order in hand before you can go to the escrow
agencies and request the partial keys.

Here's the relevant language:

> > ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS
> >
> > When an authorized government agency encounters suspected key-
> > escrow encryption, a written request will have to be submitted to
> > the two escrow agents. The request will, among other things, have
> > to identify the responsible agency and the individuals involved;
> > certify that the agency is involved in a lawfully authorized
                                           ^^^^^^^^^^^^^^^^^^^^^
> > wiretap; specify the wiretap's source of authorization and its
                                   ^^^^^^^^^^^^^^^^^^^^^^^
> > duration; and specify the serial number of the key-escrow
> > encryption chip being used. In every case, an attorney involved in
> > the investigation will have to provide the escrow agents assurance
> > that a validly authorized wiretap is being conducted.

The reason that Reno doesn't just say "a court-ordered wiretap" is
that there are some emergency circumstances under which wiretap
authorization can be gotten in advance of approval by a neutral
magistrate. Both the Wiretap Act and the Foreign Intelligence Surveillance
Act make provisions for such emergencies. 

Eventually, such emergency wiretaps do have to be reviewed by a
magistrate, however. In the Wiretap Act, and, I believe, in FISA, 
the time limit is 48 hours.


--Mike






From mnemonic  Mon Feb  7 12:10:49 1994
From: mnemonic (Mike Godwin)
Date: Mon, 7 Feb 1994 15:10:49 -0500 (EST)
Subject: Newspaper coverage of Administration encryption announcements
Message-ID: <199402072010.PAA04906@eff.org>


The Washington Post, the New York Times, and the Wall Street Journal have
all published stories over the last three days concerning the
Administration's announcement on Friday, Feb. 5, 1994, that it will
continue to deploy the controversial "Clipper Chip" encryption technology
and will not significantly change its export controls.

>From the Post on Saturday:

"That means the administration will continue long-standing restrictions on
exports of powerful encryption devices that the NSA cannot crack, and
continue to encourage use of NSA-developed encryption gear, called the
"Clipper chip," by all U.S. firms. The Clipper Chip makes it relatively
easy for the government to eavesdrop on encrypted communications....

"Further, government officials said, the administration is expected in a
few weeks to endorse an FBI proposal that U.S. telecommunications firms be
required to guarantee law enforcement agencies' ability to tape phone and
computer lines regardless of where the technology goes.

"At the core of these high-tech disputes lies a fundamental conflict
between Americans' cherished privacy rights and the government's
investigative needs."

>From the Times on Saturday:

"But the Administration's action immediately drew a chorus of criticism
from both business and privacy-rights groups. Computer and software
companies, including Apple Computer, I.B.M. and Microsoft, have adamantly
opposed the Clipper Chip because they believe customers will not trust an
encryption program that was built by the government and whose inner
workings remain a secret.

"Perhaps more importantly, they fear that it will harm their ability to
export products; they predict that foreign customers will resist buying
computers and telecommunications equipment built with decoding technology
devised by the National Security Agency.

"Privacy-rights groups argue that the technology could lead to
unauthorized eavesdropping, because the keys for unscrambling the code
will remain in official hands.

"'This is bad for privacy, bad for security and bad for exports,' said
Jerry Berman, executive director of the Electronic Frontier Foundation, a
Washington nonprofit group that lobbies on privacy issues related to
electronic networks. 'The Administration is preparing to implement systems
that the public will not trust, that foreign countries will not buy, and
that terrorists will overcome.'"

>From the Wall Street Journal on Monday:

"The issue has become a controversial one between law enforcement
officials and the computer industry and civil libertarians. In unfolding
details of the administration's decision, Mike Nelson, an official at the
Office of Science and Technology Policy, said the issue was so difficult
it represented 'the Bosnia of telecommunications policy.'

"Jerry Berman, executive director of the Electronic Frontier Foundation, a
Washington-based computer users' civil-rights group, said the
administration's handling of the Clipper Chip policy could make it 'as
successful' as the Bosnia policy, which has come under widespread
criticism."


William Safire has also written about this in today's NYTimes.



>From owner-cypherpunks  Mon Feb  7 15:40:40 1994




From kevin at axon.cs.byu.edu  Mon Feb  7 15:16:30 1994
From: kevin at axon.cs.byu.edu (Kevin Vanhorn)
Date: Mon, 7 Feb 94 15:16:30 PST
Subject: reno_key_escrow.statement (fwd)
In-Reply-To: <199402072231.RAA07108@eff.org>
Message-ID: <9402072316.AA20220@axon.cs.byu.edu>


Mike Godwin writes, about Clipper's key-escrow:

>  But you have to have a valid search
>  warrant or authorization order in hand before you can go to the escrow
>  agencies and request the partial keys.
>
>  Here's the relevant language:

>   > > ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS
>   > >
>   > > When an authorized government agency encounters suspected key-
>   > > escrow encryption, a written request will have to be submitted to
>   > > the two escrow agents. The request will, among other things, have
>   > > to identify the responsible agency and the individuals involved;
>   > > certify that the agency is involved in a lawfully authorized
>					      ^^^^^^^^^^^^^^^^^^^^^
>   > > wiretap; specify the wiretap's source of authorization and its
>				      ^^^^^^^^^^^^^^^^^^^^^^^
>   > > duration; and specify the serial number of the key-escrow
>   > > encryption chip being used. In every case, an attorney involved in
>   > > the investigation will have to provide the escrow agents assurance
>   > > that a validly authorized wiretap is being conducted.

But the word "warrant" appears nowhere in there.  The agencies requesting
the keys aren't required to present a warrant; they're only required to
promise that they're lawfully authorized.  And if they lie the evidence
is still admissible in court and they suffer no penalty.  And what does
"lawfully authorized" really mean?  Depending on what legislation
Congress passes, it could mean no more than "my supervisor approved it".

-----------------------------------------------------------------------------
Kevin S. Van Horn     | It is the means that determine the ends.
kevin at bert.cs.byu.edu |





From mnemonic at eff.org  Mon Feb  7 15:20:41 1994
From: mnemonic at eff.org (Mike Godwin)
Date: Mon, 7 Feb 94 15:20:41 PST
Subject: reno_key_escrow.statement (fwd)
In-Reply-To: <9402072316.AA20220@axon.cs.byu.edu>
Message-ID: <199402072319.SAA08343@eff.org>


 
Kevin writes:

> But the word "warrant" appears nowhere in there.  The agencies requesting
> the keys aren't required to present a warrant; they're only required to
> promise that they're lawfully authorized.

You're misunderstanding the language. Strictly speaking, law-enforcement
agents who seek wiretaps receive "authorization orders," not warrants.
So the word "authorized" is perfectly appropriate. 


--Mike








From Patrick_May at dtv.sel.sony.com  Mon Feb  7 15:36:30 1994
From: Patrick_May at dtv.sel.sony.com (Patrick May)
Date: Mon, 7 Feb 94 15:36:30 PST
Subject: A Nice Summary of Motives for Clipper
In-Reply-To: <199402061911.LAA20333@mail.netcom.com>
Message-ID: <9402072329.AA24031@hugehub>


Timothy C. May writes:
> [Explanation of why Clipper will be prevalent in five years
>  deleted.]

     Mr. May's arguments are eloquent and convincing as usual, but it
occurs to me that one important point is being overlooked in this
discussion: the algorithm will not be a secret forever.

     Even in the worst case scenario, where all major players in the
industry knuckle under to the government (including those currently
planning to use other systems), the situation will be resolved as soon
as either Clipper or one of its designers is reverse-engineered.  The
more widespread is the chip, the greater the blow to the government.
With the algorithm known there is no way to prevent compatible,
non-escrowed, devices from being used, and it would be costly and
embarrassing to attempt to recall 100 million "secure" chips.

     So, how long will we likely have to put up with this abomination?

Regards,


Patrick May     (no known relation, tentacular or otherwise)





From freeman at MasPar.COM  Mon Feb  7 16:20:41 1994
From: freeman at MasPar.COM (Jay R. Freeman)
Date: Mon, 7 Feb 94 16:20:41 PST
Subject: A Nice Summary of Motives for Clipper
Message-ID: <9402080022.AA00944@cleo.MasPar.Com>


Patrick May says:

> the [Clipper] algorithm will not be a secret forever ...

  A fascinating point!  Perhaps Clipper's accomplishment will ultimately be
positive, serving to inculcate upon us all the habit and administrative forms
of routine use of cryptography, albeit in flawed implementation.  Thus when
the algorithm is unraveled, the transition to widespread use of a more nearly
adequate cryptographic standard may well be very rapid indeed.

                                            -- Jay Freeman





From wcs at anchor.ho.att.com  Mon Feb  7 16:40:41 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Mon, 7 Feb 94 16:40:41 PST
Subject: Atlantis Project/Oceania
Message-ID: <9402080036.AA00215@anchor.ho.att.com>


> > The Atlantis Project is a group in Las Vegas which is trying to build a
> > floating city in the Caribbean sea.  Their new city would be an
> ....
> Of course, the U.S. will immediately declare they a national threat and 
> bomb them back to the stone age.  :-)

Which is kind of a problem for a floating city, since stones don't
float very well, concrete canoes excepted :-)

I'm not sure their economics can float that well either - if it costs
$500M to build, and holds 1000 people, that means $500K/person....
Maybe they're looking at more people or less money.
Nice T-Shirts and promo material, though.





From qwerty-remailer at netcom.com  Mon Feb  7 16:41:30 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Mon, 7 Feb 94 16:41:30 PST
Subject: Nate's Remailer Shutdown.
Message-ID: <199402080041.QAA02332@mail.netcom.com>


The reasons the Post Office gets more slack are that
1) They're the government, or at least used to be
2) They can randomly open mail when they feel like it, see 1)





From mnemonic  Mon Feb  7 13:59:32 1994
From: mnemonic (Mike Godwin)
Date: Mon, 7 Feb 1994 16:59:32 -0500 (EST)
Subject: EFF Wants You (to add your voice to the crypto fight)
Message-ID: <199402072159.QAA06512@eff.org>

                     * DISTRIBUTE WIDELY *

Monday, February 7th, 1994

From: Jerry Berman, Executive Director of EFF
      jberman at eff.org


Dear Friends on the Electronic Frontier,

I'm writing a personal letter to you because the time has now come for
action. On Friday, February 4, 1994, the Administration announced that it
plans to proceed on every front to make the Clipper Chip encryption scheme
a national standard, and to discourage the development and sale of
alternative powerful encryption technologies. If the government succeeds
in this effort, the resulting blow to individual freedom and privacy could
be immeasurable.

As you know, over the last three years, we at EFF have worked to ensure
freedom and privacy on the Net. Now I'm writing to let you know about
something *you* can do to support freedom and privacy. *Please take a
moment to send e-mail to U.S. Rep. Maria Cantwell (cantwell at eff.org) to
show your support of H.R. 3627, her bill to liberalize export controls on
encryption software.* I believe this bill is critical to empowering
ordinary citizens to use strong encryption, as well as to ensuring that
the U.S. software industry remains competitive in world markets.

Here are some facts about the bill:

Rep. Cantwell introduced H.R. 3627 in the House of Representatives on
November 22, 1993.  H.R. 3627 would amend the Export Control Act to move
authority over the export of nonmilitary software with encryption
capabilities from the Secretary of State (where the intelligence community
traditionally has stalled such exports) to the Secretary of Commerce. The
bill would also invalidate the current license requirements for
nonmilitary software containing encryption capablities, unless there is
substantial evidence that the software will be diverted, modified or
re-exported to a military or terroristic end-use.

If this bill is passed, it will greatly increase the availability of
secure software for ordinary citizens. Currently, software developers do
not include strong encryption capabilities in their products, because the
State Department refuses to license for export any encryption technology
that the NSA can't decipher. Developing two products, one with less secure
exportable encryption, would lead to costly duplication of effort, so even
software developed for sale in this country doesn't offer maximum
security. There is also a legitimate concern that software companies will
simply set up branches outside of this country to avoid the export
restrictions, costing American jobs.

The lack of widespread commercial encryption products means that it will
be very easy for the federal government to set its own standard--the
Clipper Chip standard. As you may know, the government's Clipper Chip
initiative is designed to set an encryption standard where the government
holds the keys to our private conversations. Together with the Digital
Telephony bill, which is aimed at making our telephone and computer
networks "wiretap-friendly," the Clipper Chip marks a dramatic new effort
on the part of the government to prevent us from being able to engage in
truly private conversations.

We've been fighting Clipper Chip and Digital Telephony in the policy arena
and will continue to do so. But there's another way to fight those
initiatives, and that's to make sure that powerful alternative encryption
technologies are in the hands of any citizen who wants to use them. The
government hopes that, by pushing the Clipper Chip in every way short of
explicitly banning alternative technologies, it can limit your choices for
secure communications.

Here's what you can do: 

I urge you to write to Rep. Cantwell today at cantwell at eff.org. In the
Subject header of your message, type "I support HR 3627." In the body of
your message, express your reasons for supporting the bill. EFF will
deliver printouts of all letters to Rep. Cantwell. With a strong showing
of support from the Net community, Rep. Cantwell can tell her colleagues
on Capitol Hill that encryption is not only an industry concern, but also
a grassroots issue. *Again: remember to put "I support HR 3627" in your
Subject header.*

This is the first step in a larger campaign to counter the efforts of
those who would restrict our ability to speak freely and with privacy.
Please stay tuned--we'll continue to inform you of things you can do to
promote the removal of restrictions on encryption.

In the meantime, you can make your voice heard--it's as easy as e-mail.
Write to cantwell at eff.org today.



Sincerely,

Jerry Berman
Executive Director, EFF
jberman at eff.org



P.S. If you want additional information about the Cantwell bill, send
e-mail to cantwell-info at eff.org. To join EFF, write membership at eff.org.

The text of the Cantwell bill can be found with the any of the following
URLs (Universal Resource Locaters):

ftp://ftp.eff.org/pub/Policy/Legislation/cantwell.bill
http://www.eff.org/ftp/EFF/Policy/Legislation/cantwell.bill
gopher://gopher.eff.org/00/EFF/legislation/cantwell.bill










From mg5n+ at andrew.cmu.edu  Mon Feb  7 17:50:40 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Mon, 7 Feb 94 17:50:40 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080036.AA00215@anchor.ho.att.com>
Message-ID: <ohJiwNG00VB7QvUUVJ@andrew.cmu.edu>


wcs at anchor.ho.att.com (bill.stewart at pleasantonca.ncr.com
+1-510-484-6204) wrote:

> > Of course, the U.S. will immediately declare they a national threat
> > and bomb them back to the stone age.  :-)
> 
> Which is kind of a problem for a floating city, since stones don't
> float very well, concrete canoes excepted :-)

Actually, they plan to build it on 3-acre concrete hexagonal platforms
with hollow centers so that they float.

> I'm not sure their economics can float that well either - if it
> costs $500M to build, and holds 1000 people, that means
> $500K/person.... Maybe they're looking at more people or less
> money.  Nice T-Shirts and promo material, though.

I think their projections were a billion dollars to build it and a
population of 20,000 - 30,000...

I was just wondering what sort of business one might engage in in
Oceania?  Cryptographic software is a possibility, but I wonder how much
revenue that might bring in.  A electronic bank would probably be a more
profitable venture, but getting a high bandwidth net connection in the
middle of the ocean would increase startup costs.  Telecom, electricity,
and water supply would probably be good businesses...but they require a
local market that would be fairly small in the startup country.  There
is also international shipping and trade, but there you have large
startup costs and would need to do extensive work to get clients.  And
there is tourism...gambling, recreational drugs, etc....





From blancw at microsoft.com  Mon Feb  7 18:20:41 1994
From: blancw at microsoft.com (Blanc Weber)
Date: Mon, 7 Feb 94 18:20:41 PST
Subject: Atlantis Project/Oceania
Message-ID: <9402080217.AA23708@netmail.microsoft.com>



"I'm not sure their economics can float that well either - if it costs
$500M to build, and holds 1000 people, that means $500K/person....
Maybe they're looking at more people or less money.
Nice T-Shirts and promo material, though."
......................

Does it not seem that they are putting more effort into the publicity, 
marketing, & attraction of money for support of this virtual country, 
than into the establishment of other fundamentals?  Like: setting up an 
alternative currency & banking system, the manner of conducting 
business with the rest of the conventional world, and resolving the 
many little problems that would be of concern when living under such 
conditions?

Blanc





From nate at VIS.ColoState.EDU  Mon Feb  7 18:56:32 1994
From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons)
Date: Mon, 7 Feb 94 18:56:32 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <ohJiwNG00VB7QvUUVJ@andrew.cmu.edu>
Message-ID: <9402080248.AA14992@vangogh.VIS.ColoState.EDU>


writes Matthew J Ghio:
>
>profitable venture, but getting a high bandwidth net connection in the
>middle of the ocean would increase startup costs.  Telecom, electricity,

Well, a satellite dish can transfer around 100MB (megaBytes, not bits)
per second.  I'm not too sure how much this kind of link costs, but I
would also assume that the Oceania people aren't going to go without a 
network conection to start.

-nate

-- 
+-----------------------------------------------------------------------+
| Nate Sammons <nate at VIS.ColoState.Edu> <nate at yuma.ANCS.ColoState.Edu>  |
|      Colorado State University Computer Visualization Laboratory      |
|    Data Visualization/Interrogation, Modeling, Animation, Rendering   |
+-----------------------------------------------------------------------+




From cknight at crl.com  Mon Feb  7 19:06:32 1994
From: cknight at crl.com (Chris Knight)
Date: Mon, 7 Feb 94 19:06:32 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <ohJiwNG00VB7QvUUVJ@andrew.cmu.edu>
Message-ID: <Pine.3.87.9402071927.A1918-0100000@crl2.crl.com>




On Mon, 7 Feb 1994, Matthew J Ghio wrote:

> I was just wondering what sort of business one might engage in in
> Oceania?  Cryptographic software is a possibility, but I wonder how much
> revenue that might bring in.  A electronic bank would probably be a more
> profitable venture, but getting a high bandwidth net connection in the
> middle of the ocean would increase startup costs.  Telecom, electricity,
> and water supply would probably be good businesses...but they require a
> local market that would be fairly small in the startup country.  There
> is also international shipping and trade, but there you have large
> startup costs and would need to do extensive work to get clients.  And
> there is tourism...gambling, recreational drugs, etc....

Have you read "Oath of Fealty" by Larry Niven?  Check it out, it's a good 
sci-fi that outlines just this kind of project.  And please, read the 
tribute in the front...


-ck







From mg5n+ at andrew.cmu.edu  Mon Feb  7 19:10:42 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Mon, 7 Feb 94 19:10:42 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080217.AA23708@netmail.microsoft.com>
Message-ID: <whJk6py00VB2MQgUYp@andrew.cmu.edu>


Blanc Weber <blancw at microsoft.com> wrote:

> Does it not seem that they are putting more effort into the publicity,
> marketing, & attraction of money for support of this virtual country,
> than into the establishment of other fundamentals?  Like: setting up
> an alternative currency & banking system...

I thought that's what cypherpunks were supposed to be doing... :-)

> ... the manner of conducting business with the rest of the conventional
> world, and resolving the many little problems that would be of
> concern when living under such conditions?

All they said on the subject was that the government would be on the
gold standard and everyone else could use whatever currency they wanted.

As for the other little problems, I'd guess they haven't got a clue. 
However, they did hire an architect who is experienced in building
floating structures, so I guess he's considered those things, ya know
like fresh water and electricity.  You could drop them an email and
ask...





From karn at qualcomm.com  Mon Feb  7 19:16:32 1994
From: karn at qualcomm.com (Phil Karn)
Date: Mon, 7 Feb 94 19:16:32 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU>
Message-ID: <199402080314.TAA24549@servo.qualcomm.com>


>Well, a satellite dish can transfer around 100MB (megaBytes, not bits)
>per second.  I'm not too sure how much this kind of link costs, but I
>would also assume that the Oceania people aren't going to go without a 
>network conection to start.

Depends entirely on what it's pointing at. The actual throughput for
a single transponder on a conventional Ku-band DOMSAT is more like 45
megabits/sec.

Because of fiber, satellites are fast falling out of favor for high
capacity point-to-point links. They're now used mainly for "thin
route" traffic, especially to remote or mobile locations, and for
broadcasting.

Phil






From mg5n+ at andrew.cmu.edu  Mon Feb  7 19:41:32 1994
From: mg5n+ at andrew.cmu.edu (Matthew J Ghio)
Date: Mon, 7 Feb 94 19:41:32 PST
Subject: nate@vis.colostate.edu remailer *GONE*
In-Reply-To: <9402071806.AA12892@vangogh.VIS.ColoState.EDU>
Message-ID: <QhJkaiS00VB24QgVJa@andrew.cmu.edu>


nate at VIS.ColoState.EDU typed:

> Everyone out there, plese listen up!  The remailer at
> nate at vis.colostate.edu has been taken down as a result of the posting
> by some anonymous person to a local list of administrators.

Sorry to hear that.  I have removed it from my listing at
<mg5n+remailers at andrew.cmu.edu>.

Perhaps in the future, remailers will make it a policy to block all mail
addressed to their site.  At least that way you could blame it on a
remailer at another site. :-(






From banisar at washofc.cpsr.org  Mon Feb  7 20:00:42 1994
From: banisar at washofc.cpsr.org (Dave Banisar)
Date: Mon, 7 Feb 94 20:00:42 PST
Subject: Campaign Against Clipper
Message-ID: <00541.2843506175.2994@washofc.cpsr.org>


  Campaign Against Clipper

CPSR ANNOUNCES CAMPAIGN TO OPPOSE CLIPPER PROPOSAL

Embargoed until 2 pm, Monday, February 7, 1994

contact: rotenberg at washofc.cpsr.org  (202 544 9240)


Washington, DC -- Following the White House decision on Friday to
endorse a secret surveillance standard for the information highway,
Computer Professionals for Social Responsibility (CPSR) today announced
a national campaign to oppose the government plan.

The Clipper proposal, developed in secret by the National Security
Agency, is a technical standard that will make it easier for government
agents to wiretap the emerging data highway.

Industry groups, professional associations and civil liberties
organizations have expressed almost unanimous opposition to the plan
since it was first proposed in April 1993.

According to Marc Rotenberg, CPSR Washington director, the
Administration made a major blunder with Clipper.  "The public does not
like Clipper and will not accept it. This proposal is fatally flawed."

CPSR cited several problems with the Clipper plan:

o The technical standard is subject to misuse and compromise. It would
provide government agents with copies of the keys that protect
electronic communications.  "It is a nightmare for computer security,"
said CPSR Policy Analyst Dave Banisar.

o The underlying technology was developed in secret by the NSA, an
intelligence agency responsible for electronic eavesdropping, not
privacy protection. Congressional investigations in the 1970s disclosed
widespread NSA abuses, including the illegal interception of millions of
cables sent by American citizens.

o Computer security experts question the integrity of the technology.
Clipper was developed in secret and its specifications are classified.
CPSR has sued the government seeking public disclosure of the Clipper
scheme.

o NSA overstepped its legal authority in developing the standard.  A
1987 law explicitly limits the intelligence agency's power to set
standards for the nation's communications network.

o There is no evidence to support law enforcement's claims that new
technologies are hampering criminal investigations. CPSR recently forced
the release of FBI documents that show no such problems.

o The Administration ignored the overwhelming opposition of the general
public. When the Commerce Department solicited public comments on the
proposal last fall, hundreds of people opposed the plan while only a few
expressed support.

CPSR today announced four goals for its campaign to oppose the Clipper
initiative:

o First, to educate the public about the implications of the Clipper
proposal.

o Second, to encourage people to express their views on the Clipper
proposal, particularly through the computer network.

Toward that goal, CPSR has already begun an electronic petition on the
Internet computer network urging the President to withdraw the Clipper
proposal. In less than one week, the CPSR campaign has drawn thousands
of electronic mail messages expressing concern about Clipper. To sign
on, email clipper.petition at cpsr.org with the message "I oppose clipper"
in the body of the text.

o Third, to pursue litigation to force the public disclosure of
documents concerning the Clipper proposal and to test the legality of
the Department of Commerce's decision to endorse the plan.

o Fourth, to examine alternative approaches to Clipper.

Mr. Rotenberg said "We want the public to understand the full
implications of this plan.  Today it is only a few experts and industry
groups that understand the proposal.  But the consequences of Clipper
will touch everyone.  It will affect medical payments, cable television
service, and everything in between.

CPSR is a membership-based public interest organization.  For more
information about CPSR, send email to cpsr at cpsr.org or call 415 322
3778.  For more information about Clipper, check the CPSR Internet
library CPSR.ORG. FTP/WAIS/Gopher and listserv access are available.







From dwomack at runner.utsa.edu  Mon Feb  7 21:36:33 1994
From: dwomack at runner.utsa.edu (David L Womack)
Date: Mon, 7 Feb 94 21:36:33 PST
Subject: keyservers
Message-ID: <9402080535.AA19289@runner.utsa.edu>


I just downloaded the demon.co.uk
 public keyring...but, since I
don't have mosaic or WWW and can't
use the ai.mit.edu server, how would
I add my public key to such a keyring?
Thanks for any thoughts.




From karn at qualcomm.com  Mon Feb  7 21:36:43 1994
From: karn at qualcomm.com (Phil Karn)
Date: Mon, 7 Feb 94 21:36:43 PST
Subject: New remailer up
In-Reply-To: <9402041508.AA18037@jungle.meaddata.com>
Message-ID: <199402080532.VAA24768@servo.qualcomm.com>


>You can get spread spectrum radio/data modems that do 256Kbits/sec
>(Cylink) and can go up to 30 Miles.  It is unlicensed in the US
>because it is limited to .8watts (I think).  I believe 10 miles is the
>limit with an omnidirectional antenna.  Spread spectrum should be
>pretty hard to triangulate on.  Remember that the technology came from
>unjammable military radios.

>I think you'd have to have a fairly sophisticated scanner to even pick
>it up.

Not quite. Very few, if any, Part 15 spread spectrum modems do automatic
transmitter power control, and as a result they generally run much more
power than necessary. That makes you much easier to spot. It also
pollutes the spectrum.

Even spread spectrum transmitters with tight power control (e.g, our
IS-95 cellular system) are easily detected (though not demodulated)
with simple AM scanners when you're close enough. Especially when the
mobile in question is a long way from the cell and transmitting near
full power as a result.

On the other hand, if you're not close, any particular mobile will be
drowned out by the several dozen others sharing the same channel.

Phil






From oseiler at unixg.ubc.ca  Mon Feb  7 21:50:42 1994
From: oseiler at unixg.ubc.ca (Oliver Seiler)
Date: Mon, 7 Feb 94 21:50:42 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080217.AA23708@netmail.microsoft.com>
Message-ID: <Pine.3.05.9402072122.C9851-b100000@unixg.ubc.ca>



On Mon, 7 Feb 1994, Blanc Weber wrote:

> 
> Does it not seem that they are putting more effort into the publicity, 
> marketing, & attraction of money for support of this virtual country, 
> than into the establishment of other fundamentals?  Like: setting up an 

They have a rather complete constitution, legal system, etc. Monetary
systems would likely appear as needed. Most businesses would likely
take all major currencies - good market for a bank to get into.

Business relations with the rest of the world? This isn't in general
specified in advance in any country, and why should it be? The only
real rule I've seen is making it illegal (for good reason) to export
drugs (eg. recreational drugs, synthesized for use on the island)
to countries where they are illegal.

Besides, since they moeny is far more important on this project than
vague untested notions of how everything should work (hey isn't
that how communist countries are set up?) in advance, they have
been doing quite well. I wish them all the luck I can spare, and
plan to pick up a t-shirt (if only for being able to tell people
about it in 100 years or so...) or a flag...

> alternative currency & banking system, the manner of conducting 
> business with the rest of the conventional world, and resolving the 
> many little problems that would be of concern when living under such 
> conditions?

How much government intervention do you see in your day to day
affairs? Personally, I see virtually nil... Free-market's tend
to sort themselves out quite nicely...

> Blanc

-Oliver (who's not waiting for somebody else to build him a country, and
is instead doing whatever it takes to get the same effect now)

| Oliver Seiler          + Erisian Development Group +  Amiga Developer  +
| oseiler at unixg.ubc.ca   +-------------Reality by the Slice--------------+
| oseiler at nyx.cs.du.edu  | Phone: (604) 683-5364     Fax: (604) 683-6142 |
| ollie at BIX.com          | POB 3547, MPO, Vancouver, BC, CANADA  V6B 3Y6 |







From oseiler at unixg.ubc.ca  Mon Feb  7 21:56:33 1994
From: oseiler at unixg.ubc.ca (Oliver Seiler)
Date: Mon, 7 Feb 94 21:56:33 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU>
Message-ID: <Pine.3.05.9402072153.D9851-b100000@unixg.ubc.ca>



On Mon, 7 Feb 1994, CVL staff member Nate Sammons wrote:

> writes Matthew J Ghio:
> >
> >profitable venture, but getting a high bandwidth net connection in the
> >middle of the ocean would increase startup costs.  Telecom, electricity,
> 
> Well, a satellite dish can transfer around 100MB (megaBytes, not bits)
> per second.  I'm not too sure how much this kind of link costs, but I
> would also assume that the Oceania people aren't going to go without a 
> network conection to start.

As soon as it's built, I would move in with a business offering just
this sort of connectivity. If I can swing the capital at the time
(probably not too hard) I'd also lay down swaths of fibre, set up
a packet radio network, and connect the island up...

> -nate

-Oliver

| Oliver Seiler          + Erisian Development Group +  Amiga Developer  +
| oseiler at unixg.ubc.ca   +-------------Reality by the Slice--------------+
| oseiler at nyx.cs.du.edu  | Phone: (604) 683-5364     Fax: (604) 683-6142 |
| ollie at BIX.com          | POB 3547, MPO, Vancouver, BC, CANADA  V6B 3Y6 |







From hfinney at shell.portal.com  Mon Feb  7 22:36:33 1994
From: hfinney at shell.portal.com (Hal)
Date: Mon, 7 Feb 94 22:36:33 PST
Subject: WRONG:  Attack on Magic Money and Chaum cash
Message-ID: <199402080633.WAA27612@jobe.shell.portal.com>


I was thinking over the attack I described on Magic Money and Chaum
cash, and I now think it will not actually work, especially in the case
of the Chaum cash.  Specifically, it will take as much work to forge
cash as to factor the modulus.

My idea was to collect signed forms of small primes, then try to find a
"smooth" number of the proper form, one which can be factored over this
set of primes.  By multiplying together the proper primes, one could
generate a signed number which would look like cash.

What I was remembering as I was driving tonight is that this is very
similar to a family of algorithms for factoring large numbers.  The one
I know best is the continued fraction algorithm, but I think the number
field sieve uses broadly similar principles.  In the cfrac algorithm,
the goal is to find two squares which are equal mod n.  This lets you
factor n immediatly by taking its gcd with the sum or difference of the
two numbers.

This is done by taking a bunch of squares and trying to factor them
over a set of small primes.  If you generate enough factorizations,
approximately as many as there are primes, you can multiply selected
ones together and generate two equal squares.

The point is, finding as many smooth numbers as there are small primes
will let you factor n.  But that is the same criterion I had to meet in
my proposed attack in order to make a profit.  So it seems that in
general my attack will not work; it will be as hard as factoring the
modulus.

There may still be a problem with Magic Money because its cash values
leave the low order 128 bits free, but I'm not so sure about it.  I was
wrong, I think, to suggest that a simple sieve could quickly identify
smooth numbers.  Although a sieve will easily tell you that a number
has _no_ factors less than some cutoff, it will not easily tell you
that a number has _only_ factors in that range.  It may be that the
only way to identify smooth numbers is by trial division, which would
be the same situation as for Chaum cash.

So, unless there is in fact some trick that can be used to quickly find
smooth numbers given that the low order 128 bits are free, I don't
think there is any need to worry about my attack on Magic Money.  And
it looks like Chaum's online cash is completely invulnerable to this
approach.

Sorry to have raised a red flag unnecessarily.

Hal





From qwerty-remailer at netcom.com  Mon Feb  7 22:41:33 1994
From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com)
Date: Mon, 7 Feb 94 22:41:33 PST
Subject: Nate's Remailer Shutdown.
Message-ID: <199402080641.WAA24210@mail.netcom.com>


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

Anonymous said,
"The reasons the Post Office gets more slack are that
1) They're the government, or at least used to be
2) They can randomly open mail when they feel like it, see 1)"

So what's your point? Talk is cheap. The situation remains the same.
The message in my post remains valid. The reason why it is so doesn't matter
to someone desiring privacy. The internet still sucks and always will, due
to the From and Received by e-mail headers as well as many other Unix system
problems like sendmail logs, and the fact that you can't trust a wire 'cause
you can't see it.

 -=Xenon=-
-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVbo8wSzG6zrQn1RAQEZqgP+LOHqzsOR+mbHjagehpv12qvihvJl9SSm
f1Rz/iVtyKhPVpvsmwhIm3S/F6AmAikQwuO7Kt90BFpS8Q2tfV+iL4mRr1009xKi
LovMs+oeydinlH6uOvKGvS4vtaju3dd7+SXQIa0sR46cN8r7O0BiVA6K+9AZ91Cx
6oONCh2Wpfo=
=7yq9
-----END PGP SIGNATURE-----





From remailer at merde.dis.org  Mon Feb  7 22:50:42 1994
From: remailer at merde.dis.org (remailer bogus account)
Date: Mon, 7 Feb 94 22:50:42 PST
Subject: PGP Tools Debugging
Message-ID: <9402080648.AA17257@merde.dis.org>


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

>> Pr0duct Cypher
>  Warlord

>>I've got the code written to check the whole coin, and I found another
>>subtle bug caused by precision setting. Since setting precision does not
>>seem to affect the speed of the decryption (I think the mpi library sets
>>it internally during modexp) I'm just going to fix it at maximum
>>and leave it there. Tomorrow I will strip out all of these damn things.

>Yea, MPI lets the precision.  This is not a bug -- the MPI library
>needs to know how big the number is.  (The bug is that its done in a
>global variable and not as a part of the number internally, but thats
>a different matter).  The reason it needs to know is so that it
>doesn't need to perform large operations for small numebers.  For
>example, there is no reason to perform a 1024-bit modexp when you are
>dealing with 384-bit numbers!

The bug was in my code, not in mpilib, but the need to set precision can
be a real pain. I've been plagued by intermittent bugs caused by mpis not
being completely cleared or fully calculated out. Since modexp does it
automatically, I'm just going to set it to max. If you or someone else with
both types of machines wants to fix that, feel free. I don't have the
means to do so, and it's been my experience that writing code you can't
test is a waste of time.

>FYI: I have both big-endian and little-endian machines at my disposal.
>Also, I was having problems building PGP Tools under mips-ultrix --
>you have some global variables in ptd that you expect from time.h
>which don't exist.  In particular, timezone and daylight.

PTD is a kludge. There are no similar dependencies in the library itself.
PTD was just written as needed to test the rest of the library, and was not
intended to be a usable application. You can either put in #ifdefs for your
machine, or set up another module with the needed globals. I just wanted to
code around the need for timezone stuff and get the test code working.

I've got another version of PGP Tools ready which removes most of the
set_precision stuff, and a version of Magic Money which checks the whole
coin when it receives it. There are a few more changes for Magic Money,
but I should be mailing out soon. Someone wrote that they had success with
a big-endian machine - whew! and thanks for testing it.

                                             Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVcQUsGoFIWXVYodAQEiQQP/Tsm/AIi+zNJ5YIzPfaEjzeSyyi4pwLTp
ZYzo88FyBBrayFpt+CkSdlatnOVu7EwyHcNBgh8Z3LJeffOcI8Wiw9WPO9v0vqHj
yE35Yq9rFfBnTjQuZ3uNnb03l1G0XfyG2AyuYer3Y4shEKwO/6DgYr4b5K9Y2Wqc
p8qpWGwUC6I=
=itBc
-----END PGP SIGNATURE-----





From orion at crl.com  Mon Feb  7 23:06:33 1994
From: orion at crl.com (Colin Orion Chandler)
Date: Mon, 7 Feb 94 23:06:33 PST
Subject: Clipper Qs
Message-ID: <Pine.3.87.9402072333.A21239-0100000@crl.crl.com>


Hurm...I have had a couple of thoughts, no dowbt simple ones, but maybe 
you can help:

	If I bought a a ClipperFone and switched chips with my neighbors chips 
(Clipper Chip, that is), could the .gov tell what was going on?
	Also, can these chips be re programmed? ;) I'd like a cracker...


___________________________________________________________________________
|---===================================--|     /\     |  |  \ |_ _\ \  / |
|---Colin Titus Orion Xavier Chandler----|    \\ \    |  | .  |  | >  <  |
|---===================================--|   \ \\ /  \__/ _|\_|___|_/\_\ |
| _____                                  |  / \/ / /		         |
|/\  __ \         __  "What year is it?" | / /   \//\   "If it's not a   | 
|\ \ \/\ \  _ __ /\_\    ___     ___     | \//\   / /	Sun, it's not a  |
| \ \ \ \ \/\`'__\/\ \  / __`\ /' _ `\   |  / / /\ /  	   computer."    |
|  \ \ \_\ \ \ \/ \ \ \/\ \L\ \/\ \/\ \  |   / \\ \  .__          __     |
|   \ \_____\ \_\  \ \_\ \____/\ \_\ \_\ |    \ \\   |_. | | |\ |  -|    |
|    \/_____/\/_/   \/_/\/___/  \/_/\/_/ |     \/    __| I_| | \| __|/160|
+________________________________________+_______________________________+
|  Colin Chandler |"It can only be accountable to *human* error."-HAL9000|
|  (415) 388-8055 | orion at crl.com, wizard @ BayMOO (mud.crl.com 8888)    |
|________________________________________________________________________|







From karn at qualcomm.com  Mon Feb  7 23:10:43 1994
From: karn at qualcomm.com (Phil Karn)
Date: Mon, 7 Feb 94 23:10:43 PST
Subject: STEG: a real-life use for steganography
In-Reply-To: <9402041840.AA21942@ah.com>
Message-ID: <199402080707.XAA24919@servo.qualcomm.com>


The biggest problem I see with your scheme is that it won't remain secret
for very long, and the government will probably just ban all CD imports
as a result. And possession of a CD player or CDs (even "legit" ones)
would be enough to send you off to kamp.

> -- A decryption system to get the data off the CD.

There's a practical problem here. Audio CD players generally provide
no easy way to get the raw bits into a computer (SPDIF interface cards
exist for PCs, but they're rare and expensive). And I haven't yet
figured out how to get a CD-ROM drive to read the raw bits off an
audio CD; I suspect it requires munging the firmware in the drive,
which makes anything you do highly manufacturer specific.

Phil





From qwerty at netcom.com  Tue Feb  8 00:06:34 1994
From: qwerty at netcom.com (Xenon)
Date: Tue, 8 Feb 94 00:06:34 PST
Subject: What's a "real encryptor"?
Message-ID: <199402080803.AAA16148@mail.netcom.com>


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

I (Nik) got a letter from a mathamatician asking me to clarify what
 I meant  by a "real encryptor". Here is the answer I gave. It is for
the newbies out there, not the serious cryptographer types who know
this already. Warning: one of my Xenon character's last rants will be
arriving shortly. Take it with a grain of salt; it's pretty nasty, and
not meant for those who already understand its message. I'm trying
to drum up some public demand for a "real encryptor", for one thing.
Think of it as propoganda, for it appeals to emotion not logic, and it
is not very fair.

Steganography involves hiding a message in a file. I can use the Mac
program Stego to place say a PGP message into a Mac PICT (just a picture)
file as the least significant bit of each pixel. If it is a 24 bit per
pixel color picture, then you can't even see a difference. If it is 8 bit
color, then you CAN. It looks like digital noise. On off, on off. No
matter. The problem IS, anyone with Stego can extract the file and
immediately see that it is an encrypted PGP message. When PGP encrypts a
file, after compressing it, it includes in the final output all sorts of
extra things like a checksum at the end, and full information given out to
anyone about the name of the key that it was encrypted with. It will
proudly announce, for instance, "This message can only be read by Pr0duct
Cypher. You do not have the secret key required to read it." I don't know
the full details. The PGP documentation mentions some of them, for the
binary format PGP output files. I could send you this if you want.

What I mean by a "real encryptor" is something just like PGP, but minus the
convenience features that get tagged onto the PGP messages. It might be as
simple as stripping them away the PGP convenience procedures. If the output
was simply an encrypted message, and it seems to me PGP could do this, it
should be hard to distinguish it from a random series of bits. Hopefully
nearly impossible! Then you can use steganography for your messages but no
one can tell if what they extracted is a message or not! The least
significant bit of most messages such as sound files is noise anyway. On
off, on off. They can't even tell how big it might be. That is a potential
mega problem with PGP itself not being able to know how big it is though.
You would have to know before hand, or make the picture or sound file BE
the right size, EXACTLY. That's certainly easy for sound files! Just send
voice mail! You could pad the content of the PGP message if you wanted to
hide the actual size of the decrypted message. If you get voice mail from
a stranger saying something vaque, you can check if it contains a PGP
message encypted with your public key.

If PGP outputted such a hard-to-distinguish-from-random data format, it
opens up many different possibilities for sending your messages. Ideally, no
one would be able to tell if it was an encrypted message except by
successfully decrypting it. As it is now, such schemes have to rely on
"encrypting" an already encrypted PGP message to hide the fact that it IS a
PGP message! Many of us just want to be left alone and are tired of having
our files tagged as BEING encrypted. Personally, I suggest using PGP as a
Clipboard utility so I can cut a message out, encrypt it, paste it back in
and save it as a word processor file which I then Macintosh BinHex encode
as text, and e-mail off. Now I'm just sending a BinHexed word processor
file, just like thousands of other Macintosh e-mailers out there every day!
This isn't good enough since it is so easy reverse, by anyof
them ;-), and they are still struggling with just e-mail. PGP is still a
program only used by those why really need it. It may remain that way,
so for those people, having a random data block output would mean they
wont set off alarms and catch the attention of the government, just for
sending a love letter to their mistress ;-).

 -Nik (-=Xenon=-)

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVb/QgSzG6zrQn1RAQHPRgQAttdvv7y01xE0+8xKOnoODYJ3Xmlw0Wrs
hIlMIGglirxY8Q244EEfjA538QES19jS95+8G5q9p5eEjM6w0apkRKQbyQOxme8j
tfBU+yhhtqTGPUidLdiOWNszn2DvD0hrTVFH15b3yFoB2F1mA1kkjbfmXAm1r7gS
MmJaO0c6ZNE=
=SIQx
-----END PGP SIGNATURE-----

P.S. Were PGP like many programs, able to accept modular "Plug ins" like
say Adobe Photoshop, this "bare" data block output could be an add-on
featue ("feature stripper?") that those who want it would use. Or at least
a separate utility that would strip and restore PGP messages.





From hughes at ah.com  Tue Feb  8 00:06:46 1994
From: hughes at ah.com (Eric Hughes)
Date: Tue, 8 Feb 94 00:06:46 PST
Subject: Magic Money coins
In-Reply-To: <199402080633.WAA27612@jobe.shell.portal.com>
Message-ID: <9402080759.AA00803@ah.com>


>I was thinking over the attack I described on Magic Money and Chaum
>cash, and I now think it will not actually work, especially in the case
>of the Chaum cash.  

Well, with Chaum's signature pairs of the form <x,f(x)^(1/e)>, you'd
still have to calculate some inverse value of a one-way function.

On he other hand, Hal says that his attack against MM coins doesn't
work.  That's OK, as far as it goes.

The problem is really quite general.  Given a set of signatures on the
same modulus, how can one calculate signed values of a particular
sort?  In the proceeding, let { < a_i, a_i^(1/e) > } be the set of
signatures one has, e the public key, n = pq the modulus, S the set of
acceptable signed elements.

Note that the product of any two signatures, pairwise, yields another
valid signature.  A signature can be multiplied by itself as well.
These are valid as RSA signatures but possibly not as any special coin
format.  Note that the Chaum signature pair above prevents
multiplicative combinations entirely.

The problem is then "Can we find an element of S in the multiplicative
span of the { a_i } modulo n?"  (The multiplicative span is any
product of the a_i, possibly taken multiple times.)

Hal's attack was about the about problem, _but without the modulo n_.

There's a subtlety to remember here: factoring doesn't mean anything
in a field.  The RSA ring is almost-a-field; if you can find a
non-invertible element, you've factored the modulus.  Factoring only
make good sense in rings where lots of elements are _not_ invertible.

So Hal's factoring attack only considered direct multiplication,
forgetting that that modular equality was what was relevant.

The upshot is this.  Let s be in S.  What we are looking for is a
factorable (in integers) number of the form s+kn.  Now s can be any
element in S, and k any integer.  That's a wide range to choose from.

A.  First off, what is the size of the possible multiplicative span?
The short answer is "It's likely the whole thing".

Recall that in an RSA cryptofield (my term for a ring where it's
infeasible for an outsider to find a zero-divisor) the invertible
elements form a multiplicative group which comprise all the 'normal'
operations in the cryptofield.  Its structure is the product of two
groups, one of order p-1 and one of order q-1.  Now the number of
generators of the Z_p is \phi(p-1).  (That's the Euler \phi function.)
The average value of \phi(x) is x * (6 / \pi^2), i.e. on average 61%
of the numbers.  [N.B. This is for random x.  p and q can be picked to
change these values.]  

Eliding the rest of the calculation, we see that with a few
signatures, it's very likely that _every_ cryptofield number is in the
multiplicative span.

B.  The next question is "How tractable is finding particular
combinations?"  I don't know, but I wouldn't trust on the lack of an
efficient algorithm.

Remember, we can pick and set of numbers to get signed to span with,
any coin format to try to create [RANT: forge indicates intent] with
that span, and we're working in a modular cryptofield.  That's lots of
possibilities.

Here is one idea for such attack.  The numbers in S all have the same
upper bits.  Suppose one could calculate a number u which was 'close
to' 1 in a range containing S.  To be specific, suppose that

	P( | s - u*s | < sqrt(s) ) > .1

that is, multiplication by u likely doesn't move the value around by
more than the square root of s.  Then one can randomly pick coin
values, multiply by u, and likely get new coin values, since all the
upper bits are the same.

Are such u rare?  Maybe not.  Consider the number 3 and values near
n/2.  Observe that 

	3 * ((n-1)/2) = ((n-1)/2) - 1 (mod n)
	3 * ((n+1)/2) = ((n+1)/2) + 1 (mod n)

So for the numbers close to half the modulus, 3 is exactly such an
almost-identity.

But can we find one for our given range?  I think so.  Here's my first
guess at how to proceed.  And it really is a guess, even if it is
inspired by a Gauss sum.

Consider the following.  Take the range S and choose random { x_i } in
S with, say, some truncated Gaussian distribution in order to favor
number in the center.  Now calculate the term

	1     x_1   x_3         x_(2n-1)
	- * ( --- + --- + ... + -------- )
	n     x_2   x_4           x_2n

In other words, just calculate an average of a bunch of values that
move one element of S to some other element of S.  Such an element
*might* tend to preserve values of S near the center, maybe not.  It
may be that diddling the distribution helps.  It may be that a
different average works, say a geometric average (although taking
roots becomes an issue).  It may be that this technique works but
doesn't converge rapidly.  I don't know; I haven't tried it.

In any case, if it does work, there are lots of candidate u's that one
can sample.

It also appears that one might be able to directly calculate some of
these near-identities with continued fractions.

C. Recommendations

In any case, the issue of creating new signatures out of old is
sufficiently unsettled in my mind that I would avoid the issue
entirely.  

1.  Don't rely only on format of the signed number for validity.

2.  Do use a one-way function in the signature in order to prevent
multiplicative attacks.

3.  Use both techniques above.

Therefore I recommend the Magic Money signature format be changed.

Eric





From qwerty at netcom.com  Tue Feb  8 00:16:34 1994
From: qwerty at netcom.com (Xenon)
Date: Tue, 8 Feb 94 00:16:34 PST
Subject: What's a "real encryptor"?
Message-ID: <199402080814.AAA17429@mail.netcom.com>


Typo correction from first post:

If PGP outputted such a hard-to-distinguish-from-random data format, it
opens up many different possibilities for sending your messages. Ideally, no
one would be able to tell if it was an encrypted message except by
successfully decrypting it. As it is now, such schemes have to rely on
"encrypting" an already encrypted PGP message to hide the fact that it IS a
PGP message! Many of us just want to be left alone and are tired of having
our files tagged as BEING encrypted. Personally, I suggest using PGP as a
Clipboard utility so I can cut a message out, encrypt it, paste it back in
and save it as a word processor file which I then Macintosh BinHex encode
as text, and e-mail off. Now I'm just sending a BinHexed word processor
file, just like thousands of other Macintosh e-mailers out there every day!
This isn't good enough since it is so easy to reverse, AND can be automated.
Honestly, I'm not doing this much yet with distant friends, but then there
are only two of them ;-), and they are still struggling with just e-mail.
PGP is still a program only used by those why really need it. It may remain
that way, so for those people, having a random data block output would mean 
they wont set off alarms and catch the attention of the government, just for
sending a love letter to their mistress ;-). It would also render the Clipper
issue moot.

-=Xenon, who never could type, and breaks things a lot still=-





From wcs at anchor.ho.att.com  Tue Feb  8 01:10:45 1994
From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 8 Feb 94 01:10:45 PST
Subject: Clipper Qs
Message-ID: <9402080909.AA04864@anchor.ho.att.com>


Doesn't matter if you switch CLipper Chips - the chip squawks its serial 
number when it starts a session, and they simply get the keys for *all*
clipperphones that they overhear while wiretapping.  That way they don't
need to keep track of who's got what chip (which is impossible,
since you could switch with your neighbor), though that may be some help
if they happen to know some eavesdropping victim's serial number
and are tapping all the pay phones in an area.

As far as reprogramming goes, no.  They're a fancy tamperproof design,
which they hope will make it difficult or impossible for people to get
the algorithm or the key out of.





From nobody at shell.portal.com  Tue Feb  8 02:26:36 1994
From: nobody at shell.portal.com (nobody at shell.portal.com)
Date: Tue, 8 Feb 94 02:26:36 PST
Subject: Magic Money -> Chaum Cash
Message-ID: <199402081025.CAA20709@jobe.shell.portal.com>


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

Ok, let's try this one more time... Based on Eric's long and mathematical
explanation, which I did not fully understand and was therefore convinced
by, I have changed the program to use full Chaum cash. It takes the 16-byte
random number, takes its MD5, and stores the MD5 in the coin. The coin is
now a triple (id,e,mpi) and the bank never sees id when blind-signing the
coin, thus preserving anonymity.

I sent this new version to csn.org as mgmny10c.zip. I haven't had a chance
to update the manual or the comments in the code, but it does seem to work.
At least, I was able to mint coins and cycle them through the server a few
times, so the basic coin cycle seems to work. Please check it out, on
machines of both endians, and let me know what happens.

                                                 Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVdfXcGoFIWXVYodAQExBQQAlAOtfHApmQlmj1bk2kdBEg+Rst0I4CcB
vIoxQ/iXiAS5c9fGdl5WNWpBk5TYCQSHm3jyzAoYaeLwJ4XsgnH5WbvB+UeRzwJX
VatnTUK7x7wZMtIBAAaaPGX2woosns83bnXMa5voKkiYeESFFLgU5Dw5zw24xFas
1fkwlBSnyRA=
=L9Ei
-----END PGP SIGNATURE-----





From pmetzger at lehman.com  Tue Feb  8 06:30:47 1994
From: pmetzger at lehman.com (Perry E. Metzger)
Date: Tue, 8 Feb 94 06:30:47 PST
Subject: Atlantis Project/Oceania
In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU>
Message-ID: <199402081429.JAA09219@snark>



CVL staff member Nate Sammons says:
> writes Matthew J Ghio:
> >
> >profitable venture, but getting a high bandwidth net connection in the
> >middle of the ocean would increase startup costs.  Telecom, electricity,
> 
> Well, a satellite dish can transfer around 100MB (megaBytes, not bits)
> per second.  I'm not too sure how much this kind of link costs, but I
> would also assume that the Oceania people aren't going to go without a 
> network conection to start.

Perhaps the appropriate time to worry about Oceania's network
connection would be when Oceania's builders have the $ 1 Billion they
need instead of begging for $20 or $30k for models. In any case, this
is NOT appropriate stuff for cypherpunks.

Perry





From paul at poboy.b17c.ingr.com  Tue Feb  8 07:10:51 1994
From: paul at poboy.b17c.ingr.com (Paul Robichaux)
Date: Tue, 8 Feb 94 07:10:51 PST
Subject: STEG: a real-life use for steganography
In-Reply-To: <199402080707.XAA24919@servo.qualcomm.com>
Message-ID: <199402081509.AA17293@poboy.b17c.ingr.com>


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

> There's a practical problem here. Audio CD players generally provide
> no easy way to get the raw bits into a computer (SPDIF interface cards
> exist for PCs, but they're rare and expensive). And I haven't yet
> figured out how to get a CD-ROM drive to read the raw bits off an
> audio CD; I suspect it requires munging the firmware in the drive,
> which makes anything you do highly manufacturer specific.

Apple's CD-300/300i drives can read audio bits directly and turn them
into a QuickTime sound channel, as can SGI's SCSI CD. Apple uses a
Sony mechanism, and SGI uses a Toshiba. The SGI drives use modified
firmware and (AFAIK) are not available elsewhere, but you can get the
Apple drives at Circuit City, Sears, etc.

With the right sequence of SCSI commands you could easily capture an
"audio" bitstream, then munge it as desired to extract the stegged
data, play it backwards, or whatever. IIR, code to directly read
arbitrary audio data on an Apple CD-ROM was recently posted in
comp.sys.mac.programmer, but I didn't save it.

- -Paul

- -- 
Paul Robichaux, KD4JZG     | "Though we live in trying times 
perobich at ingr.com          |  We're the ones who have to try." - Neil Peart
Intergraph Federal Systems | Be a cryptography user- ask me how.
	       Of course I don't speak for Intergraph.

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVen7SA78To+806NAQG3sAQAu8prXRUkJKWwmQBIeJxwQIDK+2ilvyxe
24rcK89EInIyEdLnsSrx4uly3CBpS7iWdOmoAQ9tNu5tOOi3xc+5W5cvUTJ4t/NR
gblnKM/qevO6PCdQFiJXNgzg/1DkY2LsrvnH3I+8lxXeNn06CQKB85r5COY2vL3I
ldqrGjLScHU=
=GjEo
-----END PGP SIGNATURE-----





From norm at netcom.com  Tue Feb  8 08:06:46 1994
From: norm at netcom.com (Norman Hardy)
Date: Tue, 8 Feb 94 08:06:46 PST
Subject: Magic Money ftp
Message-ID: <199402081606.IAA16443@mail.netcom.com>


Is there somewhere that I can ftp the Magic Money protocol from?







From cfrye at ciis.mitre.org  Tue Feb  8 09:11:45 1994
From: cfrye at ciis.mitre.org (Curtis D. Frye)
Date: Tue, 8 Feb 94 09:11:45 PST
Subject: Clipper Opposition
Message-ID: <9402081718.AA04480@ciis.mitre.org>


Fellow C'punks-

This is a copy of a posting I made to comp.eff.org.talk and other groups.

>-------<
In article <EACHUS.94Feb8105146 at spectre.mitre.org> Robert I. Eachus,
eachus at spectre.mitre.org writes:
>In article <strnlghtCKwCrw.DE at netcom.com> strnlght at netcom.com (David
>Sternlight) writes:
>
>  > Once they made it voluntary and promised not to outlaw non-Clipper
>  > crypto, the game was over. Arguments about its becoming de facto
>  > standard and driving out other crypto are simply too complex and
>  > iffy to convince the average reader.
>
>     David, this is where you and I part ways.  You believe that the
>adminstration is promising not to outlaw non-Clipper crypto.  But the
>reality is that the adminstration IS and has been trying its damnedest
>to harrass, intimidate, and suppress any alternative strong crypto.
>The current situation--and the recent announcements confirm this--is
>the adminstration requires a special license to export crypto, which
>you CAN'T get to publish strong crypto (And in some cases to publish
>junk crypto.  If I can't publish a public key and the algorithm to use
>it, what good is it?

David does raise a valid point that I don't think Robert deals with - how
does fighting Clipper help us in the struggle to prevent the outlawing of
all non-Clipper crypto?  If the CPSR and other organizations spend their
political capital on a losing fight, does the credibility loss kill
effective future resistance?

While the Clipper proposal *as it stands now* is most likely a done deal,
there are ways to keep up the pressure to make sure it doesn't snowball:

  o  Mount effective resistance against the Wiretap proposal and *link the
two issues* in the eyes of the public.  This shouldn't be done completely
up front - instead, the association should begin to build after a few weeks
or months to ensure that the original message is received and is not
blocked out by the "you already lost Clipper" signal;

  o  Quote export sale figures of Clipper technology often and loud - I
don't see how any foreign company would let such suspect equipment on their
property, let alone use it to transmit anything sensitive.  I truly hope
I'm not wrong on this count - if the tech sells, the case against Clipper
becomes darn near unwinnable;

  o  Track Clipper equipment purchases by US entities that do not have
government contracts;

  o  Maintain close vigilance over the law enforcement community.  How many
mid-level drug dealers would be willing to use Clipper technology to
implicate their bosses in exchange for lighter sentences?  Expect this
tactic and similar ones to be used;

  o  Compile a list and analysis of all crypto software and equipment
available overseas and compare it to commonly used US techniques.  If the
exported stuff has identical or near-identical functionality to the US
tech, there's no case for Clipper.  Combine this analysis with the export
figures and industry is bound to take notice, with their Congressional reps
following. There should be a follow-up analysis on foreign purchases before
and after Clipper is introduced.  THE FIRST PART OF THIS DOCUMENT SHOULD BE
PREPARED IMMEDIATELY!!!  If someone hasn't already begun this survey, I'll
volunteer and will put out a call for information shortly.

This battle needs to be fought on our ground - the Administration is
defining how the argument is being carried out, for now. Do we know what
our ground is?  What strategy we'll take to counter the Administration's
initiative?  The list I just gave is a series of tactical devices that
could produce specific effects, all of which are USELESS without a coherent
strategy to apply the information gained.  Do I have any suggestions? 
Nope, not beyond the tactics I discussed above.  I am, however, going to
start some serious cogitating and hope to come up with something.

That last bit shouldn't be seen as a slam on the EFF or CPSR as I don't
know what level of planning they've invested in strategy.  What I do know
is that we've lost the initiative and need to regain it; these newsgroups
are a great place to start, but most of us agree on the basic principles
that information should be free etc. etc. etc.  Why should Middle America
care what happens to terrorists and dope pushers?  How long until
"electornic privacy advocates" join that elite group?  It isn't time to
push the PANIC BUTTON yet, but there needs to be a heightened sense of
urgency in everything we do to fight against the possibility that the
Administration wants to ban all non-Clipper crypto.

That possibility scares the hell out of me and is enough to make me act
RIGHT NOW!

Curtis Frye
PRIVATE! Citizen

I don't speak for MITRE, they don't speak for me.

>-------<

--
Best regards,

Curtis D. Frye - Economic Analyst, Software Alchemist, Aspiring Author
cfrye at ciis.mitre.org
"If you think I speak for MITRE, I'll tell you how much they
 pay me and make you feel foolish."







From qwerty at netcom.com  Tue Feb  8 09:30:49 1994
From: qwerty at netcom.com (Xenon)
Date: Tue, 8 Feb 94 09:30:49 PST
Subject: X's Last R.
Message-ID: <199402081729.JAA05241@mail.netcom.com>


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

Disclaimer: The usual. Take this with a grain of salt. As propaganda, at
least its purpose is noble. In this, the final episode in the rant series,
the character Xenon is angry at the evil media-grubbing Cypherpunks for not
noticing, or worse ignoring, that PGP is indeed only "Pretty Good" when it
is considered in its present form.  I hope I haven't lost full respect due
to these essays. I did? Oh well ;-).

P.S. The new finger key server is very happy. Thank-you.

P.S.S Is it easy to modify PGP to remove its "convenience features"? How
about a utility that will strip away the "bare" encrypted message and later
restore it to life. The hell with checksums and the rest. I want my VGP! I
asked this on alt.security.pgp and the silence was amazing. Just a bunch of
flames, and one person who introduced me to steganography.

 -Nik (-=Xenon=-)

AnD br0ught t0 y0u by -=XeNoN=-, an0ther DaMNiNg CrItICism of the
Cypherpunk fad, er... m0vement.

"It'S NEW nEw NeW BuT We'Ll JuSt HiT ThAT 'd' KeY kEy kEY and iT's ByE bYe
DoN't MaKe mE THiNk! THeN, LikE AlWayS, We CAn iGn0re 0uR gReAT SelF
DeCePti0n tHaT wE HaVE a ReaL EncRYpToR. ThIS GuY iSn'T In 0uR Cli-PuBliC-
QuEy liTtlE E-cLuB anYWaY. He'S GoT n0 TitS. hE d0n'T CodE. We JUst WanT t0
TaLK AboUt PoLIticS, NoT bUidIng NeW T0oLs. PhiL DId ThAT ALrEaDy. HE mAdE
uS Co0l. wE LiKE t0 TalK AboUt US, sInCe In US liVEs PhiL. PhiL pHil PHil.
PgPGpGPgpGpGpGPgPgP. Lo0k wh0 SigNed My KeY! I'M oN mTv!"

"But when are you going to write VGP?", asks the quite voice of  humanity,
the ones who weren't invited to your e-party.

If VGP had a "random data block" output format, THEN it doesn't matter if
the Clipper Keys are known. "I'm sending a porno jpeg; my scanner isn't
that great, so it's noisy." Playboy can tag you for copyrights, but if the
fact that "noise" is really an encrypted message is ONLY known by
successfully decrypting it, then even random information highway spot-
checks would be useless. Are they going to outlaw noise? That's like trying
to legislate a change in the speed of light. I wish they WOULD outlaw
noise; it would make my stereo sound better. Phil Zimmerman didn't put a
backdoor in PGP. No, he put a front door. He fucked up, but like the
Founding Fathers who fucked up the Bill of Rights and the Constitution due
to their concern about keeping their Mercedes from the hands of the poor,
he's only human. "Encryption Always Wins." So write us a real encryptor.
Write VGP. Hurry up or I'm going to hire someone to do it for me, then you
wont be the next Phil Zimmerman, I will. Good programmers aren't cheap, but
luckily I don't have to hire a cryptographer, since the equations are
already in text books.

And if you think your a hacker, Cypherpunk, try hacking together a
complicated molecule sometime. The laws of nature constitute a mathematical
computer, and it's so much more rewarding to hack, cause God never updates
His CPU, and the programming language is beautiful and mysterious. Try
coding in DNA or in the language of chemical synthesis if you want to earn
the name "hacker". The interesting people out there are using Macs and
Windows for their personal e-mail. 100 million people who don't have the
time to learn command-line PGP, because their too busy running the world
and getting things done. Write them a fun encryptor and you will find you
have a lot more people who are worth talking to. Since MacPGP2.3 was
obviously never beta tested, it's just not up to snuff. With my guide, it
is at least usable without the frustrating 3 month learning curve needed
for each new user to make own bug work-arounds. At least Detweiler had the
insight to put a useful help feature into MacPGP to make up for the cryptic
documentation, and thus got his name on the startup screen.

I also think that the cryptographers, like the atomic scientists of only a
FEW years ago, should be just as concerned about the impact of their
science. The NSA is our friend damn it, no matter how irresponsible that
friend may at times be. The NSA has been through REAL wars, not internet
pranks. They are OUR National Security Agency. This isn't patriotism; it's
common sense. Tell them we want backdoors to be used for NATIONAL SECURITY
concerns, not to wiretap Greenpeace, and that we want SERIOUS assurances
about this. Let's get the NSA to realize they need to work WITH privacy
activists, not try to ignore or work against them. "Encryption Always
Wins." This isn't about political power and supercomputer resources. Us
versus them. It's about the laws of nature and science leading to
technology being available to the common man. But the government isn't
concerned yet because we haven't yet coded a real encryptor. All we have is
PGP. They can't read content, but they can, like anyone else, see that it
IS encrypted and most often find out who sent it to whom. Clipper also
allows anyone to start recording your Clipper calls NOW, even if they don't
have the keys yet. A random block output would mean anyone could record
your calls and never prove it was anything other than a noisy microphone or
a jpeg of Madonna.

Detweiler became an idiotic child with his "death threats" and "anarchy"
concerns limited to internet (World Wide Wiretap) remailers, added to the
fact that HE seems to be the only one abusing the remailers. He is just
noise (no pun), if this be a discussion of cryptography/anonymity. It
doesn't matter shit if a Detweiler or a Depew takes away our internet toys.
His biggest mistake was to take you guys seriously. Stop talking about the
internet and get serious. Think POSTAL SERVICE encrypted remailing
services, where the pass phrase stays in someone's head, and there is no e-
mail headers telling where that floppy hidden between two halves of a
postcard came from. Think encryption with random data block output. (Think
software to allow me to read that floppy after the rotational indexing is
lost when I separate the metal hub and later put one back on).

The "collapse of governments" claim might get a few rebellious school girls
in cheap leather to follow you home, but it's not worrying the NSA or the
tax man. "You want to drive on this highway? Pay up or go back home." "You
want that CAT scan? We accept cash." "You need unemployment support? Well,
you never paid your insurance tax." Encryption isn't going to end taxes. It
will just change the way they are collected. It will tie a service to your
payment of a tax. "You want us to shoot down that missile headed your way?
Sorry, your community didn't pay for military protection and we don't have
any strategic targets there." "You want to live in this community? Sorry
you have to pay this tax for military protection or you aren't welcome
here." "You want to sell secrets to IRAQ? We've bugged your left ear, the
one you use for the phone. Sorry about the ear ache we had to cause to get
you into the local hospital."

I think the time is coming when we are going to discover what our species
is really all about, since encryption will set us free to be ourselves, as
individuals. I think we will be pleasantly surprised. I just hope we don't
hurt each other trying to resist change. As Bucky Fuller said, "Utopia or
Oblivion." He also warned that we "NOW" (1969) have the technology to
provide everyone on this planet with adequate food and shelter, but that if
we don't give it to them, they are going to walk up that crunchy imported
gravel driveway, past your BMW, and kill you.

Was Phil Zimmerman a "Cypherpunk who wrote PGP"? Or are you guys just strip
mining the CRYPTOGRAPHY movement and selling it back to us at twice the
price? "Anarchy for sale." - Dead Kennedys.

Cypherpunks.
Cypherpunks.
Fuck off!

Send me a computer virus and I'll send you a REAL virus ;-). Stop talking
about the obsolete internet. It's just a primitive non-multimedia medium
for discussion about real life, real privacy, and real people's needs. The
information highway isn't likely to involve Unix or RFC standards. "Can I
send you a gigabyte of my latest movie? Or you can ftp it from my laptop.
You do have 2 gigs of RAM don't you?" Don't follow internet-like standards
when coding an encryptor ["PGP versions 2.3 and later use a new format for
encoding the message digest into the MPI in the signature packet, a format
which is compatible with RFC1425 (formerly RFC1115)." - Phil Zimmerman]. Do
something timeless and historically significant. Write a real encryptor.
Then it doesn't matter if everyone isn't using it, 'cause you're just
sending "noise", like everyone else. Who cares about Clipper? Don't argue
politics. Write code. Easy to use code. Plug and play user interfaces for
the Mac and Windows. Or who else you gonna talk to? E-lovers? E-people?

I'm not a "Cypherpunk", I'm a scientist. An introvert who values his
privacy. I don't need PGP, except for fun, to sign things, and to reduce
the most blatant internet privacy violations. For now it's the internet
standard, but Clipper is good enough for me, personally. It will keep those
around me who I do not wish to share my personal life with from reading my
e-mail and files on my floppies. I don't mind the NSA reading my e-mail.
But I do worry for others, who are trying to change the world in more
political ways, and fear that the NSA will not be the only ones with access
to the keys. PGP activism is just my latest hobby. I just want more people
to talk to, using PGP. I don't want my picture in Wired. You're not PUNKS.
Your just entertainment, until you get off the internet and WRITE A REAL
ENCRYPTOR. The bad guys love PGP. They don't want it to loose its
underground appeal, lest it become less popular and they can no longer
identify encrypted messages. See the big picture and do something useful,
or your just a bunch of e-yuppies worshipping money and attention as the
center of meaning in your life. Fun toys and babes. Die e-yuppie scum.
UNSUBSCRIBE.

 -=Xenon=-

P.S. Thanks for not putting my "Here's How to MacPGP!" guide on any of your
ftp sites. It would have lost its edge, mixed in with all the e-bullshit
already there about "anarchy" on the internet (WWW). And I might not have
had to send it to people by e-mail, people who don't know what ftp MEANS,
because they don't have the time to figure out stupid command-line
operating systems, the historical equivalent of programming via hard-wiring
or punch cards.

-----BEGIN PGP SIGNATURE-----
Version: 2.3

iQCVAgUBLVeCJwSzG6zrQn1RAQFnYwP/WAqeptD+rDCU9Cfyf91IJ6FPmkWJT/mF
5gGhhQmjuugn1VNTzifgh2R6aDtCMA8QkGYbsmSSsphHNhNQbPRhE7/dBj6xMq7F
RjTcfH3Ff1bNXE6y16AVnGGOdAuEEWwCSordu27sR9CJSKSnm2tTOMsxYxEOGsfZ
wX3E2atuek0=
=bYZ6
-----END PGP SIGNATURE-----






From m1tca00 at FRB.GOV  Tue Feb  8 09:46:47 1994
From: m1tca00 at FRB.GOV (Tom Allard)
Date: Tue, 8 Feb 94 09:46:47 PST
Subject: A serious question of ethics
In-Reply-To: <9402071839.AA15102@pmantis.berkeley.edu>
Message-ID: <9402081742.AA26012@mass6.FRB.GOV>



- --------
nobody at pmantis.berkeley.edu wrote:

> Does that mean that I no longer should report the open system (I don't 
> dare telnet there to find out if it is the same one)?

> Also, and I'm purely curious, what actually became of my anonymous 
> report, and do I need to be worried about SS agents in dark sunglasses 
> coming to my home and dragging me away?  (Truely worried and scared)

I work on the Federal Reserve *Board*'s Research Network.  This network
is hidden behind a firewall, and won't even let you finger (much less telnet)
into.

I sent your message to the network administrator, Janice Shack-Marquez
(m1jsm00 at frb.gov).  Obtw, Libby Flanagan has fled to the private sector
(lf at nwu.edu) where vendors can now give her coffee cups with filling out
forms.

Janice (quickly) got at least three people looking into the problem.
Bob Drzyzgula (m1rcd00 at frb.gov) found a machine that perfectly matched the
problems you described.  Bob contacted them, and they seem to have corrected
the problem.

Don't worry about black hats, though.  If anything gets investigated, it outta be
the district bank.

I *would* like to know the IP address you had connected to to verify that
we're talking about the same machine.  You can use the remailers, and encrypt
to my public key (available on the servers, key ID C744CD).  

All the "cool" secrets (wire transfers and the like) don't get anywhere NEAR
the internet.  The Federal Reserve System has a separate (yes, encrypted)
network for sharing data.  The Federal Reserve Banks are all "private"
companies, and several offer various other services (such as economic
bulletin boards and the like).  The Federal Reserve *Board* has Research
network (where I am) used to prepare statistical releases and act as a data
service for the Chairman & Governors.  The Board does not offer any services
to the internet (we should, but that's a long story).  The point of all this
is that you didn't really find anything very sensitive, although we do
appreciate closing gaping holes like that.

rgds-- TA  (tallard at frb.gov)
[awaiting approval of new disclaimer]
pgp fingerprint: 10 49 F5 24 F1 D9 A7 D6  DE 14 25 C8 C0 E2 57 9D

              

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVekwaAudFplx0TNAQHOdAP/WqSUic8PwvEuCkdOBSPZVlxJFwTlYXr8
0lLhnJDgs8+tUPp0Vd9Atc7nsvQM3mZ56xOIWED21KBcBRpaNlUG4E6bT9QrKKDi
dwfR/sHHysdpHx9yB2xlpunlkeBw2jMDEm5YbusgZNHbVpt7AaixcqKVyRrL2wJM
aNaFwEBJFOM=
=gME3
-----END PGP SIGNATURE-----





From beep at how.com  Tue Feb  8 09:56:46 1994
From: beep at how.com (beep at how.com)
Date: Tue, 8 Feb 94 09:56:46 P