diff --git a/_config.yml b/_config.yml
index d752c186a9..3ea6ff8774 100644
--- a/_config.yml
+++ b/_config.yml
@@ -12,10 +12,13 @@ tagarray: []
collections:
years:
- permalink: /:collection/:path/
+ permalink: /archive/:path/
+ output: true
+ months:
+ permalink: /archive/:path/
output: true
emails:
- permalink: /years/:path/
+ permalink: /archive/:path/
output: true
social:
diff --git a/_emails/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6.md b/_emails/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6.md
deleted file mode 100644
index 4e7607a875..0000000000
--- a/_emails/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-layout: default
----
-
-# 1992-10-04 - Secure IRC
-
-## Header Data
-
-From: tcmay@netcom.com (Timothy C. May)
-To: cypherpunks@toad.com
-Message Hash: ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6
-Message ID: \<7w969B2w164w@ideath.goldenbear.com\>
-Reply To: \<9309010251.AA03303@netcom5.netcom.com\>
-UTC Datetime: Tue, 31 Feb 92 17:19:10
-Raw Date: Tue, 31 Aug 93 17:19:10 PDT
-
-## Raw message
-
-```
-From: Arthur Abraham
-Date: Fri, 16 Oct 92 18:04:53 PDT
-To: hh@soda.berkeley.edu
-Subject: Re: Game items...
-Message-ID: <199210170104.AA06520@well.sf.ca.us>
-MIME-Version: 1.0
-Content-Type: text/plain
-
-
-re RU-486: has recently been proven to make a nifty "morning-after" pill (is
-this abortion? only if you believe in the sanctity of blastula) and a study
-in (I believe) S. CA. is beginning on effectiveness in brain tumors... seems
-as if this drug has possible wide theropeutic (aw, who can spell?) uses
-beyond directly sex-lined situations. And RU-P5 is due out 2Q93.
--a2.
-
-
-
-
-
-```
-
-## Thread
-
-+ [Return to January 1992](/years/1992/02/)
-+ [Return to February 1992](/years/1992/02/)
-
-+ 1992-10-01 (Thu, 1 Oct 92 17:43:51 -0400) - [Secure IRC](/years/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6/) - _postmastuh@dawkmastuh.guv_
- + 1992-10-04 (Sun, 4 Oct 92 19:06:41 -0700) - [Secure IRC](/years/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6/) - _Eric Hughes \_
- + 1992-10-04 (Sun, 4 Oct 92 19:06:41 -0700) - Secure IRC - _Eric Hughes \_
- + 1992-10-04 (Sun, 4 Oct 92 19:06:41 -0700) - [Secure IRC](/years/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6/) - _Eric Hughes \_
- + 1992-10-04 (Sun, 4 Oct 92 19:06:41 -0700) - [Secure IRC](/years/1992/02/ee4f48790b0b67f5a81916a65e53d6db4e431405f1287833b50b9630a07694d6/) - _Eric Hughes \_
diff --git a/_emails/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e.md b/_emails/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e.md
new file mode 100644
index 0000000000..0330cdf827
--- /dev/null
+++ b/_emails/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e.md
@@ -0,0 +1,75 @@
+---
+layout: default
+---
+
+# 1992-09-23 - KPFA interview went well
+
+## Header Data
+
+From: tcmay@netcom.com (Timothy C. May)
+To: cypherpunks@toad.com
+Message Hash: 114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e
+Message ID: \<9209232007.AA03117@netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-23 20:25:19 UTC
+Raw Date: Wed, 23 Sep 92 13:25:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: tcmay@netcom.com (Timothy C. May)
+Date: Wed, 23 Sep 92 13:25:19 PDT
+To: cypherpunks@toad.com
+Subject: KPFA interview went well
+Message-ID: <9209232007.AA03117@netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+This is my first test of this list...hope it works...and a brief
+opinion on the KPFA (etc.) interview with our own John Gilmore,
+representing the EFF, Jim Bidzos, of RSA Data Security, and Jim
+Kellstrom (sp?) of the FBI.
+
+I made a tape of it and can bring it to the 10/10/92 crypto meeting.
+
+John did an excellent job of raising the constitutional issues, while
+the FBI guy basically said "Trust us." Jim Bidzos of RSA Data Security
+didn't say much, as the thrust of the discussion was more on
+wiretapping and the proposed Digital Telephony bill, with not much of
+substance said about RSA and public key cryptography.
+
+I waited on the 1-800-464-5732 line to ask about the status of use of
+encryption, especially with RSA and RSA-like systems, but the show ran
+out of time before I could get on.
+
+This series seems timely. Every Wednesday at noon on KPFA. Check your
+local listings and the announcement list John sent out a few days ago.
+
+--Tim
+
+--
+..........................................................................
+Timothy C. May | Crypto Anarchy: encryption, digital money,
+tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
+408-688-5409 | knowledge, reputations, information markets,
+W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
+Higher Power: 2^756839 | RSA MailSafe Public Key: by arrangement
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-23 (Wed, 23 Sep 92 13:25:19 PDT) - KPFA interview went well - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-09-24 (Thu, 24 Sep 92 10:28:07 PDT) - [Re: KPFA interview went well](/years/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a) - _pozar@kumr.lns.com (Tim Pozar)_
+ + 1992-09-24 (Thu, 24 Sep 92 11:13:21 PDT) - [The aural Tim Pozar](/years/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2) - _Eric Hughes \_
+ + 1992-09-24 (Thu, 24 Sep 92 16:42:21 PDT) - [Re: The aural Tim Pozar](/years/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2) - _pozar@kumr.lns.com (Tim Pozar)_
+
diff --git a/_emails/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2.md b/_emails/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2.md
new file mode 100644
index 0000000000..f5c74d5bf8
--- /dev/null
+++ b/_emails/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2.md
@@ -0,0 +1,54 @@
+---
+layout: default
+---
+
+# 1992-09-24 - The aural Tim Pozar
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2
+Message ID: \<9209241811.AA23823@soda.berkeley.edu\>
+Reply To: \
+UTC Datetime: 1992-09-24 18:13:21 UTC
+Raw Date: Thu, 24 Sep 92 11:13:21 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Thu, 24 Sep 92 11:13:21 PDT
+To: cypherpunks@toad.com
+Subject: The aural Tim Pozar
+In-Reply-To:
+Message-ID: <9209241811.AA23823@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Tim Pozar writes:
+
+>I am also the technical consultant to the show, so your mail will not be
+>falling on deft ears...
+
+Just for the record, Tim's _are_ deft, but they are _not_ deaf.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-23 (Wed, 23 Sep 92 13:25:19 PDT) - [KPFA interview went well](/years/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e) - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-09-24 (Thu, 24 Sep 92 10:28:07 PDT) - [Re: KPFA interview went well](/years/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a) - _pozar@kumr.lns.com (Tim Pozar)_
+ + 1992-09-24 (Thu, 24 Sep 92 11:13:21 PDT) - The aural Tim Pozar - _Eric Hughes \_
+ + 1992-09-24 (Thu, 24 Sep 92 16:42:21 PDT) - [Re: The aural Tim Pozar](/years/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2) - _pozar@kumr.lns.com (Tim Pozar)_
+
diff --git a/_emails/1992/09/276aeba05fb25fa848ecbc81e28d6955ccf33532c4d011a74c023ef15ce2c9bc.md b/_emails/1992/09/276aeba05fb25fa848ecbc81e28d6955ccf33532c4d011a74c023ef15ce2c9bc.md
new file mode 100644
index 0000000000..593373ff06
--- /dev/null
+++ b/_emails/1992/09/276aeba05fb25fa848ecbc81e28d6955ccf33532c4d011a74c023ef15ce2c9bc.md
@@ -0,0 +1,197 @@
+---
+layout: default
+---
+
+# 1992-09-25 - secretions
+
+## Header Data
+
+From: Judith Milhon \
+To: cypherpunks@toad.com
+Message Hash: 276aeba05fb25fa848ecbc81e28d6955ccf33532c4d011a74c023ef15ce2c9bc
+Message ID: \<199209251001.AA16909@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-25 10:02:38 UTC
+Raw Date: Fri, 25 Sep 92 03:02:38 PDT
+
+## Raw message
+
+```
+{% raw %}From: Judith Milhon
+Date: Fri, 25 Sep 92 03:02:38 PDT
+To: cypherpunks@toad.com
+Subject: secretions
+Message-ID: <199209251001.AA16909@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+
+"The alternative to mutual trust, which is indeed a risky gamble, is the
+security of the police state."
+ -- Alan Watts
+
+This text may be published in MONDO2000 as my regular column, Irresponsible
+Journalism. Eric Hughes suggested the coda with the toad address, adding
+that it would be amusing to have it almost completely blotted by magic
+marker, as if inadequately censored.
+
+I don't want to be the venom in this toad.
+the idea is to draw in other useful minds. we can assume the WRONG PEOPLE
+already know the address.
+
+lady ada won't apologize for the gonzo wrapping for the ideas; she is
+concerned only that they be correct and clearly stated. clarifications,
+expansions, corrections are welcome. also abuse and threats, for that
+matter... any feedback, please feed me...
+
+
+THE CYPHERPUNK MOVEMENT
+by St. Jude
+
+I don't face-to-face all that much. And I don't like clubs. I was in the
+Black Hole for a reason: The Screamin' Memes were in town for one night
+only -- Thursday, of course. Thursday's the night, now that the weekend
+has annexed Fri. and Mon. I was lurking in the back, hoping not to see
+anybody, when the Jones brothers staked me out. Damn. They are deep into
+the street drugs. Keeping up with the Joneses is nigh impossible; their
+most trivial chitchat is an exercise in decryption. Eddy -- or maybe he
+was being Ellis that night -- was implying something about somebody when my
+right foot detonated down to its steel toe. I looked up -- way up -- to a
+face that wasn't there at all. Just a dome of black cloth, with goggles.
+Three-eyed goggles. Ah: a Chador. I'd heard of that. I screamed: "You
+stomped my foot FLAT!"
+ "Sorry." "Are you okay?" "Oh maaaang." Many overlapping voices, all
+of them synthesized, blurted from above. Out of two tiny speakers hanging
+like earrings off a basketweave headband like a cop's belt. The head
+bowed, bringing it almost within biting range.
+ "Gah. Ow. Ooo." Pretending to be demented with pain, I lurched deep
+into the Chador. But I was cool: I was rootling in there for clues. Ha!
+Male pheromones. Hardish male torso. I was jostling this lumpy equipment
+hanging off him, trying to get a good feel of it without alerting him. Nuh
+uh: _I_ meant electronics... what did _you_ think? Okay: I had some data
+to work with. Male with gadgets. Quelle surprise.
+ "What the hell have you got on your feet? HORSESHOES?"
+ A voice like rushing water: "Kothurni." The Chador shifted a
+little...
+and under his full black skirts I saw them: big weighted club-foot boots
+with concealed lifts, to disguise the wearer's height. Wicked.
+ The pain and the espionage cleared my head. I was ready to deal.
+ "So you're protecting your meat identity, right?"
+ The Chador seemed to teeter a little. It goggled down at me as if I
+were a smear on a slide. Its third-eye goggle was a lens. Check. Out of
+the ambient murk loomed another Chador. Exactly the same height. Right.
+ "How come you guys are in full drag?"
+ "We're here for a... uh... party." The voice from the other Chador was
+a flanged saxophone, but I could swear it had a Texas accent.
+ "Rubbish. You're having a cell meeting, right? "
+ The near Chador, the one I had groped, seemed to teeter again. What
+sounded like a tape player on fast-forward came faintly from its interior.
+An earphone?
+ The saxophone honked: "If I said I even understood what you meant, what
+kind of a chump would that make me?"
+ "I could hazard a guess. I think you're cryptoanarchists -- what I'd
+call cypherpunks!"
+ My Chador cracked up. I could tell. The farther one seemed to stiffen;
+I think it was giving me a hate stare. Hard to manage behind the whole 9
+yards o' cloth.
+ "Is that clever or what? I'm onto you like psilocybe on cowshit, dudes.
+You want to take over the world. Haha hahaha haaaaa."
+ Both of them rocked back a little. I went in after them. "You want to
+talk encryption schemes? Let's talk cryptic. Tales from the cryp'ed. But
+make it fast: The Memes are comin' on." Oh, I was bluffing. I don't know
+much about cryptography. I was just 'tuding them from tech envy. Damn:
+Chadors. And me without the first widget.
+ From the far guy came a cello, very suave: "The world has already been
+taken over. You may have noticed this. We're just trying to get some of
+it back." And the accent was -- Dutch?
+ Bob's yr uncle. Gotcha. I hadn't been certain. Maybe chadors were now
+trendy club gear -- what do I know? "Hey -- that cello's another guy? How
+many you PACKIN' in there?"
+ Out of my Chador a sawtooth rasped: "Variable. People are ringing in
+and out."
+ "You're on line?"
+ "This is a bridge. International." Sawtooth again.
+ The cello resumed, an annoyed cello: "We don't believe in takeovers.
+In fact, we are working to make things UNTAKEOVERABLE."
+ A theremin quivered, "And to make the world safe for anarchy. _We want
+the air-waves, baby_." It snickered across many frequencies.
+ The Tejana saxophone chuckled, (and an eerie treat that was, too):
+"Problem is, how to guarantee privacy for pseudonyms. So you can have a
+pseudonymous economy."
+ A toad croaked: "So, full-RSA encrypted EVERYTHING. No back doors.
+Secure digital money. Swiss bank accounts for the millions."
+ The theremin: "A global monetary system that makes governments obsolete.
+Down come the governments. Goodbye the feds." It sang, whoopingly: "BYE
+BYE, LAWWww." Horrible broad-band snickering.
+ The toad croaked: "Er... yes. Real freedom of speech, too.
+Libertech!"
+ The Dutch cello was all business: "Okay, what does it take? You need
+real-time protocols to prove you own your pseudonym. And your pseudonyms
+have online reputations, via people you've done biz with -- like a
+distributed credit rating system. With maybe designated angels -- Fair
+Witnesses."
+ I was charmed. "And you wear the chador when you face-to-face somebody
+who knows your handle!"
+ The theremin wheeped: "Actually, unmasking your real identity could be
+the ultimate collateral -- your killable, _torturable_ body. Even without
+kids, you've got a hostage to fortune -- your own meat."
+ I was reeling. "Oh yas yas. As Dylan said: 'They asked me for some
+collateral/ and I pulled down my pants'."
+ Orchestral chuckles rained down on me. Was I an international hit?
+ But at that exact moment The Memes hit the stage. The crowd did a 9.1
+Richter lurch and the other Chador pitched onto my LEFT toe, maybe denting
+the steel.
+ "AAIEEeeee. That's great COVERT GEAR you got there, guys. You couldn't
+sneak up on Helen Keller in a HAILSTORM." I was trying to spin down. "And
+dudes -- this is not the neighborhood for flashing the hardware. Getting
+rolled by winos is pretty LOW TECH."
+ A spike-knuckled glove slithered out of the farther guy, clutching what
+looked, in the near-dark, like an electric razor. "_Gonna menace 'em with
+a clean shave_?"
+ The sax: "Stunner. Bottom of the line. But." A hot line of pure
+energy cracked across its little trodes. Of course.
+ Rushing water: "See ya." And they did a fade into the smoke.
+
+ The Screamin' Memes were worthless. To hell with clubs. To hell with
+lots o' things, maybe. I am now sensing my roots, mahn; dey who are my
+bredren. Nerds.
+ Nerds as mainstreamed by the grainy but still fetching Robt Redford in
+Sneakers... Nerds who will have their revenge at last, by making the
+online realer than our current regrettable reality... No, I'm not quite
+delusional. I've heard the cypherpunks are already distributing their
+encrypted email software, which is quick and slick. I might even join the
+revolution, which is, heh, already in progress.
+ Yeah. Why not? Give me libertech or give me... _DES_?
+
+---------------------------------------------------------------------------
+-------------------------
+St. Jude, aka Lady Ada Lovelace, wrote "The Spook in the Machine" for MONDO
+#1, describing the enforcement of DES, the Data Encryption Scam with the
+handy backdoor. She can be reached online as stjude@well.sf.ca.us. Note:
+a definitely false rumor is now circulating that the revolutionists can be
+contacted via cypherpunks@toad.com.
+
+--------------------------------------------------------------------------
+
+feed me?
+
+>jude<
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-25 (Fri, 25 Sep 92 03:02:38 PDT) - secretions - _Judith Milhon \_
+
diff --git a/_emails/1992/09/2fe5a28bc8c23820dc93de1603b58c1ac84c93a16bc852a9b51eb3faed1aa231.md b/_emails/1992/09/2fe5a28bc8c23820dc93de1603b58c1ac84c93a16bc852a9b51eb3faed1aa231.md
new file mode 100644
index 0000000000..cffb0689ab
--- /dev/null
+++ b/_emails/1992/09/2fe5a28bc8c23820dc93de1603b58c1ac84c93a16bc852a9b51eb3faed1aa231.md
@@ -0,0 +1,149 @@
+---
+layout: default
+---
+
+# 1992-09-25 - the hopping remailer is done
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 2fe5a28bc8c23820dc93de1603b58c1ac84c93a16bc852a9b51eb3faed1aa231
+Message ID: \<9209251835.AA00599@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-25 18:37:12 UTC
+Raw Date: Fri, 25 Sep 92 11:37:12 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Fri, 25 Sep 92 11:37:12 PDT
+To: cypherpunks@toad.com
+Subject: the hopping remailer is done
+Message-ID: <9209251835.AA00599@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+The hopping remailer is finished. I wrote it this morning.
+
+The change to make a hopping remailer is very easy. Here's the new
+perl script:
+
+--------- cut here ---------
+while (<>) {
+ last if /^$/ ;
+ $subject = $_ if /^Subject:/ ;
+ if (/^Request-Remailing-To:/) {
+ chop ;
+ s/^.*:// ;
+ $addressee = $_ ;
+ }
+}
+
+#open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ;
+open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ;
+select( OUTPUT ) ;
+
+print "To:" . $addressee . "\n" ;
+print "From: nobody\n" ;
+print $subject ;
+print "Remailed-By: Eric Hughes \n" ;
+
+#
+# check to see if there are header lines in the body to collapse
+# into the full header.
+#
+
+if ( $_ = <> ) {
+ if (/^##$/) {
+ # do nothing if the pasting token appears
+ # the rest of the body will be directly appended
+ # this allows for extra header lines to be added
+ } else {
+ # normal line
+ print "\n" ;
+ print $_ ;
+ }
+} else {
+ # empty body
+ exit ;
+}
+
+while (<>) {
+} continue {
+ print ;
+}
+--------- cut here ---------
+
+Short explanation. The 'print "\n" ;' line was moved inside the new
+if statement. The if statement reads a line of the body and stops the
+script if there is no body. The line read is tested to see if it
+contains the two characters "##" alone on the line. "##" is the ANSI
+C token pasting operator. If there is no pasting, a blank line is
+printed to mark the end of the header and the first line of the body
+is printed. If there is pasting, then the conditional does nothing,
+which has the effect that the body is appended directly onto the end
+of the header, allowing you to add more header lines after the header
+is rewritten.
+
+
+Here is a sample message that I sent myself after the new script was
+installed:
+
+--------- cut here ---------
+To: hughes
+Subject: multiple hops
+Request-Remailing-To: hughes
+
+##
+X-Hop: 1
+Request-Remailing-To: hughes
+
+##
+X-Hop: 2
+Request-Remailing-To: hughes
+
+##
+X-Hop: 3
+
+This is a test message of multiple hops.
+
+Eric
+--------- cut here ---------
+
+
+I received four pieces of mail after sending this to myself. The
+first was the actual letter, which is still delivering normally and
+not being filtered. The next two were the first and second
+remailings; they had X-Hop: 1 and 2. The last message was the final
+one, had X-Hop: 3 in its header and was delivered normally.
+
+At each stage, the header got rewritten and a new
+Request-Remailing-To: line inserted. When that mail got delivered, it
+was again rewritten, with a new remailing request. This process is
+extensible up to the 50K or so practical limitatation on mail size.
+
+Note that this system is not at all secure by itself. But if each
+message body were encrypted first, and the message first decrypted
+before the header re-write took place, the routing instructions as a
+whole would be hidden from prying eyes.
+
+That's the next project.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-25 (Fri, 25 Sep 92 11:37:12 PDT) - the hopping remailer is done - _Eric Hughes \_
+
diff --git a/_emails/1992/09/31baaacc209deb13a95a3cb83d8cdc149943000deccc15c41b37ee3219550d01.md b/_emails/1992/09/31baaacc209deb13a95a3cb83d8cdc149943000deccc15c41b37ee3219550d01.md
new file mode 100644
index 0000000000..cbbac7e047
--- /dev/null
+++ b/_emails/1992/09/31baaacc209deb13a95a3cb83d8cdc149943000deccc15c41b37ee3219550d01.md
@@ -0,0 +1,56 @@
+---
+layout: default
+---
+
+# 1992-09-25 - Pointing out the obvious....
+
+## Header Data
+
+From: Mark Pesce \
+To: cypherpunks@toad.com
+Message Hash: 31baaacc209deb13a95a3cb83d8cdc149943000deccc15c41b37ee3219550d01
+Message ID: \<199209252326.AA19540@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-25 23:27:24 UTC
+Raw Date: Fri, 25 Sep 92 16:27:24 PDT
+
+## Raw message
+
+```
+{% raw %}From: Mark Pesce
+Date: Fri, 25 Sep 92 16:27:24 PDT
+To: cypherpunks@toad.com
+Subject: Pointing out the obvious....
+Message-ID: <199209252326.AA19540@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Hey, Kidz....
+
+
+I don't mean to point out the obvious, but when you mention a certain
+scheme for secure transfer (3 initials, you guess), or a certain organization
+dedicated to keeping it from the public (3 initals, you guess again),
+THEY READ IT.
+
+OK? Did I make my point?
+If not, we're going to unsubscribe from this list like a bat out of hell.
+
+Over,
+OS Corp.
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-25 (Fri, 25 Sep 92 16:27:24 PDT) - Pointing out the obvious.... - _Mark Pesce \_
+
diff --git a/_emails/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a.md b/_emails/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a.md
new file mode 100644
index 0000000000..bfc81b91a9
--- /dev/null
+++ b/_emails/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a.md
@@ -0,0 +1,63 @@
+---
+layout: default
+---
+
+# 1992-09-24 - Re: KPFA interview went well
+
+## Header Data
+
+From: pozar@kumr.lns.com (Tim Pozar)
+To: tcmay@netcom.com (Timothy C. May)
+Message Hash: 484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a
+Message ID: \
+Reply To: \<9209232007.AA03117@netcom.com\>
+UTC Datetime: 1992-09-24 17:28:07 UTC
+Raw Date: Thu, 24 Sep 92 10:28:07 PDT
+
+## Raw message
+
+```
+{% raw %}From: pozar@kumr.lns.com (Tim Pozar)
+Date: Thu, 24 Sep 92 10:28:07 PDT
+To: tcmay@netcom.com (Timothy C. May)
+Subject: Re: KPFA interview went well
+In-Reply-To: <9209232007.AA03117@netcom.com>
+Message-ID:
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Timothy C. May wrote:
+> This is my first test of this list...hope it works...and a brief
+> opinion on the KPFA (etc.) interview with our own John Gilmore,
+> representing the EFF, Jim Bidzos, of RSA Data Security, and Jim
+> Kellstrom (sp?) of the FBI.
+> [...]
+
+ Thanks for your input. If anyone else wants to feed back to the
+program, they can send me email and I will pass it along to the producers.
+I am also the technical consultant to the show, so your mail will not be
+falling on deft ears...
+
+ Tim
+--
+Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555
+UUCP: ...!uunet!kumr.lns.com!pozar
+Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
+Voice: +1 415 788 2022
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-23 (Wed, 23 Sep 92 13:25:19 PDT) - [KPFA interview went well](/years/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e) - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-09-24 (Thu, 24 Sep 92 10:28:07 PDT) - Re: KPFA interview went well - _pozar@kumr.lns.com (Tim Pozar)_
+ + 1992-09-24 (Thu, 24 Sep 92 11:13:21 PDT) - [The aural Tim Pozar](/years/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2) - _Eric Hughes \_
+ + 1992-09-24 (Thu, 24 Sep 92 16:42:21 PDT) - [Re: The aural Tim Pozar](/years/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2) - _pozar@kumr.lns.com (Tim Pozar)_
+
diff --git a/_emails/1992/09/63838c4c1c21215f4440e8cd823b5208586a474466b0784d8d9ce6cc851237ee.md b/_emails/1992/09/63838c4c1c21215f4440e8cd823b5208586a474466b0784d8d9ce6cc851237ee.md
new file mode 100644
index 0000000000..c9cb728f69
--- /dev/null
+++ b/_emails/1992/09/63838c4c1c21215f4440e8cd823b5208586a474466b0784d8d9ce6cc851237ee.md
@@ -0,0 +1,179 @@
+---
+layout: default
+---
+
+# 1992-09-29 - SEIZING THE MEDIA- A NETWOR
+
+## Header Data
+
+From: "Fen Labalme" \
+To: "Cypher Punks" \
+Message Hash: 63838c4c1c21215f4440e8cd823b5208586a474466b0784d8d9ce6cc851237ee
+Message ID: \<9209290409.AA25631@relay2.UU.NET\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-29 04:01:24 UTC
+Raw Date: Mon, 28 Sep 92 21:01:24 PDT
+
+## Raw message
+
+```
+{% raw %}From: "Fen Labalme"
+Date: Mon, 28 Sep 92 21:01:24 PDT
+To: "Cypher Punks"
+Subject: SEIZING THE MEDIA- A NETWOR
+Message-ID: <9209290409.AA25631@relay2.UU.NET>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Mail*Link( Remote SEIZING THE MEDIA: A NETWORKER CONGRESS
+
+from PeaceNet ACTIV-L:
+
+Date: Sat, 26 Sep 1992 23:33:10 CDT
+Sender: Activists Mailing List
+From: "(Rich Winkel)"
+Subject: PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS
+To: Multiple recipients of ACTIV-L
+
+/** gen.media: 141.0 **/
+** Topic: SEIZING THE MEDIA: NETWORKER CONGR **
+** Written 6:39 pm Sep 25, 1992 by openmedia in cdp:gen.media **
+
+ SEIZING THE MEDIA: A NETWORKER CONGRESS
+ A weekend of activity to discuss, self-educate,
+ and put into practice the creation of subversive media.
+
+ 1:30pm Saturday 24 October to 6pm Sunday 25 October 1992
+
+ Media and resource exchange; slides, fax, posters,
+ pamphlets, computer files, ideas, proposals, tactics
+
+ Practical action on billboard improvement and removal;
+ Big Art and postering
+
+ E-mail and fax facility to receive material
+ to be discussed and implemented during the weekend
+
+ Documentation to all participants
+
+ Materials supplied: photocopier reproduction/enlargement
+ and the streets of Oxford
+ Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K.
+
+ If you can't make it in person, you can take part
+ in the Seizing the Media Congress by post, fax, E-mail.
+
+ Send documents, comments, proposals, art, ideas, and posters.
+
+ Post to: BM Jed, London WC1N 3XX, United Kingdom
+ Fax to: (011 441) 0865 72 4317
+ E-Mail to: Eastoxcomcen@GN.APC.ORG
+
+ Accommodation and other information are available from Friday night
+ onwards. To make arrangements or get more information, get in
+ touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545
+ >From the United States: 011 41865 240 545
+
+ Background:
+
+ SEIZING THE MEDIA is the title of pamphlet written by the
+ Immediast Underground and first released in Amsterdam ,
+ New York City, and Seattle in early 1992. The 26 pamphlet
+ combines theory, graphics, research and proposals that examine:
+
+ * Information control
+ * Propaganda and advertising
+ * CIA
+ * Mind control
+ * Immediast counter-offensives
+ * tactics, subversive networking, public empowerment
+ * multi-media
+ * Public production libraries
+ * the liberation of public space
+
+ ...Just when Jesse Helms thought he made the world safe from
+ poetic terrorism, along come the Immediasts, a cadre of media
+ hackers who are fed up with the ecology of coercion that
+ surrounds them. Their booklet SEIZING THE MEDIA proposes an
+ all-out artistic assault on coercive communication, cultural
+ monologue, and media control. They want all media insurgents
+ to take back the airwaves with pirate radio, cable access TV,
+ altering ads and billboards, and otherwise hacking the
+ datasphere to break the spell of State/corporate media control.
+ . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000
+
+ SEIZING THE MEDIA Version 1.1 is available for $3 from
+ Open Media PO Box 2726 Westfield New Jersey 07091 USA
+
+ THE IMMEDIAST UNDERGROUND is a centerless network of artists,
+ writiers, hackers, culture jammers, pirate broadcasters, and
+ posterists who connect with one another through information
+ systems, mail art, networker congresses, and the underground
+ press, and who communicate with the public through actions
+ against all forms of coercive communication, space
+ infringement, and media control.
+ For more info contact:
+ Immediast U. PO Box 2726 Westfield New Jersey 07091 USA
+
+ DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES
+ Since the beginning of the year, members of alternative
+ info-nets, artists, insurgents, and cultural workers have
+ been holding networker congresses, transnational engagements
+ in cultural production, dialogue, collaborations, open
+ exchange, subversive brainstorming, and collective
+ disruptions of dominant culture.
+
+ THE NETWORKER, A NEW PERCEPTION
+ In societies where information is money and media is power,
+ public access is as controlled as the corporate states grip
+ on communication law, censorship, commerce, covert action
+ and surveillance. In this context, uninhibited public
+ communication, expression, and cultural production are acts
+ of freedom, sovereignty, and defiance. Rooted in the drive to
+ connect and exchange with others, Networker Congress engage
+ in culture and media as the battleground for greater openness
+ and freedom.
+
+ MORE INFORMATION about NETWORKER CONGRESSES contact:
+
+ H.R. Fricker
+ Buro fur kunsterische Umtriebe
+ CH 9043 Trogen Switzerland
+
+ Retrofuturism
+ PO Box 2278
+ Iowa City, Iowa 52244
+
+ Face of the Congress
+ FaGaGaGa
+ Po Box 1382
+ Youngstown, Ohio 44501
+
+ Peter Kaufman
+ Bergenwissenstrasse 11
+ CH-8123 EbmatigenDecentralized Networker Congresses
+ Switzerland
+
+ Decentralized Networker Congresses
+
+ Netshaker
+ PO Box 978
+ Hanover, New Hampshire 03766
+
+** End of text from cdp:gen.media **
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-29 (Mon, 28 Sep 92 21:01:24 PDT) - SEIZING THE MEDIA- A NETWOR - _"Fen Labalme" \_
+
diff --git a/_emails/1992/09/6dcabcb0ac94c59c64f95177c1a985dfc027584f9a22e2aed8114ee95c861c01.md b/_emails/1992/09/6dcabcb0ac94c59c64f95177c1a985dfc027584f9a22e2aed8114ee95c861c01.md
new file mode 100644
index 0000000000..1040bbd7fa
--- /dev/null
+++ b/_emails/1992/09/6dcabcb0ac94c59c64f95177c1a985dfc027584f9a22e2aed8114ee95c861c01.md
@@ -0,0 +1,270 @@
+---
+layout: default
+---
+
+# 1992-09-24 - Returned mail: Unable to deliver mail
+
+## Header Data
+
+From: Mailer-Daemon@atdt.org (Mail Delivery Subsystem)
+To: cypherpunks@toad.com
+Message Hash: 6dcabcb0ac94c59c64f95177c1a985dfc027584f9a22e2aed8114ee95c861c01
+Message ID: \<9209242349.AB06629@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-24 23:49:37 UTC
+Raw Date: Thu, 24 Sep 92 16:49:37 PDT
+
+## Raw message
+
+```
+{% raw %}From: Mailer-Daemon@atdt.org (Mail Delivery Subsystem)
+Date: Thu, 24 Sep 92 16:49:37 PDT
+To: cypherpunks@toad.com
+Subject: Returned mail: Unable to deliver mail
+Message-ID: <9209242349.AB06629@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+ ----- Transcript of session follows -----
+554 cypherpunks@toad.com... Recipient names must be specified
+
+ ----- Unsent message follows -----
+Return-Path:
+Received: by atdt.org (5.61+++/JLK-atdt)
+ id AA06629; Thu, 24 Sep 92 19:49:05 -0400
+Date: Thu, 24 Sep 92 19:49:05 -0400
+From: cypherpunks@toad.com
+Message-Id: <9209242349.AA06629@atdt.org>
+To: cypherpunks@toad.com
+Subject: Information Brokers
+
+____________________________________________________________________________
+
+
+SYDNEY MORNING HERALD
+August 13 1992
+
+
+HUGE TRADE IN PERSONAL FILES
+By MALCOLM BROWN
+
+
+Westpac, National Australia Bank, NRMA Insurance Ltd, Custom Credit
+and
+Citicorp are some of the big names in a damning report by the ICAC
+Assistant Commissioner, Mr Adrian Roden, QC, on the unauthorised
+release of
+confidential government information.
+
+
+Mr Roden found that there was a multi-million-dollar trade in such
+information which involved public servants, including police, and
+private
+inquiry agents.
+""Information, from a variety of State and Commonwealth government
+sources
+and the private sector has been freely and regularly sold and
+exchanged for
+many years," he said. "NSW public officials have been heavily
+involved."
+
+
+Mr Roden heard 446 witnesses in public and private hearings over 168
+days
+before compiling his 1,300-page report.
+
+
+Even so, he said, it was necessary to be selective; thousands of
+private
+and commercial inquiry agents had not examined.
+
+
+Mr Roden found that more than 250 people had participated in the
+illicit
+trade or had contributed to it.
+
+OOf these, 155 had engaged in corrupt conduct. A further 101 had
+engaged in
+conduct which allowed, encouraged or caused the occurrence of corrupt
+conduct.
+
+
+Many are NSW and Commonwealth public servants who sold information
+collected by the agencies where they work, including the Roads and
+Traffic
+Authority (RTA), police force, Telecom and Sydney County Council.
+
+
+The Attorney-General, Mr Hannaford, announced that the Director of
+Public
+Prosecutions had set up a task force to consider laying charges
+against
+more than 100 people named in the report.
+
+HHe said many of the public servants named could expect to lose their
+jobs
+and that the heads of all the government departments involved had been
+told
+to examine the report and take action against those involved.
+
+
+The Assistant Police Commissioner, Mr Col Cole, confirmed yesterday
+that
+five police officers had been suspended and announced that three task
+forces had been set up and computer security upgraded.
+
+
+Mr Hannaford foreshadowed the introduction of privacy legislation to
+make
+the unauthorised use of confidential information a criminal offence.
+
+
+The major banks said that they could not condone what their staff had
+done
+but said the staff had believed that they were acting in the best
+interests
+of their employers and the community.
+
+
+None of the banks was planning to sack staff found to be corrupt
+although
+several said the staff had been counselled or "educated".
+
+MMr Roden said the trade involved banks, insurance companies and other
+financial institutions which had provided "a ready market".
+
+
+The link was provided by private and commercial inquiry agents. With
+some
+banks, codes had been used to conceal the nature of the transactions.
+
+
+"As they have gone about their corrupt trade, commercial interest has
+prevailed over commercial ethics, greed ha~ prevailed over public
+duty;
+laws and regulations designed to protect confidentiality have been
+ignored," Mr Roden said.
+
+
+"Frequently the client, generally an insurance company, bank or other
+financial institution, ordered the information from the agent with a
+full
+appreciation of how it was to be obtained.
+
+""The evidence disclosed that in the collection and recovery
+departments of
+a number of those institutions, it has long been standard practice to
+use
+confidential government information . . . as a means of locating
+debtors."
+
+
+Some finance and insurance companies had directed agents to keep all
+references to the trade off invoices and reports.
+
+
+"Some even directed that the agents falsely state the source of the
+information in their reports," Mr Roden said.
+
+
+"Some solicitors in private practice have sought and purchased
+confidential
+government information in circumstances in which they must have known
+that
+it could not have been properly obtained."
+
+
+Mr Kevin Rindfleish, an unlicensed private inquiry agent, had sold
+Department of Motor Transport/Roads and Traffic Authority and social
+security information "on a large scale". His principal client had been
+the
+ANZ Bank.
+AA private investigator, Mr Terence John Hancock, and his company, All
+Cities Investigations Pty Ltd, had sold confidential government
+information
+to the National Australia Bank and Westpac on a regular basis.
+
+
+ Two employees of the NAB had used prior contacts to provide the bank
+with
+access to RTA, social security, Australia Post and immigration
+information.
+Between them, the employees also provided silent numbers and
+information on
+electricity consumers.
+
+
+The Advance Bank had "over a period of years" obtained information
+improperly released from the RTA, the Department of Social Security
+and the
+Department of Immigration. The practice was "known and approved at
+least to
+senior management level".
+
+
+New Zealand Insurance and Manufacturers Mutual had bought confidential
+government information from private investigators.
+
+
+NRMA Insurance Ltd and the Government Insurance Office were "found to
+have
+participated as freely in the illicit trade in confidential government
+information as their more commercially orientated competitors".
+
+
+"Evidence relating to NRMA Insurance Ltd established not only that it
+purchased confidential government information through private
+investigators, but also that investigators were required to obtain
+relevant
+government information by unauthorised means if they were to retain
+the
+company's work."
+EEsanda Finance Corporation Ltd had bought confidential information
+over at
+least 23 years. Custom Credit Corporation Ltd which had engaged in the
+illicit trade over "many years", had maintained false records to
+conceal
+how it obtained information.
+
+
+Alston de Zilwa, former underwriter and operations manager of Citicorp
+Ltd
+and later, Toyota Finance Australia Limited's credit operations
+manager,
+had established for each of the two companies a system for obtaining
+confidential information.
+
+
+The companies would seek information directly from employees of the
+DMA and
+RTA and pay a private inquiry agent, Mr Kevin Robinson, who would
+"launder"
+it, then invoice the companies for the corresponding sum.
+
+
+Mr Roden said that hundreds of thousands of dollars had changed hands
+in
+the trade uncovered. One agent had estimated that he had paid $40,000
+to
+$50,000 a year for Social Security information alone.
+
+
+Another had said he received $100,000 over two years for government
+information.
+YYet another had, according to records, charged a bank $186,000 for
+"inquiry
+services" over a period of 18 months.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-24 (Thu, 24 Sep 92 16:49:37 PDT) - Returned mail: Unable to deliver mail - _Mailer-Daemon@atdt.org (Mail Delivery Subsystem)_
+
diff --git a/_emails/1992/09/736e7c10f33ebf5915a11376d9bb00bd63e298a9770ccbe3072397ca30e5526a.md b/_emails/1992/09/736e7c10f33ebf5915a11376d9bb00bd63e298a9770ccbe3072397ca30e5526a.md
new file mode 100644
index 0000000000..f72a1bfd27
--- /dev/null
+++ b/_emails/1992/09/736e7c10f33ebf5915a11376d9bb00bd63e298a9770ccbe3072397ca30e5526a.md
@@ -0,0 +1,258 @@
+---
+layout: default
+---
+
+# 1992-09-24 - No Subject
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 736e7c10f33ebf5915a11376d9bb00bd63e298a9770ccbe3072397ca30e5526a
+Message ID: \<9209241809.AA23637@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-24 18:10:30 UTC
+Raw Date: Thu, 24 Sep 92 11:10:30 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Thu, 24 Sep 92 11:10:30 PDT
+To: cypherpunks@toad.com
+Subject: No Subject
+Message-ID: <9209241809.AA23637@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+How to Make an Automated Remailer in Your Copious Spare Time with Easy
+to Find and Inexpensive Software Tools You May Have Lying Around.
+
+
+
+
+The basic remailer illustrates how to hook in automated software
+processing into the Unix mail system. Here are the basic elements.
+
+1. .forward
+2. slocal and .maildelivery
+3. remail.perl
+4. /usr/lib/sendmail
+
+--------------------------------------------
+1. .forward
+
+Unix mail provides a way to have accounts on many different machines
+but to receive all your mail in one place. That facility is the
+.forward file, which resides in the home directory. The file is one
+line long and contains the email address to which the mail will be
+forwarded.
+
+But the .forward file has another mode of operation. If the string
+begins with the pipe character '|', the mail will be piped through the
+program listed. Enclose the string with double quotes if you need
+spaces included. Here is my .forward file:
+
+"| /usr/local/lib/mh/slocal -user hughes"
+
+Thus all my mail gets processed by the slocal program, described next.
+
+I don't know where the man page for .forward is. Perhaps someone
+could provide a reference.
+
+---------
+
+2. slocal and .maildelivery
+
+The software system MH contains a bunch of useful tools for handling
+mail, only one of which we need. For details on MH, do 'man mh'.
+
+MH has a nice little mail hook processor called slocal. Its docs can
+be found by 'man mhook'. slocal can conditionally perform operations
+on mail messages and consider them either delivered or not. It allows
+multiple operations on individual mail messages.
+
+slocal reads the file .maildelivery when it starts up for
+instructions. Here is my .maildelivery file:
+
+#
+# field pattern action/ string
+# result (quote included spaces)
+#
+Request-Remailing-To "" pipe R "perl remail.perl"
+Request-Remailing-To "" file R archive.remailer
+
+The various pieces of the .maildelivery file are fully documented in
+the man page. I'll just explain what mine does. Each line describes
+one operation to be performed on each incoming mail message. Fields
+are separated by whitespace, so if you need to include spaces, use
+quotes.
+
+The first field, labelled field, is the mail header field to look for.
+slocal can selectively process on any header line. If the header line
+does not exist, then the mail does not match this line and no
+operation is performed. If the header line does exist, processing
+continues.
+
+The second field, pattern, is a text string to match with the contents
+of that header line, i.e. with everything after the colon. In my
+case, I put the empty string in, which matches everything. You need
+the pair of quotes to have a placeholder for the field contents.
+
+The next field, action, tells what to do with the message. 'pipe'
+sends the message to the standard input of the named program. 'file'
+appends the message to an archive or log file. A useful pipe command
+for testing is "tee foo", which makes a copy of the message in file
+foo, but does not append, so that you get an exact copy of what slocal
+is going to pass to your pipe. This allows testing of the pipe
+program without sending yourself mail all the time.
+
+The next field, result, tells what to do with the message after
+processing. I am currently using R for Regardless to indicate that
+this action should always be performed no matter what. The code R
+indicates that the mail should be considered not delivered after
+processing; thus slocal writes the mail back into my local spool and I
+see it as normal. Later, after I'm sick of looking at all the
+forwarded mail, I'll change this code to A, meaning if the processing
+succeeds, then the mail is considered delivered. The archive file
+will always remain R.
+
+The last field, string, is the parameter to the action. It is a file
+name or program. Use quotes to include spaces. The name of my mail
+processor is "perl remail.perl", which is to run the perl script
+remail.perl on the mail.
+
+The .maildelivery file is also the place to put encryption hooks to
+automatically decrypt the bodies of messages. More on that in a
+future version.
+
+---------
+
+3. remail.perl
+
+Perl is a wonderful language for doing all sorts of useful work like
+processing mail headers. Do 'man perl' for details, or get the
+O'Reilly book and really learn how to use it.
+
+The perl script, in summary, strips off the mail headers, saving the
+Subject: line, rewrites a new header, and appends the body of the
+previous message. Here is the script:
+
+--------- cut here ---------
+while (<>) {
+ last if /^$/ ;
+ $subject = $_ if /^Subject:/ ;
+ if (/^Request-Remailing-To:/) {
+ chop ;
+ s/^.*:// ;
+ $addressee = $_ ;
+ }
+}
+
+#open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ;
+open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ;
+select( OUTPUT ) ;
+
+print "To:" . $addressee . "\n" ;
+print "From: nobody\n" ;
+print $subject ;
+print "Remailed-By: Eric Hughes \n" ;
+print "\n" ;
+
+while (<>) {
+} continue {
+ print ;
+}
+--------- cut here ---------
+
+Here is a summary of the operation. To really understand this, you'll
+have to learn perl.
+
+The while loop processes standard input. 'last' terminates the loop
+as soon as a blank line is seen. A blank line separates the header
+from the body. The subject line, if seen, sets the subject variable
+to the whole subject line. The Request- header line has its final
+newline removed, the contents up to the colon substituted into
+nonexistence, and saves the rest in the addressee variable.
+
+Next the pipe to sendmail is opened and its output is selected so that
+all print commands will go to the pipe. There is a comment for a
+different output channel to the file foo which can be commented in for
+testing.
+
+Next the remailed header is constructed out of print statements.
+
+Lastly the rest of the standard input is passed through unmodified to
+the output channel. The while loop terminates when there is no more
+input.
+
+---------
+
+4. sendmail
+
+sendmail is the backend mailer; it expects complete mail messages and
+does not usually generate any line itself except for the first "From"
+(with no colon) line. Any header you construct will thus get passed
+through mostly unmodified. Hence you can put in any "From:" line you
+want and any other header info, such as my "Remailed-By:" line.
+
+sendmail expects the name of the addressee on its command line,
+otherwise it puts an "Apparently-To:" line in the header.
+
+Any mail processor which remails should probably go through sendmail,
+although it would also be possible to talk to an SMTP port directly,
+were you so motivated. MH also has some remailing programs; see 'man
+mhook'.
+
+---------
+
+A few words for tinkerers.
+
+-- You can always send mail to yourself. Especially after you've done
+one kind of mail processing and want to pass the mail through the
+filters again.
+
+-- When getting started, create an empty .maildelivery file first and
+then get your .forward file working. Test it by sending messages to
+yourself. If you're not getting them, they are going into the bit
+bucket. All your other mail will as well, in this case, so if you
+can't afford to lose mail, do it right the first time or work on a
+spare account.
+
+-- Any mail slocal does not process will get delivered as normal.
+Running a remailer will not interfere with your other work.
+
+-- Remember to use quote marks.
+
+-- You don't need to be a sysadmin to run this kind of remailer.
+There is nothing, however, to prevent a sysadmin from running this
+sofware under an alias. The sysadmin is also a 'trusted user' to
+sendmail and can get rid of pesky "From"-no-colon lines.
+
+-- Perl has a random function which could be used to automatically
+choose various "From:" lines from a database. Remember to include
+yeltsy@kremvax.rus.
+
+-- postnews or inews could be substituted for sendmail. Different
+header lines would have to be created. Such a service could run in
+parallel with a remailer. You too can now repost to alt.sex.bondage!
+
+
+Enjoy. And watch for interesting improvements like encryption.
+
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-24 (Thu, 24 Sep 92 11:10:30 PDT) - No Subject - _Eric Hughes \_
+
diff --git a/_emails/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2.md b/_emails/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2.md
new file mode 100644
index 0000000000..e6dd8deb3f
--- /dev/null
+++ b/_emails/1992/09/90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-09-24 - Re: The aural Tim Pozar
+
+## Header Data
+
+From: pozar@kumr.lns.com (Tim Pozar)
+To: hughes@soda.berkeley.edu (Eric Hughes)
+Message Hash: 90aa886e6ed977b1d1f23bb41ecef6ad549dd017bc141b6bdefb8b0b42e038f2
+Message ID: \
+Reply To: \<9209241811.AA23823@soda.berkeley.edu\>
+UTC Datetime: 1992-09-24 23:42:21 UTC
+Raw Date: Thu, 24 Sep 92 16:42:21 PDT
+
+## Raw message
+
+```
+{% raw %}From: pozar@kumr.lns.com (Tim Pozar)
+Date: Thu, 24 Sep 92 16:42:21 PDT
+To: hughes@soda.berkeley.edu (Eric Hughes)
+Subject: Re: The aural Tim Pozar
+In-Reply-To: <9209241811.AA23823@soda.berkeley.edu>
+Message-ID:
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Eric Hughes wrote:
+> Tim Pozar writes:
+>
+> >I am also the technical consultant to the show, so your mail will not be
+> >falling on deft ears...
+>
+> Just for the record, Tim's _are_ deft, but they are _not_ deaf.
+
+ Thanks... :-)
+
+ Tim
+
+--
+Internet: pozar@kumr.lns.com FidoNet: Tim Pozar @ 1:125/555
+UUCP: ...!uunet!kumr.lns.com!pozar
+Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
+Voice: +1 415 788 2022
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-23 (Wed, 23 Sep 92 13:25:19 PDT) - [KPFA interview went well](/years/1992/09/114d62fabc9ea292aa291c6e0f0a85d514e73fe329f645d92916e8012e9d4a2e) - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-09-24 (Thu, 24 Sep 92 10:28:07 PDT) - [Re: KPFA interview went well](/years/1992/09/484d54b869575b86e1f5f4cbe21959684137e0c875004ff63c502b11f717fb7a) - _pozar@kumr.lns.com (Tim Pozar)_
+ + 1992-09-24 (Thu, 24 Sep 92 11:13:21 PDT) - [The aural Tim Pozar](/years/1992/09/17a09f8ed3e4c3e98e902c889e53518adfcf481d9d8ac1c147fbf572113bebf2) - _Eric Hughes \_
+ + 1992-09-24 (Thu, 24 Sep 92 16:42:21 PDT) - Re: The aural Tim Pozar - _pozar@kumr.lns.com (Tim Pozar)_
+
diff --git a/_emails/1992/09/b4b554a32aff1742f72a2dd539e78d65c7adb945500134a33e2174f795a7e928.md b/_emails/1992/09/b4b554a32aff1742f72a2dd539e78d65c7adb945500134a33e2174f795a7e928.md
new file mode 100644
index 0000000000..4ece851954
--- /dev/null
+++ b/_emails/1992/09/b4b554a32aff1742f72a2dd539e78d65c7adb945500134a33e2174f795a7e928.md
@@ -0,0 +1,51 @@
+---
+layout: default
+---
+
+# 1992-09-24 - Fake Mail
+
+## Header Data
+
+From: cliff_stoll@harvard.edu
+To: hughes@soda.berkeley.edu
+Message Hash: b4b554a32aff1742f72a2dd539e78d65c7adb945500134a33e2174f795a7e928
+Message ID: \<9209240552.AA04259@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-24 05:53:12 UTC
+Raw Date: Wed, 23 Sep 92 22:53:12 PDT
+
+## Raw message
+
+```
+{% raw %}From: cliff_stoll@harvard.edu
+Date: Wed, 23 Sep 92 22:53:12 PDT
+To: hughes@soda.berkeley.edu
+Subject: Fake Mail
+Message-ID: <9209240552.AA04259@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Pssst!
+
+I have a nice fake mail program that interfaces with emacs.
+I'll send it along to anyone who wants it.
+
+PS: Have you seen my latest chocolate chip cookie recipe?
+ Too bad about Martha. Maybe people like me are wed
+ to science...and great cookies.
+
+ADFGVX
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-24 (Wed, 23 Sep 92 22:53:12 PDT) - Fake Mail - _cliff_stoll@harvard.edu_
+
diff --git a/_emails/1992/09/b5e24ee5d6a00a60a5cdd485ad3b67fa4016296e3d5df8faa2c6181e88494b20.md b/_emails/1992/09/b5e24ee5d6a00a60a5cdd485ad3b67fa4016296e3d5df8faa2c6181e88494b20.md
new file mode 100644
index 0000000000..2fa8ffc8eb
--- /dev/null
+++ b/_emails/1992/09/b5e24ee5d6a00a60a5cdd485ad3b67fa4016296e3d5df8faa2c6181e88494b20.md
@@ -0,0 +1,582 @@
+---
+layout: default
+---
+
+# 1992-09-21 - Long but good: Hammill on encryption
+
+## Header Data
+
+From: whitakerNeternity.demon.co.uk.demon.co.uk ("Russell E. Whitaker")
+To: _N/A_
+Message Hash: b5e24ee5d6a00a60a5cdd485ad3b67fa4016296e3d5df8faa2c6181e88494b20
+Message ID: \<717081867snx@eternity.demon.co.uk.demon.co.uk\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-21 13:24:27 UTC
+Raw Date: Mon, 21 Sep 1992 13:24:27 +0000
+
+## Raw message
+
+```
+{% raw %}From: whitakerNeternity.demon.co.uk.demon.co.uk ("Russell E. Whitaker")
+Date: Mon, 21 Sep 1992 13:24:27 +0000
+Subject: Long but good: Hammill on encryption
+Message-ID: <717081867snx@eternity.demon.co.uk.demon.co.uk>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+The following is the text of a *very* interesting speech
+given in 1987 by mathematician Chuck Hammill. The Soviet
+Union is mentioned; while this may be a little dated, there's
+always China... and Cuba... and a few other places...
+
+Enjoy,
+
+Russell
+
+
+
+ FROM CROSSBOWS TO CRYPTOGRAPHY: THWARTING THE STATE VIA
+ TECHNOLOGY
+
+ Given at the Future of Freedom Conference, November 1987
+
+
+ You know, technology--and particularly computer
+technology--has often gotten a bad rap in Libertarian cir-
+cles. We tend to think of Orwell's 1984, or Terry Gilliam's
+Brazil, or the proximity detectors keeping East Berlin's
+slave/citizens on their own side of the border, or the so-
+phisticated bugging devices Nixon used to harass those on
+his "enemies list." Or, we recognize that for the price of
+a ticket on the Concorde we can fly at twice the speed of
+sound, but only if we first walk thru a magnetometer run by
+a government policeman, and permit him to paw thru our be-
+longings if it beeps.
+
+ But I think that mind-set is a mistake. Before there
+were cattle prods, governments tortured their prisoners with
+clubs and rubber hoses. Before there were lasers for
+eavesdropping, governments used binoculars and lip-readers.
+Though government certainly uses technology to oppress, the
+evil lies not in the tools but in the wielder of the tools.
+
+ In fact, technology represents one of the most promis-
+ing avenues available for re-capturing our freedoms from
+those who have stolen them. By its very nature, it favors
+the bright (who can put it to use) over the dull (who can-
+not). It favors the adaptable (who are quick to see the
+merit of the new( over the sluggish (who cling to time-
+tested ways). And what two better words are there to de-
+scribe government bureaucracy than "dull" and "sluggish"?
+
+ One of the clearest, classic triumphs of technology
+over tyranny I see is the invention of the man-portable
+crossbow. With it, an untrained peasant could now reliably
+and lethally engage a target out to fifty meters--even if
+that target were a mounted, chain-mailed knight. (Unlike
+the longbow, which, admittedly was more powerful, and could
+get off more shots per unit time, the crossbow required no
+formal training to utilize. Whereas the longbow required
+elaborate visual, tactile and kinesthetic coordination to
+achieve any degree of accuracy, the wielder of a crossbow
+could simply put the weapon to his shoulder, sight along the
+arrow itself, and be reasonably assured of hitting his tar-
+get.)
+
+ Moreover, since just about the only mounted knights
+likely to visit your average peasant would be government
+soldiers and tax collectors, the utility of the device was
+plain: With it, the common rabble could defend themselves
+not only against one another, but against their governmental
+masters. It was the medieval equivalent of the armor-
+piercing bullet, and, consequently, kings and priests (the
+medieval equivalent of a Bureau of Alcohol, Tobacco and
+Crossbows) threatened death and excommunication, respec-
+tively, for its unlawful possession.
+
+ Looking at later developments, we see how technology
+like the firearm--particularly the repeating rifle and the
+handgun, later followed by the Gatling gun and more advanced
+machine guns--radically altered the balance of interpersonal
+and inter-group power. Not without reason was the Colt .45
+called "the equalizer." A frail dance-hall hostess with one
+in her possession was now fully able to protect herself
+against the brawniest roughneck in any saloon. Advertise-
+ments for the period also reflect the merchandising of the
+repeating cartridge rifle by declaring that "a man on
+horseback, armed with one of these rifles, simply cannot be
+captured." And, as long as his captors were relying upon
+flintlocks or single-shot rifles, the quote is doubtless a
+true one.
+
+ Updating now to the present, the public-key cipher
+(with a personal computer to run it) represents an equiv-
+alent quantum leap--in a defensive weapon. Not only can
+such a technique be used to protect sensitive data in one's
+own possession, but it can also permit two strangers to ex-
+change information over an insecure communications
+channel--a wiretapped phone line, for example, or
+skywriting, for that matter)--without ever having previously
+met to exchange cipher keys. With a thousand-dollar com-
+puter, you can create a cipher that a multi-megabuck CRAY
+X-MP can't crack in a year. Within a few years, it should
+be economically feasible to similarly encrypt voice communi-
+cations; soon after that, full-color digitized video images.
+Technology will not only have made wiretapping obsolete, it
+will have totally demolished government's control over in-
+formation transfer.
+
+ I'd like to take just a moment to sketch the mathemat-
+ics which makes this principle possible. This algorithm is
+called the RSA algorithm, after Rivest, Shamir, and Adleman
+who jointly created it. Its security derives from the fact
+that, if a very large number is the product of two very
+large primes, then it is extremely difficult to obtain the
+two prime factors from analysis of their product. "Ex-
+tremely" in the sense that if primes p and q have 100
+digits apiece, then their 200-digit product cannot in gen-
+eral be factored in less than 100 years by the most powerful
+computer now in existence.
+
+ The "public" part of the key consists of (1) the prod-
+uct pq of the two large primes p and q, and (2) one fac-
+tor, call it x , of the product xy where xy = {(p-1) *
+(q-1) + 1}. The "private" part of the key consists of the
+other factor y.
+
+ Each block of the text to be encrypted is first turned
+into an integer--either by using ASCII, or even a simple
+A=01, B=02, C=03, ... , Z=26 representation. This integer
+is then raised to the power x (modulo pq) and the resulting
+integer is then sent as the encrypted message. The receiver
+decrypts by taking this integer to the (secret) power y
+(modulo pq). It can be shown that this process will always
+yield the original number started with.
+
+ What makes this a groundbreaking development, and why
+it is called "public-key" cryptography," is that I can
+openly publish the product pq and the number x , while
+keeping secret the number y --so that anyone can send me
+an encrypted message, namely
+ x
+ a (mod pq) ,
+but only I can recover the original message a , by taking
+what they send, raising it to the power y and taking the
+result (mod pq). The risky step (meeting to exchange cipher
+keys) has been eliminated. So people who may not even trust
+each other enough to want to meet, may still reliably ex-
+change encrypted messages--each party having selected and
+disseminated his own pq and his x , while maintaining
+the secrecy of his own y.
+
+ Another benefit of this scheme is the notion of a "dig-
+ital signature," to enable one to authenticate the source of
+a given message. Normally, if I want to send you a message,
+I raise my plaintext a to your x and take the result (mod
+your pq) and send that.
+
+ However, if in my message, I take the plaintext a and
+raise it to my (secret) power y , take the result (mod my
+pq), then raise that result to your x (mod your pq) and
+send this, then even after you have normally "decrypted" the
+message, it will still look like garbage. However, if you
+then raise it to my public power x , and take the result
+(mod my public pq ), so you will not only recover the ori-
+ginal plaintext message, but you will know that no one but I
+could have sent it to you (since no one else knows my secret
+y).
+
+ And these are the very concerns by the way that are to-
+day tormenting the Soviet Union about the whole question of
+personal computers. On the one hand, they recognize that
+American schoolchildren are right now growing up with com-
+puters as commonplace as sliderules used to be--more so, in
+fact, because there are things computers can do which will
+interest (and instruct) 3- and 4-year-olds. And it is pre-
+cisely these students who one generation hence will be going
+head-to-head against their Soviet counterparts. For the
+Soviets to hold back might be a suicidal as continuing to
+teach swordsmanship while your adversaries are learning
+ballistics. On the other hand, whatever else a personal
+computer may be, it is also an exquisitely efficient copying
+machine--a floppy disk will hold upwards of 50,000 words of
+text, and can be copied in a couple of minutes. If this
+weren't threatening enough, the computer that performs the
+copy can also encrypt the data in a fashion that is all but
+unbreakable. Remember that in Soviet society publicly ac-
+cessible Xerox machines are unknown. (The relatively few
+copying machines in existence are controlled more inten-
+sively than machine guns are in the United States.)
+
+ Now the "conservative" position is that we should not
+sell these computers to the Soviets, because they could use
+them in weapons systems. The "liberal" position is that we
+should sell them, in the interests of mutual trade and
+cooperation--and anyway, if we don't make the sale, there
+will certainly be some other nation willing to.
+
+ For my part, I'm ready to suggest that the Libertarian
+position should be to give them to the Soviets for free, and
+if necessary, make them take them . . . and if that doesn't
+work load up an SR-71 Blackbird and air drop them over
+Moscow in the middle of the night. Paid for by private sub-
+scription, of course, not taxation . . . I confess that this
+is not a position that has gained much support among members
+of the conventional left-right political spectrum, but, af-
+ter all, in the words of one of Illuminatus's characters, we
+are political non-Euclideans: The shortest distance to a
+particular goal may not look anything like what most people
+would consider a "straight line." Taking a long enough
+world-view, it is arguable that breaking the Soviet govern-
+ment monopoly on information transfer could better lead to
+the enfeeblement and, indeed, to the ultimate dissolution of
+the Soviet empire than would the production of another dozen
+missiles aimed at Moscow.
+
+ But there's the rub: A "long enough" world view does
+suggest that the evil, the oppressive, the coercive and the
+simply stupid will "get what they deserve," but what's not
+immediately clear is how the rest of us can escape being
+killed, enslaved, or pauperized in the process.
+
+ When the liberals and other collectivists began to at-
+tack freedom, they possessed a reasonably stable, healthy,
+functioning economy, and almost unlimited time to proceed to
+hamstring and dismantle it. A policy of political
+gradualism was at least conceivable. But now, we have
+patchwork crazy-quilt economy held together by baling wire
+and spit. The state not only taxes us to "feed the poor"
+while also inducing farmers to slaughter milk cows and drive
+up food prices--it then simultaneously turns around and sub-
+sidizes research into agricultural chemicals designed to in-
+crease yields of milk from the cows left alive. Or witness
+the fact that a decline in the price of oil is considered as
+potentially frightening as a comparable increase a few years
+ago. When the price went up, we were told, the economy
+risked collapse for for want of energy. The price increase
+was called the "moral equivalent of war" and the Feds swung
+into action. For the first time in American history, the
+speed at which you drive your car to work in the morning be-
+came an issue of Federal concern. Now, when the price of
+oil drops, again we risk problems, this time because Ameri-
+can oil companies and Third World basket-case nations who
+sell oil may not be able to ever pay their debts to our
+grossly over-extended banks. The suggested panacea is that
+government should now re-raise the oil prices that OPEC has
+lowered, via a new oil tax. Since the government is seeking
+to raise oil prices to about the same extent as OPEC did,
+what can we call this except the "moral equivalent of civil
+war--the government against its own people?"
+
+ And, classically, in international trade, can you imag-
+ine any entity in the world except a government going to
+court claiming that a vendor was selling it goods too
+cheaply and demanding not only that that naughty vendor be
+compelled by the court to raise its prices, but also that it
+be punished for the act of lowering them in the first place?
+
+ So while the statists could afford to take a couple of
+hundred years to trash our economy and our liberties--we
+certainly cannot count on having an equivalent period of
+stability in which to reclaim them. I contend that there
+exists almost a "black hole" effect in the evolution of
+nation-states just as in the evolution of stars. Once free-
+dom contracts beyond a certain minimum extent, the state
+warps the fabric of the political continuum about itself to
+the degree that subsequent re-emergence of freedom becomes
+all but impossible. A good illustration of this can be seen
+in the area of so-called "welfare" payments. When those who
+sup at the public trough outnumber (and thus outvote) those
+whose taxes must replenish the trough, then what possible
+choice has a democracy but to perpetuate and expand the tak-
+ing from the few for the unearned benefit of the many? Go
+down to the nearest "welfare" office, find just two people
+on the dole . . . and recognize that between them they form
+a voting bloc that can forever outvote you on the question
+of who owns your life--and the fruits of your life's labor.
+
+ So essentially those who love liberty need an "edge" of
+some sort if we're ultimately going to prevail. We obvi-
+ously can't use the altruists' "other-directedness" of
+"work, slave, suffer, sacrifice, so that next generation of
+a billion random strangers can live in a better world."
+Recognize that, however immoral such an appeal might be, it
+is nonetheless an extremely powerful one in today's culture.
+If you can convince people to work energetically for a
+"cause," caring only enough for their personal welfare so as
+to remain alive enough and healthy enough to continue
+working--then you have a truly massive reservoir of energy
+to draw from. Equally clearly, this is just the sort of ap-
+peal which tautologically cannot be utilized for egoistic or
+libertarian goals. If I were to stand up before you tonight
+and say something like, "Listen, follow me as I enunciate my
+noble "cause," contribute your money to support the "cause,"
+give up your free time to work for the "cause," strive
+selflessly to bring it about, and then (after you and your
+children are dead) maybe your children's children will actu-
+ally live under egoism"--you'd all think I'd gone mad. And
+of course you'd be right. Because the point I'm trying to
+make is that libertarianism and/or egoism will be spread if,
+when, and as, individual libertarians and/or egoists find it
+profitable and/or enjoyable to do so. And probably only
+then.
+
+ While I certainly do not disparage the concept of poli-
+tical action, I don't believe that it is the only, nor even
+necessarily the most cost-effective path toward increasing
+freedom in our time. Consider that, for a fraction of the
+investment in time, money and effort I might expend in try-
+ing to convince the state to abolish wiretapping and all
+forms of censorship--I can teach every libertarian who's in-
+terested how to use cryptography to abolish them
+unilaterally.
+
+ There is a maxim--a proverb--generally attributed to
+the Eskimoes, which very likely most Libertarians have al-
+ready heard. And while you likely would not quarrel with
+the saying, you might well feel that you've heard it often
+enough already, and that it has nothing further to teach us,
+and moreover, that maybe you're even tired of hearing it. I
+shall therefore repeat it now:
+
+ If you give a man a fish, the saying runs, you feed him
+for a day. But if you teach a man how to fish, you feed him
+for a lifetime.
+
+ Your exposure to the quote was probably in some sort of
+a "workfare" vs. "welfare" context; namely, that if you
+genuinely wish to help someone in need, you should teach him
+how to earn his sustenance, not simply how to beg for it.
+And of course this is true, if only because the next time he
+is hungry, there might not be anybody around willing or even
+able to give him a fish, whereas with the information on how
+to fish, he is completely self sufficient.
+
+ But I submit that this exhausts only the first order
+content of the quote, and if there were nothing further to
+glean from it, I would have wasted your time by citing it
+again. After all, it seems to have almost a crypto-altruist
+slant, as though to imply that we should structure our ac-
+tivities so as to maximize the benefits to such hungry
+beggars as we may encounter.
+
+ But consider:
+
+ Suppose this Eskimo doesn't know how to fish, but he
+does know how to hunt walruses. You, on the other hand,
+have often gone hungry while traveling thru walrus country
+because you had no idea how to catch the damn things, and
+they ate most of the fish you could catch. And now suppose
+the two of you decide to exchange information, bartering
+fishing knowledge for hunting knowledge. Well, the first
+thing to observe is that a transaction of this type
+categorically and unambiguously refutes the Marxist premise
+that every trade must have a "winner" and a "loser;" the
+idea that if one person gains, it must necessarily be at the
+"expense" of another person who loses. Clearly, under this
+scenario, such is not the case. Each party has gained some-
+thing he did not have before, and neither has been dimin-
+ished in any way. When it comes to exchange of information
+(rather than material objects) life is no longer a zero-sum
+game. This is an extremely powerful notion. The "law of
+diminishing returns," the "first and second laws of
+thermodynamics"--all those "laws" which constrain our possi-
+bilities in other contexts--no longer bind us! Now that's
+anarchy!
+
+ Or consider another possibility: Suppose this hungry
+Eskimo never learned to fish because the ruler of his
+nation-state had decreed fishing illegal. Because fish
+contain dangerous tiny bones, and sometimes sharp spines, he
+tells us, the state has decreed that their consumption--and
+even their possession--are too hazardous to the people's
+health to be permitted . . . even by knowledgeable, willing
+adults. Perhaps it is because citizens' bodies are thought
+to be government property, and therefore it is the function
+of the state to punish those who improperly care for govern-
+ment property. Or perhaps it is because the state gener-
+ously extends to competent adults the "benefits" it provides
+to children and to the mentally ill: namely, a full-time,
+all-pervasive supervisory conservatorship--so that they need
+not trouble themselves with making choices about behavior
+thought physically risky or morally "naughty." But, in any
+case, you stare stupefied, while your Eskimo informant re-
+lates how this law is taken so seriously that a friend of
+his was recently imprisoned for years for the crime of "pos-
+session of nine ounces of trout with intent to distribute."
+
+ Now you may conclude that a society so grotesquely
+oppressive as to enforce a law of this type is simply an
+affront to the dignity of all human beings. You may go far-
+ther and decide to commit some portion of your discretion-
+ary, recreational time specifically to the task of thwarting
+this tyrant's goal. (Your rationale may be "altruistic" in
+the sense of wanting to liberate the oppressed, or
+"egoistic" in the sense of proving you can outsmart the
+oppressor--or very likely some combination of these or per-
+haps even other motives.)
+
+ But, since you have zero desire to become a martyr to
+your "cause," you're not about to mount a military campaign,
+or even try to run a boatload of fish through the blockade.
+However, it is here that technology--and in particular in-
+formation technology--can multiply your efficacy literally a
+hundredfold. I say "literally," because for a fraction of
+the effort (and virtually none of the risk) attendant to
+smuggling in a hundred fish, you can quite readily produce a
+hundred Xerox copies of fishing instructions. (If the tar-
+geted government, like present-day America, at least permits
+open discussion of topics whose implementation is re-
+stricted, then that should suffice. But, if the government
+attempts to suppress the flow of information as well, then
+you will have to take a little more effort and perhaps write
+your fishing manual on a floppy disk encrypted according to
+your mythical Eskimo's public-key parameters. But as far as
+increasing real-world access to fish you have made genuine
+nonzero headway--which may continue to snowball as others
+re-disseminate the information you have provided. And you
+have not had to waste any of your time trying to convert id-
+eological adversaries, or even trying to win over the unde-
+cided. Recall Harry Browne's dictum from "Freedom in an
+Unfree World" that the success of any endeavor is in general
+inversely proportional to the number of people whose persua-
+sion is necessary to its fulfilment.
+
+ If you look at history, you cannot deny that it has
+been dramatically shaped by men with names like Washington,
+Lincoln, . . . Nixon . . . Marcos . . . Duvalier . . .
+Khadaffi . . . and their ilk. But it has also been shaped
+by people with names like Edison, Curie, Marconi, Tesla and
+Wozniak. And this latter shaping has been at least as per-
+vasive, and not nearly so bloody.
+
+ And that's where I'm trying to take The LiberTech
+Project. Rather than beseeching the state to please not en-
+slave, plunder or constrain us, I propose a libertarian net-
+work spreading the technologies by which we may seize
+freedom for ourselves.
+
+ But here we must be a bit careful. While it is not (at
+present) illegal to encrypt information when government
+wants to spy on you, there is no guarantee of what the fu-
+ture may hold. There have been bills introduced, for exam-
+ple, which would have made it a crime to wear body armor
+when government wants to shoot you. That is, if you were to
+commit certain crimes while wearing a Kevlar vest, then that
+fact would constitute a separate federal crime of its own.
+This law to my knowledge has not passed . . . yet . . . but
+it does indicate how government thinks.
+
+ Other technological applications, however, do indeed
+pose legal risks. We recognize, for example, that anyone
+who helped a pre-Civil War slave escape on the "underground
+railroad" was making a clearly illegal use of technology--as
+the sovereign government of the United States of America at
+that time found the buying and selling of human beings quite
+as acceptable as the buying and selling of cattle. Simi-
+larly, during Prohibition, anyone who used his bathtub to
+ferment yeast and sugar into the illegal psychoactive drug,
+alcohol--the controlled substance, wine--was using technol-
+ogy in a way that could get him shot dead by federal agents
+for his "crime"--unfortunately not to be restored to life
+when Congress reversed itself and re-permitted use of this
+drug.
+
+ So . . . to quote a former President, un-indicted co-
+conspirator and pardoned felon . . . "Let me make one thing
+perfectly clear:" The LiberTech Project does not advocate,
+participate in, or conspire in the violation of any law--no
+matter how oppressive, unconstitutional or simply stupid
+such law may be. It does engage in description (for educa-
+tional and informational purposes only) of technological
+processes, and some of these processes (like flying a plane
+or manufacturing a firearm) may well require appropriate li-
+censing to perform legally. Fortunately, no license is
+needed for the distribution or receipt of information it-
+self.
+
+ So, the next time you look at the political scene and
+despair, thinking, "Well, if 51% of the nation and 51% of
+this State, and 51% of this city have to turn Libertarian
+before I'll be free, then somebody might as well cut my
+goddamn throat now, and put me out of my misery"--recognize
+that such is not the case. There exist ways to make your-
+self free.
+
+ If you wish to explore such techniques via the Project,
+you are welcome to give me your name and address--or a fake
+name and mail drop, for that matter--and you'll go on the
+mailing list for my erratically-published newsletter. Any
+friends or acquaintances whom you think would be interested
+are welcome as well. I'm not even asking for stamped self-
+addressed envelopes, since my printer can handle mailing la-
+bels and actual postage costs are down in the noise compared
+with the other efforts in getting an issue out. If you
+should have an idea to share, or even a useful product to
+plug, I'll be glad to have you write it up for publication.
+Even if you want to be the proverbial "free rider" and just
+benefit from what others contribute--you're still welcome:
+Everything will be public domain; feel free to copy it or
+give it away (or sell it, for that matter, 'cause if you can
+get money for it while I'm taking full-page ads trying to
+give it away, you're certainly entitled to your capitalist
+profit . . .) Anyway, every application of these principles
+should make the world just a little freer, and I'm certainly
+willing to underwrite that, at least for the forseeable fu-
+ture.
+
+ I will leave you with one final thought: If you don't
+learn how to beat your plowshares into swords before they
+outlaw swords, then you sure as HELL ought to learn before
+they outlaw plowshares too.
+
+ --Chuck Hammill
+
+ THE LIBERTECH PROJECT
+ 3194 Queensbury Drive
+ Los Angeles, California
+ 90064
+ 310-836-4157
+
+[The above LiberTech address was updated June 1992, with the
+ permission of Chuck Hammill, by:
+
+Russell Earl Whitaker whitaker@eternity.demon.co.uk
+Communications Editor 71750.2413@compuserve.com
+EXTROPY: The Journal of Transhumanist Thought AMIX: RWHITAKER
+Board member, Extropy Institute (ExI)
+[.sig revised 11 September 1992 /// Send mail to eternity node]
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
+pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
+lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
+tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
+by51az4=
+=LOCL
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+
+
+That's it from here.
+
+Over.
+Ono-Sendai Corporation
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-21 (Mon, 21 Sep 1992 13:24:27 +0000) - Long but good: Hammill on encryption - _whitakerNeternity.demon.co.uk.demon.co.uk ("Russell E. Whitaker")_
+
diff --git a/_emails/1992/09/bd1e6c9886e9a2f9780afa9c3aa25f128a88366fc2ee4796813ce0a27f66ca77.md b/_emails/1992/09/bd1e6c9886e9a2f9780afa9c3aa25f128a88366fc2ee4796813ce0a27f66ca77.md
new file mode 100644
index 0000000000..e3e4bde2b6
--- /dev/null
+++ b/_emails/1992/09/bd1e6c9886e9a2f9780afa9c3aa25f128a88366fc2ee4796813ce0a27f66ca77.md
@@ -0,0 +1,47 @@
+---
+layout: default
+---
+
+# 1992-09-25 - through mr. crypto
+
+## Header Data
+
+From: nobody@soda.berkeley.edu
+To: cypherpunks@toad.com
+Message Hash: bd1e6c9886e9a2f9780afa9c3aa25f128a88366fc2ee4796813ce0a27f66ca77
+Message ID: \<9209250231.AA10851@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-25 02:32:44 UTC
+Raw Date: Thu, 24 Sep 92 19:32:44 PDT
+
+## Raw message
+
+```
+{% raw %}From: nobody@soda.berkeley.edu
+Date: Thu, 24 Sep 92 19:32:44 PDT
+To: cypherpunks@toad.com
+Subject: through mr. crypto
+Message-ID: <9209250231.AA10851@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+** I am also the technical consultant to the show, so your mail will not be
+** falling on deft ears...
+
+Awwww.... it wasn't that badly engineered.
+
+sho3t
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-25 (Thu, 24 Sep 92 19:32:44 PDT) - through mr. crypto - _nobody@soda.berkeley.edu_
+
diff --git a/_emails/1992/09/bdccb11e37262b96d2fae5d7defb5b431acc6fb83513bf85f49373e0ee6376b5.md b/_emails/1992/09/bdccb11e37262b96d2fae5d7defb5b431acc6fb83513bf85f49373e0ee6376b5.md
new file mode 100644
index 0000000000..8bba90f52e
--- /dev/null
+++ b/_emails/1992/09/bdccb11e37262b96d2fae5d7defb5b431acc6fb83513bf85f49373e0ee6376b5.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-09-24 - New! Eric's Cheap Remailing Service. Free!
+
+## Header Data
+
+From: nobody@soda.berkeley.edu
+To: cypherpunks@toad.com
+Message Hash: bdccb11e37262b96d2fae5d7defb5b431acc6fb83513bf85f49373e0ee6376b5
+Message ID: \<9209240027.AA27179@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-24 00:28:41 UTC
+Raw Date: Wed, 23 Sep 92 17:28:41 PDT
+
+## Raw message
+
+```
+{% raw %}From: nobody@soda.berkeley.edu
+Date: Wed, 23 Sep 92 17:28:41 PDT
+To: cypherpunks@toad.com
+Subject: New! Eric's Cheap Remailing Service. Free!
+Message-ID: <9209240027.AA27179@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Pssst.
+
+You don't know where you heard this. There's a new service available,
+and it's free.
+
+If you send mail to
+
+ hughes@soda.berkeley.edu
+
+with a header line of the form
+
+ Request-Remailing-To:
+
+then the software will strip off all the header lines (except the
+Subject: line) and remail it to the addressee of your choice.
+
+But there's this rumor that he's saving all the message that pass
+through. Damn.
+
+Mr. Crypto
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-24 (Wed, 23 Sep 92 17:28:41 PDT) - New! Eric's Cheap Remailing Service. Free! - _nobody@soda.berkeley.edu_
+
diff --git a/_emails/1992/09/cf16d07098fa4977f67d9fbeb8ff6eec1d0a578559b800f719727d00fd753581.md b/_emails/1992/09/cf16d07098fa4977f67d9fbeb8ff6eec1d0a578559b800f719727d00fd753581.md
new file mode 100644
index 0000000000..3352f10906
--- /dev/null
+++ b/_emails/1992/09/cf16d07098fa4977f67d9fbeb8ff6eec1d0a578559b800f719727d00fd753581.md
@@ -0,0 +1,95 @@
+---
+layout: default
+---
+
+# 1992-09-22 - Radio program on wiretaps and encryption: Wednesday at noon
+
+## Header Data
+
+From: gnu
+To: cypherpunks@toad.com
+Message Hash: cf16d07098fa4977f67d9fbeb8ff6eec1d0a578559b800f719727d00fd753581
+Message ID: \<9209221917.AA02319@toad.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-22 19:17:43 UTC
+Raw Date: Tue, 22 Sep 92 12:17:43 PDT
+
+## Raw message
+
+```
+{% raw %}From: gnu
+Date: Tue, 22 Sep 92 12:17:43 PDT
+To: cypherpunks@toad.com
+Subject: Radio program on wiretaps and encryption: Wednesday at noon
+Message-ID: <9209221917.AA02319@toad.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Newsgroups: sci.crypt,alt.privacy,alt.activism
+Subject: Radio program on wiretaps and encryption: Wednesday at noon
+Message-Id: <35449@hoptoad.uucp>
+Date: 22 Sep 92 19:15:19 GMT
+
+The Telecommunications Radio Project at KPFA is producing a series of
+thirteen hour-long radio programs on issues in communications. The
+first program is on the FBI's `Digital Telephony' e-z-wiretap proposal
+and the politics of encryption.
+
+The first half-hour will be an introduction and a panel discussion,
+featuring Jim Bidzos of RSA Data Security; Jim Kalstrom, head of
+investigative technology for the FBI; and me, representing the
+Electronic Frontier Foundation. You can phone in questions and comments
+in the second half of the show. The call-in number is:
+
+ +1 800 464 5732
+
+This program will be broadcast live on Wed, September 23, at noon, on
+these California stations:
+
+ KPFA Berkeley
+ KPFK Los Angeles
+ KHSU Arcata
+
+These other stations will be picking up the broadcast,
+and probably transmitting it at a later time. Phone the station to find
+out when it's scheduled.
+
+KMUD Redway, California KCBL Sacramento, California
+KPBS San Diego, California WMNF Tampa, Florida
+KSUI Iowa City, Iowa KSAI Minneapolis, Minnesota
+KSMU Springfield, Missouri WCPN Cleveland, Ohio
+WYSO Yellow Springs, Ohio WBAI New York, New York
+WXXI Rochester, New York WEOS Geneva, New York
+KRCL Salt Lake City, Utah KPBX Spokane, Washington
+KUOW Seattle, Washington
+
+If you are not with in reach of a station that is broadcasting the
+Communications Revolution, please call your local station and pitch it
+to the program director. Have them call the Telecommincations Radio
+Project at KPFA, at +1 510 848 6767 x263 or x264.
+
+Future shows (Wednesdays at noon) will cover isses like how the concept
+of libraries is changing; what information is availible to (and held
+back from) the public; and electronic democracy where the voters can
+feed back directly to goverment agencies or change the outcome of an
+election via computer networks.
+
+Please tune in, and phone in good questions. See you in the airwaves!
+--
+John Gilmore gnu@toad.com -- gnu@cygnus.com -- gnu@eff.org
+"It isn't given to us to know those rare moments when people
+ are wide open and the lightest touch can wither or heal."
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-22 (Tue, 22 Sep 92 12:17:43 PDT) - Radio program on wiretaps and encryption: Wednesday at noon - _gnu_
+
diff --git a/_emails/1992/09/dea8962389f95a613d81ddd1ee911ba94d52c9ffa1af91c5f3e2b33da1145de1.md b/_emails/1992/09/dea8962389f95a613d81ddd1ee911ba94d52c9ffa1af91c5f3e2b33da1145de1.md
new file mode 100644
index 0000000000..312afaedb8
--- /dev/null
+++ b/_emails/1992/09/dea8962389f95a613d81ddd1ee911ba94d52c9ffa1af91c5f3e2b33da1145de1.md
@@ -0,0 +1,50 @@
+---
+layout: default
+---
+
+# 1992-09-26 - Hints
+
+## Header Data
+
+From: not_root@nowhere.com
+To: cypherpunks@toad.com
+Message Hash: dea8962389f95a613d81ddd1ee911ba94d52c9ffa1af91c5f3e2b33da1145de1
+Message ID: \<9209260027.AA08573@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-26 00:27:32 UTC
+Raw Date: Fri, 25 Sep 92 17:27:32 PDT
+
+## Raw message
+
+```
+{% raw %}From: not_root@nowhere.com
+Date: Fri, 25 Sep 92 17:27:32 PDT
+To: cypherpunks@toad.com
+Subject: Hints
+Message-ID: <9209260027.AA08573@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Most internet traffic is archived (and later Grep'd) anyway.
+If you're really that worried about it, then we should have
+been speaking in Aramaic all this time, or using encrypted
+e-mail (and I'm sure traffic which mentions the characters
+"crypt" draws attention as well, and most of the msgs on this
+mailing list have already violated that one.) I'm interested
+to see the PGP addition to the re-mailer.
+
+-- Concerned, yet not overly unrealistic about it.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-26 (Fri, 25 Sep 92 17:27:32 PDT) - Hints - _not_root@nowhere.com_
+
diff --git a/_emails/1992/09/edabc89a8f270cafcb5d558d067e5198da549c2b69c3664e175a4606e39f0898.md b/_emails/1992/09/edabc89a8f270cafcb5d558d067e5198da549c2b69c3664e175a4606e39f0898.md
new file mode 100644
index 0000000000..8330f136d4
--- /dev/null
+++ b/_emails/1992/09/edabc89a8f270cafcb5d558d067e5198da549c2b69c3664e175a4606e39f0898.md
@@ -0,0 +1,44 @@
+---
+layout: default
+---
+
+# 1992-09-24 - Interesting post to alt.cyberpunk.tech
+
+## Header Data
+
+From: Mark Pesce \
+To: cypherpunks@toad.com
+Message Hash: edabc89a8f270cafcb5d558d067e5198da549c2b69c3664e175a4606e39f0898
+Message ID: \<199209240744.AA20447@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-24 07:45:30 UTC
+Raw Date: Thu, 24 Sep 92 00:45:30 PDT
+
+## Raw message
+
+```
+{% raw %}From: Mark Pesce
+Date: Thu, 24 Sep 92 00:45:30 PDT
+To: cypherpunks@toad.com
+Subject: Interesting post to alt.cyberpunk.tech
+Message-ID: <199209240744.AA20447@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Thought ya'll might be interested in this....
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-24 (Thu, 24 Sep 92 00:45:30 PDT) - Interesting post to alt.cyberpunk.tech - _Mark Pesce \_
+
diff --git a/_emails/1992/09/fdf9c19e77ec3f1a9bbc6bc19266d565b89d19dbd0ad369f5a2e800af3fc9558.md b/_emails/1992/09/fdf9c19e77ec3f1a9bbc6bc19266d565b89d19dbd0ad369f5a2e800af3fc9558.md
new file mode 100644
index 0000000000..827b1e8a56
--- /dev/null
+++ b/_emails/1992/09/fdf9c19e77ec3f1a9bbc6bc19266d565b89d19dbd0ad369f5a2e800af3fc9558.md
@@ -0,0 +1,91 @@
+---
+layout: default
+---
+
+# 1992-09-22 - No Subject
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: fdf9c19e77ec3f1a9bbc6bc19266d565b89d19dbd0ad369f5a2e800af3fc9558
+Message ID: \<9209220543.AA25094@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-09-22 05:47:51 UTC
+Raw Date: Mon, 21 Sep 92 22:47:51 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 21 Sep 92 22:47:51 PDT
+To: cypherpunks@toad.com
+Subject: No Subject
+Message-ID: <9209220543.AA25094@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Welcome to the cypherpunks mailing list.
+
+We have a real mailing list now, and not just a mail alias on my
+account. Thanks to John Gilmore for space on hoptoad and Hugh Daniel
+for setting things up.
+
+Mail to the list members at
+
+ cypherpunks@toad.com
+
+Request additions or deletions, talk to the list maintainer (me, Eric
+Hughes) at
+
+ cypherpunks-request@toad.com
+
+Tell your friends about the list and have them join if they wish, and
+have them do the same, but please do not post the list address yet.
+We'd like to have a core group working before we advertise to avoid
+diffusion of interest at the outset.
+
+----------------------
+
+ANNOUNCEMENT
+
+Second Meeting -- October 10, 1992
+
+
+The second meeting will be held at the new Cygnus offices. Exact
+address and directions to follow.
+
+We do not have an exact agenda yet, but one should be arriving in the
+next few days. Please mark you calendars now and start telling your
+friends.
+
+For this meeting and until further announced, we are using a
+transitive trust system for invitations. Invite anybody you want and
+let them invite anybody they want and so on.
+
+The crypto-anarchy game we tried out at the first meeting was as good
+a success as we could have hoped for from an untested idea. The game
+seems useful and fun enough to warrant continued play and play
+testing, so we'll be playing again at this and future meetings.
+
+We observed several interesting emergent behaviors in the first
+session, including resellers and reputation behaviors. We'll play a
+two hour session this time and discuss it afterwards.
+
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [September 1992](/years/1992/09)
+
++ 1992-09-22 (Mon, 21 Sep 92 22:47:51 PDT) - No Subject - _Eric Hughes \_
+
diff --git a/_emails/1992/10/0162570b9d666ee011a10386b278f1a79e9e438ad0c6f94161324578b3c0974c.md b/_emails/1992/10/0162570b9d666ee011a10386b278f1a79e9e438ad0c6f94161324578b3c0974c.md
new file mode 100644
index 0000000000..a115179c25
--- /dev/null
+++ b/_emails/1992/10/0162570b9d666ee011a10386b278f1a79e9e438ad0c6f94161324578b3c0974c.md
@@ -0,0 +1,79 @@
+---
+layout: default
+---
+
+# 1992-10-30 - Subscribe
+
+## Header Data
+
+From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
+To: cypherpunks@toad.com
+Message Hash: 0162570b9d666ee011a10386b278f1a79e9e438ad0c6f94161324578b3c0974c
+Message ID: \
+Reply To: _N/A_
+UTC Datetime: 1992-10-30 19:02:40 UTC
+Raw Date: Fri, 30 Oct 92 12:02:40 PPE
+
+## Raw message
+
+```
+{% raw %}From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
+Date: Fri, 30 Oct 92 12:02:40 PPE
+To: cypherpunks@toad.com
+Subject: Subscribe
+Message-ID:
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+I got this address off Extropians. Sorry if there's a separate
+"request" address I should be using, but I don't know what it is.
+
+Please add me to your mailing list.
+
+Please use one of these addresses:
+
+ Internet: edgar@spectrx.saigon.com
+ UUCP: szebra!spectrx!edgar
+
+The address in the network header may not work.
+
+I'm familiar with how PGP 2.0 works, including some bugs. I'm trying
+to start a low-cost public key registry, which can verify public
+keys independent of the network.
+
+Here is my signed 512-bit public key:
+
+-----Type bits/keyID Date User ID
+-----pub 512/4F0C47 1992/09/26 Edgar W. Swank
+-----sig! 67F70B 1992/10/14 Philip R. Zimmermann
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.02
+
+mQBNAirEvxwAAAECAMUkLHrx6JH45BMd4bxZDNQO3HrLmhZSvsHJzLH9+90BTbuX
+3Kvo0pSLCh98m2Abu/LtoHDggJOKxRGee+5PDEcABRG0KUVkZ2FyIFcuIFN3YW5r
+IDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQKtu1h+J13g7/Z/cLAQFg
+nAQAjRlKmmSvDMZUWKM2BQFmpqHBiaCg7OLKEFng9pZGx2qzYHCZOL+a9A0exN9P
+RAtV6bEm9+F8VoOEpVyF346XJwwE1e/13IETHFi7Jd9fbjsw8voQFqz69X2p8xoE
+LxYtqSlwfOQ3S7JOyyx4/p04fG/JZuRJicVaUIRlDKHJPJ0=
+=tsbS
+-----END PGP PUBLIC KEY BLOCK-----
+
+--
+edgar@spectrx.saigon.com (Edgar W. Swank)
+SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-30 (Fri, 30 Oct 92 12:02:40 PPE) - Subscribe - _edgar@spectrx.Saigon.COM (Edgar W. Swank)_
+
diff --git a/_emails/1992/10/019cdf477893905cbdcbdba0dcfe5805886c1a979a064b38f898dc8d87e9e89d.md b/_emails/1992/10/019cdf477893905cbdcbdba0dcfe5805886c1a979a064b38f898dc8d87e9e89d.md
new file mode 100644
index 0000000000..e2c3392c3a
--- /dev/null
+++ b/_emails/1992/10/019cdf477893905cbdcbdba0dcfe5805886c1a979a064b38f898dc8d87e9e89d.md
@@ -0,0 +1,47 @@
+---
+layout: default
+---
+
+# 1992-10-17 - Re: Game items...
+
+## Header Data
+
+From: Arthur Abraham \
+To: hh@soda.berkeley.edu
+Message Hash: 019cdf477893905cbdcbdba0dcfe5805886c1a979a064b38f898dc8d87e9e89d
+Message ID: \<199210170104.AA06520@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-17 01:04:53 UTC
+Raw Date: Fri, 16 Oct 92 18:04:53 PDT
+
+## Raw message
+
+```
+{% raw %}From: Arthur Abraham
+Date: Fri, 16 Oct 92 18:04:53 PDT
+To: hh@soda.berkeley.edu
+Subject: Re: Game items...
+Message-ID: <199210170104.AA06520@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+re RU-486: has recently been proven to make a nifty "morning-after" pill (is
+this abortion? only if you believe in the sanctity of blastula) and a study
+in (I believe) S. CA. is beginning on effectiveness in brain tumors... seems
+as if this drug has possible wide theropeutic (aw, who can spell?) uses
+beyond directly sex-lined situations. And RU-P5 is due out 2Q93.
+-a2.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-17 (Fri, 16 Oct 92 18:04:53 PDT) - Re: Game items... - _Arthur Abraham \_
+
diff --git a/_emails/1992/10/01dd3338e31b454f5ddf16d8d379d36e6690381811c64d219d0f07c6a96a902b.md b/_emails/1992/10/01dd3338e31b454f5ddf16d8d379d36e6690381811c64d219d0f07c6a96a902b.md
new file mode 100644
index 0000000000..1782f70dcf
--- /dev/null
+++ b/_emails/1992/10/01dd3338e31b454f5ddf16d8d379d36e6690381811c64d219d0f07c6a96a902b.md
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+# 1992-10-19 - one time pads.
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 01dd3338e31b454f5ddf16d8d379d36e6690381811c64d219d0f07c6a96a902b
+Message ID: \<9210191548.AA01490@soda.berkeley.edu\>
+Reply To: \<9210190136.1.13588@cup.portal.com\>
+UTC Datetime: 1992-10-19 15:48:48 UTC
+Raw Date: Mon, 19 Oct 92 08:48:48 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 19 Oct 92 08:48:48 PDT
+To: cypherpunks@toad.com
+Subject: one time pads.
+In-Reply-To: <9210190136.1.13588@cup.portal.com>
+Message-ID: <9210191548.AA01490@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Keith's CD-for-a-pad idea is a variant of a book code. In a book
+code, parts of the key are in various standard books, often the bible.
+
+Advantages: easier key distribution.
+
+Disadvantages: key material is public. Should an internal spy learn
+the few bits of addressing information (which CD, where), the cipher
+is compromised.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-19 (Mon, 19 Oct 92 02:21:17 PDT) - [one time pads.](/years/1992/10/ed656b95f52bf63782f7b835e6ae14c1bd892422ed6422815953acd9285309f7) - _hkhenson@cup.portal.com_
+ + 1992-10-19 (Mon, 19 Oct 92 08:48:48 PDT) - one time pads. - _Eric Hughes \_
+ + 1992-10-20 (Mon, 19 Oct 92 17:09:14 PDT) - [one time pads.](/years/1992/10/aa4ce8970b83924042b4db610a7bd986514f98bf7dffd14a05363fce934e7c9c) - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/01dddd6d92298c29d33c6a80d463aafff03a2ab4ad339017eeac7855d5d198f5.md b/_emails/1992/10/01dddd6d92298c29d33c6a80d463aafff03a2ab4ad339017eeac7855d5d198f5.md
new file mode 100644
index 0000000000..5347634716
--- /dev/null
+++ b/_emails/1992/10/01dddd6d92298c29d33c6a80d463aafff03a2ab4ad339017eeac7855d5d198f5.md
@@ -0,0 +1,45 @@
+---
+layout: default
+---
+
+# 1992-10-16 - Re: Who uses ethernet (Mr Squirrel?)
+
+## Header Data
+
+From: George A. Gleason \
+To: shipley@tfs.COM
+Message Hash: 01dddd6d92298c29d33c6a80d463aafff03a2ab4ad339017eeac7855d5d198f5
+Message ID: \<199210160927.AA11421@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-16 09:28:15 UTC
+Raw Date: Fri, 16 Oct 92 02:28:15 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Fri, 16 Oct 92 02:28:15 PDT
+To: shipley@tfs.COM
+Subject: Re: Who uses ethernet (Mr Squirrel?)
+Message-ID: <199210160927.AA11421@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Tom, if you're interested in ISDN, my organisation (Integrated Signal) will
+probably be in a position to hook you up early next year. We're 90% certain
+to be putting in a network very close to your neighborhood.
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-16 (Fri, 16 Oct 92 02:28:15 PDT) - Re: Who uses ethernet (Mr Squirrel?) - _George A. Gleason \_
+
diff --git a/_emails/1992/10/027aedd907cd2259e85e2d6a68d28423eb507129b907c2ae6cff84c4d4d1fe90.md b/_emails/1992/10/027aedd907cd2259e85e2d6a68d28423eb507129b907c2ae6cff84c4d4d1fe90.md
new file mode 100644
index 0000000000..11f23657fa
--- /dev/null
+++ b/_emails/1992/10/027aedd907cd2259e85e2d6a68d28423eb507129b907c2ae6cff84c4d4d1fe90.md
@@ -0,0 +1,182 @@
+---
+layout: default
+---
+
+# 1992-10-13 - New remailer...
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: CYPHERPUNKS \
+Message Hash: 027aedd907cd2259e85e2d6a68d28423eb507129b907c2ae6cff84c4d4d1fe90
+Message ID: \<921013203148_74076.1041_DHJ21-1@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-13 20:37:43 UTC
+Raw Date: Tue, 13 Oct 92 13:37:43 PDT
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Tue, 13 Oct 92 13:37:43 PDT
+To: CYPHERPUNKS
+Subject: New remailer...
+Message-ID: <921013203148_74076.1041_DHJ21-1@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+I have been experimenting with Eric's remailing software on
+the Sun 4 I use at work. This is what I've found.
+
+First, Eric's descriptions of how all the different software
+components work together have been very helpful. The software
+has gone through three revisions as Eric added new features, so
+I implemented them in that order - first the basic remailer,
+then adding the "##" and "::" support for header management.
+
+(I had to get perl and slocal before I could get started.
+Luckily my system already uses sendmail.)
+
+Basically, I was able to put the parts together the way Eric
+described and have it work. I was able to send messages and
+have them remailed. I even did some tests bouncing mail between
+my remailer and Eric's.
+
+Then I tried adding a new feature to the remailer - automatic
+message decryption using PGP. It's not really very secure since
+anyone with root privileges at my site can see my pass phrase,
+but my site is pretty isolated (a 2400 baud modem is the only link
+to the outside world). For this I had to add one line to Eric's
+model .maildelivery file to invoke my PGP filter, and had to write
+about a five line shell script to run PGP in a useful way. I
+am still tuning this a little bit but I can send the exact scripts
+out when people are ready for them.
+
+One nice thing about this is that, with my remailer plus Eric's,
+and with the decryption option, you can now send anonymous messages
+for which no one person can tell that you did it. What you would
+do is to send the message first through Eric's remailer, so I
+don't know where it came from, then through my remailer, but with
+the message encrypted so that Eric can't tell where it's going after
+it leaves me. If more people will run remailers then we'll have
+much more security.
+
+I will now tell you how to use it, in case you want to experiment.
+But remember that all messages are going across an intermittently-
+polled 2400 baud modem, so don't expect fast turnaround and please
+don't send a large volume of messages. Also, please don't pass
+information about this remailer beyond this list, for now.
+
+The remailer is at hal@ghs.com. The basic remailing operation is
+as Eric has described: either put "Request-Remailing-To: " in
+the header of the message, or put, as the first two lines of the
+body of your message:
+
+::
+Request-Remailing-To:
+
+And follow these two lines with a blank line, then the message to
+be forwarded.
+
+Decryption is just a little complicated. The thing to remember is
+that you want to do more than just have me decrypt the message. You
+want me to then remail the message after decryption. This means
+that you should prepare a message with remailing instructions as
+above, then encrypt the whole thing, including the "::" and
+"Request-Remailing-To:" lines. Encrypt using PGP with the public
+key I show below, and use the -a flag for Ascii output.
+
+This will create a PGP output file, typically with the extension .asc.
+The first line will be:
+
+-----BEGIN PGP MESSAGE-----
+
+Now, you can send this message to me, but you have to do one more
+thing. You have to mark it as an encrypted message, by putting the
+line "Encrypted: PGP" in the header. If you can't put stuff into
+the headers of messages, then use Eric's "::" feature and add the
+following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----":
+
+::
+Encrypted: PGP
+
+Don't forget the blank line after these two.
+
+Now, this message can be sent to my remailer. It will be decrypted
+and then remailed to whomever you requested.
+
+I know this sounds complicated, so let me break it down into steps:
+
+ 1. Create the message.
+
+ 2. Add "::" and "Request-Remailing-To: " and a blank line to the
+ top.
+
+ 3. Encrypt the whole file using PGP and the public key below.
+
+ 4. Add "::" and "Encrypted: PGP" and a blank line to the top of
+ the encrypted file.
+
+ 5. Send it to hal@ghs.com.
+
+That's not so bad, is it?
+
+Now, if you're really adventurous, here's how to do the double-remailing
+process I described above, the one which keeps any one remailer from
+knowing who's talking to whom.
+
+ 1. Create the message.
+
+ 2. Add "::" and "Request-Remailing-To: " and a blank line to the
+ top.
+
+ 3. Encrypt the whole file using PGP and the public key below.
+
+ 4. Add "::" and "Request-Remailing-To: hal@ghs.com", then a blank line,
+ then "##" then "Encrypted: PGP", then a blank line, to the top of
+ the encrypted file.
+
+ 5. Send it to hughes@soda.berkeley.edu
+
+The only complicated step is step 4, where you put in the remailing
+request to go from Eric's system to mine, and use the "##" line so
+that the outgoing message has "Encrypted: PGP" in the header.
+
+If you want real security, encrypt the message using your friend's
+public key after step 1 and send that. Then nobody will even know
+what you're saying, let alone who you're talking to.
+
+As promised, here's the public key for my remailer:
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.01
+
+mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l
+oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2
+aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA
+7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H
+WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5
+hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ==
+=p8FS
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+Hal
+74076.1041@compuserve.com
+
+P.S. Coming soon: anonymous return addresses!
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-13 (Tue, 13 Oct 92 13:37:43 PDT) - New remailer... - _Hal \<74076.1041@CompuServe.COM\>_
+
diff --git a/_emails/1992/10/028104239841ce7ed12abdf25e98b3f8d6f6ed3ca45ae4c095e115cb184c3b35.md b/_emails/1992/10/028104239841ce7ed12abdf25e98b3f8d6f6ed3ca45ae4c095e115cb184c3b35.md
new file mode 100644
index 0000000000..509b04ee28
--- /dev/null
+++ b/_emails/1992/10/028104239841ce7ed12abdf25e98b3f8d6f6ed3ca45ae4c095e115cb184c3b35.md
@@ -0,0 +1,53 @@
+---
+layout: default
+---
+
+# 1992-10-31 - Re: remove from mailing list
+
+## Header Data
+
+From: Andrew Purshottam \
+To: cypherpunks@toad.com
+Message Hash: 028104239841ce7ed12abdf25e98b3f8d6f6ed3ca45ae4c095e115cb184c3b35
+Message ID: \<9210302349.AA01575@meefun.YP.acad\>
+Reply To: \<9210242237.aa22143@src4src.linet.org\>
+UTC Datetime: 1992-10-31 00:50:53 UTC
+Raw Date: Fri, 30 Oct 92 17:50:53 PPE
+
+## Raw message
+
+```
+{% raw %}From: Andrew Purshottam
+Date: Fri, 30 Oct 92 17:50:53 PPE
+To: cypherpunks@toad.com
+Subject: Re: remove from mailing list
+In-Reply-To: <9210242237.aa22143@src4src.linet.org>
+Message-ID: <9210302349.AA01575@meefun.YP.acad>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Are you Jethroes still using berkeley mail? Get a real mail user
+agent, like MH, and you can write a pattern that collects all the mail
+sent to a given address into a mail folder, effectively making your
+own digest.
+
+Andy
+
+
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sat, 24 Oct 92 21:11:19 PDT) - [remove from mailing list](/years/1992/10/9bfdbcec27940a27cd9e7024fe2b938174899c51cbfa7016369746042e754a55) - _joeb@arden.linet.org_
+ + 1992-10-31 (Fri, 30 Oct 92 17:50:53 PPE) - Re: remove from mailing list - _Andrew Purshottam \_
+
diff --git a/_emails/1992/10/033ae3ee73aaa2679f7aa880c4601e687ba98804670907595faf860d3d0c2981.md b/_emails/1992/10/033ae3ee73aaa2679f7aa880c4601e687ba98804670907595faf860d3d0c2981.md
new file mode 100644
index 0000000000..8f71a18cf9
--- /dev/null
+++ b/_emails/1992/10/033ae3ee73aaa2679f7aa880c4601e687ba98804670907595faf860d3d0c2981.md
@@ -0,0 +1,48 @@
+---
+layout: default
+---
+
+# 1992-10-12 - Next meeting: Nov. 21
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 033ae3ee73aaa2679f7aa880c4601e687ba98804670907595faf860d3d0c2981
+Message ID: \<9210121527.AA23015@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-12 15:20:43 UTC
+Raw Date: Mon, 12 Oct 92 08:20:43 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 12 Oct 92 08:20:43 PDT
+To: cypherpunks@toad.com
+Subject: Next meeting: Nov. 21
+Message-ID: <9210121527.AA23015@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+The next physical cypherpunks meeting was decided on Saturday at
+that meeting. It will be Saturday, November 21, starting at noon at
+the Cygnus Support offices in Mountain View. I am announcing the date
+now so that you can put it on your calendar.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-12 (Mon, 12 Oct 92 08:20:43 PDT) - Next meeting: Nov. 21 - _Eric Hughes \_
+
diff --git a/_emails/1992/10/041ccd8442454608e3dec5534526a715161e63caf6d81ac5e2f5ea068bf6c330.md b/_emails/1992/10/041ccd8442454608e3dec5534526a715161e63caf6d81ac5e2f5ea068bf6c330.md
new file mode 100644
index 0000000000..976fb9f1b3
--- /dev/null
+++ b/_emails/1992/10/041ccd8442454608e3dec5534526a715161e63caf6d81ac5e2f5ea068bf6c330.md
@@ -0,0 +1,60 @@
+---
+layout: default
+---
+
+# 1992-10-21 - TEMPEST, Eavesdropping
+
+## Header Data
+
+From: pmetzger@shearson.com (Perry E. Metzger)
+To: cypherpunks@toad.com
+Message Hash: 041ccd8442454608e3dec5534526a715161e63caf6d81ac5e2f5ea068bf6c330
+Message ID: \<9210211934.AA09886@newsu.shearson.com\>
+Reply To: \<9210211711.AA11833@soda.berkeley.edu\>
+UTC Datetime: 1992-10-21 21:07:37 UTC
+Raw Date: Wed, 21 Oct 92 14:07:37 PDT
+
+## Raw message
+
+```
+{% raw %}From: pmetzger@shearson.com (Perry E. Metzger)
+Date: Wed, 21 Oct 92 14:07:37 PDT
+To: cypherpunks@toad.com
+Subject: TEMPEST, Eavesdropping
+In-Reply-To: <9210211711.AA11833@soda.berkeley.edu>
+Message-ID: <9210211934.AA09886@newsu.shearson.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+>From: Eric Hughes
+
+>>Their chief concern doesn't seem to be folks like us, but rather
+>>concerns about vans parking outside high tech and defense contractors
+>>and slurping up what they can [...]
+
+>When banks start signing with private keys, then we get an even more
+>interesting monitoring problem.
+
+Consider that the international clearing and settlement systems for
+interbank transactions process several TRILLION a day in electronic
+transactions, and then consider what diverting just a tiny little bit
+of that to yourself would be worth. Security in banks is ALREADY
+crucial.
+
+Perry
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-21 (Wed, 21 Oct 92 10:11:42 PDT) - [TEMPEST, Eavesdropping](/years/1992/10/4d3c0b68b446f11f664d02d6696ac26026c7e92e0e14c93cbc6235b7eb4495c3) - _Eric Hughes \_
+ + 1992-10-21 (Wed, 21 Oct 92 14:07:37 PDT) - TEMPEST, Eavesdropping - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/07ae1782d78a668866ed682f440cba74ebbd27148657ab8bcb66f1a7d5c36516.md b/_emails/1992/10/07ae1782d78a668866ed682f440cba74ebbd27148657ab8bcb66f1a7d5c36516.md
new file mode 100644
index 0000000000..79b7e56b7a
--- /dev/null
+++ b/_emails/1992/10/07ae1782d78a668866ed682f440cba74ebbd27148657ab8bcb66f1a7d5c36516.md
@@ -0,0 +1,88 @@
+---
+layout: default
+---
+
+# 1992-10-09 - New feature of the remailer
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 07ae1782d78a668866ed682f440cba74ebbd27148657ab8bcb66f1a7d5c36516
+Message ID: \<9210090703.AA26448@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-09 06:56:11 UTC
+Raw Date: Thu, 8 Oct 92 23:56:11 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Thu, 8 Oct 92 23:56:11 PDT
+To: cypherpunks@toad.com
+Subject: New feature of the remailer
+Message-ID: <9210090703.AA26448@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+New! Just finished. Fidonet support. Dumb mailer support. Incoming
+header line pasting.
+
+Here's what's going on. There are a lot of mailers, the Fidonet
+gateway in particular, which don't allow you to put arbitrary header
+lines in your outgoing messages. Previously people using these
+systems couldn't use the remailer because they couldn't put the
+necessary "Request-Remailing-To:" in the header.
+
+Now they can. Instead of putting header lines into actual header, I
+now support a syntax which allows header lines to be _added_ to the
+header on incoming mail. These extended header lines are in the body
+of the message proper, but a filter on incoming mail effectively
+adds them to the header.
+
+This allows anybody who can send me mail with a reasonably unmangled
+body to use any feature of the remailer that should ever get written.
+
+Example:
+
+------- cut here -------
+
+To: hughes@soda.berkeley.edu
+From: Secret_Squirrel@treehouse.com
+Subject: Mrs. Tree's secret recipe for pinole
+
+::
+Request-Remailing-To: Crusader_Rabbit@rocky.moosylvania.org
+
+I just paid $2600 for this recipe [etc. etc.]
+[...]
+
+------- cut here -------
+
+If "::" is on the first body line all by itself, whatever lines follow
+up to the first blank line will be appended to the header when it is
+scanned for special instruction lines.
+
+This new feature is completely modular. It doesn't (seem to) break
+any of the other existing features. I'll post the source with an
+explanation tomorrow.
+
+In the meantime, try it out.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Thu, 8 Oct 92 23:56:11 PDT) - New feature of the remailer - _Eric Hughes \_
+ + 1992-10-09 (Fri, 9 Oct 92 00:14:13 PDT) - [Re: New feature of the remailer](/years/1992/10/469abb614c7863da4b08c8492ddedd9268dc6c9ee9e116c72675887290677963) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/098ca600122482f9530453b1ebec0212ca1c89ee459be44f395c8b1c1a939bde.md b/_emails/1992/10/098ca600122482f9530453b1ebec0212ca1c89ee459be44f395c8b1c1a939bde.md
new file mode 100644
index 0000000000..d967ae0204
--- /dev/null
+++ b/_emails/1992/10/098ca600122482f9530453b1ebec0212ca1c89ee459be44f395c8b1c1a939bde.md
@@ -0,0 +1,218 @@
+---
+layout: default
+---
+
+# 1992-10-28 - Threat to our privacy
+
+## Header Data
+
+From: pmetzger@shearson.com (Perry E. Metzger)
+To: cypherpunks@toad.com
+Message Hash: 098ca600122482f9530453b1ebec0212ca1c89ee459be44f395c8b1c1a939bde
+Message ID: \<9210272346.AA11735@newsu.shearson.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-28 00:23:08 UTC
+Raw Date: Tue, 27 Oct 92 17:23:08 PPE
+
+## Raw message
+
+```
+{% raw %}From: pmetzger@shearson.com (Perry E. Metzger)
+Date: Tue, 27 Oct 92 17:23:08 PPE
+To: cypherpunks@toad.com
+Subject: Threat to our privacy
+Message-ID: <9210272346.AA11735@newsu.shearson.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+For Cypherpunks: A copy of mail I just sent to...
+ libernet@dartmouth.edu, extropians@gnu.ai.mit.edu,
+ prz@sage.cgd.ucar.edu, mike@eff.org, mkapor@eff.org
+
+
+[This is being sent out to a wide audiance. If you receive this, its
+because
+
+My friends, its rare of me to try to encourage panic. Occassionally,
+however, by panicing early we can avert a disaster later on.
+
+Risks, an internet mailing list, reported about a week ago on a
+proposal by Dr. Dorothy Denning, one of the most prominent people in
+the field of cryptography, that copies of all private encryption keys
+associated with public key cryptographic systems be held, effectively
+by the government, to permit them to read people's encrypted messages
+to each other. Naturally, such invasions of privacy will only be
+permitted "when a warrant is produced". It has been suggested that
+this idea might be taken up by several government agencies for
+"review".
+
+Many have noted that the dawning of cheap and effective cryptographic
+systems could spell the end of the ability of governments to invade
+people's privacy. Unfortunately, it appears that the government and
+its cronies have also realized this, and intend to take preemptive
+action. Our notion of civil rights has decayed so far that it is now
+considered a citizen's duty to not merely be quiet while he is
+enslaved but to actively cooperate with his own enslavement. Not
+merely must we put up with the indignity of the government being
+granted the right to read our papers and communications to each other,
+not merely has the FBI attempted to get legislation passed to make
+phone companies give them easier access to tap phone lines under color
+of "maintaining the current capability in the presense of new
+technology", but now it is suggested that we ordinary citizens must
+personally cooperate to make it easier for them to read our
+communications. We will be branded criminals if we fail to cooperate,
+presuming that ideas like this are enacted.
+
+It is crucial that the fiends proposing this be convinced that
+resistance will be too high to implement their plan. It is crucial
+that before they can even propose legislation that the threat here be
+brought to the attention of the news media. If the currently proposed
+FBI legislation were passed, a dictatorial government would have all
+the tools it would need to tap all the phones in the country -- the
+only thing restraining that behavior would be a system of warrants
+that could disappear with a mere change in attitude. If Denning's more
+serious and sinister idea were proposed for future enactment as
+legislation (this has not yet been proposed), it would become
+impossible for individuals to take any action to protect their own
+communications privacy from a dictatorial regime, even ignoring the
+question of abuses that could occur right now. I'm convinced that the
+only thing that prevented the FBI bill from passing this year was the
+fact that media attention was brought to bear. Its important that this
+new proposal be exposed to similar sunshine. Far be it for me to
+suggest restraint of free speech, but I would like to see people
+think of making such suggestions as having the social acceptability of
+calling a black person "nigger".
+
+Here, for reference, is a copy of an article Dr. Denning just posted
+to sci.crypt on usenet.
+
+I encourage people, rather than discussing this matter on libernet or
+extropians, to discuss this on sci.crypt where the topic is just
+breaking.
+
+Perry Metzger
+
+----------------------------------------------------------------------
+
+Article 6275 of sci.crypt:
+Path: shearson.com!uunet!uunet!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning
+From: denning@guvax.acc.georgetown.edu
+Newsgroups: sci.crypt
+Subject: Re: A Trial Balloon on Registered Keys
+Message-ID: <1992Oct27.143737.1574@guvax.acc.georgetown.edu>
+Date: 27 Oct 92 14:37:37 -0500
+Distribution: world
+Organization: Georgetown University
+Lines: 94
+
+The posting about the proposal I made at the NCSC for key registration
+is essentially correct. Let me add to it the following:
+
+1. The government is not taking any action to curb crypto and is
+unlikely to take any such action in the near future. No proposal has
+been made and no government agency that I am aware of has plans to
+make such a proposal. The closest we've had to a proposal was a "Sense
+of Congress" resolution in Senate Bill 266 over a year ago. This
+would not have mandated anything, but said it was the sense of
+Congress that service providers should provide accesss to the
+plaintext of encrypted communications under a court order. It got a lot of
+opposition and was withdrawn. Thus, don't panic folks -- this was just me
+making a suggestion. I didn't realize I had that much clout to cause
+such a stir and call to arms! I expect that the next step will be government
+sponsored discussions about crypto policy, probably sponsored by NIST,
+at the recommendation of the Computer System Security Advisory Board
+headed by Willis Ware. That will provide a forum to work through these
+issues.
+
+2. The reason I made the proposal is because I am concerned that we
+may be facing a major crisis in law enforcement. I expect many of
+you will say "that's wonderful" but I don't see it that way.
+Electronic surveillance has been an essential tool in preventing
+serious crimes such as terrorist attacks and destabilizing organized crime.
+The economic benefits alone are estimated to be in the billions. This
+issue is not about snooping on innocent citizens but about doing what
+we can do prevent major crimes that could seriously disrupt other
+liberties. The problem is likely to get even worse if criminals know
+they use the telecommunications systems without any chance of getting
+caught.
+
+3. My proposal was to register your private key with a trustee,
+different from the government. The key would be encrypted under some
+other public key so the trustee couldn't decrypt it. I have suggested
+it be the key of the DOJ, but it could be another independent trustee.
+I believe this would provide acceptably good protection since someone
+would need to get a court order and then the cooperation of 3 agencies
+to get at your communications: the telecommunications provider (to get
+the bit stream), the first trustee (to get the encrypted key), and
+the second to decrypt it. Experience with the telecom providers has
+been that they are very fussy about court orders -- you have to get
+the semicolons right!
+
+You can get even more security by using Silvio Micali's "fair
+public-key cryptosystem" approach. Called "fair" because it is
+designed to strike a balance between the needs of the Government and
+those of the citizens. With his approach, you would break your key
+up into 5 parts and give it to different trustees. All 5 parts
+are needed to reassemble it, but it is possible to veryify the parts
+individually and as a whole without putting them together --
+ingenious! He presented this at CRYPTO '92.
+
+4. Someone suggested that law enforcement routinely taps without
+court order. This is an ungrounded claim for which I have never
+seen any evidence. Regardless, their ability to do this is
+disappearing with the new digital based technologies. They need the
+help of the service providers, who in turn ask for court orders.
+Court orders are not all that easy to get as law enforcers have to
+document why other approaches have failed etc.
+
+5. Many people have noted that you could not enforce key
+registration. They may be right, but I am not throwing in the towel
+yet. Let's take phones, which is what law enforcers are most
+interested in. Products are emerging that you can attach to your
+phone and that will do DES encryption. Criminals and everyone
+else are most likely to use commercial products -- easiest to
+get and cheapest. The products could be designed so key registration
+would essentially be part of the sales process.
+
+There can be social benefit to government regulation even when
+regulation is not 100% successful. None of our laws prevent the
+acts they outlaw. But this does not mean we should get rid of
+all laws.
+
+6. Some people have said we should not give up our privacy to the
+government. But the constitution does not give us absolute privacy.
+We are protected from unreasonable searches and seizures, but not
+reasonable ones in response to "probable cause" of crime. In all
+areas of our lives, the government can invade our privacy if they
+have good reason to believe we are engaged in major criminal activity.
+They can break into our homes, our safes, and so on. Do we really
+want a society where electronic communications cannot ever be broken
+when there is good reason to believe some major threat against society
+is being planned?
+
+Thank you for your comments and for encouraging those on the other
+news groups to move over to sci.crypt. I'll try to keep up with
+this newsgroup and respond to other comments if appropriate, but
+I honestly can't track them all.
+
+Dorothy Denning
+denning@cs.georgetown.edu (posting from guvax)
+
+
+
+
+----------------------------------------------------------------------
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-28 (Tue, 27 Oct 92 17:23:08 PPE) - Threat to our privacy - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/0bfa1d7d1f80cbd3ce39cc23172cc4e724e96af15fbdaf8df16e75cb89f68a9c.md b/_emails/1992/10/0bfa1d7d1f80cbd3ce39cc23172cc4e724e96af15fbdaf8df16e75cb89f68a9c.md
new file mode 100644
index 0000000000..cee8fd8561
--- /dev/null
+++ b/_emails/1992/10/0bfa1d7d1f80cbd3ce39cc23172cc4e724e96af15fbdaf8df16e75cb89f68a9c.md
@@ -0,0 +1,73 @@
+---
+layout: default
+---
+
+# 1992-10-23 - Re: Keystone
+
+## Header Data
+
+From: gnu@cygnus.com
+To: cypherpunks@toad.com
+Message Hash: 0bfa1d7d1f80cbd3ce39cc23172cc4e724e96af15fbdaf8df16e75cb89f68a9c
+Message ID: \<9210230728.AA25822@cygnus.com\>
+Reply To: \<9210230622.AA26831@soda.berkeley.edu\>
+UTC Datetime: 1992-10-23 07:28:19 UTC
+Raw Date: Fri, 23 Oct 92 00:28:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: gnu@cygnus.com
+Date: Fri, 23 Oct 92 00:28:19 PDT
+To: cypherpunks@toad.com
+Subject: Re: Keystone
+In-Reply-To: <9210230622.AA26831@soda.berkeley.edu>
+Message-ID: <9210230728.AA25822@cygnus.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+> "A provider of communications services cannot be held liable for the
+> consequences of encrypted communications that pass though its system."
+
+Far too simple. Suppose the provider is a BBS operator who *knows* what
+their users are passing through the system? Suppose the provider has
+keys to the encrypted communications? Suppose those keys are only to be
+used under duress (e.g. under a court order)? Suppose the provider
+is a parent and the user is their teenage daughter? Suppose the
+encryption is easily breakable?
+
+The principle you are looking for is that if the service provider has
+no *control* over the content, then they should have no *liability*
+for it either. The courts are gradually making that happen. But
+control relates directly to the specific facts of the particular case --
+not whether encryption is in use.
+
+The case law on liability for content is gradually being made. So
+far, no particularly horrible precedents have been set (I don't think
+there are precedents yet in the arrest-the-record-store-owner-for-rap-
+records-the-cops-don't-like issue). In a good decision, Compuserve
+was let off the hook for a message sent by someone who Compuserve even
+paid to moderate a corner of their service -- because Compuserve
+didn't control the content of that corner.
+
+I realize that this group has a tendency toward extremism, but let's
+temper that with a bit of wisdom, too.
+
+ John
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 11:19:49 PDT) - [re: Keystone](/years/1992/10/90acf83b11143d2b8c4c4029e49ae5df05278a74166799409280e6de432e0a6a) - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+ + 1992-10-23 (Thu, 22 Oct 92 23:22:28 PDT) - [Keystone](/years/1992/10/dbefe9ce00cd47ed9ef4144315bc660edb3c2704e4ded25c391ab61617053e53) - _Eric Hughes \_
+ + 1992-10-23 (Fri, 23 Oct 92 00:28:19 PDT) - Re: Keystone - _gnu@cygnus.com_
+ + 1992-10-23 (Fri, 23 Oct 92 10:27:18 PDT) - [Keystone](/years/1992/10/7eafa220d02ff7674103b943a51cc62015c3bc371211bcd6d8b3a9f5e836b8a1) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/0dc2cf15ce93cba1ee63387f52280c165516ebf5779bfeb873d6e38425e5e49a.md b/_emails/1992/10/0dc2cf15ce93cba1ee63387f52280c165516ebf5779bfeb873d6e38425e5e49a.md
new file mode 100644
index 0000000000..5d4cbe057e
--- /dev/null
+++ b/_emails/1992/10/0dc2cf15ce93cba1ee63387f52280c165516ebf5779bfeb873d6e38425e5e49a.md
@@ -0,0 +1,74 @@
+---
+layout: default
+---
+
+# 1992-10-22 - temporary request
+
+## Header Data
+
+From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS)
+To: CYPHERPUNKS@TOAD.COM
+Message Hash: 0dc2cf15ce93cba1ee63387f52280c165516ebf5779bfeb873d6e38425e5e49a
+Message ID: \<719795393.8323950@AppleLink.Apple.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-22 23:28:44 UTC
+Raw Date: Thu, 22 Oct 92 16:28:44 PDT
+
+## Raw message
+
+```
+{% raw %}From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS)
+Date: Thu, 22 Oct 92 16:28:44 PDT
+To: CYPHERPUNKS@TOAD.COM
+Subject: temporary request
+Message-ID: <719795393.8323950@AppleLink.Apple.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Greetings CypherFolk,
+
+I, one of your newest members, am on vacation in Europe (right now I'm in
+Holland enjoying the "coffee" shops) and am temporarily restricted to using
+AppleLink as my gateway to Internet. Because it costs $0.50 to $0.80 per piece
+of email, I asked Eric to _temporarily_ remove me from the general alias until
+I return to the US in December, saving me major bucks. When I get back, I'll
+announce that you can send me mail at "ddt@well.sf.ca.us". I enjoyed the
+repartee I sampled and look forward to joining in as I learn more.
+
+Offer of the Week:
+If anyone needs me to physically pick up a PGP key from someone here in Europe,
+I have a train pass good for another month (maybe longer if I can alter it
+again) and will consider any request that will take me to interesting locations
+and connect me with interesting folks.
+
+Further Request:
+If any of you send any interesting stuff to the group alias (e.g. Russ
+Whitaker's article on "computer cryptography" from the Economist) and think it
+might be of general interest to someone learning about the whole encryption
+process (i.e. me), please cc me at "deltorto@applelink.apple.com" anytime. This
+would be appreciated. I also encourage anyone who has helpful learning material
+to forward it to me so I can get up to speed. I am working on an interesting
+project I would like to share with the right people, but I am not prepared to
+discuss it in public.
+
+Does anyone have a copy of PGP 2.0 that runs on a Macintosh? If you email it to
+me, I will cover any costs you incur. Coolness.
+
+Until we all meet in person,
+
+ dave
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 16:28:44 PDT) - temporary request - _DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS)_
+
diff --git a/_emails/1992/10/0eec0ebc8ca754a17d7524fa51a07b6557113dffeb3bd13e9f3da940001c47f9.md b/_emails/1992/10/0eec0ebc8ca754a17d7524fa51a07b6557113dffeb3bd13e9f3da940001c47f9.md
new file mode 100644
index 0000000000..04a6dcede1
--- /dev/null
+++ b/_emails/1992/10/0eec0ebc8ca754a17d7524fa51a07b6557113dffeb3bd13e9f3da940001c47f9.md
@@ -0,0 +1,61 @@
+---
+layout: default
+---
+
+# 1992-10-24 - Multiple messages + entropy
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: \
+Message Hash: 0eec0ebc8ca754a17d7524fa51a07b6557113dffeb3bd13e9f3da940001c47f9
+Message ID: \<921024155350_74076.1041_DHJ67-1@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-24 16:02:41 UTC
+Raw Date: Sat, 24 Oct 92 09:02:41 PDT
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Sat, 24 Oct 92 09:02:41 PDT
+To:
+Subject: Multiple messages + entropy
+Message-ID: <921024155350_74076.1041_DHJ67-1@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+The Internet PEM (Privacy Enhanced Mail) standard uses the
+concept which Dean Tribble mentioned of multiple encryption
+(using each recipient's public key) of a single session key
+which encrypts the message. PGP's data structures do not
+currently provide for this but could be extended pretty easily
+to allow it.
+
+On the entropy measure - I thought entropy was how many bits
+of information you get per character. Encrypted binary text
+would be pretty close to 8 bits per character. The RFC1113
+Ascii encoding used by PGP reduces this to 6 bits per character
+(e.g. a character set with 64 printable characters) neglecting
+line separators and message beginnings and endings. So there
+should be a little less than 6 bits per character for encrypted,
+Ascii-encoded messages.
+
+Hal
+74076.1041@compuserve.com
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-24 (Sat, 24 Oct 92 09:02:41 PDT) - Multiple messages + entropy - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-26 (Mon, 26 Oct 92 09:53:38 PPE) - [entropy](/years/1992/10/372c96cffd382696c685f18f23b0868ec033ccb4cd1e33b39fcededb8cc5f91d) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/0f6bbccf741960b8c34c3990dace27fba9fb2d8092b51b0f79b3ac8353ccbdc5.md b/_emails/1992/10/0f6bbccf741960b8c34c3990dace27fba9fb2d8092b51b0f79b3ac8353ccbdc5.md
new file mode 100644
index 0000000000..db86f42d65
--- /dev/null
+++ b/_emails/1992/10/0f6bbccf741960b8c34c3990dace27fba9fb2d8092b51b0f79b3ac8353ccbdc5.md
@@ -0,0 +1,49 @@
+---
+layout: default
+---
+
+# 1992-10-28 - Messages in the Least Significant Bits
+
+## Header Data
+
+From: tcmay@netcom.com (Timothy C. May)
+To: cypherpunks@toad.com
+Message Hash: 0f6bbccf741960b8c34c3990dace27fba9fb2d8092b51b0f79b3ac8353ccbdc5
+Message ID: \<9210280303.AA21744@netcom2.netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-28 03:06:05 UTC
+Raw Date: Tue, 27 Oct 92 20:06:05 PPE
+
+## Raw message
+
+```
+{% raw %}From: tcmay@netcom.com (Timothy C. May)
+Date: Tue, 27 Oct 92 20:06:05 PPE
+To: cypherpunks@toad.com
+Subject: Messages in the Least Significant Bits
+Message-ID: <9210280303.AA21744@netcom2.netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Cypherpunks,
+
+Here's a message I just posted to another mailing list. It has rather
+strict policies against cross-posting, so I've edited out the headers
+and the initial chunk of text I quoted. That should make me kosher.
+
+(This topic also came up in some e-mail with George Gleason.)
+
+Forwarded message:
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-28 (Tue, 27 Oct 92 20:06:05 PPE) - Messages in the Least Significant Bits - _tcmay@netcom.com (Timothy C. May)_
+
diff --git a/_emails/1992/10/0fc82407e8fa8a6ef671268b6a7f0783f2980e9ede01ea33ac59ac5e564b0027.md b/_emails/1992/10/0fc82407e8fa8a6ef671268b6a7f0783f2980e9ede01ea33ac59ac5e564b0027.md
new file mode 100644
index 0000000000..b0bf8dd20a
--- /dev/null
+++ b/_emails/1992/10/0fc82407e8fa8a6ef671268b6a7f0783f2980e9ede01ea33ac59ac5e564b0027.md
@@ -0,0 +1,59 @@
+---
+layout: default
+---
+
+# 1992-10-27 - list status
+
+## Header Data
+
+From: pmetzger@shearson.com (Perry E. Metzger)
+To: hughes@soda.berkeley.edu
+Message Hash: 0fc82407e8fa8a6ef671268b6a7f0783f2980e9ede01ea33ac59ac5e564b0027
+Message ID: \<9210271954.AA07709@newsu.shearson.com\>
+Reply To: \<9210271856.AA03357@soda.berkeley.edu\>
+UTC Datetime: 1992-10-27 20:24:00 UTC
+Raw Date: Tue, 27 Oct 92 13:24:00 PPE
+
+## Raw message
+
+```
+{% raw %}From: pmetzger@shearson.com (Perry E. Metzger)
+Date: Tue, 27 Oct 92 13:24:00 PPE
+To: hughes@soda.berkeley.edu
+Subject: list status
+In-Reply-To: <9210271856.AA03357@soda.berkeley.edu>
+Message-ID: <9210271954.AA07709@newsu.shearson.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+>From: Eric Hughes
+>Breakdown of the list by top-level domain:
+
+>U.S. domains:
+> 42 com
+> 42 edu
+> 1 gov
+> 1 mil
+> 10 org
+> 6 us
+
+Hmm... Wonder who Mr. .gov and Mr. .mil are...
+
+(1/2 :-)
+
+Perry
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-27 (Tue, 27 Oct 92 11:57:12 PPE) - [list status](/years/1992/10/77250e97ac7c83428c993340774581a44c7395bc5a6b955b6a3bfd78ec75ec7c) - _Eric Hughes \_
+ + 1992-10-27 (Tue, 27 Oct 92 13:24:00 PPE) - list status - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/12951b10c85d64c94a33420c3f2b983a727031d9401a623cc5c0b8940927614e.md b/_emails/1992/10/12951b10c85d64c94a33420c3f2b983a727031d9401a623cc5c0b8940927614e.md
new file mode 100644
index 0000000000..340afba3b8
--- /dev/null
+++ b/_emails/1992/10/12951b10c85d64c94a33420c3f2b983a727031d9401a623cc5c0b8940927614e.md
@@ -0,0 +1,67 @@
+---
+layout: default
+---
+
+# 1992-10-21 - Put me on your mailing list!
+
+## Header Data
+
+From: "Campbell James A" \
+To: "cypherpunks" \
+Message Hash: 12951b10c85d64c94a33420c3f2b983a727031d9401a623cc5c0b8940927614e
+Message ID: \<9210212129.AA27437@toad.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-21 21:29:41 UTC
+Raw Date: Wed, 21 Oct 92 14:29:41 PDT
+
+## Raw message
+
+```
+{% raw %}From: "Campbell James A"
+Date: Wed, 21 Oct 92 14:29:41 PDT
+To: "cypherpunks"
+Subject: Put me on your mailing list!
+Message-ID: <9210212129.AA27437@toad.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Hey, I'd like to be on the mailing list for CYPHERPUNKS. My address is:
+
+ ujacampbe@memstvx1.memst.edu
+
+If you need this too, here's my PGP 2.0 public key:
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0ln9CiLJljssOeflC9A+QIDujXhPT
+yApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvfvQPEiGIFQQYxviF+Qg/+6/JVvLCj
+vnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP9AU+wYw62aXmTNtW1BUtX5BHAAUR
+tDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2FtcGJlQG1lbXN0dngxLm1lbXN0LmVk
+dT4=
+=0rCj
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+Thanks!
+
+
+James A. Campbell
+
+Memphis State University
+Memphis, Tennessee
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-21 (Wed, 21 Oct 92 14:29:41 PDT) - Put me on your mailing list! - _"Campbell James A" \_
+
diff --git a/_emails/1992/10/12bc0f85f9a646add4c5603e08fe8e538363c6c8b9aa6e63490461eea74314a6.md b/_emails/1992/10/12bc0f85f9a646add4c5603e08fe8e538363c6c8b9aa6e63490461eea74314a6.md
new file mode 100644
index 0000000000..f1b6d7667e
--- /dev/null
+++ b/_emails/1992/10/12bc0f85f9a646add4c5603e08fe8e538363c6c8b9aa6e63490461eea74314a6.md
@@ -0,0 +1,70 @@
+---
+layout: default
+---
+
+# 1992-10-16 - Re: one time pads
+
+## Header Data
+
+From: Peter Shipley \
+To: cypherpunks@toad.com
+Message Hash: 12bc0f85f9a646add4c5603e08fe8e538363c6c8b9aa6e63490461eea74314a6
+Message ID: \<9210160103.AA06271@edev0.TFS\>
+Reply To: \<9210160007.AA18430@soda.berkeley.edu\>
+UTC Datetime: 1992-10-16 01:03:41 UTC
+Raw Date: Thu, 15 Oct 92 18:03:41 PDT
+
+## Raw message
+
+```
+{% raw %}From: Peter Shipley
+Date: Thu, 15 Oct 92 18:03:41 PDT
+To: cypherpunks@toad.com
+Subject: Re: one time pads
+In-Reply-To: <9210160007.AA18430@soda.berkeley.edu>
+Message-ID: <9210160103.AA06271@edev0.TFS>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+>
+>Physical security is not a big issue for RSA (in the pgp implementation)
+>because the secret key ring is itself encrypted. The problem is not so much
+>physical-intrusion-to-get-the-key as it is physical intrusion aimed at
+>modifying software.
+
+To add my two cents, I once had some sensitive files solen from me.
+the cracker had modified the crypt command to record passwords
+and current directory (since crypt only works on stdin and stdout).
+
+In a matter of a few days they have my crypt password and enough infomation
+from my file to raise some real hell.
+
+Note that they did not bother with breaking the crypt or guessing the password
+they just rigged the system binaries.
+
+ -Pete
+
+PS: this happend a year ago, and last month a copy of the files
+ appeared on some systems owned by the Bay Area Air Quality Management
+ District in SF (baaqmd).
+
+PPS: I *know* that crypt is insecure but I had tared/compressed it and des
+ was not avalible on the systems I was working on.
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-15 (Thu, 15 Oct 92 02:23:21 PDT) - [Re: one time pads](/years/1992/10/5d5b98b544ddca1167fefcf884fb753cc1d761f014b8e779949d089d9d8109ee) - _George A. Gleason \_
+ + 1992-10-16 (Thu, 15 Oct 92 17:08:10 PDT) - [Re: one time pads](/years/1992/10/6d1555d9ba7e7f5df99b0b1e6d959204e559a393d247f7263b6320400b221fe9) - _Eric Hollander \_
+ + 1992-10-16 (Thu, 15 Oct 92 18:03:41 PDT) - Re: one time pads - _Peter Shipley \_
+
diff --git a/_emails/1992/10/13448cebdb0e3f6fa278cb853f0f0e9221952f53a09470ce78415ecc4fe7835a.md b/_emails/1992/10/13448cebdb0e3f6fa278cb853f0f0e9221952f53a09470ce78415ecc4fe7835a.md
new file mode 100644
index 0000000000..4163312c7a
--- /dev/null
+++ b/_emails/1992/10/13448cebdb0e3f6fa278cb853f0f0e9221952f53a09470ce78415ecc4fe7835a.md
@@ -0,0 +1,63 @@
+---
+layout: default
+---
+
+# 1992-10-14 - re: Matching Text, Headders and Signatures with Crypto Hashes
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 13448cebdb0e3f6fa278cb853f0f0e9221952f53a09470ce78415ecc4fe7835a
+Message ID: \<2936.2ADBB282@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-14 05:45:57 UTC
+Raw Date: Tue, 13 Oct 92 22:45:57 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Tue, 13 Oct 92 22:45:57 PDT
+To: cypherpunks@toad.com
+Subject: re: Matching Text, Headders and Signatures with Crypto Hashes
+Message-ID: <2936.2ADBB282@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> From: hugh@domingo.teracons.com (Hugh Daniel)
+
+ U> For example in NetNews I proposed changing the
+ U> MessageId: headder such that part of the gobldyguk on the
+ U> left side of the atsign was a crypto hash of the body of
+ U> the message and some of the important sending host
+ U> generated headders. With this system of MessageId:'s
+ U> anyone who corrupts a message (intentionaly or otherwise)
+ U> creates a bogus message, as the next machine that gets the
+ U> message can see that the message does not match it
+ U> MessageId: line.
+
+There's a FidoNet mailer (Dutchie) that uses MD4 to generate message
+IDs in exactly this way... They did some cheat, to allow certain
+filters (CR/LF vs LF, etc) to work.
+
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-14 (Tue, 13 Oct 92 22:45:57 PDT) - re: Matching Text, Headders and Signatures with Crypto Hashes - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/13c718fd6a00a709360fa83486aabdfc938ad255783a4024fb7ca1487cbac0e9.md b/_emails/1992/10/13c718fd6a00a709360fa83486aabdfc938ad255783a4024fb7ca1487cbac0e9.md
new file mode 100644
index 0000000000..c02dbbd590
--- /dev/null
+++ b/_emails/1992/10/13c718fd6a00a709360fa83486aabdfc938ad255783a4024fb7ca1487cbac0e9.md
@@ -0,0 +1,118 @@
+---
+layout: default
+---
+
+# 1992-10-05 - Meeting Sat. Oct. 10, noon, Mt. View
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 13c718fd6a00a709360fa83486aabdfc938ad255783a4024fb7ca1487cbac0e9
+Message ID: \<9210050830.AA03692@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-05 08:23:23 UTC
+Raw Date: Mon, 5 Oct 92 01:23:23 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 5 Oct 92 01:23:23 PDT
+To: cypherpunks@toad.com
+Subject: Meeting Sat. Oct. 10, noon, Mt. View
+Message-ID: <9210050830.AA03692@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ANNOUNCEMENT
+============
+
+Second Meeting
+
+Saturday, October 10, 1992
+12:00 noon - 6:00 p.m.
+
+Cygnus Support offices
+1937 Landings Drive
+Mountain View
+
+
+The second meeting of the cypherpunks will be Saturday at noon. John
+Gilmore has graciously provided us with a meeting space at the new
+Cygnus Support offices. These offices are so new, in fact, that
+Cygnus will not have moved in yet. This meeting will be
+bring-your-own-pillow (or chair), since it will be held in largely
+empty space. Directions are at the end of the message.
+
+Attendance is transitive trust, arbitrarily deep. Invite whoever you
+want, and let them do so also, and so on. Invite them also to join
+the mailing list. Do not, however, just post the announcement. Time
+for that will come.
+
+I'd like everyone who plans on attending the meeting to send me,
+hughes@soda.berkeley.edu, a message telling me so. I'd like to get a
+rough head count before Saturday for game planning.
+
+We are starting at noon because of popular demand. Eat beforehand or
+bring a burrito or something. It will be fine to eat during the first
+segment; it won't be any more disruptive than the game is.
+
+Bring your PGP public key for in-person key distribution, preferably
+on diskette. We'll need a portable PC or three to do key
+distribution; if you have one you can bring, post to the list and tell
+people.
+
+We realized after the first meeting that a strict schedule was
+nonsense. This meeting has a very informal schedule.
+
+
+Schedule
+--------
+
+Starting at noon, we're going to play session two of the
+crypto-anarchy game, in which players try to conduct business under
+the watchful eyes of others. We want to play for two hours and then
+have discuss experiences afterward for about an hour. Some of the
+improvements over last time will be flatter denominations of money,
+wider distribution of commodities, more watchers (governmental and
+otherwise), and perhaps some pre-printed forms.
+
+We'll take a break to regroup for about ten or twenty minutes.
+
+For the second half we'll talk about the security of remailers. I'll
+lead the discussion. We'll be designing protocols and analyzing
+attacks and defenses. I've done this with DigiCash for electronic
+money protocols, and remailers are much easier, but still probably
+more than an afternoon's discussion. We'll do this until six or so,
+when people will have to start leaving.
+
+Everyone who wants to will go out for dinner. I don't know the
+restaurants down there; perhaps someone could suggest one?
+
+
+Directions
+----------
+It's at 1937 Landings Drive, Mt. View. 101 to Amphitheatre Parkway
+(the bay side of Rengstorff Ave), go right at the first light,
+pass a right turn, and just before the road crests a tiny hill,
+turn right into the Landings complex. We're in Building H.
+
+
+--
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-05 (Mon, 5 Oct 92 01:23:23 PDT) - Meeting Sat. Oct. 10, noon, Mt. View - _Eric Hughes \_
+
diff --git a/_emails/1992/10/150cc9075146bf18554193b2b52dfc56cd0a54da12fbd6bf8d9fcb1e1b285478.md b/_emails/1992/10/150cc9075146bf18554193b2b52dfc56cd0a54da12fbd6bf8d9fcb1e1b285478.md
new file mode 100644
index 0000000000..25ff10bd37
--- /dev/null
+++ b/_emails/1992/10/150cc9075146bf18554193b2b52dfc56cd0a54da12fbd6bf8d9fcb1e1b285478.md
@@ -0,0 +1,70 @@
+---
+layout: default
+---
+
+# 1992-10-31 - re: Why I Don't Use PGP
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 150cc9075146bf18554193b2b52dfc56cd0a54da12fbd6bf8d9fcb1e1b285478
+Message ID: \<3394.2AF2012B@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-31 03:46:23 UTC
+Raw Date: Fri, 30 Oct 92 20:46:23 PPE
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Fri, 30 Oct 92 20:46:23 PPE
+To: cypherpunks@toad.com
+Subject: re: Why I Don't Use PGP
+Message-ID: <3394.2AF2012B@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> From: tcmay@netcom.com (Timothy C. May)
+
+ U> 10. Because I use a Mac and the Mac version is not out yet.
+
+I'll ask in the FidoNet PUBLIC_KEYS echo about Smackintoshes.
+
+ U> 9. Because the Mac version may NEVER be out.
+
+... prolly cuz noone can figger out how to make a lot of money from
+it!
+
+ U> 4. Because I'm not yet convinced it is needed.
+
+Ayup. My feelings exackly. This is starting to sound just like my gun
+arguments... I don't need one on the street, but someday I may, no?
+
+ U> 3. Because ideally our mailers should handle this in a
+ U> push-button way
+
+Some do already...
+
+
+--- ReadMail
+ * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-31 (Fri, 30 Oct 92 20:46:23 PPE) - re: Why I Don't Use PGP - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/156252f47fbad0cd66b933fed873c3264c37a1109b19f5dad86089525996d53c.md b/_emails/1992/10/156252f47fbad0cd66b933fed873c3264c37a1109b19f5dad86089525996d53c.md
new file mode 100644
index 0000000000..29537384dc
--- /dev/null
+++ b/_emails/1992/10/156252f47fbad0cd66b933fed873c3264c37a1109b19f5dad86089525996d53c.md
@@ -0,0 +1,63 @@
+---
+layout: default
+---
+
+# 1992-10-20 - Mac Version PGP
+
+## Header Data
+
+From: No_Such_Address@atdt.org
+To: cypherpunks@toad.com
+Message Hash: 156252f47fbad0cd66b933fed873c3264c37a1109b19f5dad86089525996d53c
+Message ID: \<9210201806.AA07990@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-20 18:06:12 UTC
+Raw Date: Tue, 20 Oct 92 11:06:12 PDT
+
+## Raw message
+
+```
+{% raw %}From: No_Such_Address@atdt.org
+Date: Tue, 20 Oct 92 11:06:12 PDT
+To: cypherpunks@toad.com
+Subject: Mac Version PGP
+Message-ID: <9210201806.AA07990@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+No one has been able to get me the source-code to PGP, and when
+I ftp'd it from wherever, it came ZIP'd in a format that my
+unzipper doesn't recognize. (Maybe I've been ZIP superceded).
+Anyway, it hasn't been very convenient to get a hold of it for me.
+
+But, it should be fairly straight forward to throw it into
+THINK C. THINK C supports a console with command-line. You
+would not necessarily have to Mac-ify it (although it would
+certainly make it more aesthetically pleasing); so porting
+to the Mac is not a dead-end port. THINK C should be
+able to compile and execute PGP as-is.
+
+As soon as I can get the source, I'll put my words into action.
+
+(re: Macifying it: It's simple enough to slap together an
+interface on top of something like PGP; that's one, maybe two
+dialog boxes with a bunch of radio buttons and check boxes
+and a routine to parse it all and hand the info over in a way
+PGP expects. BFD. So, criticisms I've heard about
+it being a hassle and a pointless exercise to port PGP to the
+Mac are without merit, as far as I'm concerned.)
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Tue, 20 Oct 92 11:06:12 PDT) - Mac Version PGP - _No_Such_Address@atdt.org_
+
diff --git a/_emails/1992/10/15812353cae00b92b6950171b0944602902caba39821204d31a8223d50e1bff6.md b/_emails/1992/10/15812353cae00b92b6950171b0944602902caba39821204d31a8223d50e1bff6.md
new file mode 100644
index 0000000000..c449a93d88
--- /dev/null
+++ b/_emails/1992/10/15812353cae00b92b6950171b0944602902caba39821204d31a8223d50e1bff6.md
@@ -0,0 +1,95 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Registering Keys...
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: CYPHERPUNKS \
+Message Hash: 15812353cae00b92b6950171b0944602902caba39821204d31a8223d50e1bff6
+Message ID: \<921026155917_74076.1041_DHJ88-1@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 16:23:21 UTC
+Raw Date: Mon, 26 Oct 92 09:23:21 PPE
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Mon, 26 Oct 92 09:23:21 PPE
+To: CYPHERPUNKS
+Subject: Registering Keys...
+Message-ID: <921026155917_74076.1041_DHJ88-1@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+This proposal to register keys was also mentioned in the July, 1992
+Communications of the ACM, in an article by Ron Rivest, one of the
+creators of the RSA algorithm. He was mostly criticizing the proposed
+government Digital Signature Standard, stating that he thought that
+the NSA was purposely trying to get "weak" cryptography installed as
+the standard. Then he goes on to say,
+
+"Are there technical alternatives that would satisfy all parties?
+Perhaps. It is certainly the case that the formulation of the problem
+to be solved has never been made explicit for the cryptographic
+community to work on. I suspect that a solution based on 'escrowed
+secret keys' might be workable, wherein each user is legally required
+to depost his or her secret key with a trusted third party, such as
+the user's bank. Cryptographic hardware and software would only
+operate with public keys that were certified to having their corres-
+ponding secret keys appropriately escrowed. A federal agency could
+then obtain the secret key, or its use, with an appropriate warrant.
+Once their secret keys were escrowed, multinational corporations could
+even operate across borders with a high degree of authentication and
+privacy (except perhaps from court-ordered wiretaps). Cryptographic
+hardware and software manufactured in the U.S. would not operate
+abroad without public keys suitably certified as having their secret
+counterparts escrowed in the U.S. In an extension of this approach,
+users can escrow their secret keys with several trusted third parties
+in a 'secret-sharing' manner, so that no single third party can com-
+promise the user's key. While this approach may have its own difficulties,
+it does illustrate that weak cryptography is not the only technical
+approach available. There may be much better techniques for achieving
+a compromise between a number of conflicting national concerns."
+
+At the time that I read this, I thought it was largely a rhetorical
+device, making the point that if the government wants to infringe on
+people's privacy, it should come out in the open and do so, rather
+than skulking about. (Like saying, "if the government _really_ wants
+to stop sexual immorality it would have to put a TV camera in every
+bedroom".) And of course (I thought) this kind of proposal would never
+be taken seriously. I'm shocked that Denning is now advocating it openly.
+
+This proposal makes it illegal for people to communicate so secretly
+that the government can't find out what they are saying. It could
+apply to postal mail as well as email - it would be illegal to send
+a message via post which the government couldn't interpret. If this
+is really the government's purpose, then it should also require that all
+private conversations be recorded, and the resulting tapes be "escrowed"
+similarly in case the government needed to find out what was said,
+for which it would have to get a court order.
+
+As Tim suggested, this is probably a "trial balloon" being floated to
+see what the reaction is. Let's see that it gets shot down.
+
+Hal
+74076.1041@compuserve.com
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 09:23:21 PPE) - Registering Keys... - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-26 (Mon, 26 Oct 92 10:08:45 PPE) - [Registering Keys...](/years/1992/10/2354d012d9195764785cc4d5b1fb9b3a566d8c08b2f3caadb23470bad07047e3) - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/1948a7ffa411c9042feb2752a23ce12790792008ce818a44ddb4efb02b7a3321.md b/_emails/1992/10/1948a7ffa411c9042feb2752a23ce12790792008ce818a44ddb4efb02b7a3321.md
new file mode 100644
index 0000000000..35fa23cdfc
--- /dev/null
+++ b/_emails/1992/10/1948a7ffa411c9042feb2752a23ce12790792008ce818a44ddb4efb02b7a3321.md
@@ -0,0 +1,46 @@
+---
+layout: default
+---
+
+# 1992-10-25 - pgp
+
+## Header Data
+
+From: David Cabana (MTH) \
+To: cypherpunks@toad.com
+Message Hash: 1948a7ffa411c9042feb2752a23ce12790792008ce818a44ddb4efb02b7a3321
+Message ID: \<9210250037.AA19290@ultrix.csc.usf.edu.\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 00:43:41 UTC
+Raw Date: Sat, 24 Oct 92 17:43:41 PDT
+
+## Raw message
+
+```
+{% raw %}From: David Cabana (MTH)
+Date: Sat, 24 Oct 92 17:43:41 PDT
+To: cypherpunks@toad.com
+Subject: pgp
+Message-ID: <9210250037.AA19290@ultrix.csc.usf.edu.>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Where in the U.S. can I ftp a copy of PGP? I tried Kauri.vuw.ac.nz,
+but their README asked that I not transfer files. I would like to
+respect their wishes...
+ Thanks,
+ drc
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sat, 24 Oct 92 17:43:41 PDT) - pgp - _David Cabana (MTH) \_
+
diff --git a/_emails/1992/10/1afebd35d2386ecbd3e928fbe8238aa1ae87a785db7db042acce1e283ed3cd16.md b/_emails/1992/10/1afebd35d2386ecbd3e928fbe8238aa1ae87a785db7db042acce1e283ed3cd16.md
new file mode 100644
index 0000000000..125d5283a3
--- /dev/null
+++ b/_emails/1992/10/1afebd35d2386ecbd3e928fbe8238aa1ae87a785db7db042acce1e283ed3cd16.md
@@ -0,0 +1,114 @@
+---
+layout: default
+---
+
+# 1992-10-13 - Re: one time pads
+
+## Header Data
+
+From: George A. Gleason \
+To: hughes@soda.berkeley.edu
+Message Hash: 1afebd35d2386ecbd3e928fbe8238aa1ae87a785db7db042acce1e283ed3cd16
+Message ID: \<199210130821.AA03658@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-13 08:14:58 UTC
+Raw Date: Tue, 13 Oct 92 01:14:58 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Tue, 13 Oct 92 01:14:58 PDT
+To: hughes@soda.berkeley.edu
+Subject: Re: one time pads
+Message-ID: <199210130821.AA03658@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Good hard critique, Eric! Now if I might try to salvage my position...
+
+"One time pads are very (much more) expensive on a per-link basis than
+public key systems..."
+
+Yes, of course. However I don't envision OTPs as a standard for bulk
+encryption on large networks. Rather, for person-to-person communication in
+small networks. Examples: a group of civil rights attorneys suing the
+Federal govt., an international environmental organisation's main offices in
+the capital cities of a small number of countries, etc. Cases where the
+adversary is one or more powerful governments, and the number of links
+required is relatively small. Given the nature of the relationships between
+these kinds of networks and their adversaries, the expense would seem to be
+justified; in any case, the **incremental** cost of for instance a set of
+30MB cartridges as compared to a few floppy discs, is an minor fraction of
+the cost of the airline tickets and other expenses for trusted couriers.
+(oops: "a minor fraction...")
+
+Your discussion of bandwidth can be met with a similar counter-arguement.
+First of all, I would reject the use of UPS or (God help us) the *Post
+Office* as a courier, particularly where one or more governments may be the
+adversaries against whom protection is needed.
+So your reference to those carriers is not relevant to the main point of my
+case. I'm assuming that key materials are transported by trusted courier
+and are guarded by same until they reach their intended recipient. Okay,
+that *really* drives up the cost, doesn't it...? Not if the key materials
+"hitch hike" on an existing travel plan: attorney A flies out to city B to
+visit attorney B... and happens to carry key material onboard in his/her
+shoulder bag. No added cost except for the storage devices, and that is not
+significant.
+
+Re mathematical breakthroughs in factoring etc, you say, "we don't know when
+that will happen, and we don't know which will happen." Exactly my point.
+*We* don't know. But the NSA and so on, most certainly do know, and they
+won't be telling. If the breakthrough comes, then the period between that
+point and the point when it is publicised, will be one of false security.
+Was it Kahn who said nothing is more dangerous than a bad cipher? My point
+here comes down to nothing more or less than the principle of caution in the
+face of an unknown.
+
+(Discussion of relative cost of brute force solutions, and the question of
+hard problems and scale.) I agree that my intuition about these things may
+be highly flawed. However this doesn't invalidate my point about the
+possibility of basic breakthroughs happening behind closed doors. Now in a
+way I'll admit that my arguement here sort of comes down to a black box.
+However, again I would assert that there are cases where the almost
+irrational caution is worthwhile.
+
+You say in concluding, "Perfect security is not worth the cost in time,
+effort, or dollars when the marginal cost of perfection is less (do you mean
+more?) than perfection." You cite examples of international banking
+systems.
+
+I would cite examples of political movements which have been sabotaged and
+destroyed by government covert action. One need not look far to run into
+COINTELPRO and the more recent French govt action of blowing up a Greenpeace
+vessel. Where your adversaries are the intelligence agencies of world
+powers, and where lives are at stake, I would say the cost of perfect
+security is justified. Now of course, the French terrorist bombing, the
+destruction of Black nationalist and student organising groups in the US,
+and other examples, may not (probably would not) have been prevented
+altogether by adoption of perfect communications security. Che Guevara
+after all used OTPs, and it was radio direction finding and traffic analysis
+(rather than cryptanalysis) which ultimately led to his murder by US-backed
+mercenaries.
+
+If we are promoting a tendency which is inherently political, it implicitly
+recognises governments as its adversaries. Our choices of cryptographic
+systems should reflect a wide range of applications and not exclude some
+a-priori on grounds of cost or convenience.
+
+-George (gg@well.sf.ca.us)
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-13 (Tue, 13 Oct 92 01:14:58 PDT) - Re: one time pads - _George A. Gleason \_
+ + 1992-10-13 (Tue, 13 Oct 92 08:51:51 PDT) - [one time pads](/years/1992/10/59880107a8682ff630340193de22e9bf74179cc0b1399b38c188fa4c661518f3) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/1be047fb00ed9b8e7e62a36076bd875e747fc5da248ab50cd0ef9aff7be79589.md b/_emails/1992/10/1be047fb00ed9b8e7e62a36076bd875e747fc5da248ab50cd0ef9aff7be79589.md
new file mode 100644
index 0000000000..fdb5d0914a
--- /dev/null
+++ b/_emails/1992/10/1be047fb00ed9b8e7e62a36076bd875e747fc5da248ab50cd0ef9aff7be79589.md
@@ -0,0 +1,84 @@
+---
+layout: default
+---
+
+# 1992-10-13 - Re: Mr. Squirrel
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: CYPHERPUNKS \
+Message Hash: 1be047fb00ed9b8e7e62a36076bd875e747fc5da248ab50cd0ef9aff7be79589
+Message ID: \<921013154244_74076.1041_DHJ92-2@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-13 15:55:18 UTC
+Raw Date: Tue, 13 Oct 92 08:55:18 PDT
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Tue, 13 Oct 92 08:55:18 PDT
+To: CYPHERPUNKS
+Subject: Re: Mr. Squirrel
+Message-ID: <921013154244_74076.1041_DHJ92-2@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+||ugh Daniel raises some questions about using public keys to
+verify pseudonyms:
+
+> Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone
+> can use any public key they want also.
+
+But, once person A creates public key X, nobody else can sign messages
+using X. So if all messages from A are signed under X, we can know
+that they are all from the same person, even if they are sent anonymously
+or under a pseudonym.
+
+> So, in a many-to-one scope (as
+> in a maillist) where the sender can not use the one-on-one signed
+> signiture method how do we have proff of who the sender really is?
+
+You can use signatures even in a many-to-one scope. Messages from
+a particular person could be signed and the signature appended to
+the message. Then anyone who has the public key can check to see
+who the message came from. The process is a little unwieldy now
+in PGP because you have to separate the signature and message into
+separate files and run PGP on the signature file. This should be
+streamlined.
+
+> [Good points about keeping track of key-pseudonym pairs]
+> But all this needs to be done automaticly by the mailers and
+> interfaces, else the system will be mis-used and folks will tire of
+> the extra work that gets them little advantage.
+
+Absolutely. The most crying need now, IMO, is to better integrate the
+cryptographic tools into mail readers and senders, so that it's not
+such a pain to use these things. People should be able to give a single
+command or press a button to decrypt an incoming message or encrypt an
+outgoing one. Only then will these features be used by average people.
+
+There was a message posted on alt.security.pgp describing how to
+use PGP with the Emacs mail reading program. I'd like to see more
+messages telling how to use it with other systems.
+
+Hal
+74076.1041@compuserve.com
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-13 (Tue, 13 Oct 92 08:55:18 PDT) - Re: Mr. Squirrel - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-13 (Tue, 13 Oct 92 10:04:24 PDT) - [Re: Mr. Squirrel](/years/1992/10/fe748ec0459677318d9e9d5d0611919b35b8f6e096b4d2ede12008c07f006f28) - _nowhere@bsu-cs.bsu.edu (Chael Hall)_
+ + 1992-10-13 (Tue, 13 Oct 92 11:49:36 PDT) - [Mr. Squirrel](/years/1992/10/4449d8423a3d4ccea75be61a5bd0f1ff0f12e8a37191013726ee2d9bfc0c5fb6) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/1cb41753bf65e002a001ebdff3469ba8c095aa151ce1f7a7b8fc22e578c215bd.md b/_emails/1992/10/1cb41753bf65e002a001ebdff3469ba8c095aa151ce1f7a7b8fc22e578c215bd.md
new file mode 100644
index 0000000000..fc96753c13
--- /dev/null
+++ b/_emails/1992/10/1cb41753bf65e002a001ebdff3469ba8c095aa151ce1f7a7b8fc22e578c215bd.md
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+# 1992-10-18 - Re: one time pads
+
+## Header Data
+
+From: George A. Gleason \
+To: hughes@soda.berkeley.edu
+Message Hash: 1cb41753bf65e002a001ebdff3469ba8c095aa151ce1f7a7b8fc22e578c215bd
+Message ID: \<199210180820.AA24894@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-18 08:21:11 UTC
+Raw Date: Sun, 18 Oct 92 01:21:11 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Sun, 18 Oct 92 01:21:11 PDT
+To: hughes@soda.berkeley.edu
+Subject: Re: one time pads
+Message-ID: <199210180820.AA24894@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Sigh... well, I guess I can see if the people I know who are interested,
+would do it as a freebie...
+
+Funny thing is, when I first looked into crypto for dissident purposes, back
+in 1981 or so, I was interested in a PKS implementation, but someone else in
+my circle persuaded me that OTPs would be preferable in some cases. Now
+here we are with a PKS and I'm still making noises about OTPs.
+
+Guess the debate is closed for the moment... congratulations, y'all, for
+good arguements in a good tone.
+Now the well is about to close for the night, so I gotta scoot.
+Be back soon...
+
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-18 (Sun, 18 Oct 92 01:21:11 PDT) - Re: one time pads - _George A. Gleason \_
+
diff --git a/_emails/1992/10/1ce894a4595e4385435ca9bc1f3f60cac623e7cf191fa1f6b08f23122cd86ff0.md b/_emails/1992/10/1ce894a4595e4385435ca9bc1f3f60cac623e7cf191fa1f6b08f23122cd86ff0.md
new file mode 100644
index 0000000000..2394172959
--- /dev/null
+++ b/_emails/1992/10/1ce894a4595e4385435ca9bc1f3f60cac623e7cf191fa1f6b08f23122cd86ff0.md
@@ -0,0 +1,217 @@
+---
+layout: default
+---
+
+# 1992-10-09 - The technical explanation of "::" incoming header pasting
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 1ce894a4595e4385435ca9bc1f3f60cac623e7cf191fa1f6b08f23122cd86ff0
+Message ID: \<9210091650.AA12173@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-09 16:43:05 UTC
+Raw Date: Fri, 9 Oct 92 09:43:05 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Fri, 9 Oct 92 09:43:05 PDT
+To: cypherpunks@toad.com
+Subject: The technical explanation of "::" incoming header pasting
+Message-ID: <9210091650.AA12173@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+There's a new feature in the remailing software.
+
+Some people can't add arbitrary header fields because of mailer or
+gateway restrictions. This restricts them from using the remailer. I
+have added a facility to allow new header fields to be pasted onto the
+end of a header when the mail arrives. This effectively happens
+before processing by the remailer software. These new fields exist
+during transit in the message body, where they remain untouched. Only
+after the message is delivered to my account does this operator
+take effect.
+
+Syntax: If the first line of the body is the two characters "::", then
+the following lines are appended to the header, up to the next blank
+line.
+
+Here's how it works.
+
+First of all, here's my new .maildelivery file:
+
+------- cut here -------
+#
+# field pattern action/ string
+# result (quote included spaces)
+#
+Request-Remailing-To "" pipe R "perl remailer/remail.perl"
+Request-Remailing-To "" file R remailer/archive
+* "" pipe R "/usr/local/lib/mh/rcvtty -biff"
+* "" pipe ? "perl remailer/incoming.header.perl"
+------- cut here -------
+
+Comments are indicated by #. The Request-Remailing-To lines have been
+there. The second of the makes an archive for debugging purposes. It
+will go eventually. The third field, "*", indicates all fields, it
+runs 'rcvtty' on my mail; this replaces the function of biff, since
+mail is getting piped to slocal now, disabling biff.
+
+The last line is the important one. It says "If the mail hasn't been
+delivered by now, run the incoming header rewrite script on it. If
+that doesn't work, continue trying to deliver it."
+
+Now here's the trick. slocal has no way of taking the output of the
+rewrite and continuing to process it. (It should. It would make this
+whole job easy.) So in order to continue processing, you need to
+redeliver the mail. You could invoke sendmail and mail it back to
+yourself, but that would mangle the existing header. So the thing to
+do is to recursively invoke slocal from within the perl script.
+
+Here's the perl script to do all this:
+
+------- cut here -------
+ # First read in the whole header.
+ # We check for the Second-Pass: line to detect infinite loops.
+
+while (<>) {
+ last if /^$/ ;
+ exit 1 if /^Second-Pass:/ ;
+ $header .= $_ ;
+}
+
+ # We have just read the last line in the header.
+ # Now we check to see if there is a pasting operator.
+
+if ( ( $_ = <> ) && /^::$/ ) {
+ while (<>) {
+ last if /^$/ ;
+ $header .= $_ ;
+ }
+} else {
+ # There is either an empty body or no pasting operator
+ # Thus exit with a return code of 1 to indicate that
+ # the mail has not been delivered.
+ exit 1 ;
+}
+
+# There was a header pasting operator.
+# So we open 'slocal' as a pipe, effectively redelivering the mail
+# back to ourselves.
+
+#open( OUTPUT, ">foo" ) ;
+open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ;
+select( OUTPUT ) ;
+
+# print a "From " line to satisfy slocal
+
+@weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ;
+@months = ( "Jan","Feb","Mar","Apr","May",
+ "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ;
+($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ;
+printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ;
+printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ;
+
+# Now just print out the message
+
+print $header ;
+print "Second-Pass:\n" ;
+print "\n" ;
+while (<>) {
+} continue {
+ print ;
+}
+
+------- cut here -------
+
+Here's how the perl script works.
+
+The first loop reads lines from the existing header. When it sees a
+blank line (regexp /^$/) it terminates the loop. If it sees a field
+"Second-Pass", it knows it has filtered this message before and exits
+with a return code indicating that the mail has not been delivered.
+The variable $header is appended with the current header line.
+$header contains the whole header when the loop terminates.
+
+Properly speaking, the Second-Pass test is not necessary to detect
+infinite loops. Since the pasting operator gets removed during the
+rewrite, the script won't return an exit status of 0 more times than
+the pasting operator appears. But should something get screwed up,
+such as a different module adding pasting commands (how? I don't know),
+the Second-Pass test should prevent infinite recursion.
+
+The next statement reads another line from the input file. This line
+is the first line of the message body. If this line is the pasting
+operator, then header lines are accumulated in $header as before until
+a blank line. The difference is that these header lines are being
+read from the body of the message. If there is no pasting operator,
+the script exits undelivered.
+
+At this point we now have to redeliver the message back to ourselves.
+We first open slocal as the output pipe.
+
+The next section is a kludge. It turns out that slocal strips off the
+out-of-band "From " (no colon) line that the mail delivery system
+uses. In other words, the message which slocal pipes into its pipes
+is not identical to the message it itself received. This means that
+slocal cannot be directly recursed. What this section does is to
+create a "From " line to make slocal happy. It calls localtime() and
+then formats those numbers into the proper form.
+
+It turns out that slocal will deliver this mail without the "From "
+line, even to /usr/spool/mail, but it doesn't do so properly. On my
+system, in added some delimiters which I think I've tracked down to
+the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these
+are not null on my system, there's some garbage added which screws up
+separation of the spool file into messages. Adding a "From " line
+fixes that. This misbehavior may not be so surprising, considering
+that slocal was "meant" to be invoked only in a .forward file.
+
+Now we print the variable $header which contains the whole header,
+including newlines. Using a single string removes the need for an
+array. We added the Second-Pass line and a blank line for the end of
+the header. The final loop prints out the rest of the message body.
+
+There is another way to proceed to get the same functionality. One
+could write a filter to translate the first occurrence only of
+\n\n::\n into \n. We could then pass the message through this filter
+before slocal saw it. And for now, that would do the same thing.
+
+But suppose we want more that one rewrite rule active? Then you would
+only be able to apply each rewrite rule exactly once in fixed order.
+You want to be able to rewrite a message and then apply all the
+rewrite rules again.
+
+At least one other rewrite rule is planned: automatic decryption.
+Since decrypting a message will completely change the body, and since
+some of the header fields may need to be hidden, you have to be able
+to decrypt the body and then paste on header lines. But since you
+need to indicate an encrypted body by a header line (well, not really,
+but it's more reliable), and since some people can't add these header
+lines, you need to paste lines before encryption as well.
+
+Thus the rewrite rules need to be applied asyncronously and hence I'm
+using a fairly complex slocal scheme to do a simple filter.
+Eventually I hope to write an equivalent to slocal which knows about
+message rewrites and simple filters, but that's for later.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Fri, 9 Oct 92 09:43:05 PDT) - The technical explanation of "::" incoming header pasting - _Eric Hughes \_
+
diff --git a/_emails/1992/10/1eea0ede39035ff4b7e883851446a69768d6e4f5d546d0a5b37182f47cce4f4e.md b/_emails/1992/10/1eea0ede39035ff4b7e883851446a69768d6e4f5d546d0a5b37182f47cce4f4e.md
new file mode 100644
index 0000000000..222c42a8a0
--- /dev/null
+++ b/_emails/1992/10/1eea0ede39035ff4b7e883851446a69768d6e4f5d546d0a5b37182f47cce4f4e.md
@@ -0,0 +1,74 @@
+---
+layout: default
+---
+
+# 1992-10-14 - Integrated privacy...
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 1eea0ede39035ff4b7e883851446a69768d6e4f5d546d0a5b37182f47cce4f4e
+Message ID: \<2931.2ADB225F@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-14 02:52:16 UTC
+Raw Date: Tue, 13 Oct 92 19:52:16 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Tue, 13 Oct 92 19:52:16 PDT
+To: cypherpunks@toad.com
+Subject: Integrated privacy...
+Message-ID: <2931.2ADB225F@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> Absolutely. The most crying need now, IMO, is to better
+ U> integrate the cryptographic tools into mail readers and
+ U> senders, so that it's not such a pain to use these things.
+ U> People should be able to give a single command or press a
+ U> button to decrypt an incoming message or encrypt an
+ U> outgoing one.
+
+I just completed (well, it's in "beta") a mail-reader package for
+MSDOS and FidoNet. It does "rm" type stuff, and has PGP integrated
+reawonably well. Single character commands to decrypt, encrypt, sign,
+or encrypt/sign. It furnishes the distributed PGP.EXE program with
+it's imput (deriving it from the message itself). It'll extract keys
+from messages, and all that.
+
+It's MSDOS and .MSG-type FidoNet message base oriented, but it does
+all it's work in pure ASCII (FidoNet .MSG files are mixed binary and
+text). It is intentionally "RFC-822 like", and will become fully
+RFC-822 "soon".
+
+I was reasonably careful regarding de-cyphered plaintext laying about
+on disk, etc. It's available via Wazoo filerequest as magicname RM.
+(That's probably as obscure to you as FTP is to FidoNet.)
+
+It will be released as "copyleft" with all sources. Binaries only
+this week til I get it shaken down.
+
+
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-14 (Tue, 13 Oct 92 19:52:16 PDT) - Integrated privacy... - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/200d440b3ce47cfce824973681a175c86df247d92d5e7dc292012ab8bc88656a.md b/_emails/1992/10/200d440b3ce47cfce824973681a175c86df247d92d5e7dc292012ab8bc88656a.md
new file mode 100644
index 0000000000..29bc073693
--- /dev/null
+++ b/_emails/1992/10/200d440b3ce47cfce824973681a175c86df247d92d5e7dc292012ab8bc88656a.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-10-23 - Diffie-Hellman
+
+## Header Data
+
+From: "Scott Collins" \
+To: "Cypher Punks" \
+Message Hash: 200d440b3ce47cfce824973681a175c86df247d92d5e7dc292012ab8bc88656a
+Message ID: \<9210230706.AA04122@relay2.UU.NET\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-23 07:06:14 UTC
+Raw Date: Fri, 23 Oct 92 00:06:14 PDT
+
+## Raw message
+
+```
+{% raw %}From: "Scott Collins"
+Date: Fri, 23 Oct 92 00:06:14 PDT
+To: "Cypher Punks"
+Subject: Diffie-Hellman
+Message-ID: <9210230706.AA04122@relay2.UU.NET>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Subject: Diffie-Hellman
+
+>Since there's no perceived value and since all the software would
+>require license from RSADSI, it won't happen that way.
+
+It was not my understanding that RSA held any patents, copyrights or other controls
+over Diffie-Hellman key exchange. The 'big-number' math required is not
+difficult and is fully documented in Knuth's "The Art of Computer Programming",
+vol2: Seminumerical Algorithms; section 4.3: Multiple Precision Arithmetic.
+Also note that this multiple precision code is available in the PGP source in
+the file mpilib.c.
+
+The exchanged key could easily be a DES (or other fast symmetric cypher) key --
+and usually is. Unless you want to perform an authenticated key exchange with
+Diffie-Hellman as described in "Authentication and Authenticated Key Exchanges" [Diffie,
+Van Oorschot and Wiener in "Designs, Codes and Cryptography", 2, 107-125 (1992)]
+using certificates signed with the RSA algorithm, then RSA doesn't have to enter
+the picture at all.
+
+Is my understanding of RSAs controls incorrect?
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-23 (Fri, 23 Oct 92 00:06:14 PDT) - Diffie-Hellman - _"Scott Collins" \_
+
diff --git a/_emails/1992/10/20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070.md b/_emails/1992/10/20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070.md
new file mode 100644
index 0000000000..ef9e2d95e0
--- /dev/null
+++ b/_emails/1992/10/20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070.md
@@ -0,0 +1,58 @@
+---
+layout: default
+---
+
+# 1992-10-08 - Subscriptions, etc.
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070
+Message ID: \<9210081604.AA15870@soda.berkeley.edu\>
+Reply To: \<9210081541.AA03134@toad.com\>
+UTC Datetime: 1992-10-08 15:57:23 UTC
+Raw Date: Thu, 8 Oct 92 08:57:23 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Thu, 8 Oct 92 08:57:23 PDT
+To: cypherpunks@toad.com
+Subject: Subscriptions, etc.
+In-Reply-To: <9210081541.AA03134@toad.com>
+Message-ID: <9210081604.AA15870@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Yow! I'm a hypocrite!
+
+Now _I_ forgot to look at the reply line. Damn.
+
+Diligence, diligence.
+
+--------------------------------------------
+
+In other news, the list membership is up to 60 people and one local
+newsgroup gateway. I have five more to add, some of whose addresses I
+have to find out.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-08 (Thu, 8 Oct 92 07:04:56 PDT) - [Subscribe](/years/1992/10/454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f) - _whitaker@eternity.demon.co.uk (Russell E. Whitaker)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:41:35 PDT) - [Subscribe](/years/1992/10/4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42) - _hughes (Eric Hughes)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:57:23 PDT) - Subscriptions, etc. - _Eric Hughes \_
+
diff --git a/_emails/1992/10/21eb2845724e8c20b4bad621a09e57464c0ff3888812380cbecbb2b49bae4fbb.md b/_emails/1992/10/21eb2845724e8c20b4bad621a09e57464c0ff3888812380cbecbb2b49bae4fbb.md
new file mode 100644
index 0000000000..1ade3c3d63
--- /dev/null
+++ b/_emails/1992/10/21eb2845724e8c20b4bad621a09e57464c0ff3888812380cbecbb2b49bae4fbb.md
@@ -0,0 +1,46 @@
+---
+layout: default
+---
+
+# 1992-10-10 - random
+
+## Header Data
+
+From: Eric Hollander \
+To: cypherpunks@toad.com
+Message Hash: 21eb2845724e8c20b4bad621a09e57464c0ff3888812380cbecbb2b49bae4fbb
+Message ID: \<9210102041.AA04891@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-10 20:33:53 UTC
+Raw Date: Sat, 10 Oct 92 13:33:53 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hollander
+Date: Sat, 10 Oct 92 13:33:53 PDT
+To: cypherpunks@toad.com
+Subject: random
+Message-ID: <9210102041.AA04891@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+So when are we going to start alt.crypt, where we just post a lot of
+uuencode'ed random data?
+
+e
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-10 (Sat, 10 Oct 92 13:33:53 PDT) - random - _Eric Hollander \_
+
diff --git a/_emails/1992/10/228284a4836f0d9252ddf094ef2c55dbc324950fbbc2b9e7af6b1106cd26051b.md b/_emails/1992/10/228284a4836f0d9252ddf094ef2c55dbc324950fbbc2b9e7af6b1106cd26051b.md
new file mode 100644
index 0000000000..8b5108301d
--- /dev/null
+++ b/_emails/1992/10/228284a4836f0d9252ddf094ef2c55dbc324950fbbc2b9e7af6b1106cd26051b.md
@@ -0,0 +1,51 @@
+---
+layout: default
+---
+
+# 1992-10-23 - Eavesdropping on a printer's signature
+
+## Header Data
+
+From: nobody@soda.berkeley.edu
+To: cypherpunks@toad.com
+Message Hash: 228284a4836f0d9252ddf094ef2c55dbc324950fbbc2b9e7af6b1106cd26051b
+Message ID: \<9210230609.AA26646@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-23 06:10:13 UTC
+Raw Date: Thu, 22 Oct 92 23:10:13 PDT
+
+## Raw message
+
+```
+{% raw %}From: nobody@soda.berkeley.edu
+Date: Thu, 22 Oct 92 23:10:13 PDT
+To: cypherpunks@toad.com
+Subject: Eavesdropping on a printer's signature
+Message-ID: <9210230609.AA26646@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+While doing a summer (1980?) co-op with Raytheon Submarine Signal
+division in Newport RI, a milk-truck-sized van pulled up out front
+and opened a sliding side door. Inside was a line printer
+that was busy printing out the same text that an internal (in the
+middle of the building, perhaps 150 feet away) line-printer was
+printing. There were mistakes, but it was readable.
+
+My guess is that with all the electromechanical pulses the printer
+was emanating this was pretty easy. Probably harder to do with a
+laser printer...
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-23 (Thu, 22 Oct 92 23:10:13 PDT) - Eavesdropping on a printer's signature - _nobody@soda.berkeley.edu_
+
diff --git a/_emails/1992/10/2354d012d9195764785cc4d5b1fb9b3a566d8c08b2f3caadb23470bad07047e3.md b/_emails/1992/10/2354d012d9195764785cc4d5b1fb9b3a566d8c08b2f3caadb23470bad07047e3.md
new file mode 100644
index 0000000000..332bad216b
--- /dev/null
+++ b/_emails/1992/10/2354d012d9195764785cc4d5b1fb9b3a566d8c08b2f3caadb23470bad07047e3.md
@@ -0,0 +1,65 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Registering Keys...
+
+## Header Data
+
+From: pmetzger@shearson.com (Perry E. Metzger)
+To: 74076.1041@compuserve.com
+Message Hash: 2354d012d9195764785cc4d5b1fb9b3a566d8c08b2f3caadb23470bad07047e3
+Message ID: \<9210261643.AA16936@newsu.shearson.com\>
+Reply To: \<921026155917_74076.1041_DHJ88-1@CompuServe.COM\>
+UTC Datetime: 1992-10-26 17:08:45 UTC
+Raw Date: Mon, 26 Oct 92 10:08:45 PPE
+
+## Raw message
+
+```
+{% raw %}From: pmetzger@shearson.com (Perry E. Metzger)
+Date: Mon, 26 Oct 92 10:08:45 PPE
+To: 74076.1041@compuserve.com
+Subject: Registering Keys...
+In-Reply-To: <921026155917_74076.1041_DHJ88-1@CompuServe.COM>
+Message-ID: <9210261643.AA16936@newsu.shearson.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+>From: Hal <74076.1041@compuserve.com>
+
+>This proposal makes it illegal for people to communicate so secretly
+>that the government can't find out what they are saying. It could
+>apply to postal mail as well as email - it would be illegal to send
+>a message via post which the government couldn't interpret. If this
+>is really the government's purpose, then it should also require that all
+>private conversations be recorded, and the resulting tapes be "escrowed"
+>similarly in case the government needed to find out what was said,
+>for which it would have to get a court order.
+
+>As Tim suggested, this is probably a "trial balloon" being floated to
+>see what the reaction is. Let's see that it gets shot down.
+
+I find it repugnant that we've gone all the way over to the notion
+that people must actively cooperate with their own enslavement. We'd
+better start getting organized flames against this idea mobilized.
+Denning is on the net -- anyone care to start flaming on sci.crypt?
+Its likely the place that will get the most response in the general
+community.
+
+Perry
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 09:23:21 PPE) - [Registering Keys...](/years/1992/10/15812353cae00b92b6950171b0944602902caba39821204d31a8223d50e1bff6) - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-26 (Mon, 26 Oct 92 10:08:45 PPE) - Registering Keys... - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/235c7c3e14ca0abdb4ef75a7cbe79f081cb2aae7eb5ca8ebfcc604717216bfc1.md b/_emails/1992/10/235c7c3e14ca0abdb4ef75a7cbe79f081cb2aae7eb5ca8ebfcc604717216bfc1.md
new file mode 100644
index 0000000000..9b5f1f1c0e
--- /dev/null
+++ b/_emails/1992/10/235c7c3e14ca0abdb4ef75a7cbe79f081cb2aae7eb5ca8ebfcc604717216bfc1.md
@@ -0,0 +1,58 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Re: Alpha Particles and One Time Pads
+
+## Header Data
+
+From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
+To: cypherpunks@toad.com
+Message Hash: 235c7c3e14ca0abdb4ef75a7cbe79f081cb2aae7eb5ca8ebfcc604717216bfc1
+Message ID: \<9210261024.AA11069@kg6kf.ampr.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 10:44:55 UTC
+Raw Date: Mon, 26 Oct 92 03:44:55 PPE
+
+## Raw message
+
+```
+{% raw %}From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
+Date: Mon, 26 Oct 92 03:44:55 PPE
+To: cypherpunks@toad.com
+Subject: Re: Alpha Particles and One Time Pads
+Message-ID: <9210261024.AA11069@kg6kf.ampr.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Tim May sez:
+ Here's a posting I just sent to sci.crypt, dealing with using alpha
+ particle sources as noise sources for generating one-time pads.
+
+Tim,
+Why not use a back-biased germanium diode, or other noisy semiconductor
+junction? Seriously, the NRC has allowed the smoke detector people to
+spread those little radioactive chunks of Americium for too long.
+
+John Walker of AutoDesk actually built an IBM-PC card that generated
+random numbers from a radioactive source.
+
+All the best,
+
+^M
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 03:44:55 PPE) - Re: Alpha Particles and One Time Pads - _marc@kg6kf.ampr.org (Marc de Groot - KG6KF)_
+ + 1992-10-26 (Mon, 26 Oct 92 12:13:42 PPE) - [Re: Alpha Particles and One Time Pads](/years/1992/10/96f4cccc3f7dcec3807398d9e17c2ea77516a4daa35cb38c9570bec1fea0481d) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/23def49fd60616a55ca036b06643363d86f2e3d62e1b1ead38adbf49d8495208.md b/_emails/1992/10/23def49fd60616a55ca036b06643363d86f2e3d62e1b1ead38adbf49d8495208.md
new file mode 100644
index 0000000000..6e39db236a
--- /dev/null
+++ b/_emails/1992/10/23def49fd60616a55ca036b06643363d86f2e3d62e1b1ead38adbf49d8495208.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-10-16 - Re: Game items...
+
+## Header Data
+
+From: Eric Hollander \
+To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
+Message Hash: 23def49fd60616a55ca036b06643363d86f2e3d62e1b1ead38adbf49d8495208
+Message ID: \<9210160013.AA19109@soda.berkeley.edu\>
+Reply To: \<2962.2ADD350B@fidogate.FIDONET.ORG\>
+UTC Datetime: 1992-10-16 00:23:16 UTC
+Raw Date: Thu, 15 Oct 92 17:23:16 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hollander
+Date: Thu, 15 Oct 92 17:23:16 PDT
+To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
+Subject: Re: Game items...
+In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG>
+Message-ID: <9210160013.AA19109@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+>-- Access to genuine information on RU-48 (?) the so-called abortion
+>pill. Turns out it does some cool stuff re: breast cancer and even
+>morning-after abortion.
+
+RU 486 (no, it's not Intel's pharmaceuticals division).
+
+This is actually a really good example of something that could be the
+subject of the game. Medical researchers need it because it has the
+potential to save lives. However, synthesis and import of it into the
+United States is banned, no matter what quantities are needed or what use it
+is needed for. It is an interesting and powerful substance and we should be
+doing research on it, but instead we are letting a small minority of people
+with no medical knowledge dictate the policy of our entire nation. Oh
+well. I hope to have European citizenship someday (especially if Geroge
+wins).
+
+e
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-15 (Thu, 15 Oct 92 02:10:13 PDT) - [re: Game items...](/years/1992/10/ce279b19b49d07d1574d291311a0733a6c7c3f25ba24f44c9ebe81f8b10d6b36) - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+ + 1992-10-16 (Thu, 15 Oct 92 17:23:16 PDT) - Re: Game items... - _Eric Hollander \_
+
diff --git a/_emails/1992/10/2414b4e9749952e702f40e3ab08b5c8c4f13ba6c41f4fd2ddcc01ba85e3079c8.md b/_emails/1992/10/2414b4e9749952e702f40e3ab08b5c8c4f13ba6c41f4fd2ddcc01ba85e3079c8.md
new file mode 100644
index 0000000000..c3714921ca
--- /dev/null
+++ b/_emails/1992/10/2414b4e9749952e702f40e3ab08b5c8c4f13ba6c41f4fd2ddcc01ba85e3079c8.md
@@ -0,0 +1,59 @@
+---
+layout: default
+---
+
+# 1992-10-22 - Re: Keystone
+
+## Header Data
+
+From: sdw@meaddata.com (Stephen Williams)
+To: gnu@cygnus.com
+Message Hash: 2414b4e9749952e702f40e3ab08b5c8c4f13ba6c41f4fd2ddcc01ba85e3079c8
+Message ID: \<9210221600.AA21898@bugatti.meaddata.com\>
+Reply To: \<9210220637.AA20200@cygnus.com\>
+UTC Datetime: 1992-10-22 17:09:30 UTC
+Raw Date: Thu, 22 Oct 92 10:09:30 PDT
+
+## Raw message
+
+```
+{% raw %}From: sdw@meaddata.com (Stephen Williams)
+Date: Thu, 22 Oct 92 10:09:30 PDT
+To: gnu@cygnus.com
+Subject: Re: Keystone
+In-Reply-To: <9210220637.AA20200@cygnus.com>
+Message-ID: <9210221600.AA21898@bugatti.meaddata.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+..
+> real advantage, since you can get free source for just about program,
+> while "free" PC programs means free binaries. If anyone knows of a
+> reasonably popular PC terminal emulator for which source code is
+> freely available and distributable, let us know.
+PC Kermit, of course. The best vt100 emulator around, last I used them
+heavily.
+>
+
+sdw
+--
+Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager
+LIG dev./sales Internet: sdw@world.std.com CIS 76244.210@compuserve.com
+OO R&D Source Dist. By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342
+GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Wed, 21 Oct 92 22:35:21 PDT) - [Keystone](/years/1992/10/4b028509a502332d7eb20d667f19c0822f161f636956254fb21a228f7050899b) - _Eric Hughes \_
+ + 1992-10-22 (Wed, 21 Oct 92 23:35:44 PDT) - [Re: Keystone](/years/1992/10/fb6cd513252375d40032e5c92dc6f0e2a944525554d20788331d097d9233143d) - _gnu@cygnus.com_
+ + 1992-10-22 (Thu, 22 Oct 92 10:09:30 PDT) - Re: Keystone - _sdw@meaddata.com (Stephen Williams)_
+
diff --git a/_emails/1992/10/26b81383c805929e3c002c3f7836848983275fee0cf94a079d7717bfd346d887.md b/_emails/1992/10/26b81383c805929e3c002c3f7836848983275fee0cf94a079d7717bfd346d887.md
new file mode 100644
index 0000000000..e7902f1b3f
--- /dev/null
+++ b/_emails/1992/10/26b81383c805929e3c002c3f7836848983275fee0cf94a079d7717bfd346d887.md
@@ -0,0 +1,52 @@
+---
+layout: default
+---
+
+# 1992-10-27 - Re: A Trial Balloon to Ban Encryption?
+
+## Header Data
+
+From: gnu
+To: tcmay@netcom.com (Timothy C. May), cypherpunks
+Message Hash: 26b81383c805929e3c002c3f7836848983275fee0cf94a079d7717bfd346d887
+Message ID: \<9210270908.AA00325@toad.com\>
+Reply To: \<9210261819.AA07688@netcom2.netcom.com\>
+UTC Datetime: 1992-10-27 09:08:56 UTC
+Raw Date: Tue, 27 Oct 92 02:08:56 PPE
+
+## Raw message
+
+```
+{% raw %}From: gnu
+Date: Tue, 27 Oct 92 02:08:56 PPE
+To: tcmay@netcom.com (Timothy C. May), cypherpunks
+Subject: Re: A Trial Balloon to Ban Encryption?
+In-Reply-To: <9210261819.AA07688@netcom2.netcom.com>
+Message-ID: <9210270908.AA00325@toad.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+> I think it was John Gilmore who said: "If encryption is outlawed, only
+> outlaws will have encryption."
+
+Maybe. But I like John Perry Barlow's formulation better:
+
+"You can have my encryption algorithm when you pry my cold dead fingers
+from its private key."
+
+ John
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 11:22:35 PPE) - [(fwd) A Trial Balloon to Ban Encryption?](/years/1992/10/38fbbe375ba50d24f74e7a2036b91a85401f68ccf280d843e3d6930e6634d353) - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-10-27 (Tue, 27 Oct 92 02:08:56 PPE) - Re: A Trial Balloon to Ban Encryption? - _gnu_
+
diff --git a/_emails/1992/10/275154781ea5f331380a67d875964b36eacfaa5b6310d2811f94b1db35be8356.md b/_emails/1992/10/275154781ea5f331380a67d875964b36eacfaa5b6310d2811f94b1db35be8356.md
new file mode 100644
index 0000000000..5fafdf7c35
--- /dev/null
+++ b/_emails/1992/10/275154781ea5f331380a67d875964b36eacfaa5b6310d2811f94b1db35be8356.md
@@ -0,0 +1,68 @@
+---
+layout: default
+---
+
+# 1992-10-22 - "Cypherpunks write code"
+
+## Header Data
+
+From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+To: cypherpunks@toad.com
+Message Hash: 275154781ea5f331380a67d875964b36eacfaa5b6310d2811f94b1db35be8356
+Message ID: \<2580@eternity.demon.co.uk\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-22 07:00:52 UTC
+Raw Date: Thu, 22 Oct 92 00:00:52 PDT
+
+## Raw message
+
+```
+{% raw %}From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+Date: Thu, 22 Oct 92 00:00:52 PDT
+To: cypherpunks@toad.com
+Subject: "Cypherpunks write code"
+Message-ID: <2580@eternity.demon.co.uk>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Eric Hughes writes:
+
+>
+> Cypherpunks write code.
+>
+> This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix,
+> etc. for the PC, someone who knows the various Mac, Amiga, Atari, and
+> other machines. This will mean someone to write nice pretty visual
+> interfaces for PGP to put all the PGP options on menus where they are
+> all visible. This will mean people to think about BBS/terminal
+> protocols. This will mean lots of individual contributions, no single
+> of which need be large, but whose sum will be.
+>
+> Eric
+>
+
+Count me in on the Procomm scripting. I *may* do something for Telix,
+too.
+
+Who knows? I may sell the scripts/interfaces on AMiX. ;-)
+
+
+Russell Earl Whitaker whitaker@eternity.demon.co.uk
+Communications Editor 71750.2413@compuserve.com
+EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER
+Board member, Extropy Institute (ExI)
+================ PGP 2.0 public key available =======================
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 00:00:52 PDT) - "Cypherpunks write code" - _whitaker@eternity.demon.co.uk (Russell E. Whitaker)_
+
diff --git a/_emails/1992/10/27708d1bd342959acd3e40d9fa98d462c357f0b098de7f57772db854d4934a7f.md b/_emails/1992/10/27708d1bd342959acd3e40d9fa98d462c357f0b098de7f57772db854d4934a7f.md
new file mode 100644
index 0000000000..4689c5e532
--- /dev/null
+++ b/_emails/1992/10/27708d1bd342959acd3e40d9fa98d462c357f0b098de7f57772db854d4934a7f.md
@@ -0,0 +1,81 @@
+---
+layout: default
+---
+
+# 1992-10-20 - More private PGP...?
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 27708d1bd342959acd3e40d9fa98d462c357f0b098de7f57772db854d4934a7f
+Message ID: \<9210201533.AA07309@soda.berkeley.edu\>
+Reply To: \<9210200622.AA10349@soda.berkeley.edu\>
+UTC Datetime: 1992-10-20 15:33:46 UTC
+Raw Date: Tue, 20 Oct 92 08:33:46 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Tue, 20 Oct 92 08:33:46 PDT
+To: cypherpunks@toad.com
+Subject: More private PGP...?
+In-Reply-To: <9210200622.AA10349@soda.berkeley.edu>
+Message-ID: <9210201533.AA07309@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+>One of the things I've noticed about PGP is that it makes it pretty
+>obvious that you're sending an encrypted message. [...] Sending
+>encrypted messages may call unwelcome attention to yourself.
+
+First, let me get on record as saying that Hal's "innocent mode" is a
+good idea that should be implemented.
+
+But it's not really a good long-term solution from a social point of
+view. Encrypted traffic should become the norm, not the exception.
+Flagging that you're sending encrypted traffic should be encouraged.
+When questioned about this, people should respond in shocked tones
+"What do mean? Aren't you encrypting _your_ email?" and then proceed
+to suppress gentle laughter at them when they say no.
+
+When it's cool to encrypt, only the uncool will be plain.
+
+So, then, more peer pressure! Consider someone asking you about your
+encrypted mail to be an opportunity to start a conversation about
+their position on personal privacy. When your sysadmin asks why your
+mail can't be read, tell him you are defending your privacy and ask if
+there is any problem with that. Then, when the sysadmin puts in a
+filter for PGP traffic, use innocent mode.
+
+>Another thing that I think is kind of bad about PGP in the context
+>of avoiding traffic analysis is that it puts the key ID of the
+>destination person in the header.
+
+Absolutely. Ditto for signatures. Both should be able to be
+selectively removed. In any case, it should be possible to have
+nothing appear on the outer envelope.
+
+Another feature for PGP would be automatic message padding. To
+properly do a mix you need to quantize the message lengths. If PGP
+were to automatically pad with random data, it would save a lot of
+integration work for the mix. PGP already has a random number
+generator, after all.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Mon, 19 Oct 92 23:22:30 PDT) - [More private PGP...?](/years/1992/10/28d6b7fffe6975bc2644d84e8b632806749253c90050aafafcf27218d336ff2f) - _nobody@soda.berkeley.edu_
+ + 1992-10-20 (Tue, 20 Oct 92 08:33:46 PDT) - More private PGP...? - _Eric Hughes \_
+
diff --git a/_emails/1992/10/28d6b7fffe6975bc2644d84e8b632806749253c90050aafafcf27218d336ff2f.md b/_emails/1992/10/28d6b7fffe6975bc2644d84e8b632806749253c90050aafafcf27218d336ff2f.md
new file mode 100644
index 0000000000..44991f9b3f
--- /dev/null
+++ b/_emails/1992/10/28d6b7fffe6975bc2644d84e8b632806749253c90050aafafcf27218d336ff2f.md
@@ -0,0 +1,105 @@
+---
+layout: default
+---
+
+# 1992-10-20 - More private PGP...?
+
+## Header Data
+
+From: nobody@soda.berkeley.edu
+To: cypherpunks@toad.com
+Message Hash: 28d6b7fffe6975bc2644d84e8b632806749253c90050aafafcf27218d336ff2f
+Message ID: \<9210200622.AA10349@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-20 06:22:30 UTC
+Raw Date: Mon, 19 Oct 92 23:22:30 PDT
+
+## Raw message
+
+```
+{% raw %}From: nobody@soda.berkeley.edu
+Date: Mon, 19 Oct 92 23:22:30 PDT
+To: cypherpunks@toad.com
+Subject: More private PGP...?
+Message-ID: <9210200622.AA10349@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+One of the things I've noticed about PGP is that it makes it pretty
+obvious that you're sending an encrypted message. The big
+
+-----BEGIN PGP MESSAGE-----
+
+at the start pretty much gives that away.
+
+In most cases, this is fine, but sometimes it may not be desirable
+to make it this obvious. Sending encrypted messages may call
+unwelcome attention to yourself. Also, some people are experimenting
+with packet radio on the amateur bands, and it's not legal to send
+encrypted messages there.
+
+What I think would be nice would be an "innocent" mode for PGP
+in which it created files which looked like something else. For
+example, what if your encrypted output file looked like:
+
+begin 666 testpat.gif
+MI\44:#G4D>QQXR!-M,Z20O1K&5D0, 5-4F.X<%MT
+M2:V94,K;XE@B?]%IHF+_WGI%(]#=F]/[LV+&!
+M,NH0(!3B35CW#!-Z7"B_L'=-C 8DLB-(J R"3?EE9<.>QE4Y?T$66IA7B@W?
+end
+
+This will be recognizable, if you've seen many, as a uuencoded file,
+a common encoding for non-ascii files. The header line suggests
+that it is a graphics file. Tons of these types of files are sent
+across email networks every day. Sending your encrypted messages
+in this form would give you a lower profile.
+
+Still, if someone goes to the effort to uudecode your message,
+and examines the resulting file, it will be obvious that it's not
+a GIF file because it lacks the proper headers. Instead, with
+the current PGP implementation it will be obvious that it is in
+fact a PGP file, because the header format matches the PGP spec.
+
+Again, I think it would be better if PGP in this mode were able to
+produce a file without headers which will give away what it is. Even
+better would be the ability to mimic headers of some other types
+of files, such as the .ZIP, .ZOO, or Unix "compress" format which are
+often used in binary files people mail around.
+
+Another thing that I think is kind of bad about PGP in the context
+of avoiding traffic analysis is that it puts the key ID of the
+destination person in the header. There was some discussion during
+development of a mode in which no key ID information would be in the
+header; the only way you'd have of knowing if the message was for
+you was to try decrypting it. (There is a checksum which is used
+internally to tell if the decryption was done with the right key.)
+This way you could broadcast messages to some group, and no one could
+know which person in the group you were sending to.
+
+These "anonymous destination" messages could be encoded with a key
+ID of zeros, and the PGP software could easily be modified to let
+the user try a decryption on such a message, reporting success or
+failure.
+
+How useful do these kinds of features seem to people? Would they
+really be helpful or is this just paranoia?
+
+Hal
+74076.1041@compuserve.com
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Mon, 19 Oct 92 23:22:30 PDT) - More private PGP...? - _nobody@soda.berkeley.edu_
+ + 1992-10-20 (Tue, 20 Oct 92 08:33:46 PDT) - [More private PGP...?](/years/1992/10/27708d1bd342959acd3e40d9fa98d462c357f0b098de7f57772db854d4934a7f) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/298d86c630be7b06958a77a0e2a93e61224cded16c21ee64acb6bc0f39e9ecfd.md b/_emails/1992/10/298d86c630be7b06958a77a0e2a93e61224cded16c21ee64acb6bc0f39e9ecfd.md
new file mode 100644
index 0000000000..d6a7d7fecf
--- /dev/null
+++ b/_emails/1992/10/298d86c630be7b06958a77a0e2a93e61224cded16c21ee64acb6bc0f39e9ecfd.md
@@ -0,0 +1,61 @@
+---
+layout: default
+---
+
+# 1992-10-23 - BBS E-mail policy Now see if this number is in one of the following ranges:
+
+## Header Data
+
+From: tribble@xanadu.com (E. Dean Tribble)
+To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET
+Message Hash: 298d86c630be7b06958a77a0e2a93e61224cded16c21ee64acb6bc0f39e9ecfd
+Message ID: \<9210231641.AA11868@xanadu.xanadu.com\>
+Reply To: \<9210230601.AA26160@soda.berkeley.edu\>
+UTC Datetime: 1992-10-23 21:42:19 UTC
+Raw Date: Fri, 23 Oct 92 14:42:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: tribble@xanadu.com (E. Dean Tribble)
+Date: Fri, 23 Oct 92 14:42:19 PDT
+To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET
+Subject: BBS E-mail policy Now see if this number is in one of the following ranges:
+In-Reply-To: <9210230601.AA26160@soda.berkeley.edu>
+Message-ID: <9210231641.AA11868@xanadu.xanadu.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+ [1.5 .. 2.5] encrypted text
+ [3 .. 6] regular text
+ [7 .. 8] line noise
+
+ This is a very simple measure. There are other measures to look for
+ the deviation from an expected distribution, which give much more
+ accurate distinctions. One can very easily separate languages from
+ each other just by looking at such measures.
+
+Where does uuencoded [compressed] binary lie? I would suspect it lies
+right around where encrypted text is. Presumably straight encrypted
+text is statistically random [7..8], but that when you8 encrypt to
+just the ascii subset is when you lose the entropy.
+
+dean
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 09:25:56 PDT) - [BBS E-mail policy](/years/1992/10/8a24672636a42d5225524b26c5cc78e1b0ba1b62a4c1e1fe1825463951a6b9e0) - _omega@spica.bu.edu (The Omega)_
+ + 1992-10-23 (Thu, 22 Oct 92 23:02:09 PDT) - [BBS E-mail policy](/years/1992/10/bc5b354247141e46df2c768591ee1dffd7fbc017a03b959da779cf82e2521133) - _Eric Hughes \_
+ + 1992-10-23 (Fri, 23 Oct 92 14:42:19 PDT) - BBS E-mail policy Now see if this number is in one of the following ranges: - _tribble@xanadu.com (E. Dean Tribble)_
+ + 1992-10-24 (Fri, 23 Oct 92 23:20:44 PDT) - [entropy measures](/years/1992/10/3c38d48ebe6788447fca198f92d44a9ffa68121b79032804da9a7944dc97d602) - _Eric Hughes \_
+ + 1992-10-26 (Sun, 25 Oct 92 21:41:19 PPE) - [Re: entropy measures](/years/1992/10/b71072e5de22f0ee2513a7bc057b82b39ad7284a70bf4913906340f5c39b27b3) - _Eric Hollander \_
+
diff --git a/_emails/1992/10/2be473d52a0362296b2fa5db0c5b7368828c3e322b7e2ac29c00d371d3c17539.md b/_emails/1992/10/2be473d52a0362296b2fa5db0c5b7368828c3e322b7e2ac29c00d371d3c17539.md
new file mode 100644
index 0000000000..bdcf51c08d
--- /dev/null
+++ b/_emails/1992/10/2be473d52a0362296b2fa5db0c5b7368828c3e322b7e2ac29c00d371d3c17539.md
@@ -0,0 +1,54 @@
+---
+layout: default
+---
+
+# 1992-10-20 - Home security...
+
+## Header Data
+
+From: mark@coombs.anu.edu.au (Mark)
+To: cypherpunks@toad.com
+Message Hash: 2be473d52a0362296b2fa5db0c5b7368828c3e322b7e2ac29c00d371d3c17539
+Message ID: \<9210200918.AA18129@coombs.anu.edu.au\>
+Reply To: \<199210200855.AA27037@well.sf.ca.us\>
+UTC Datetime: 1992-10-20 09:19:05 UTC
+Raw Date: Tue, 20 Oct 92 02:19:05 PDT
+
+## Raw message
+
+```
+{% raw %}From: mark@coombs.anu.edu.au (Mark)
+Date: Tue, 20 Oct 92 02:19:05 PDT
+To: cypherpunks@toad.com
+Subject: Home security...
+In-Reply-To: <199210200855.AA27037@well.sf.ca.us>
+Message-ID: <9210200918.AA18129@coombs.anu.edu.au>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+>This general area is part of a larger topic called TEMPEST. Anyone else
+>interested in pursuing this angle...?
+
+What's the best sources for faraday cages and TEMPEST etc? And does anyone
+out there implement anything of this type of security at home to protect
+against monitoring? The cost of such an exercise would be rather prohibitive
+to say the least.
+
+Just curious..
+Mark
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Tue, 20 Oct 92 01:56:22 PDT) - [Re: one time pads.](/years/1992/10/f521aad835f2995f4c759db006e61372149cd4cb840a397f387ad8a0a9dca1cb) - _George A. Gleason \_
+ + 1992-10-20 (Tue, 20 Oct 92 02:19:05 PDT) - Home security... - _mark@coombs.anu.edu.au (Mark)_
+
diff --git a/_emails/1992/10/2d63e88350175c0c0fbf601fc8fa86677404a48be269affc97ed929f354f72e5.md b/_emails/1992/10/2d63e88350175c0c0fbf601fc8fa86677404a48be269affc97ed929f354f72e5.md
new file mode 100644
index 0000000000..2621132bb1
--- /dev/null
+++ b/_emails/1992/10/2d63e88350175c0c0fbf601fc8fa86677404a48be269affc97ed929f354f72e5.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-10-25 - re: multiple message destinations
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 2d63e88350175c0c0fbf601fc8fa86677404a48be269affc97ed929f354f72e5
+Message ID: \<3266.2AEAF026@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 19:08:31 UTC
+Raw Date: Sun, 25 Oct 92 12:08:31 PPE
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Sun, 25 Oct 92 12:08:31 PPE
+To: cypherpunks@toad.com
+Subject: re: multiple message destinations
+Message-ID: <3266.2AEAF026@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+
+ U> 1) [...] Or send it yourself.
+
+As a paranoid person myself (I use the two phrases "sufficiently
+paranoid" (me, and most of us in here are sufficiently paranoid -- to
+at least consider the issues) and "insufficiently paranoid" -- people
+who conduct business over cordless or cellular voice, etc -- these
+paren'd subtexts are getting out of hand -- as a paranoid person
+myself I would only trust sending them myself.
+
+It's really a "code" issue -- given a list of addressees, will the
+miserable program you're using do the work for you.
+
+
+--- ReadMail
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sun, 25 Oct 92 12:08:31 PPE) - re: multiple message destinations - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/2d70f4bb92f4ef328aae493b3882459b8bb67b24261f1bb28f4a91e316c8e243.md b/_emails/1992/10/2d70f4bb92f4ef328aae493b3882459b8bb67b24261f1bb28f4a91e316c8e243.md
new file mode 100644
index 0000000000..0c6fefc505
--- /dev/null
+++ b/_emails/1992/10/2d70f4bb92f4ef328aae493b3882459b8bb67b24261f1bb28f4a91e316c8e243.md
@@ -0,0 +1,62 @@
+---
+layout: default
+---
+
+# 1992-10-07 - re: introducers
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 2d70f4bb92f4ef328aae493b3882459b8bb67b24261f1bb28f4a91e316c8e243
+Message ID: \<2715.2AD37337@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-07 23:46:07 UTC
+Raw Date: Wed, 7 Oct 92 16:46:07 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Wed, 7 Oct 92 16:46:07 PDT
+To: cypherpunks@toad.com
+Subject: re: introducers
+Message-ID: <2715.2AD37337@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> Detection of tampering is plenty good enough, I think, for
+ U> a _network_ policy of key distribution. For most people,
+ U> it will work fine.
+
+I guess I had to come at this from the backside. You are right.
+Accepting keys over the network will provide reasonably well-sealed
+envelopes. It won't provide notarized, hand-delivered security, but
+that's not what's needed *usually*.
+
+ U> For personal use, for people I know, I'm going to rely on
+ U> personally
+ U> exchanged keys.
+
+Exactly.
+
+ * Origin: World Power Systems / FidoNews (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-07 (Wed, 7 Oct 92 16:46:07 PDT) - re: introducers - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/2f6d5e1afd06d6ab7efd62ee0ef4f4e446d648d9648b1a1bcdca947107a33d2f.md b/_emails/1992/10/2f6d5e1afd06d6ab7efd62ee0ef4f4e446d648d9648b1a1bcdca947107a33d2f.md
new file mode 100644
index 0000000000..43fa37ea3d
--- /dev/null
+++ b/_emails/1992/10/2f6d5e1afd06d6ab7efd62ee0ef4f4e446d648d9648b1a1bcdca947107a33d2f.md
@@ -0,0 +1,74 @@
+---
+layout: default
+---
+
+# 1992-10-14 - Game items...
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: CYPHERPUNKS \
+Message Hash: 2f6d5e1afd06d6ab7efd62ee0ef4f4e446d648d9648b1a1bcdca947107a33d2f
+Message ID: \<921014151922_74076.1041_DHJ62-1@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-14 15:27:57 UTC
+Raw Date: Wed, 14 Oct 92 08:27:57 PDT
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Wed, 14 Oct 92 08:27:57 PDT
+To: CYPHERPUNKS
+Subject: Game items...
+Message-ID: <921014151922_74076.1041_DHJ62-1@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+I'm trying to think in terms of things which were illegal but
+which have good moral connotations today.
+
+Crosses and other Christian symbols were supposedly outlawed
+during the Roman empire (leading to the adoption of the fish
+as a symbol of Christianity). Posing as early Christians smuggling
+crosses ought to make the right-wingers happy!
+
+Abolitionists had to smuggle runaway slaves out of the South
+on the so-called "underground railroad". Perhaps cryptography
+would have helped them coordinate their efforts.
+
+Much of the support in the U.S. for freedom and privacy comes from
+our revolutionary heritage. I'm embarrassed at how little I can
+recall of what things were restricted in those pre-revolutionary
+days. I recall the Stamp Act and a few other laws, and I imagine
+that seditious materials were restricted. Perhaps the game players
+could be early revolutionaries trading items forbidden under British
+rule.
+
+Hal Finney - 74076.1041@Compuserve.Com
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
+sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
+JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
+tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
+M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
+0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
+xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
+=fF6Z
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-14 (Wed, 14 Oct 92 08:27:57 PDT) - Game items... - _Hal \<74076.1041@CompuServe.COM\>_
+
diff --git a/_emails/1992/10/2ff29505951a381077a03c5daef44ec830ba5b90cf48eb6abe31bc094aeaee28.md b/_emails/1992/10/2ff29505951a381077a03c5daef44ec830ba5b90cf48eb6abe31bc094aeaee28.md
new file mode 100644
index 0000000000..3b77df1f9f
--- /dev/null
+++ b/_emails/1992/10/2ff29505951a381077a03c5daef44ec830ba5b90cf48eb6abe31bc094aeaee28.md
@@ -0,0 +1,104 @@
+---
+layout: default
+---
+
+# 1992-10-21 - Keystone
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 2ff29505951a381077a03c5daef44ec830ba5b90cf48eb6abe31bc094aeaee28
+Message ID: \<9210211643.AA11195@soda.berkeley.edu\>
+Reply To: \<9210201753.AA009kv@fnordbox.UUCP\>
+UTC Datetime: 1992-10-21 16:43:25 UTC
+Raw Date: Wed, 21 Oct 92 09:43:25 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Wed, 21 Oct 92 09:43:25 PDT
+To: cypherpunks@toad.com
+Subject: Keystone
+In-Reply-To: <9210201753.AA009kv@fnordbox.UUCP>
+Message-ID: <9210211643.AA11195@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Eric:
+>:I would be hesitant to implement a system that _only_ required a user
+>:to generate a key pair.
+
+Loyd:
+>I take the opposite view -- I dare *not* supply such a system.
+[...]
+>But many users do not have the interest/time/ability to set up PGP on their
+>home system. For them, I want to provide the best possible privacy given the
+>ease with which anyone who can find their local LMOS can tap (voice or data)
+>a line...
+
+Where is the key pair generated? It must be on the BBS since your
+user may not have PGP running. The private key isn't private! The
+work to do public key encryption in the first place is hardly valuable
+if the owner of the private key doesn't hold it.
+
+If you just want inter-BBS privacy, why not set up each BBS with a PGP
+key pair, and use that for transfering messages? There's not much
+difference in security. A monitoring sysop would be able to read all
+the traffic originating on that board in either system. The
+difference is that such a monitoring sysop would not be able to read
+replies. Why? Because the private keys are kept on the originating
+board.
+
+But it sounds as though you're trying to prevent against external
+monitoring and that you trust your sysops. In this case there is no
+advantage to issuing keys to individuals; it's just not worth the
+effort.
+
+Loyd:
+>I don't have my user's terminal program -- I *do* have the bbs software.
+
+This is the unfortunate fact of the situation, I acknowledge. But do
+you know what terminal programs are in the most common use? I suspect
+most of this stuff could be done with script programming in the
+various terminal packages.
+
+Do you know, in aggregate, how many users of each terminal program you
+have? You can poll your users to find out. You'll need this data to
+allocate your effort.
+
+And you've got lots of people willing to help, even if they can't
+because they are working on other projects. Everyone on this list,
+for example. Let me repeat, for those of you who did not previously
+know you were willing to help. Everyone on this list should be
+willing to help Loyd write scripts for his users to use PGP.
+
+Cypherpunks write code.
+
+This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix,
+etc. for the PC, someone who knows the various Mac, Amiga, Atari, and
+other machines. This will mean someone to write nice pretty visual
+interfaces for PGP to put all the PGP options on menus where they are
+all visible. This will mean people to think about BBS/terminal
+protocols. This will mean lots of individual contributions, no single
+of which need be large, but whose sum will be.
+
+Eric
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Tue, 20 Oct 92 14:43:30 PDT) - [Re: Keystone](/years/1992/10/503c3b8d260c9d277fec543d1511e53afe6d139974194bbc24df6f7f32462d72) - _fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)_
+ + 1992-10-21 (Wed, 21 Oct 92 09:43:25 PDT) - Keystone - _Eric Hughes \_
+
diff --git a/_emails/1992/10/30f312069f952f339e3cbab3214d8960f76615d1d3a492b081fc86cbba3080d9.md b/_emails/1992/10/30f312069f952f339e3cbab3214d8960f76615d1d3a492b081fc86cbba3080d9.md
new file mode 100644
index 0000000000..63a6f36620
--- /dev/null
+++ b/_emails/1992/10/30f312069f952f339e3cbab3214d8960f76615d1d3a492b081fc86cbba3080d9.md
@@ -0,0 +1,72 @@
+---
+layout: default
+---
+
+# 1992-10-31 - re: Why I Don't Use PGP...
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 30f312069f952f339e3cbab3214d8960f76615d1d3a492b081fc86cbba3080d9
+Message ID: \<3400.2AF2EC7B@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-31 20:31:32 UTC
+Raw Date: Sat, 31 Oct 92 13:31:32 PPE
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Sat, 31 Oct 92 13:31:32 PPE
+To: cypherpunks@toad.com
+Subject: re: Why I Don't Use PGP...
+Message-ID: <3400.2AF2EC7B@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+
+ U> From: 74076.1041@CompuServe.COM (Hal)
+
+ U> The best way to integrate PGP into other software is a
+ U> tough
+ U> question. There are so many different ways in which
+ U> people read and send mail.
+
+ U> don't know which programs can do this. A lot of Unix
+ U> programs can, like VI and EMACS, but I don't know about
+ U> PC's or other home machines. PGP has a filter mode which
+
+
+Not to brag, but my offline-reader (DOS version of a 'read news'
+program), as well as at least one other I know of, does a pretty good
+job of this. It handles the decrypted plaintext reasonably securely
+too. It does the decryption locally. (You have to manage your own
+keyrings externally, though of course keys embedded in messages are
+handled OK.)
+
+Solutions are out there.
+
+
+--- ReadMail
+ * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-31 (Sat, 31 Oct 92 13:31:32 PPE) - re: Why I Don't Use PGP... - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+ + 1992-10-31 (Sat, 31 Oct 92 13:45:38 PPE) - [re: Why I Don't Use PGP...](/years/1992/10/f487615e36c2f4deaf5a01fa4e159c3bf63ecc93a3423ead808d29f2a0350da3) - _tcmay@netcom.com (Timothy C. May)_
+
diff --git a/_emails/1992/10/310aa141e3533fdd3670d2879114cb218dcb9d99e646a6311ff8bbfa97206b48.md b/_emails/1992/10/310aa141e3533fdd3670d2879114cb218dcb9d99e646a6311ff8bbfa97206b48.md
new file mode 100644
index 0000000000..505a1a6bf0
--- /dev/null
+++ b/_emails/1992/10/310aa141e3533fdd3670d2879114cb218dcb9d99e646a6311ff8bbfa97206b48.md
@@ -0,0 +1,53 @@
+---
+layout: default
+---
+
+# 1992-10-10 - re: Better directions to the meeting on Saturday at noon
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 310aa141e3533fdd3670d2879114cb218dcb9d99e646a6311ff8bbfa97206b48
+Message ID: \<2889.2AD73B41@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-10 20:15:11 UTC
+Raw Date: Sat, 10 Oct 92 13:15:11 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Sat, 10 Oct 92 13:15:11 PDT
+To: cypherpunks@toad.com
+Subject: re: Better directions to the meeting on Saturday at noon
+Message-ID: <2889.2AD73B41@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Things are not good here. I have to stay and deal with my best friend
+Deke who seems to be going nuts. (It's not a new story, but it heated
+up last night.) Now, at 1pm, I've gotta stay here another hour or so,
+and be back by 630, so I guess I'm gonna have to miss another. I'll
+see you all elsewhen (to borrow a Hugh-ism).
+
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-10 (Sat, 10 Oct 92 13:15:11 PDT) - re: Better directions to the meeting on Saturday at noon - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/3128a7c4ccd184baf0476e40998c112d09c1af9fe04ab6f4bd40b1b8d7a5207a.md b/_emails/1992/10/3128a7c4ccd184baf0476e40998c112d09c1af9fe04ab6f4bd40b1b8d7a5207a.md
new file mode 100644
index 0000000000..ff994081da
--- /dev/null
+++ b/_emails/1992/10/3128a7c4ccd184baf0476e40998c112d09c1af9fe04ab6f4bd40b1b8d7a5207a.md
@@ -0,0 +1,52 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Re: Registering Keys with Big Brother
+
+## Header Data
+
+From: efrem@spitha.informix.com (Efrem Lipkin)
+To: cypherpunks@toad.com
+Message Hash: 3128a7c4ccd184baf0476e40998c112d09c1af9fe04ab6f4bd40b1b8d7a5207a
+Message ID: \<9210261016.AA15135@spitha.informix.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 10:52:20 UTC
+Raw Date: Mon, 26 Oct 92 03:52:20 PPE
+
+## Raw message
+
+```
+{% raw %}From: efrem@spitha.informix.com (Efrem Lipkin)
+Date: Mon, 26 Oct 92 03:52:20 PPE
+To: cypherpunks@toad.com
+Subject: Re: Registering Keys with Big Brother
+Message-ID: <9210261016.AA15135@spitha.informix.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+It seems that registration would defeat the advantage
+of a public key system, but it would not prevent private
+encrypted messages from being hidden from casual traffic
+analysis or even notice by public key wrapping.
+
+This would make registration rather useless against a
+conspiracy and thus hard to justify in the face of commercial
+and constitutional opposition.
+
+--efrem
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 03:52:20 PPE) - Re: Registering Keys with Big Brother - _efrem@spitha.informix.com (Efrem Lipkin)_
+ + 1992-10-26 (Mon, 26 Oct 92 09:40:33 PPE) - [Registering Keys with Big Brother](/years/1992/10/c42d2d0187951763f35a791c544b34c096c6e0d58664eb4dc74d2729d6257648) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/325a35fb9d7b76f703a824d2a599c2fc66875ad4fc6d75213b20337b577a174e.md b/_emails/1992/10/325a35fb9d7b76f703a824d2a599c2fc66875ad4fc6d75213b20337b577a174e.md
new file mode 100644
index 0000000000..c3bfe91181
--- /dev/null
+++ b/_emails/1992/10/325a35fb9d7b76f703a824d2a599c2fc66875ad4fc6d75213b20337b577a174e.md
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+# 1992-10-20 - Re: More private PGP...?
+
+## Header Data
+
+From: George A. Gleason \
+To: nobody@soda.berkeley.edu
+Message Hash: 325a35fb9d7b76f703a824d2a599c2fc66875ad4fc6d75213b20337b577a174e
+Message ID: \<199210200915.AA27714@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-20 09:16:09 UTC
+Raw Date: Tue, 20 Oct 92 02:16:09 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Tue, 20 Oct 92 02:16:09 PDT
+To: nobody@soda.berkeley.edu
+Subject: Re: More private PGP...?
+Message-ID: <199210200915.AA27714@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Hal, I think those would be vry useful. Now of course, we don't want to
+advocate that radio users in the United States do anything like sending
+ciphertext over the airwaves, but we might want to develop something that we
+can ship to the Gusanos who want to take Cuba back for the Mafia, or maybe
+in a better vein, something that the Tien-an-men kids can use when
+overthrowing the Commies in China.
+
+Good ideas about message headers. Since the source code for PGP is widely
+available, it would seem a straightforward matter to alter the program to
+include the new features.
+
+What I'd really like also is a Mac version....
+
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Tue, 20 Oct 92 02:16:09 PDT) - Re: More private PGP...? - _George A. Gleason \_
+
diff --git a/_emails/1992/10/34602500d479303d1a7a304cabde762a9624b8b46feca41333e5d7a3bc26d4f9.md b/_emails/1992/10/34602500d479303d1a7a304cabde762a9624b8b46feca41333e5d7a3bc26d4f9.md
new file mode 100644
index 0000000000..920a60cd58
--- /dev/null
+++ b/_emails/1992/10/34602500d479303d1a7a304cabde762a9624b8b46feca41333e5d7a3bc26d4f9.md
@@ -0,0 +1,50 @@
+---
+layout: default
+---
+
+# 1992-10-25 - pgp key distribution
+
+## Header Data
+
+From: shawnb \
+To: cypherpunks@toad.com
+Message Hash: 34602500d479303d1a7a304cabde762a9624b8b46feca41333e5d7a3bc26d4f9
+Message ID: \<9210250333.AA11925@toad.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 03:33:12 UTC
+Raw Date: Sat, 24 Oct 92 20:33:12 PDT
+
+## Raw message
+
+```
+{% raw %}From: shawnb
+Date: Sat, 24 Oct 92 20:33:12 PDT
+To: cypherpunks@toad.com
+Subject: pgp key distribution
+Message-ID: <9210250333.AA11925@toad.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+I'm pretty new to this mailing list, so something along these lines may
+have already been proposed, but I was considering the possibility of
+putting together a list of pgp public keys for distribution through this
+list. My own collection of keys is pretty small, and I would pernally
+like to expand this, but I think this would provide a great service to the
+group as well. Let me know what you all think.
+
+Shawn
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sat, 24 Oct 92 20:33:12 PDT) - pgp key distribution - _shawnb \_
+ + 1992-10-25 (Sat, 24 Oct 92 20:54:34 PDT) - [Re: pgp key distribution](/years/1992/10/8848ce1351a4a5cbb0fed3d61c2af59d18118d66c467fc4a93e9b9b4c9f36503) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/35579c9de2cb0cbf5765897a6665b3bccfcfd2b6b524607768adfb798bcdd72a.md b/_emails/1992/10/35579c9de2cb0cbf5765897a6665b3bccfcfd2b6b524607768adfb798bcdd72a.md
new file mode 100644
index 0000000000..4fe3ae127b
--- /dev/null
+++ b/_emails/1992/10/35579c9de2cb0cbf5765897a6665b3bccfcfd2b6b524607768adfb798bcdd72a.md
@@ -0,0 +1,58 @@
+---
+layout: default
+---
+
+# 1992-10-11 - [gg@well.sf.ca.us: Re: +-=*^]
+
+## Header Data
+
+From: d9mj@crux2.cit.cornell.edu
+To: cypherpunks@toad.com
+Message Hash: 35579c9de2cb0cbf5765897a6665b3bccfcfd2b6b524607768adfb798bcdd72a
+Message ID: \<9210110102.AA21921@crux1.cit.cornell.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-11 00:55:26 UTC
+Raw Date: Sat, 10 Oct 92 17:55:26 PDT
+
+## Raw message
+
+```
+{% raw %}From: d9mj@crux2.cit.cornell.edu
+Date: Sat, 10 Oct 92 17:55:26 PDT
+To: cypherpunks@toad.com
+Subject: [gg@well.sf.ca.us: Re: +-=*^]
+Message-ID: <9210110102.AA21921@crux1.cit.cornell.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Look at what my mailer did to your header. Is this a result of your
+perl script or my screwed router?
+
+Date: Sat, 10 Oct 1992 05:06:40 -0400
+Illegal-Object: Syntax error in From: address found on router.mail.cornell.edu:
+ From: George A.Gleason
+ ^ ^-illegal period in phrase
+ \-phrases containing '.' must be quoted
+X-Ph: V3.12@router.mail.cornell.edu
+>From:
+To: Secret_Squirrel@treehouse.com, shipley@tfs.COM
+Subject: Re: +-=*^
+Cc: cypherpunks@toad.com
+
+[message deleted]
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-11 (Sat, 10 Oct 92 17:55:26 PDT) - [gg@well.sf.ca.us: Re: +-=*^] - _d9mj@crux2.cit.cornell.edu_
+ + 1992-10-11 (Sun, 11 Oct 92 11:52:09 PDT) - [[gg@well.sf.ca.us: Re: +-=*^]](/years/1992/10/7fbcfff145a8eea8bdd67a992755fc3e470eb037dc849602e09bc070154828ff) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/372c96cffd382696c685f18f23b0868ec033ccb4cd1e33b39fcededb8cc5f91d.md b/_emails/1992/10/372c96cffd382696c685f18f23b0868ec033ccb4cd1e33b39fcededb8cc5f91d.md
new file mode 100644
index 0000000000..8a3e368c72
--- /dev/null
+++ b/_emails/1992/10/372c96cffd382696c685f18f23b0868ec033ccb4cd1e33b39fcededb8cc5f91d.md
@@ -0,0 +1,59 @@
+---
+layout: default
+---
+
+# 1992-10-26 - entropy
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 372c96cffd382696c685f18f23b0868ec033ccb4cd1e33b39fcededb8cc5f91d
+Message ID: \<9210261653.AA13072@soda.berkeley.edu\>
+Reply To: \<921024155350_74076.1041_DHJ67-1@CompuServe.COM\>
+UTC Datetime: 1992-10-26 16:53:38 UTC
+Raw Date: Mon, 26 Oct 92 09:53:38 PPE
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 26 Oct 92 09:53:38 PPE
+To: cypherpunks@toad.com
+Subject: entropy
+In-Reply-To: <921024155350_74076.1041_DHJ67-1@CompuServe.COM>
+Message-ID: <9210261653.AA13072@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Hal:
+>Ascii encoding used by PGP reduces this to 6 bits per character
+>(e.g. a character set with 64 printable characters) neglecting
+>line separators and message beginnings and endings. So there
+>should be a little less than 6 bits per character for encrypted,
+>Ascii-encoded messages.
+
+Hal is, of course, right. I was getting myself confused between
+entropy lost in the encoding and the entropy of the encoding. The
+channel uses up two bits of entropy per character in the encoding.
+What's left is six bits.
+
+As punishment for getting this so egregiously wrong, I'm going to post
+some C code for measuring entropy so that you all can play with it.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-24 (Sat, 24 Oct 92 09:02:41 PDT) - [Multiple messages + entropy](/years/1992/10/0eec0ebc8ca754a17d7524fa51a07b6557113dffeb3bd13e9f3da940001c47f9) - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-26 (Mon, 26 Oct 92 09:53:38 PPE) - entropy - _Eric Hughes \_
+
diff --git a/_emails/1992/10/3843b9127a4b6cfaa8d420adae4a43519a8821bfa7898172b6f162b3bdaca046.md b/_emails/1992/10/3843b9127a4b6cfaa8d420adae4a43519a8821bfa7898172b6f162b3bdaca046.md
new file mode 100644
index 0000000000..8c4cd9586c
--- /dev/null
+++ b/_emails/1992/10/3843b9127a4b6cfaa8d420adae4a43519a8821bfa7898172b6f162b3bdaca046.md
@@ -0,0 +1,194 @@
+---
+layout: default
+---
+
+# 1992-10-14 - Some (Pseudo)Random Thoughts
+
+## Header Data
+
+From: tcmay@netcom.com (Timothy C. May)
+To: cypherpunks@toad.com
+Message Hash: 3843b9127a4b6cfaa8d420adae4a43519a8821bfa7898172b6f162b3bdaca046
+Message ID: \<9210141805.AA04539@netcom2.netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-14 18:06:29 UTC
+Raw Date: Wed, 14 Oct 92 11:06:29 PDT
+
+## Raw message
+
+```
+{% raw %}From: tcmay@netcom.com (Timothy C. May)
+Date: Wed, 14 Oct 92 11:06:29 PDT
+To: cypherpunks@toad.com
+Subject: Some (Pseudo)Random Thoughts
+Message-ID: <9210141805.AA04539@netcom2.netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Some thoughts on the recent meetings and what we're doing:
+
+
+1. The importance of trading physical goods in the Crypto Anarchy
+Game.
+
+This, in my view, has been given undue and misleading importance.
+Physical goods are inherently easy to trace through remailers (via
+sniffers, radioactive tracers, weight of packages, and many other
+physical cues), are hard to store physically (imagine getting 100
+parcels for later remailing), and, most importantly, have none of the
+"envelope within envelope within...." protection accorded to the bits
+of a cryptographic remailing, or DC-Net, system! The elegance of
+cryptographic protocols is lost with physical goods.
+
+Furthermore, physical delivery of any good, whether drugs, stolen
+missile components, antiquities and art items, whatever, is
+fundamentally a hard problem to solve...smugglers and thieves have
+been dealing this since the beginning of time. Stings can be easily
+arranged, delivery is not anonymous (one merely watches who takes
+delivery, or who opens a train station locker, etc....this is all SOP
+for narcs and counterespionage types), and a raid on a remailing
+entity will result in confiscation of the physical goods and (likely)
+prosecution of those caught holding the stuff. (Raiding a bit
+remailing entity produces only random-appearing bits...granted, the
+authorities may well outlaw bit remailing, or use the RICO and
+conspiracy/sedition laws to prosecute, but that's another topic.)
+
+Our recent emphasis on physical goods, and all the ideas pouring in on
+what other kinds of "contraband" besides drugs can be used, is
+misleading. None of the richness of the cryptographic world is
+faithfully preserved. I urge we get back to our roots and deal only
+with things that can be expressed purely in bit form.
+
+2. The "colonization of cyberspace" does not mean there is no
+interaction with the physical world, of course. But that interaction
+can be mediated with money made by converting information or digital
+money into physical money. Several methods for this conversion path
+can be considered:
+
+-Alice sells information in the cyberspace domain for the equivalent
+of, say, $30,000. She converts this to "real" dollars by using an
+escrow entity which hold both sides of the transaction until it's
+completed. They then mail the information to the purchaser and send an
+ordinary check "for services rendered" to Alice for $30K. She reports
+it on her taxes, probably as a "consulting fee" (for which essentially
+no government supervision currently exists, nor is likely to....), and
+the conversion has taken place. (Note: there are still elements of
+trust involved, notably involving the escrow agent, but trust works
+pretty well for many things, especially when reputations are at
+stake. Understanding how real businesses depend on reputations is a
+missing part of modern cryptology analyses of transactions...the
+protocol analyzers and number theorists almost never take into account
+how reputations work in the real world, But I digress.)
+
+-Alice and Bob trade information such that Bob gets the information
+worth about $30K, as above, and Alice gets another piece of
+information she can use in the "real world" that is worth about $30K.
+This might be stock tips, or, better, information she can turn around
+and sell in the "open market" of a service like AMIX! There are lots
+of wrinkles, inefficiencies, etc., to be worked out.
+
+-And then there is digital money. You all know about this, or should.
+David Chaum, DigiCash, blinded notes, credentials, etc. The handout
+for the first meeting had a glossary of terms. (IMHO, we should be
+spending more of our time at our meeting discussing this, and less in
+playing more interations of the Game.)
+
+The fascinating novel "Snow Crash," by Neil Stephenson, makes a
+mistake in having Hiro Protagonist a very wealthy man in the Metaverse
+(Stephenson's term for the virtual reality cyberspace) but a very poor
+man in the Real World. Information _is_ money. Information is liquid,
+flows across borders, and is generally convertible into real money.
+(One simple conversion strategy, alluded to above, is for Alice to
+sell her information for, say, $500K, and then to receive a
+"consulting contract," perhaps called a "retainer," of $50K a year for
+the next 20 years. Her retainer is fully legal, is perhaps handled
+through cut-outs who specialize in this kind of thing, and is a
+low-risk way to "launder" money from cyberspace into the real world. I
+have a lot more to say on these schemes, perhaps later.)
+
+3. Are we emphasizing "The Game" too much?
+
+If the goal is to produce a paper-based game, similar to "Monopoly" or
+fantasy role-playing games, then I suppose more practice is needed.
+But I'm not sure how worthwhile it is to try to design such a game.
+(Those who wish to should do so, then commercialize it, and become the
+Avalon Hill of crypto games!)
+
+If the goal is educational, for newly interested folks, then I also
+question how much more effort should be put into it. The ideas of
+anonymous remailers, of digital money, etc., are, I think, gotten
+across in the first 60 minutes of the game, especially if some of the
+formalism is first explained (as it was at the first game, where
+digital mixes, tamper-resistand modules for implementing mixes, the
+"Dining Cryptographers Protocol," and digital money had all been
+freshly covered, so participants were putting the theory to test).
+
+
+I found the first game was instructive, the second much less so (and
+_not_ because of the focus on drug selling...that was a relatively
+minor issue). My impression is that many of the newcomers--and they
+should jump in here with their own reactions (too bad we don't have
+hypertext links!)--didn't really know how remailing mixes work, how
+digital psueodnyms can protect privacy in transactions, and how the
+"Game" was intended to exercise these concepts.
+
+4. We need to talk about the charter or purpose of the "Cypherpunks"
+or "Cryptology Amateurs for Social Irresponsibility" (CASI--Eric
+Hughes's term) group.
+
+-Is it mostly educational?
+-Is it a lobbying group, as are EFF, CPSR, and the like?
+-Is it to produce remailers, digital money, and other programming?
+-Is it subversive?
+
+Now clearly we can't say it's subversive (any bets on who's gatewaying
+these messages to Other Listeners?). But we also don't want to skew
+things toward "YALG" (Yet Another Lobbying Group), nor do we want to
+be a spoon-feeding educational group for people with a casual (and
+transient) interest in crypto stuff.
+
+5. There have have been several messages so far about worries about
+the legal implications of these topics, about how some
+corporate-affiliated subscribers will desubscribe "real fast" if
+certain discussion trends continue, and so on. Now we can't please
+everybody, but maybe we ought to talk about this sensitive issue soon,
+and _in person_.
+
+Since it relates to our charter, Point 4 above, I recommend we do this
+at our next meeting. I'd favor that over another iteration of the
+Game.
+
+In conclusion, we are in at the beginning of Something Big. While I'm
+somewhat skeptical about the claims for things like nanotech, I see
+this whole cyberspace/cryptology/digital money/transnationalism ball of
+wax being _much_ easier to implement. Networks are multiplying beyond
+any hope of government control, bandwidths are skyrocketing, CPUs are
+putting awesome power on our desktops, PGP is generating incredible
+interest, and social trends are making the time right for crypto
+anarchy.
+
+I look forward to hearing your views.
+
+
+--
+..........................................................................
+Timothy C. May | Crypto Anarchy: encryption, digital money,
+tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
+408-688-5409 | knowledge, reputations, information markets,
+W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
+Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-14 (Wed, 14 Oct 92 11:06:29 PDT) - Some (Pseudo)Random Thoughts - _tcmay@netcom.com (Timothy C. May)_
+
diff --git a/_emails/1992/10/38fbbe375ba50d24f74e7a2036b91a85401f68ccf280d843e3d6930e6634d353.md b/_emails/1992/10/38fbbe375ba50d24f74e7a2036b91a85401f68ccf280d843e3d6930e6634d353.md
new file mode 100644
index 0000000000..322a627a51
--- /dev/null
+++ b/_emails/1992/10/38fbbe375ba50d24f74e7a2036b91a85401f68ccf280d843e3d6930e6634d353.md
@@ -0,0 +1,150 @@
+---
+layout: default
+---
+
+# 1992-10-26 - (fwd) A Trial Balloon to Ban Encryption?
+
+## Header Data
+
+From: tcmay@netcom.com (Timothy C. May)
+To: cypherpunks@toad.com
+Message Hash: 38fbbe375ba50d24f74e7a2036b91a85401f68ccf280d843e3d6930e6634d353
+Message ID: \<9210261819.AA07688@netcom2.netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 18:22:35 UTC
+Raw Date: Mon, 26 Oct 92 11:22:35 PPE
+
+## Raw message
+
+```
+{% raw %}From: tcmay@netcom.com (Timothy C. May)
+Date: Mon, 26 Oct 92 11:22:35 PPE
+To: cypherpunks@toad.com
+Subject: (fwd) A Trial Balloon to Ban Encryption?
+Message-ID: <9210261819.AA07688@netcom2.netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Fellow Cypherpunks,
+
+I have rewritten my posting on Denning's proposal and posted it to
+sci.crypt, for wider discussion. I'm surprised the sci.crypt folks had
+not already the significance. You might want to consider debating the
+issue there, rather than on this list, as your words will then be
+heard by more folks and could mobilize an effort against proposal like
+this one of Denning's.
+
+Cryptically your,
+
+--Tim
+
+Newsgroups: sci.crypt
+Path: netcom.com!tcmay
+From: tcmay@netcom.com (Timothy C. May)
+Subject: A Trial Balloon to Ban Encryption?
+Message-ID: <1992Oct26.180813.7002@netcom.com>
+Organization: Netcom - Online Communication Services (408 241-9760 guest)
+X-Newsreader: Tin 1.1 PL5
+Date: Mon, 26 Oct 1992 18:08:13 GMT
+
+
+Is there a trial balloon being floated to effectively ban encryption?
+
+Noted and influential influential crypto advisor Dorothy Denning has
+apparently floated the idea of _public key registration_ in a paper or
+talk at the 15th Computer Security Conference in Baltimore, held
+recently. Discussion of this is in comp.risks ("RISKS"), so far, but
+certainly belongs in this group.
+
+I posted a summary of this position to a private mailing list devoted
+to crypto issues and got a huge response of concerned folks. I don't
+understand why this is not a hot topic on sci.crypt, so I'll post
+something right now.
+
+Here's my understanding of her proposal:
+
+* Anyone using public key cryptography would be required to register
+the private key with the appropriate authorities, for example, the
+Justice Department.
+
+* To head off the obvious concerns about the government routinely
+reading e-mail, financial dealings, etc., this registered key would be
+stored at an independent agency after first being encrypted with the
+_public key_ of Justice. (That is, the independent key storage agency
+would have an unusable key, so _they_ couldn't use it themselves.)
+
+* To obtain a usable form of the private key, Justice would have to
+get a valid court order, go to the independent storage agency, present
+the order, pick up the key, open it with their own _private key_, and
+proceed to open mail, read communications, etc.
+
+This is ostensibly the procedure now used for wiretaps.
+
+But the effect on encryption would be chilling:
+
+-would greatly complicate the rapid changing of keys
+
+-would probably be a way to get "unlicensed" crypto programs off the
+market (e.g., don't think about using PGP 2.0, as the key registration
+authorities would either insist on another algorithm, or would send
+the "registration application" to, for example, RSA Data Security for
+legal action)
+
+-would undoubtedly require a "fee" (like a driver's license)
+
+-would interfere with the use of digital pseudonyms, anonymous nets (a
+la Chaum's "DC Net" proposal, which some of us are exploring now), and
+digital money
+
+-would establish the precedent that private communications are not
+legal, that copies of all private communications must be placed in
+escrow with the government
+
+Registering keys is no different than, for example, requiring a permit
+for every public utterance or for registering typewriters, modems,
+computers, fax machines, and copiers. Or banning the use of sealed
+envelopes for mail. In Phil Zimmerman's great words, it would be like
+requiring all mail to be sent on postcards.
+
+My suspicion, which Prof. Denning will presumably comment on if she's
+reading this, is that the government folks have come to understand the
+profound implications of modern crypto and are looking for approaches
+to head off the coming sea changes. Granted, there are serious
+national security threats in using modern crypto methods, but there
+are in any of the new technologies, such as those listed above.
+Besides, does anyone think all keys will be registered? Hiding bits is
+a relatively easy thing to do.
+
+This key registration proposal is more odious than the "backdoors in
+telecom equipment" proposal discussed here recently.
+
+Can we remain silent as our liberties are taken away?
+
+I think it was John Gilmore who said: "If encryption is outlawed, only
+outlaws will have encryption."
+
+
+--
+..........................................................................
+Timothy C. May | Crypto Anarchy: encryption, digital money,
+tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
+408-688-5409 | knowledge, reputations, information markets,
+W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
+Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 11:22:35 PPE) - (fwd) A Trial Balloon to Ban Encryption? - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-10-27 (Tue, 27 Oct 92 02:08:56 PPE) - [Re: A Trial Balloon to Ban Encryption?](/years/1992/10/26b81383c805929e3c002c3f7836848983275fee0cf94a079d7717bfd346d887) - _gnu_
+
diff --git a/_emails/1992/10/39a4d88ae35f5601244d259d0f691e6b2c8ec39aab73c9c220c99654fea8fa60.md b/_emails/1992/10/39a4d88ae35f5601244d259d0f691e6b2c8ec39aab73c9c220c99654fea8fa60.md
new file mode 100644
index 0000000000..d25be49b05
--- /dev/null
+++ b/_emails/1992/10/39a4d88ae35f5601244d259d0f691e6b2c8ec39aab73c9c220c99654fea8fa60.md
@@ -0,0 +1,74 @@
+---
+layout: default
+---
+
+# 1992-10-09 - re: +-=*^
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 39a4d88ae35f5601244d259d0f691e6b2c8ec39aab73c9c220c99654fea8fa60
+Message ID: \<2747.2AD5CD4D@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-09 18:13:54 UTC
+Raw Date: Fri, 9 Oct 92 11:13:54 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Fri, 9 Oct 92 11:13:54 PDT
+To: cypherpunks@toad.com
+Subject: re: +-=*^
+Message-ID: <2747.2AD5CD4D@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> re: problem with key distribution; right, OK, I hadn't
+ U> thought that there might be a security problem with
+ U> casually giving someone your key without them being able
+ U> to authenticate that it came from you. Good point.
+
+But as Eric pointed out, and I realized later, the underlying social
+structure will allow detection of bum keys (presuming the scammed
+person or someone s/he knows notices, etc, and so on, a wholew world
+resides here...)
+
+ U> Here's my public key. If you feel it is not secure
+ U> enough, we can always use the cone of silence:
+ U>
+ U> -----BEGIN PGP PUBLIC KEY BLOCK-----
+ U> Version: 2.0
+ U>
+ U>
+ U> 23l1t34u
+ U> -----END PGP PUBLIC KEY BLOCK-----
+
+Now I feel very unsecure, because the above is all I got. It ain't no
+public key...
+
+
+PS: Too much anonymity? I have to reply in hte mailing list to this
+person cuz it's a faked From... (trust me)
+
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Fri, 9 Oct 92 11:13:54 PDT) - re: +-=*^ - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/3c38d48ebe6788447fca198f92d44a9ffa68121b79032804da9a7944dc97d602.md b/_emails/1992/10/3c38d48ebe6788447fca198f92d44a9ffa68121b79032804da9a7944dc97d602.md
new file mode 100644
index 0000000000..e2040f4ea0
--- /dev/null
+++ b/_emails/1992/10/3c38d48ebe6788447fca198f92d44a9ffa68121b79032804da9a7944dc97d602.md
@@ -0,0 +1,66 @@
+---
+layout: default
+---
+
+# 1992-10-24 - entropy measures
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 3c38d48ebe6788447fca198f92d44a9ffa68121b79032804da9a7944dc97d602
+Message ID: \<9210240620.AA08036@soda.berkeley.edu\>
+Reply To: \<9210231641.AA11868@xanadu.xanadu.com\>
+UTC Datetime: 1992-10-24 06:20:44 UTC
+Raw Date: Fri, 23 Oct 92 23:20:44 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Fri, 23 Oct 92 23:20:44 PDT
+To: cypherpunks@toad.com
+Subject: entropy measures
+In-Reply-To: <9210231641.AA11868@xanadu.xanadu.com>
+Message-ID: <9210240620.AA08036@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Dean:
+>Where does uuencoded [compressed] binary lie? I would suspect it lies
+>right around where encrypted text is.
+
+Right.
+
+>Presumably straight encrypted
+>text is statistically random [7..8], but that when you encrypt to
+>just the ascii subset is when you lose the entropy.
+
+Exactly.
+
+uuencoding will have a slightly lower single-character entropy than
+the ASCII armor PGP uses because just about every line begins with the
+letter 'M'. This will skew the distribution slightly. But a better
+way of distinguishing uuencoding and ascii armor is to see that in
+falls in the same entropy class, and then just looking at the
+alphabetic subsets used.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 09:25:56 PDT) - [BBS E-mail policy](/years/1992/10/8a24672636a42d5225524b26c5cc78e1b0ba1b62a4c1e1fe1825463951a6b9e0) - _omega@spica.bu.edu (The Omega)_
+ + 1992-10-23 (Thu, 22 Oct 92 23:02:09 PDT) - [BBS E-mail policy](/years/1992/10/bc5b354247141e46df2c768591ee1dffd7fbc017a03b959da779cf82e2521133) - _Eric Hughes \_
+ + 1992-10-23 (Fri, 23 Oct 92 14:42:19 PDT) - [BBS E-mail policy Now see if this number is in one of the following ranges:](/years/1992/10/298d86c630be7b06958a77a0e2a93e61224cded16c21ee64acb6bc0f39e9ecfd) - _tribble@xanadu.com (E. Dean Tribble)_
+ + 1992-10-24 (Fri, 23 Oct 92 23:20:44 PDT) - entropy measures - _Eric Hughes \_
+ + 1992-10-26 (Sun, 25 Oct 92 21:41:19 PPE) - [Re: entropy measures](/years/1992/10/b71072e5de22f0ee2513a7bc057b82b39ad7284a70bf4913906340f5c39b27b3) - _Eric Hollander \_
+
diff --git a/_emails/1992/10/3e1735e0a8e172c942c2f35d934ddf647ef5c97007e6978b2e39a8506dc6808b.md b/_emails/1992/10/3e1735e0a8e172c942c2f35d934ddf647ef5c97007e6978b2e39a8506dc6808b.md
new file mode 100644
index 0000000000..c1ee4e784f
--- /dev/null
+++ b/_emails/1992/10/3e1735e0a8e172c942c2f35d934ddf647ef5c97007e6978b2e39a8506dc6808b.md
@@ -0,0 +1,110 @@
+---
+layout: default
+---
+
+# 1992-10-17 - Keystone
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 3e1735e0a8e172c942c2f35d934ddf647ef5c97007e6978b2e39a8506dc6808b
+Message ID: \<9210172209.AA29900@soda.berkeley.edu\>
+Reply To: \<9210170556.AA009js@fnordbox.UUCP\>
+UTC Datetime: 1992-10-17 22:10:14 UTC
+Raw Date: Sat, 17 Oct 92 15:10:14 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Sat, 17 Oct 92 15:10:14 PDT
+To: cypherpunks@toad.com
+Subject: Keystone
+In-Reply-To: <9210170556.AA009js@fnordbox.UUCP>
+Message-ID: <9210172209.AA29900@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+First, let me congratulate Loyd and the others involved with Keystone
+for working towards the creation of a local distribution mechanism for
+keys.
+
+Every city in the U.S. needs something like this. If it's not
+happening in your area, start it. Start by getting PGP and making your
+own key. Then exchange keys with people you know.
+
+We have members of the list in many parts of the U.S., Canada, and
+Europe. There's plenty of work to do. Look around. If no one else
+is doing this, you should.
+
+>Ideally, you would be able to send RSA-encrypted email from any bbs
+>on any of the local nets to any other bbs -- even if all you know is
+>the destination address. We're going to do this by attempting to make
+>the bbs PGP-friendly. All the user has to do is generate a key pair.
+
+There are, roughly speaking, two kinds of privacy; one is provided,
+and one is defended. Provided privacy is unstable, since the person
+using the privacy does not create it. Defended privacy is stable,
+because those who want privacy create it themselves to the level at
+which they want it. Both systems do provide privacy, no mistake.
+
+I would be hesitant to implement a system that _only_ required a user
+to generate a key pair. This, for the users, is too much provided
+privacy. It will not teach the users how privacy really works, nor
+will it give them any good idea how their privacy is being maintained.
+
+Defended privacy does not need to be difficult. I would spend effort,
+instead of modifying BBS software, to make it easier for users to
+handle encrypted email with their own terminal programs.
+
+Now, any privacy is better than none. I don't really know if it is
+easier to modify your BBS or your modem program. But all other things
+being equal, make it easier for users to maintain their own privacy.
+
+>[...] a master keyring that will be regularly distributed via a
+>trusted system to other nodes in town.
+
+Again, trusted systems can turn into provided privacy. If there is a
+distributed solution you can think up, use it.
+
+>The first [weak link, line security] is almost insurmountable --
+>unless the user takes the time to d/l a complete copy of PGP and the
+>Austin Keystone Keyring and encrypt the mail on their home system.
+
+This should not be such an onerous task. It might be now, but that
+can change. Finding ways for users to manage keys, to get keys, and
+to look up keys are all interesting and useful problems to solve.
+
+Every user should encrypt outgoing mail on the home system before it
+leaves and decrypt incoming mail on the home system after it arrives.
+If this is not easy, it should be made easy.
+
+Not every user need have the complete directory on their own system.
+They merely need a way to communicate with those that they want to.
+This probably means a directory service, where people can download
+keys for the people they want to communicate with. Moving around a
+complete directory does not scale well.
+
+As far as BBS support, if I want to respond to someone and I don't
+have the corresponding key, I should be able to initiate a zmodem
+transfer of that key relatively easily, for instance without leaving
+the discussion area to go to a download area.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-17 (Sat, 17 Oct 92 07:16:32 PDT) - [Intro & Keystone](/years/1992/10/bfb3ed37d92a8d3b2b0087d4c8b9ae40db038981b9f15d89ec0bcbd2e2e7ed6d) - _fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)_
+ + 1992-10-17 (Sat, 17 Oct 92 15:10:14 PDT) - Keystone - _Eric Hughes \_
+
diff --git a/_emails/1992/10/3fd0e544238de7181d76d863b77743d4ae1d3dc88e4eaee330999abcb62314cc.md b/_emails/1992/10/3fd0e544238de7181d76d863b77743d4ae1d3dc88e4eaee330999abcb62314cc.md
new file mode 100644
index 0000000000..748f75cfcb
--- /dev/null
+++ b/_emails/1992/10/3fd0e544238de7181d76d863b77743d4ae1d3dc88e4eaee330999abcb62314cc.md
@@ -0,0 +1,79 @@
+---
+layout: default
+---
+
+# 1992-10-06 - re: Nuts & Acorns
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 3fd0e544238de7181d76d863b77743d4ae1d3dc88e4eaee330999abcb62314cc
+Message ID: \<2654.2AD20C59@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-06 22:11:44 UTC
+Raw Date: Tue, 6 Oct 92 15:11:44 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Tue, 6 Oct 92 15:11:44 PDT
+To: cypherpunks@toad.com
+Subject: re: Nuts & Acorns
+Message-ID: <2654.2AD20C59@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ > To: Tom Jennings
+
+tj>>
+I am considering becoming and "introducer" for parts of FidoNet. I
+can't seem to get past the problems of how to assign reliability to
+public keys I receive over an unsecured email channel to begin with.
+No other method is practical.
+<<
+
+>>??
+Huh? I don't understand what you're pointing out. If I send you my
+public key -- even if I cc: dockmaster -- what does it matter that the
+NSA knows my public key (unoless they want to send me msgs, too)?
+<<
+
+Not my worry. What I meant was, how do I know htat the keyfile I
+received from "John Smith @ net address" really is his, and not some
+faker. Short of physically getting key disks from someone face to
+face (flatly im-possible here), I don't know.
+
+The assurance of course is the social system: if someone sends me a
+message and keyfile, "here's my file, my name is Eric Hughes", and I
+distribute it...
+
+I can think of no way to prevent this, other than let a social system
+detect and repair -- "HEY THATS NOT ME!!!" form the 'real' you would
+raise a flag... and an audit trail at the introducers site
+(dangerous...!) might help.
+
+Anyhoo, that's what I meant.
+--- RM version 0.-1 (watch out)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-06 (Tue, 6 Oct 92 15:11:44 PDT) - re: Nuts & Acorns - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+ + 1992-10-06 (Tue, 6 Oct 92 15:59:23 PDT) - [Nuts & Acorns](/years/1992/10/b106cdc1eb583bff16fa9268f26e98be158ce990a6bbf7894c7c2074f047ea51) - _pmetzger@shearson.com (Perry E. Metzger)_
+ + 1992-10-07 (Tue, 6 Oct 92 17:44:27 PDT) - [Nuts & Acorns](/years/1992/10/f15e5fceb881331d0abfe3e479ccbe1aaa0955f01737edfcbcb97a68f27288e8) - _tribble@xanadu.com_
+
diff --git a/_emails/1992/10/40122c10b02d8f98f7843b615af9824d0e08ae642020e324118791616e8d211a.md b/_emails/1992/10/40122c10b02d8f98f7843b615af9824d0e08ae642020e324118791616e8d211a.md
new file mode 100644
index 0000000000..1c202a6f1a
--- /dev/null
+++ b/_emails/1992/10/40122c10b02d8f98f7843b615af9824d0e08ae642020e324118791616e8d211a.md
@@ -0,0 +1,60 @@
+---
+layout: default
+---
+
+# 1992-10-27 - Re: Registering Keys with Big Brother
+
+## Header Data
+
+From: gnu@cygnus.com
+To: Arthur Abraham \
+Message Hash: 40122c10b02d8f98f7843b615af9824d0e08ae642020e324118791616e8d211a
+Message ID: \<9210270724.AA29964@cygnus.com\>
+Reply To: \<199210270553.AA26809@well.sf.ca.us\>
+UTC Datetime: 1992-10-27 07:24:43 UTC
+Raw Date: Tue, 27 Oct 92 00:24:43 PPE
+
+## Raw message
+
+```
+{% raw %}From: gnu@cygnus.com
+Date: Tue, 27 Oct 92 00:24:43 PPE
+To: Arthur Abraham
+Subject: Re: Registering Keys with Big Brother
+In-Reply-To: <199210270553.AA26809@well.sf.ca.us>
+Message-ID: <9210270724.AA29964@cygnus.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Arthur Abrahams incisively notes:
+> Seems to me that there would be a certain amount of trouble with people
+> registering one private key but communicating with another they had
+> forgotten to register. Bad situation for my large sibling 'cause he
+> wouldn't realize this until after the court order etc. A good solution
+> would be BIG fines for mis-encryption and sampling of messages...
+
+There is no need for sampling of messages. You don't understand the
+theory of power. Simply make the penalty for encryption without registry,
+larger than the penalty for any other crime. Then no crime can be hidden
+behind it. It's like getting Al Capone for income tax evasion; if you
+investigate someone and they are enforcing privacy on their communications,
+you can put them in jail for life for that, and can stop worrying about the
+original suspected offense.
+
+ John
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-27 (Mon, 26 Oct 92 22:54:33 PPE) - [Re: Registering Keys with Big Brother](/years/1992/10/dcf9d115e0ad4b617fdbf127754c16f4c569db245e2713554ab65a2db0302f9c) - _Arthur Abraham \_
+ + 1992-10-27 (Tue, 27 Oct 92 00:24:43 PPE) - Re: Registering Keys with Big Brother - _gnu@cygnus.com_
+
diff --git a/_emails/1992/10/428592ad0b9a398c4644a4e59509ecf89710f218eef38258f438441f9b907320.md b/_emails/1992/10/428592ad0b9a398c4644a4e59509ecf89710f218eef38258f438441f9b907320.md
new file mode 100644
index 0000000000..53c72f4138
--- /dev/null
+++ b/_emails/1992/10/428592ad0b9a398c4644a4e59509ecf89710f218eef38258f438441f9b907320.md
@@ -0,0 +1,156 @@
+---
+layout: default
+---
+
+# 1992-10-09 - re: Subscribe
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 428592ad0b9a398c4644a4e59509ecf89710f218eef38258f438441f9b907320
+Message ID: \<2733.2AD49634@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-09 01:48:59 UTC
+Raw Date: Thu, 8 Oct 92 18:48:59 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Thu, 8 Oct 92 18:48:59 PDT
+To: cypherpunks@toad.com
+Subject: re: Subscribe
+Message-ID: <2733.2AD49634@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+My public key.
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQBNAirHIV8AAAECAOE6hyvBZUslVOgi12u6d7/6yMIXX4aKIRcfV3wa/ysHl+ul
+d4agC1YW+YimYeA+/bXOBxH/Y/KRzT/tLvUlcRcABRG0MVRvbSBKZW5uaW5ncyA8
+dG9takBmaWRvc3cuZmlkb25ldC5vcmcsIDE6MTI1LzExMT4=
+=dADc
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+My public key ring, signed with my secret key:
+
+-----BEGIN PGP MESSAGE-----
+Version: 2.0
+
+owF1l3VU0/v/xzeGtCBwQUJ0ICI5OqUbJEYb1IQx5tgGYwMpBamBpNJggAEoKiAq
+HVe6Q0pC8tKO0tH8JlcO9/zO+f7zOe/P+4/3eb8fz+erogA2VKcAol9lmDs0ViA/
+L3mdBQIDmKkA47t9zTtBybMxWgRHMzFr/pgLHXIsVYQW+yWb94wbYdAYS7nw5gXk
+tzbBbHO1QSuNTpl6zzKU6rVWOs0L/b1mEemAWCrRwlAHAABIDWgwlYrbWbw2XoaW
+b3zZCgv3S3HuqqopxwsyjKNvnaK98dRo/hV6Ox7arP/466UMMPCHYzTqTKh1rbiS
+1ZsgvHKm2lZ1yF6go9O90lO5hqdz74QuG6b8CnexkThg53Mdluod7XCds1a/WBp7
+Xya6xBFoGMOAee6kzK4bNk3aXWtAmQNOsRYCtUpkLQne3nAPD7AeBGznjsTDUHAc
+WNX3z0oTjofjMEi8H8QVjsZiIC5YCAGlXggERf1GdEb0q7TgCSIoBVHmkotkeXv7
+wBdZ+vc9HTNJVPM5qilvhegDL2Z7KQqkrg2KqvY62YPiIgH0LUX1U2w40Y0H7dkP
+6IQU8pEIZ2u+QmBkOsCUSrQCLkWhRAWoFd3nfF4WwjkvsHSRCOBxjHXGkt84zP0z
+3E4S/fmqExOsl8b8/iwnQ3WehZ0f3oKXv9ico4CslM61J1fdzp1ADzjFXgjUKxHV
+xsFcwToQsKmLDgyH9wOruilIK0Iw0jLyEH9piBvSFYuB4yFYHOI/j+s1en7yuBYG
+4KHRaiu3KqlnBPkWqz/et99F20etH4q0Vfhp6qzazcxcSQph6Cvc1aIKK+zVi6vJ
+mnip4yXJHMydlhEbQtXLPdp99DiKBT69wx5ZoC290jPdNzgivHs0yK4l/nzkfq0f
+1BLPyS17+2Yo4m6DWNncJsekp2Yy6Lai6an4GOI9Uufyt6oJDn5W9zjaJNvUWFTz
+5f26W/QMjJy9mbJBqtG1+yCSfOD7gyIFe9ZT2RduNXjs3ezVZTOSihVLHI+9d7ND
+QHaXptgqKk1Hudju+5EFKHCs3GG+GPBVCNiCgMRgKGwU5eWlKHCkFChwNP8XHNUT
+OGZtwD0GI70XrQ9scaP9V1Bhwqki38qz/OueQwMg/PxpyQJVwj+5lLkftublBGrL
+B8jTaESJNXgtMcdPU13YNCMWddocUuBEAZJ/H909OIxGK1l6X824DgQWeIMO9Ssz
+B+x+yVuwfiTr1vYvGrVofdLjWYmWHJHJA9pn7yTowWSVW7q7aiIm74w4zOEGdPvq
+cVlgj/vJXjrL5c/O1PCeU7s1J/B1FdgXdCCfwOv9md592Tk9eVcNkkd+I7/PBR9m
+nQ27cu7Sd+OQIMIAW4MgZ3HlpOE9Sc1oVMACDJNSCAw/0q1D4uBItw8yzSNTRVVW
+lyzWIxhXUMMLLEB3wdB8odektdZtldT7KtzskVy2LORr6UK6XdyY6UJrZjXjZjnH
+tH3hUO2FEV5pwbJgIjzaN2YoyT863BMsmPlB5FbllWdmQcm8HDFUdNl5jz+sqJKt
+1Z8YM9x8+KLQwdwZWmwqnHhM5Y9uwjruOKQ3HuvpTglZ7X8DV1pFVlFOUlruf6oG
+OlHtLjfw0PLjZG/BCzK1SI1vhjiPNnTZznJmse6cOACATdLs5ZG468ZB4Js+75TK
+XrTchGTiYY6XPI1hSssa5705G1GkQ3+iWodLK5fdzFjRp9KLQKBAHOhAnriXXJQy
+FVIkN43v9napcZDl8y8oXj6IW9mj3mfJnmWEpRo79F+OGzdee62QCqEb7is3LKo5
+WLxjvWZ0ge5qOAF7jb0iSymCdlguFyhG6nFWJnF2pEz3Y+Yrg/9Cv3vtzvH99kWR
+LsyZogpGUaXxlehAKV2mZ1E9MpWYSzZ2YW8oqh1fTVHsxFDdAGpAiBqogyeyhm9W
+newGI52/mRrTCHwwHttXWkTeY+F+5/bMGPDWwVryS/reEoeDFOOFpyy58ULzLP4s
+aqgLS09Sc+AVfTg9dpsuZkHHAwdnSY2cH60/eCdo32KCmdBXP2x0SqNyBoP4Ncf2
+y4Q0xi8h9MY5tRRrt00ULeEPH/g9gm8eG6oRnnhkqOokL5Uh1Wx7bbnlgc2R+tux
+A2MDlQ5Fm9+5C8jNYtSTgRsLL/VmGBwjuvQ1Enerrpfq5IARUjliVfiVImx2z/6D
+zDqJnzwrUn8F8U7Evghd3rE0RQwtrxdDYu/+uO2J3resQRh64qM3LjcCWXP753Oc
+xy3+ubuE8D0W7I+h5AyugqEwFzgYfPNfH8kogFURKE/KlqabjAIEQ9n7/+nS4chc
+/2JuYTzBvC5IDUhq5jHkNs1ZbJ8dDOYWncgvzX2/edjrbUy/sYDAF4qsVCjEx7IW
+uZ0TNVdX6TCydOeSJeQ2xRv7OFQvZpIj6ek8BPGetr4IuXq6r9PyXMvYxz5EIYc1
+jR+wxzf621YCnFFXF06nQocYM4WfJT4ZSOUaXco73A7IFYfSWfON24h/OHLAke+b
+9dJPfG9fADzUbD9dmcokouzeHcA8uiLxmH4f6VbBa3ul+cKGrRT1evFHTvbMT+rD
+aiUp4irCTSv1xb8mmk/jsuzvWNIl2xqfQx6n8sJa6JGCn5QDV6inTilsxRn/uPcQ
+LFYM7rPOiN8Y1iaJlSWNJKQMvtbf1x1fHP7UuMY2FJNlzy6VuPD+RgmmQ2HwYRnt
+1qFY2VC7W14InkaEkSVg8TM7m/irMy8QdnFSbGPqp8O4thAlbGPNz28R8okt2XxV
+5+832PRLTKrg6NzEDBDLGeC6PwqKaeFuwzFgAwjYBI7B+4OFTfTMrG+Arcz1re20
+LPUkdPVs9UzMoaaUXZGTrNAkmH9CR8mXCjAAEe8dbGJY5rKaDsgwebcmEXm13yCn
+9kuW7YKUbZcd5IUmKS/ANjR7dUQsq3bepF3NNfBCxCgHFxHjfy07lJPumA56XfyI
+TlF08KdZVsBTr0QBnfk6zkDlUM27zx0jpHbFndmIKx+fxbjVMefPaIfS3AYZvawr
++xiUKfrQwZ+upF/UZxgU8zJl7N1hqwNHZO66S0Fvrat/EO3CbE5jT8H6JHeK5t68
+jNWzXzx1uVKK7MgvX6YDhQdYEi0TSNuG7e+nCOPMhwgy4xEdQIk41B3pgfQEW0LA
+N5BoNByHhv0ud544f01vGAIOcUG4QgguMBwE7kqgJE2qKEDSka+VgCe+FssHbXV+
+oq66Y0OqrOpFJwewcHtIHeb+lW/jAZZ1fGdVGGILlZR5sXyIETX3j5ogXxp6Fz8A
+SI7XV88Mbbhi9tXZqMwiSO5UCHcjv555jDIdaYs6dUlgZZ5/IIMgJI0/97M0hTtn
+kXpHS9L3Llogw0YtIEKCY8yfOFjB0q8E5wpxumF1ktiwlnKbrYCQ2DmBYSBQeZca
+UIPfzekEvjArlVkXfjPK2/7ImKUJo2v9LkXcqT1jiGSqv/OrsJLQMa87t90DzZE3
+M83vfGJEjs64+lgozqYaVfz0nz7ZzWQkEzlpLXaGND2HnWicumZHY5JU5VAbnfO5
+qev6za2e5zK0slMO5qUyFqf7P+7HH8b0VVusZ7cVpN0CUygfCe9Rl34kfOvo63Wp
+5lzJBvcGtLYoaQvW4br0cmYSH2OUWrKjcfPsT7OMei5L1I2w1UrPDoWA/a3bSCN7
+ePnk8+Q4JpVnAUFljz4rMAkTeVmrUfRjWue/LQRV7psqI091E1t6t4ggpXKVYDF9
+6A1G5nBhbAIkRSUyabE7ZzsPfEzlj/CXKe0fBoUFm1C+cG9KSwsGq3r8WWu6+SIh
+BB8YBONB0Rzwhyx6PeHYPEDg32dBh56kM6ba98TNjJ7SQh4u9rguw/TPbwIOB9+0
+sc6+lvoSxpbgJ2DEs9GU9vXMd+dc26Ud2SeiDRq3yltFZPYtOCDcDlJBFQ+TJ/Pq
+eLZpAttoJYgCAAM+K/ox4zNCC2L3OnjoO05/CzAK5jQ3cX6Y5tkW5Vy1Sp+2VBB3
+TaF80vCHz5djsgEyOUdkB9A6Ff2eHHnfHZLnyAmu6JT64F/0nQ/DtDuuu0+xYq/U
++PCThgaejv6T9cuZKWm3uwT9j4ENbDV7lc8SgTx758O396XVF0PFx5I81MJ+8LDE
+oZvESyeizkS3lWnF9QgHlpWYmr4ynuBWPi8r8tye/iyrFzithC7KlWWH9fXC4/Qg
+gz9kL0F/TwhgAwL+TywhCHhpTRdvCIyAImCQEJgLBOP/H64v/FJPuL5rBO0xPDP6
+fMXXP+1KYuEXF2n4XTDI7HK7z3oTYc6pwBY6q/Jlxmv/3mYv+9Y3oroG3mknwbkP
+wkCMrAiPfaRcnevPt/iy1SsBz/DRiFVr/IOzlUVZNKu80vny+iki46ZndSLsld6N
+cSUDhc73AUZuleTStbYuJImZnDUt21TZytkyq3fElTJwRKv7HA0cnSDo9pqPwtZo
+1N1mZVYoiT1UNuWAq++D00jKdZQNiZYZCszzMYmq4pG7Zqxre7H6i+V3bsWJ8bLq
+YcM9f3aFn3+48BvCcDg/sDbB2x2serTWdIF54z3gEBwSAYN4+PyHySvOgZMozrcH
+7bHsVfudH8o2bbbsUx7gJ9LAMY9+PH/70SSC0469ZUvjka0Wo8/dphvOC0yuqqkH
+gxkT9TRFzzkFL35t2yEtzrHlaU7NtTa/KFtGPUSM0ZCHHkBE7hNZcB+ZErsaclbh
+spFIZE3NFukLtt5QBuXXL5uzmujPVxOapmZvnVXOJmcRfswka/0thQnwAJKwH2ji
+/i1F4+a1CQ3J89XGD4De/QH1m47wkp/mfmhit05i6JuKBhGUn7+ayqZDN2fDtoEZ
+lfSuBuNkzegt6ot/mAgYw2EYCQ8swRNsAEN6eFCmsNu//zRd3LE4gjfEDfcfKLme
+yBMo8zKgXeraS7HL4fLmOjYKBsy43OokkT2N2KSgIAvo6/uBxovmj7UA270X1S4j
+YVBwPDd7rJ4Wc05p/kjgazcBCIe//Wj8Feq6UfnZJkSLE/OmTfdIVoH0ivZ8mTC+
+QaHH++KF6q2poNO8jubXP9hngsx00IRfo+oV33rKJ8pVbcKrgqRsjqE08TsdGWVS
+JVKsDn71kvW8wCCq3Ldmp/nvs04R0fxnL9gF8hyK0aYuvfSNeMZoy7lNfAWbUN//
+2EnLeuiynnhcaY+gRJZIW2PRYGM4BoPEILzBqngs+vZR7+7t+982SxwsrUKZVSWl
+paXVTxqu7kmFk8KUWAA6ULvRnFfH4g8W+rxedV/+U4NLstbrbaeKgy3JPZocrviW
+V2kIhyqaEnKb44yEWetCu8nbsyX2uwkPRpnSnMSU83c+Gy4oNlrwfit2f6MLZakn
+B+1Y2vMzEbPuJDJR65VVeXHNqOtcH3NsTO3fZyYHbBwYDrro5jH+/ZdeLDMne8NA
+ykllagu7dTINZB+ADi1HJZW6uqP3emf7FWW73L14X9xhjEXWbvRM9w4OgnSQ5Kz+
+c9mndfo17s54z6ArCrzc2papTIM+FBfWhSgbPyXq185szIC/P1GuW+2HDvavbGbf
++2Q7PnBtRGg41yt+TLVpNRGprWrRZv+zcJQYnpQhH867VgBSXIrJ+C5rZZ3JQrna
+/wE=
+=irCz
+-----END PGP MESSAGE-----
+
+
+ * Origin: World Power Systems / FidoNews (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Thu, 8 Oct 92 18:48:59 PDT) - re: Subscribe - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/4449d8423a3d4ccea75be61a5bd0f1ff0f12e8a37191013726ee2d9bfc0c5fb6.md b/_emails/1992/10/4449d8423a3d4ccea75be61a5bd0f1ff0f12e8a37191013726ee2d9bfc0c5fb6.md
new file mode 100644
index 0000000000..be33d453bf
--- /dev/null
+++ b/_emails/1992/10/4449d8423a3d4ccea75be61a5bd0f1ff0f12e8a37191013726ee2d9bfc0c5fb6.md
@@ -0,0 +1,53 @@
+---
+layout: default
+---
+
+# 1992-10-13 - Mr. Squirrel
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 4449d8423a3d4ccea75be61a5bd0f1ff0f12e8a37191013726ee2d9bfc0c5fb6
+Message ID: \<9210131856.AA29470@soda.berkeley.edu\>
+Reply To: \<9210131710.AA20497@bsu-cs.bsu.edu\>
+UTC Datetime: 1992-10-13 18:49:36 UTC
+Raw Date: Tue, 13 Oct 92 11:49:36 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Tue, 13 Oct 92 11:49:36 PDT
+To: cypherpunks@toad.com
+Subject: Mr. Squirrel
+In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu>
+Message-ID: <9210131856.AA29470@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+A signature on a message is dependent on the contents of the message;
+it is not a free floating bit of information. You can't copy a
+signature, therefore, without copying the message or find another
+message that hashes to the same value. This is the design criterion
+behind one-way functions--that you can't (feasibly) find a message
+that hashes to a given value.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-13 (Tue, 13 Oct 92 08:55:18 PDT) - [Re: Mr. Squirrel](/years/1992/10/1be047fb00ed9b8e7e62a36076bd875e747fc5da248ab50cd0ef9aff7be79589) - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-13 (Tue, 13 Oct 92 10:04:24 PDT) - [Re: Mr. Squirrel](/years/1992/10/fe748ec0459677318d9e9d5d0611919b35b8f6e096b4d2ede12008c07f006f28) - _nowhere@bsu-cs.bsu.edu (Chael Hall)_
+ + 1992-10-13 (Tue, 13 Oct 92 11:49:36 PDT) - Mr. Squirrel - _Eric Hughes \_
+
diff --git a/_emails/1992/10/454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f.md b/_emails/1992/10/454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f.md
new file mode 100644
index 0000000000..c25fffa7e9
--- /dev/null
+++ b/_emails/1992/10/454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f.md
@@ -0,0 +1,66 @@
+---
+layout: default
+---
+
+# 1992-10-08 - Subscribe
+
+## Header Data
+
+From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+To: cypherpunks@toad.com
+Message Hash: 454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f
+Message ID: \<1480@eternity.demon.co.uk\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-08 14:04:56 UTC
+Raw Date: Thu, 8 Oct 92 07:04:56 PDT
+
+## Raw message
+
+```
+{% raw %}From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+Date: Thu, 8 Oct 92 07:04:56 PDT
+To: cypherpunks@toad.com
+Subject: Subscribe
+Message-ID: <1480@eternity.demon.co.uk>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+SUBSCRIBE
+
+To human overseer: Please subscribe me to the cypherpunks list...
+
+Thanks,
+
+
+Russell Earl Whitaker whitaker@eternity.demon.co.uk
+Communications Editor 71750.2413@compuserve.com
+EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER
+Board member, Extropy Institute (ExI)
+[.sig revised 1 October 1992 /// Send mail to eternity node]
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
+pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
+lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
+tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
+by51az4=
+=LOCL
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-08 (Thu, 8 Oct 92 07:04:56 PDT) - Subscribe - _whitaker@eternity.demon.co.uk (Russell E. Whitaker)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:41:35 PDT) - [Subscribe](/years/1992/10/4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42) - _hughes (Eric Hughes)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:57:23 PDT) - [Subscriptions, etc.](/years/1992/10/20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/45cba9314df0b5d366aa10e328f5e1583af274d04a9344baf485eb69ffc88689.md b/_emails/1992/10/45cba9314df0b5d366aa10e328f5e1583af274d04a9344baf485eb69ffc88689.md
new file mode 100644
index 0000000000..0073912d90
--- /dev/null
+++ b/_emails/1992/10/45cba9314df0b5d366aa10e328f5e1583af274d04a9344baf485eb69ffc88689.md
@@ -0,0 +1,102 @@
+---
+layout: default
+---
+
+# 1992-10-10 - Better directions to the meeting on Saturday at noon
+
+## Header Data
+
+From: gnu@cygnus.com
+To: cypherpunks@toad.com
+Message Hash: 45cba9314df0b5d366aa10e328f5e1583af274d04a9344baf485eb69ffc88689
+Message ID: \<9210100950.AA28200@cygnus.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-10 09:43:25 UTC
+Raw Date: Sat, 10 Oct 92 02:43:25 PDT
+
+## Raw message
+
+```
+{% raw %}From: gnu@cygnus.com
+Date: Sat, 10 Oct 92 02:43:25 PDT
+To: cypherpunks@toad.com
+Subject: Better directions to the meeting on Saturday at noon
+Message-ID: <9210100950.AA28200@cygnus.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Someone asked for better directions, and the original ones were
+pretty skimpy anyway. Here's a better try.
+
+ Cygnus Support
+ 1937 Landings Drive
+ Mt. View, CA 94043
+
+There's no phone service there yet.
+
+Take US 101 toward Mt. View. From San Francisco, it's about a
+40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway
+exit. If you were heading south on 101, you curve around to the
+right, cross over the freeway, and get to a stoplight. If you were
+heading north on 101, you just come right off the exit to the
+stoplight. The light is the intersection of Amphitheatre and
+Charleston Rd. Take a right on Charleston; there's a right-turn-only
+lane.
+
+Follow Charleston for a short distance. You'll pass the
+Metaphor/Kaleida buildings on the right. At a clump of palm trees and
+a "Landmark Deli" sign, you can take a right into Landings Drive; this
+gets you into the complex from the north. Or you can go slightly
+further along Charleston and take the next right, into a driveway with
+a big "Landmark" sign in the middle. No matter which way you got into
+the complex, follow around it until you are on the side that faces the
+freeway. There's a clock tower that rises out of one of the
+buildings, to the right (south) of the deli. Enter through the doors
+immediately under the clock tower. They'll be open between noon and
+1PM at least. (See below if you're late.)
+
+Once inside, take the stairs up, immediately to your right. At the top
+of the stairs, turn right past the treetops, and we'll be in 1937 on
+your left.
+
+If you are late and the door under the clock tower is locked, you can
+go to the deli (which will be around a building and left, as you face
+the door), cut between the buildings to the right of the deli, and
+into the back lawns between the complex and the farm behind it. Walk
+around the buildings until you see a satellite dish in the lawn. Go
+up the stairs next to the dish, which are the back stairs into the
+Cygnus office space. We'll prop the door (or you can bang on it if we
+forget).
+
+Or, you can find the guard who's wandering around the complex, who
+knows there's a meeting happening and will let you in. They can be
+beeped at 965 5250, though you'll have trouble finding a phone.
+
+Don't forget to eat first, or bring food at noon! I recommend hitting
+the burrito place on Rengstorff (La Costen~a) at about 11:45. To get
+there, when you get off 101, take Rengstorff (toward the hills) rather
+than Amphitheatre (toward the bay). Follow it about ten blocks until
+the major intersection at Middlefield Road. La Costen~a is the store
+on your left at the corner. You can turn left into the narrow lane
+behind the store, which leads to a parking lot, and enter by the front
+door, which faces the intersection. To get to the meeting from there,
+just retrace your route on Rengstorff, go straight over the freeway,
+and turn right at the stoplight onto Charleston; see above.
+
+See you there!
+
+ John Gilmore
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-10 (Sat, 10 Oct 92 02:43:25 PDT) - Better directions to the meeting on Saturday at noon - _gnu@cygnus.com_
+
diff --git a/_emails/1992/10/469abb614c7863da4b08c8492ddedd9268dc6c9ee9e116c72675887290677963.md b/_emails/1992/10/469abb614c7863da4b08c8492ddedd9268dc6c9ee9e116c72675887290677963.md
new file mode 100644
index 0000000000..6a5e9d1bbd
--- /dev/null
+++ b/_emails/1992/10/469abb614c7863da4b08c8492ddedd9268dc6c9ee9e116c72675887290677963.md
@@ -0,0 +1,48 @@
+---
+layout: default
+---
+
+# 1992-10-09 - Re: New feature of the remailer
+
+## Header Data
+
+From: Peter Shipley \
+To: Eric Hughes \
+Message Hash: 469abb614c7863da4b08c8492ddedd9268dc6c9ee9e116c72675887290677963
+Message ID: \<9210090721.AA09749@edev0.TFS\>
+Reply To: \<9210090703.AA26448@soda.berkeley.edu\>
+UTC Datetime: 1992-10-09 07:14:13 UTC
+Raw Date: Fri, 9 Oct 92 00:14:13 PDT
+
+## Raw message
+
+```
+{% raw %}From: Peter Shipley
+Date: Fri, 9 Oct 92 00:14:13 PDT
+To: Eric Hughes
+Subject: Re: New feature of the remailer
+In-Reply-To: <9210090703.AA26448@soda.berkeley.edu>
+Message-ID: <9210090721.AA09749@edev0.TFS>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+
+Now what is needed is a user interface/script for submitting mail.
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Thu, 8 Oct 92 23:56:11 PDT) - [New feature of the remailer](/years/1992/10/07ae1782d78a668866ed682f440cba74ebbd27148657ab8bcb66f1a7d5c36516) - _Eric Hughes \_
+ + 1992-10-09 (Fri, 9 Oct 92 00:14:13 PDT) - Re: New feature of the remailer - _Peter Shipley \_
+
diff --git a/_emails/1992/10/47f75618579e176e33b68fa8db4a67f40b80a2f50bba439002ae5d2f7151e4ba.md b/_emails/1992/10/47f75618579e176e33b68fa8db4a67f40b80a2f50bba439002ae5d2f7151e4ba.md
new file mode 100644
index 0000000000..1a1a895408
--- /dev/null
+++ b/_emails/1992/10/47f75618579e176e33b68fa8db4a67f40b80a2f50bba439002ae5d2f7151e4ba.md
@@ -0,0 +1,44 @@
+---
+layout: default
+---
+
+# 1992-10-17 - game items
+
+## Header Data
+
+From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan)
+To: cypherpunks@toad.com
+Message Hash: 47f75618579e176e33b68fa8db4a67f40b80a2f50bba439002ae5d2f7151e4ba
+Message ID: \<9210170316.AA05655@wixer\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-17 05:31:21 UTC
+Raw Date: Fri, 16 Oct 92 22:31:21 PDT
+
+## Raw message
+
+```
+{% raw %}From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan)
+Date: Fri, 16 Oct 92 22:31:21 PDT
+To: cypherpunks@toad.com
+Subject: game items
+Message-ID: <9210170316.AA05655@wixer>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+For that matter, vibrators are illegal now for sale in Texas. Most all sex toys have to be renamed as "personal enhancement devices" or sumsuch in retail outlets to avoid seizure.
+
+Also, drug testing decoy materials - like powdered fake urine - are illegal in TX.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-17 (Fri, 16 Oct 92 22:31:21 PDT) - game items - _wixer!pacoid@cs.utexas.edu (Paco Xander Nathan)_
+
diff --git a/_emails/1992/10/4819c24f105df5961c3b7abe09a69ebbe8477c9adee58cbaa1c345e6f3cd9503.md b/_emails/1992/10/4819c24f105df5961c3b7abe09a69ebbe8477c9adee58cbaa1c345e6f3cd9503.md
new file mode 100644
index 0000000000..2c11bd6239
--- /dev/null
+++ b/_emails/1992/10/4819c24f105df5961c3b7abe09a69ebbe8477c9adee58cbaa1c345e6f3cd9503.md
@@ -0,0 +1,114 @@
+---
+layout: default
+---
+
+# 1992-10-29 - drugs for sale
+
+## Header Data
+
+From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
+To: cypherpunks@toad.com
+Message Hash: 4819c24f105df5961c3b7abe09a69ebbe8477c9adee58cbaa1c345e6f3cd9503
+Message ID: \<3373.2AF03157@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-29 21:26:42 UTC
+Raw Date: Thu, 29 Oct 92 14:26:42 PPE
+
+## Raw message
+
+```
+{% raw %}From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
+Date: Thu, 29 Oct 92 14:26:42 PPE
+To: cypherpunks@toad.com
+Subject: drugs for sale
+Message-ID: <3373.2AF03157@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+A cross posting from FidoNet PUBLIC_KEYS. It would be nice if some
+other cypherpunks could join the PUBLIC_KEYS echo.
+
+
+
+;Date 29 Oct 92 11:28:07
+From: Jesse David Hollington@1:125/33
+To: Arol Ambler@1:125/111
+Subject: Test
+>----------------------- Do not change this line -----------------------------<
+ AA> Anyway, anyone who is concerned can always use some method that hides the
+ AA> fact that any secret content is even being communicated. (Variations on
+ AA> read every fifth word to see the real message, or other standard
+ AA> methods).
+
+ It's funny you should bring that up. One of the major proponents of
+encryption here in Region 12 posted the following in the Regional Sysop Echo
+some time ago...
+
+=============================================================================
+
+Having said that, I also wonder whether this insistence upon having
+everything in plain text isn't fostered by some sysops as a means of
+receiving information that they otherwise wouldn't be privy to. If
+one is truly paranoid ( *not* that I would fall into that category
+in anyone's wildest dreams...ahem), one should worry about why some
+netmail is read so assiduosly by passthrough systems in the first place.
+
+Fortunately, even mail that I send direct to nodes is quoted back and
+often passes through a whole variety of systems for their inspection and
+review.
+
+Since almost all of my netmail is incredibly innocent there might
+always be the possibility that some of it will come back to hover
+like a bad dream in some creative complaint. In broader legal terms,
+every other communication system avoids eavesdropping on mail.
+
+
+P.S. To understand how powerless you are to prevent encrypted text, read
+the leftmost letter of each sentence in the last three paragraghs
+downwards...ahem.
+
+===========================================================================
+
+ He raises a valid point. Sysops who are so paranoid about encrypted mail
+being sent through their systems should realize that they are really powerless
+to prevent it if somebody is determined enough to send a coded message to
+somebody else.
+
+ I've sought legal opinions in Canadian law (I don't know how it is in the
+U.S.) and I've discovered that the less I know about mail passing through my
+system, the safer I am. If I keep every message on my system, and read them
+all, then I can be held liable if somebody routes something illegal through my
+system and it slips by me. If I kill all passthrough mail, and read nothing
+except what is addressed to me, I am operating under common carrier status,
+and can't be held liable any more than Federal Express or UPS could.
+
+ As a result, it's actually better to *encourage* people to send encrypted
+mail through your system. The belief that if people are sending encrypted
+mail they're doing something wrong is a fallacy... then again, I'm preaching
+to the converted here.
+
+Cheers,
+ Jesse.
+
+
+--- Maximus 2.01wb
+ * Origin: On a Clear Disk You Can Seek Forever (1:225/1)
+--
+tom jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
+INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-29 (Thu, 29 Oct 92 14:26:42 PPE) - drugs for sale - _tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)_
+
diff --git a/_emails/1992/10/49e2a322f784875ed7aff0927bade4a23461f8d0b4577c3665c1452ebb6a1d7b.md b/_emails/1992/10/49e2a322f784875ed7aff0927bade4a23461f8d0b4577c3665c1452ebb6a1d7b.md
new file mode 100644
index 0000000000..e84a88cbc8
--- /dev/null
+++ b/_emails/1992/10/49e2a322f784875ed7aff0927bade4a23461f8d0b4577c3665c1452ebb6a1d7b.md
@@ -0,0 +1,47 @@
+---
+layout: default
+---
+
+# 1992-10-02 - Re: Secure IRC
+
+## Header Data
+
+From: George A. Gleason \
+To: postmastuh@dawkmastuh.guv
+Message Hash: 49e2a322f784875ed7aff0927bade4a23461f8d0b4577c3665c1452ebb6a1d7b
+Message ID: \<199210020800.AA21035@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-02 07:53:02 UTC
+Raw Date: Fri, 2 Oct 92 00:53:02 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Fri, 2 Oct 92 00:53:02 PDT
+To: postmastuh@dawkmastuh.guv
+Subject: Re: Secure IRC
+Message-ID: <199210020800.AA21035@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Interesting ideas so far... Hey, anyone see the Quantum Crypto article in
+October Scientific AMerican? Of course the approach isn't practical at this
+point, and doing it over fiber optics won't be any better since the
+amplification along the way would raise the quantum process to the classical
+level and destroy its value... but even so, interesting as theory...
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-02 (Fri, 2 Oct 92 00:53:02 PDT) - Re: Secure IRC - _George A. Gleason \_
+
diff --git a/_emails/1992/10/4ac131a44b9a1890122ffbba123034be4eff191a4476e1986383eedf0ea3c413.md b/_emails/1992/10/4ac131a44b9a1890122ffbba123034be4eff191a4476e1986383eedf0ea3c413.md
new file mode 100644
index 0000000000..6a31a160b5
--- /dev/null
+++ b/_emails/1992/10/4ac131a44b9a1890122ffbba123034be4eff191a4476e1986383eedf0ea3c413.md
@@ -0,0 +1,67 @@
+---
+layout: default
+---
+
+# 1992-10-16 - Who uses ethernet (Mr Squirrel?)
+
+## Header Data
+
+From: pmetzger@shearson.com (Perry E. Metzger)
+To: shipley@tfs.com
+Message Hash: 4ac131a44b9a1890122ffbba123034be4eff191a4476e1986383eedf0ea3c413
+Message ID: \<9210161803.AA15862@newsu.shearson.com\>
+Reply To: \<9210160112.AA06320@edev0.TFS\>
+UTC Datetime: 1992-10-16 18:34:23 UTC
+Raw Date: Fri, 16 Oct 92 11:34:23 PDT
+
+## Raw message
+
+```
+{% raw %}From: pmetzger@shearson.com (Perry E. Metzger)
+Date: Fri, 16 Oct 92 11:34:23 PDT
+To: shipley@tfs.com
+Subject: Who uses ethernet (Mr Squirrel?)
+In-Reply-To: <9210160112.AA06320@edev0.TFS>
+Message-ID: <9210161803.AA15862@newsu.shearson.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+>From: Peter Shipley
+
+>>
+>>Who uses ethernet?! :-)
+>>
+
+>I do at home, want to tap it? simple. just crawl under my house and
+>pug in to any jack, don't owrry about bringing batteies there are plenty
+>of 120V outlets.
+
+> -Pete
+
+>PS: and soon I plan on using ISDN to bridge by home ethernet backbone
+> onto the internet
+
+Old hat -- I still remember the days of yore (only about five years
+ago, but it seems like an eternity) when I worked at bellcore and
+Phil Karn revealed to me that his home network was on the internet.
+All I've got from home is a wimpy little UUCP link to this very day.
+
+Perry
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-14 (Tue, 13 Oct 92 22:45:57 PDT) - [re: Re: Mr. Squirrel](/years/1992/10/7e499c6a0ad8c00016756be087eed59e5468584faa0524d693043c0e0b32bba9) - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+ + 1992-10-14 (Wed, 14 Oct 92 11:11:49 PDT) - [Re: Mr. Squirrel](/years/1992/10/9894f672507495f4713359bc2ebc73e36ca07ccfd88543541a4e7184b7746c3a) - _Eric Hollander \_
+ + 1992-10-16 (Thu, 15 Oct 92 18:13:10 PDT) - [Who uses ethernet (Mr Squirrel?)](/years/1992/10/704ce56d2f4067d0cdc37a26e31ddbefffd3edd65ca38ff8ee81d27247ee473a) - _Peter Shipley \_
+ + 1992-10-16 (Fri, 16 Oct 92 11:34:23 PDT) - Who uses ethernet (Mr Squirrel?) - _pmetzger@shearson.com (Perry E. Metzger)_
+ + 1992-10-16 (Fri, 16 Oct 92 11:47:34 PDT) - [Re: Who uses ethernet (Mr Squirrel?)](/years/1992/10/cddc36f8c672bf9bb89b6149942bfd28939f85f5395dd7bcffef31c0a29e8e96) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/4b028509a502332d7eb20d667f19c0822f161f636956254fb21a228f7050899b.md b/_emails/1992/10/4b028509a502332d7eb20d667f19c0822f161f636956254fb21a228f7050899b.md
new file mode 100644
index 0000000000..7063768797
--- /dev/null
+++ b/_emails/1992/10/4b028509a502332d7eb20d667f19c0822f161f636956254fb21a228f7050899b.md
@@ -0,0 +1,65 @@
+---
+layout: default
+---
+
+# 1992-10-22 - Keystone
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 4b028509a502332d7eb20d667f19c0822f161f636956254fb21a228f7050899b
+Message ID: \<9210220541.AA13526@soda.berkeley.edu\>
+Reply To: \<9210220333.AA009m7@fnordbox.UUCP\>
+UTC Datetime: 1992-10-22 05:35:21 UTC
+Raw Date: Wed, 21 Oct 92 22:35:21 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Wed, 21 Oct 92 22:35:21 PDT
+To: cypherpunks@toad.com
+Subject: Keystone
+In-Reply-To: <9210220333.AA009m7@fnordbox.UUCP>
+Message-ID: <9210220541.AA13526@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Ah. A small PGP subset. You hadn't mentioned this. When you said
+you weren't requiring the user to run PGP, I assumed key generation
+must occur on the board.
+
+As for your fatal flaw I hadn't spotted, I had spotted it, and the
+location of the private key was the critical point. If the key is on
+the BBS, the message goes out in the clear.
+
+Look, it boils down to this. If the message traffic to the BBS is to
+be encrypted, then the user has to generate a key on his own machine
+and decrypt it on his own machine. There's no way around that.
+
+But the user interface problem can be solved. Just make a bunch of
+.com files which do nothing but spawn pgp by invoking the correct
+arguments. Very simple; a few lines of C is all. Even the PGPPATH
+can be set before the spawn. It's an easy encapsulation. It will run
+a bit slower for load time, but not appreciably. And you won't have
+to recompile PGP from the distributed executables.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Wed, 21 Oct 92 22:35:21 PDT) - Keystone - _Eric Hughes \_
+ + 1992-10-22 (Wed, 21 Oct 92 23:35:44 PDT) - [Re: Keystone](/years/1992/10/fb6cd513252375d40032e5c92dc6f0e2a944525554d20788331d097d9233143d) - _gnu@cygnus.com_
+ + 1992-10-22 (Thu, 22 Oct 92 10:09:30 PDT) - [Re: Keystone](/years/1992/10/2414b4e9749952e702f40e3ab08b5c8c4f13ba6c41f4fd2ddcc01ba85e3079c8) - _sdw@meaddata.com (Stephen Williams)_
+
diff --git a/_emails/1992/10/4b7db885ad2f8c9b50f47b7e01dff5dcd4bf4f8c93d38b54b2450802d2b96240.md b/_emails/1992/10/4b7db885ad2f8c9b50f47b7e01dff5dcd4bf4f8c93d38b54b2450802d2b96240.md
new file mode 100644
index 0000000000..7a810624ce
--- /dev/null
+++ b/_emails/1992/10/4b7db885ad2f8c9b50f47b7e01dff5dcd4bf4f8c93d38b54b2450802d2b96240.md
@@ -0,0 +1,59 @@
+---
+layout: default
+---
+
+# 1992-10-09 - +-=*^
+
+## Header Data
+
+From: Secret_Squirrel@Treehouse.COM
+To: cypherpunks@toad.com
+Message Hash: 4b7db885ad2f8c9b50f47b7e01dff5dcd4bf4f8c93d38b54b2450802d2b96240
+Message ID: \<9210091712.AA27717@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-09 17:05:09 UTC
+Raw Date: Fri, 9 Oct 92 10:05:09 PDT
+
+## Raw message
+
+```
+{% raw %}From: Secret_Squirrel@Treehouse.COM
+Date: Fri, 9 Oct 92 10:05:09 PDT
+To: cypherpunks@toad.com
+Subject: +-=*^
+Message-ID: <9210091712.AA27717@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+re: Interface for re-mailer; why not hitch it to emacs or something?
+
+re: problem with key distribution; right, OK, I hadn't thought that
+there might be a security problem with casually giving someone your
+key
+without them being able to authenticate that it came from you. Good
+point.
+
+Here's my public key. If you feel it is not secure enough, we can
+always use the cone of silence:
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+
+23l1t34u
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-09 (Fri, 9 Oct 92 10:05:09 PDT) - +-=*^ - _Secret_Squirrel@Treehouse.COM_
+ + 1992-10-09 (Fri, 9 Oct 92 11:16:24 PDT) - [Re: +-=*^](/years/1992/10/aca914116e261da03e08977616fac44612be493b810335fb01c85b9597d7a534) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/4c67e79a2ec7344d27550db884c628f037f2077d684ba8190ca763a77730d2bc.md b/_emails/1992/10/4c67e79a2ec7344d27550db884c628f037f2077d684ba8190ca763a77730d2bc.md
new file mode 100644
index 0000000000..959b515c7d
--- /dev/null
+++ b/_emails/1992/10/4c67e79a2ec7344d27550db884c628f037f2077d684ba8190ca763a77730d2bc.md
@@ -0,0 +1,65 @@
+---
+layout: default
+---
+
+# 1992-10-13 - Mr. Squirrel? Just who is whom here?
+
+## Header Data
+
+From: hugh@domingo.teracons.com (Hugh Daniel)
+To: CYPHERPUNKS@TOAD.COM
+Message Hash: 4c67e79a2ec7344d27550db884c628f037f2077d684ba8190ca763a77730d2bc
+Message ID: \<9210131201.AA12086@domingo.teracons.com\>
+Reply To: \<921010180751_74076.1041_DHJ61-1@CompuServe.COM\>
+UTC Datetime: 1992-10-13 12:02:06 UTC
+Raw Date: Tue, 13 Oct 92 05:02:06 PDT
+
+## Raw message
+
+```
+{% raw %}From: hugh@domingo.teracons.com (Hugh Daniel)
+Date: Tue, 13 Oct 92 05:02:06 PDT
+To: CYPHERPUNKS@TOAD.COM
+Subject: Mr. Squirrel? Just who is whom here?
+In-Reply-To: <921010180751_74076.1041_DHJ61-1@CompuServe.COM>
+Message-ID: <9210131201.AA12086@domingo.teracons.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+ Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone
+can use any public key they want also. So, in a many-to-one scope (as
+in a maillist) where the sender can not use the one-on-one signed
+signiture method how do we have proff of who the sender really is?
+ Maybe public forums are just not places where it is easy to verify
+the identity of a speaker?
+
+ A second thing that Hal's comments bring up is that we were reading
+the From: headders and ignoreing the keys. In good crypto-mail
+readers the key ought to be checked against our own data base of
+others keys and the result added to the hedders as say:
+ KeyCheck: FooBar Bazoid holds this key in XXX database
+or some such rot. I wonder what is more important, who I claim to be
+in a random message or what key I include...
+ New keys ought for an ID (or new ID's for the same key) should be
+added to the data base as well.
+ But all this needs to be done automaticly by the mailers and
+interfaces, else the system will be mis-used and folks will tire of
+the extra work that gets them little advantage.
+
+ ||ugh Daniel
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-10 (Sat, 10 Oct 92 11:04:58 PDT) - [Mr. Squirrel?](/years/1992/10/a7deae21289e64af8c4c457307bdf1c62cbeb469f75b1613a3ed1a9dfa73b939) - _Hal \<74076.1041@CompuServe.COM\>_
+ + 1992-10-13 (Tue, 13 Oct 92 05:02:06 PDT) - Mr. Squirrel? Just who is whom here? - _hugh@domingo.teracons.com (Hugh Daniel)_
+ + 1992-10-13 (Tue, 13 Oct 92 08:58:32 PDT) - [Mr. Squirrel? Just who is whom here?](/years/1992/10/b522b87517a2d84b579f40e313b2fa857de956c060f703f320fd96498bfcfd60) - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/4ca87779428bbf54ceb61e5789afa6cddb59f6abb001b6b2f5ff15428f981342.md b/_emails/1992/10/4ca87779428bbf54ceb61e5789afa6cddb59f6abb001b6b2f5ff15428f981342.md
new file mode 100644
index 0000000000..cfb60d22db
--- /dev/null
+++ b/_emails/1992/10/4ca87779428bbf54ceb61e5789afa6cddb59f6abb001b6b2f5ff15428f981342.md
@@ -0,0 +1,173 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Alpha Particles and One Time Pads
+
+## Header Data
+
+From: tcmay@netcom.com (Timothy C. May)
+To: cypherpunks@toad.com
+Message Hash: 4ca87779428bbf54ceb61e5789afa6cddb59f6abb001b6b2f5ff15428f981342
+Message ID: \<9210260530.AA00679@netcom2.netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 06:32:00 UTC
+Raw Date: Sun, 25 Oct 92 23:32:00 PPE
+
+## Raw message
+
+```
+{% raw %}From: tcmay@netcom.com (Timothy C. May)
+Date: Sun, 25 Oct 92 23:32:00 PPE
+To: cypherpunks@toad.com
+Subject: Alpha Particles and One Time Pads
+Message-ID: <9210260530.AA00679@netcom2.netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Fellow Cypherpunks,
+
+Here's a posting I just sent to sci.crypt, dealing with using alpha
+particle sources as noise sources for generating one-time pads.
+Ordinarily I wouldn't bother you folks with this, especially since
+you're all reading sci.crypt (aren't you? Only the FidoNetters have a
+good excuse not to.).
+
+But this thread ties together two aspects of my life, cryptography and
+alpha particle errors in chips.
+
+--Tim
+
+Newsgroups: sci.crypt
+Path: netcom.com!tcmay
+From: tcmay@netcom.com (Timothy C. May)
+Subject: Re: Hardware random number generators compatible with PCs?
+Message-ID: <1992Oct26.051612.29869@netcom.com>
+Organization: Netcom - Online Communication Services (408 241-9760 guest)
+X-Newsreader: Tin 1.1 PL5
+References: <1992Oct25.224554.1853@fasttech.com>
+Date: Mon, 26 Oct 1992 05:16:12 GMT
+
+Bohdan Tashchuk (zeke@fasttech.com) wrote:
+
+: The recent post on building a random number generator using a zener diode got
+: me to thinking once again about commercial alternatives.
+:
+: I haven't seen any commercial alternatives discussed here recently. And since
+: the market is so specialized, they may well exist but I'm simply not aware of
+: them.
+:
+: The ideal product would have the following features:
+:
+: * cost less than $100
+: * use a radioactive Alpha ray emitter as the source
+
+It's a small world! In my earlier incarnation as a physicist for
+Intel, I discovered the alpha particle "soft error" effect in memory
+chips. By 1976 chips, especially dynamic RAMs, were storing less than
+half a million electrons as the difference between a "1" and a "0". A
+several MeV alpha could generate more than a million electron-hole
+pairs, thus flipping some bits.
+
+(Obviously the effect of alphas on particle detectors was
+known, and smoke detectors were in wide use, but nobody prior to 1977
+knew that memory bits could be flipped by alphas, coming from uranium
+and thorium in the package materials. It's a long story, so I won't
+say any more about it here.)
+
+: * connect to an IBM PC serial or parallel port
+: * be "dongle" sized, ie be able to plug directly onto the port, and
+: not have a cable from an external box to the port
+: * be powered directly from the port
+: * generate at least 1000 "highly random" bits per second
+
+This should be feasible by placing a small (sub-microcurie) amount of
+Americium-241 on a small DRAM chip that is known to be alpha-sensitive
+(and not all of them are, due to processing tricks). Errors would
+occur at random intervals, depending on which bits got hit. Getting
+1000 errors a second would be tough, though, as such high intensities
+would also tend to eventually destroy the chip (through longterm
+damage to the silicon, threshold voltage shifts, etc.). If you really
+want to pursue this seriously, I can help with the calculations, etc.
+
+: Details:
+:
+: Certainly in high volume these things can be made cheaply. Smoke detectors
+: often sell for under $10, and have a radioactive source, an IC, a case, etc.
+
+Yes, but smoke detectors use ionization in a chamber (the smoke from a
+fire makes ionization easier). That is, no real ICs. But ICs, and even
+RAM chips, are cheap, so your $10 figure is almost certainly in the ballpark.
+
+A bigger concern is safety, or the _perceived_ safety. Smoke detectors
+have, I understand, moved away from alpha particle-based detectors to
+photoelectric detectors (smoke obscures beam of light). Don't
+underestimate the public's fear of radioactivity, even at low levels.
+
+: Using a well-designed circuit based on Alpha decay should mean that the
+: randomness is pretty darn good.
+
+But not necessarily any better than noise from a Zener. With the
+higher bit rate from diode noise, more statistical tricks can be done.
+The relatively low bit rate from alpha decay gives less flexibility.
+On the other hand, alpha hits are undeniably quite random, with
+essentially no way to skew the odds (unlike with diode noise).
+
+: Everyone these days has either a serial or parallel port available, either
+: directly or thru a switch box.
+:
+: The tiny "dongle" size is a convenience. If it is small and powered directly
+: from the port, there are no cables to get in the way. There is enough power
+: available from the signal lines on these ports to power simple devices. E.g.
+: most mice don't require an external power supply.
+:
+: For most applications 1000 bits per second should be adequate. For example,
+: it would be quite adequate for session keys. For generating pseudo
+: one-time-pads, an overnight run should generate plenty of values. Continuously
+: generating values for a month would produce about 300 MB, which should be
+: enough to exchange new CD-ROM key disks once a month.
+
+One time pads are complicated to use. Only very high security
+applications that can also afford them use them. For example, some
+diplomatic traffic. I can't conceive of a case where 300 MB a month
+could be used.
+
+And _theft_ (or copying) of the CD-ROM one time pads has got to be a
+much bigger issue that whether alpha particle noise sources are better
+than diode noise sources! By about 10 orders of magnitude I would say.
+
+Black bag jobs on the sites holding the keys will be the likeliest
+attack, not trying to analyze how random the noise is (even a fairly
+crummy noise source will not yield enough information to a
+cryptanalyst trying to break a one-time pad).
+
+Having said all this, I'm glad you gave some thought to alphas. For a
+time in the late 1970s this was the chip industry's number one
+headache...it was definitely the most exciting time of my life.
+
+--Tim
+--
+..........................................................................
+Timothy C. May | Crypto Anarchy: encryption, digital money,
+tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
+408-688-5409 | knowledge, reputations, information markets,
+W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
+Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Sun, 25 Oct 92 23:32:00 PPE) - Alpha Particles and One Time Pads - _tcmay@netcom.com (Timothy C. May)_
+ + 1992-10-26 (Mon, 26 Oct 92 12:47:45 PPE) - [Re: Alpha Particles and One Time Pads](/years/1992/10/bb4a49d7659a5c58389bf70574ecfa3693eb62b1952698da3e844d6829c85135) - _Peter Shipley \_
+ + 1992-10-26 (Mon, 26 Oct 92 14:09:43 PPE) - [Alpha Particles and One Time Pads](/years/1992/10/f9cc5c6d8ba5bdb505c75decc71a4fbd1c865e5e4a2322f842ff044c8dde44af) - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/4d3c0b68b446f11f664d02d6696ac26026c7e92e0e14c93cbc6235b7eb4495c3.md b/_emails/1992/10/4d3c0b68b446f11f664d02d6696ac26026c7e92e0e14c93cbc6235b7eb4495c3.md
new file mode 100644
index 0000000000..c404377e57
--- /dev/null
+++ b/_emails/1992/10/4d3c0b68b446f11f664d02d6696ac26026c7e92e0e14c93cbc6235b7eb4495c3.md
@@ -0,0 +1,61 @@
+---
+layout: default
+---
+
+# 1992-10-21 - TEMPEST, Eavesdropping
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 4d3c0b68b446f11f664d02d6696ac26026c7e92e0e14c93cbc6235b7eb4495c3
+Message ID: \<9210211711.AA11833@soda.berkeley.edu\>
+Reply To: \<9210202224.AA28714@netcom2.netcom.com\>
+UTC Datetime: 1992-10-21 17:11:42 UTC
+Raw Date: Wed, 21 Oct 92 10:11:42 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Wed, 21 Oct 92 10:11:42 PDT
+To: cypherpunks@toad.com
+Subject: TEMPEST, Eavesdropping
+In-Reply-To: <9210202224.AA28714@netcom2.netcom.com>
+Message-ID: <9210211711.AA11833@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+>Their chief concern doesn't seem to be folks like us, but rather
+>concerns about vans parking outside high tech and defense contractors
+>and slurping up what they can [...]
+
+When banks start signing with private keys, then we get an even more
+interesting monitoring problem.
+
+>And someone asked about building Faraday cages. Don't even try!
+
+Sometimes it is cheaper to build a whole building to be tempest-spec
+than to buy all tempest-spec electronics. What I have heard about
+such stuff is solid copper walls and no windows. No exacly your
+classical Faraday cage; more like your classical Gaussian surface. :->
+
+TEMPEST is an acronym. I don't remember for what.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-21 (Wed, 21 Oct 92 10:11:42 PDT) - TEMPEST, Eavesdropping - _Eric Hughes \_
+ + 1992-10-21 (Wed, 21 Oct 92 14:07:37 PDT) - [TEMPEST, Eavesdropping](/years/1992/10/041ccd8442454608e3dec5534526a715161e63caf6d81ac5e2f5ea068bf6c330) - _pmetzger@shearson.com (Perry E. Metzger)_
+
diff --git a/_emails/1992/10/4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42.md b/_emails/1992/10/4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42.md
new file mode 100644
index 0000000000..50b4114d2d
--- /dev/null
+++ b/_emails/1992/10/4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42.md
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+# 1992-10-08 - Subscribe
+
+## Header Data
+
+From: hughes (Eric Hughes)
+To: whitaker@eternity.demon.co.uk
+Message Hash: 4dda48fae2f6e862d1a35aa019c82ecee26503b544f80ca323cc75f6238d3c42
+Message ID: \<9210081541.AA03134@toad.com\>
+Reply To: \<1480@eternity.demon.co.uk\>
+UTC Datetime: 1992-10-08 15:41:35 UTC
+Raw Date: Thu, 8 Oct 92 08:41:35 PDT
+
+## Raw message
+
+```
+{% raw %}From: hughes (Eric Hughes)
+Date: Thu, 8 Oct 92 08:41:35 PDT
+To: whitaker@eternity.demon.co.uk
+Subject: Subscribe
+In-Reply-To: <1480@eternity.demon.co.uk>
+Message-ID: <9210081541.AA03134@toad.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+You are subscribed.
+
+Next time, please use the cypherpunks-request@toad.com address for
+administrative matters. Tell your friends this as well. Your request
+got sent out to the whole list, not a tragedy, but an annoyance.
+
+I met Max More at a party about a month ago. I suspect he might be
+interested in the list. Do you have an e-mail address for him?
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-08 (Thu, 8 Oct 92 07:04:56 PDT) - [Subscribe](/years/1992/10/454afdeccfcfc12faec4a1c95227823ccd2317215802fba5cb077de5bba38b1f) - _whitaker@eternity.demon.co.uk (Russell E. Whitaker)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:41:35 PDT) - Subscribe - _hughes (Eric Hughes)_
+ + 1992-10-08 (Thu, 8 Oct 92 08:57:23 PDT) - [Subscriptions, etc.](/years/1992/10/20afd4cea4d9e2d57280c5afce0c3f16abf843ef65658c20b5cd90f7b78a1070) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/4e2d68b1b438d44805f4da04f132ea6afbc6804413a7808e5a4966e63ef11f13.md b/_emails/1992/10/4e2d68b1b438d44805f4da04f132ea6afbc6804413a7808e5a4966e63ef11f13.md
new file mode 100644
index 0000000000..2bf97a82b5
--- /dev/null
+++ b/_emails/1992/10/4e2d68b1b438d44805f4da04f132ea6afbc6804413a7808e5a4966e63ef11f13.md
@@ -0,0 +1,54 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Re: Registering Keys with Big Brother
+
+## Header Data
+
+From: George A. Gleason \
+To: tcmay@netcom.com
+Message Hash: 4e2d68b1b438d44805f4da04f132ea6afbc6804413a7808e5a4966e63ef11f13
+Message ID: \<199210260853.AA20086@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 08:54:38 UTC
+Raw Date: Mon, 26 Oct 92 01:54:38 PPE
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Mon, 26 Oct 92 01:54:38 PPE
+To: tcmay@netcom.com
+Subject: Re: Registering Keys with Big Brother
+Message-ID: <199210260853.AA20086@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Tim's summary of Denning raises some interesting points, and no doubt this
+will end up in the courts in due time. Some angles of attack which might be
+pursued include 2nd amendment (original grounds: protection against tyrrany)
+and 1st amendment. Re the latter, a lawyer I spoke with some years ago,
+proposed the idea that freedom of speech in some cases depends on the
+ability for the speaker to determine who will and who will not receive what
+is said.
+
+Then of course there is always good oldfashioned civil disobedience. If
+enough people conscientiously violate the regulation, it will become
+unenforceable and all the more likely to be overturned.
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 01:54:38 PPE) - Re: Registering Keys with Big Brother - _George A. Gleason \_
+ + 1992-10-26 (Mon, 26 Oct 92 09:38:01 PPE) - [Registering Keys with Big Brother](/years/1992/10/51213736f60c1e2796c2efeb25d8bc8604e98cac27e3dbb72131f18007d74363) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/4e5fbb8165043de2724fa04e92f0ab99ed97bc40a4bc063185c8a2e6d719999f.md b/_emails/1992/10/4e5fbb8165043de2724fa04e92f0ab99ed97bc40a4bc063185c8a2e6d719999f.md
new file mode 100644
index 0000000000..176e69fdfa
--- /dev/null
+++ b/_emails/1992/10/4e5fbb8165043de2724fa04e92f0ab99ed97bc40a4bc063185c8a2e6d719999f.md
@@ -0,0 +1,59 @@
+---
+layout: default
+---
+
+# 1992-10-21 - Re: Home security...
+
+## Header Data
+
+From: George A. Gleason \
+To: mark@coombs.anu.edu.au
+Message Hash: 4e5fbb8165043de2724fa04e92f0ab99ed97bc40a4bc063185c8a2e6d719999f
+Message ID: \<199210210815.AA06441@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-21 08:16:08 UTC
+Raw Date: Wed, 21 Oct 92 01:16:08 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Wed, 21 Oct 92 01:16:08 PDT
+To: mark@coombs.anu.edu.au
+Subject: Re: Home security...
+Message-ID: <199210210815.AA06441@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Tempest: there are companies which make cages for Macs and PCs, I don't have
+addresses but they can probably be found with some searching of ads. The
+main application it would seem, is not the individual home user (unless
+s/he's a notorious digital dissident) but rather the encrypted BBS,
+particularly one which decrypts and re-encrypts or retransmits messages.
+Consider the labor cost of monitoring a computer, and you can see it would
+be reserved for the ones that are "significant."
+
+Keeping your computer off the phones and AC while doing crypto processing,
+can be fairly easy. Unplug the darn modem from the phone socket. (Gee that
+was simple, wasn't it?) Use a laptop and run it entirely on the batteries
+while doing crypto processing. You can go buy an old laptop pretty cheaply
+these days... Or get an uninterruptable power supply for your main
+computer; cost will vary from $600 to $1500 depending on how much time you
+need to be running on the large batteries which are converted into AC to run
+the computer.
+
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-21 (Wed, 21 Oct 92 01:16:08 PDT) - Re: Home security... - _George A. Gleason \_
+
diff --git a/_emails/1992/10/4eeee33db706827275e7187c82882825658b0861bfe99b00cfe2ef651e9e14c1.md b/_emails/1992/10/4eeee33db706827275e7187c82882825658b0861bfe99b00cfe2ef651e9e14c1.md
new file mode 100644
index 0000000000..c58c3d621c
--- /dev/null
+++ b/_emails/1992/10/4eeee33db706827275e7187c82882825658b0861bfe99b00cfe2ef651e9e14c1.md
@@ -0,0 +1,56 @@
+---
+layout: default
+---
+
+# 1992-10-10 - a key
+
+## Header Data
+
+From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
+To: cypherpunks@toad.com
+Message Hash: 4eeee33db706827275e7187c82882825658b0861bfe99b00cfe2ef651e9e14c1
+Message ID: \<9210100755.AA05427@kg6kf.ampr.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-10 10:07:47 UTC
+Raw Date: Sat, 10 Oct 92 03:07:47 PDT
+
+## Raw message
+
+```
+{% raw %}From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
+Date: Sat, 10 Oct 92 03:07:47 PDT
+To: cypherpunks@toad.com
+Subject: a key
+Message-ID: <9210100755.AA05427@kg6kf.ampr.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+A key...
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQA9AirWaLMAAAEBgMlJILifxrXH8fkJwJbeSHXAY1Q9/AzPybGVy0Dx/q70Fr3d
+KhM6XoSEgaw2Ezzn2QAFEbQWTWFyYyBkZSBHcm9vdCAoY2FzdWFsKbQjTWFyYyBk
+ZSBHcm9vdCA8bWFyY0BrZzZrZi5hbXByLm9yZz4=
+=LL6T
+-----END PGP PUBLIC KEY BLOCK-----
+
+This is a casual key for me. Perhaps a causal key for me too.
+
+-Marc de Groot
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-10 (Sat, 10 Oct 92 03:07:47 PDT) - a key - _marc@kg6kf.ampr.org (Marc de Groot - KG6KF)_
+
diff --git a/_emails/1992/10/503c3b8d260c9d277fec543d1511e53afe6d139974194bbc24df6f7f32462d72.md b/_emails/1992/10/503c3b8d260c9d277fec543d1511e53afe6d139974194bbc24df6f7f32462d72.md
new file mode 100644
index 0000000000..d3b7f4010a
--- /dev/null
+++ b/_emails/1992/10/503c3b8d260c9d277fec543d1511e53afe6d139974194bbc24df6f7f32462d72.md
@@ -0,0 +1,78 @@
+---
+layout: default
+---
+
+# 1992-10-20 - Re: Keystone
+
+## Header Data
+
+From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)
+To: soda.berkeley.edu!hughes@cs.utexas.edu
+Message Hash: 503c3b8d260c9d277fec543d1511e53afe6d139974194bbc24df6f7f32462d72
+Message ID: \<9210201753.AA009kv@fnordbox.UUCP\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-20 21:43:30 UTC
+Raw Date: Tue, 20 Oct 92 14:43:30 PDT
+
+## Raw message
+
+```
+{% raw %}From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)
+Date: Tue, 20 Oct 92 14:43:30 PDT
+To: soda.berkeley.edu!hughes@cs.utexas.edu
+Subject: Re: Keystone
+Message-ID: <9210201753.AA009kv@fnordbox.UUCP>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+:I would be hesitant to implement a system that _only_ required a user
+:to generate a key pair. This, for the users, is too much provided
+:privacy. It will not teach the users how privacy really works, nor
+:will it give them any good idea how their privacy is being maintained.
+
+I take the opposite view -- I dare *not* supply such a system. Any user that
+is interested enough in 100% privacy will be encouraged -- both from the
+email prompt and through the message bases/file areas -- to d/l a copy of
+PGP. I'll probably write a tutorial on using it as well.
+
+But many users do not have the interest/time/ability to set up PGP on their
+home system. For them, I want to provide the best possible privacy given the
+ease with which anyone who can find their local LMOS can tap (voice or data)
+a line...
+
+:Defended privacy does not need to be difficult. I would spend effort,
+:instead of modifying BBS software, to make it easier for users to
+:handle encrypted email with their own terminal programs.
+
+I don't have my user's terminal program -- I *do* have the bbs software.
+
+:Again, trusted systems can turn into provided privacy. If there is a
+:distributed solution you can think up, use it.
+
+I don't know any way to maintain an up-to-date, central keyring without
+someone being in charge of regular updates. I'd make it available via
+Fido, FTP, BMS and regular d/l.
+
+Loyd
+
+***************************************************************************
+* loydb@fnordbox.UUCP Once you pull the pin, * Loyd Blankenship *
+* GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 *
+* Compu$erve: [73407,515] your friend! * Austin, TX 78760 *
+* cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 *
+***************************************************************************
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-20 (Tue, 20 Oct 92 14:43:30 PDT) - Re: Keystone - _fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)_
+ + 1992-10-21 (Wed, 21 Oct 92 09:43:25 PDT) - [Keystone](/years/1992/10/2ff29505951a381077a03c5daef44ec830ba5b90cf48eb6abe31bc094aeaee28) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/51213736f60c1e2796c2efeb25d8bc8604e98cac27e3dbb72131f18007d74363.md b/_emails/1992/10/51213736f60c1e2796c2efeb25d8bc8604e98cac27e3dbb72131f18007d74363.md
new file mode 100644
index 0000000000..bafff5fffa
--- /dev/null
+++ b/_emails/1992/10/51213736f60c1e2796c2efeb25d8bc8604e98cac27e3dbb72131f18007d74363.md
@@ -0,0 +1,84 @@
+---
+layout: default
+---
+
+# 1992-10-26 - Registering Keys with Big Brother
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 51213736f60c1e2796c2efeb25d8bc8604e98cac27e3dbb72131f18007d74363
+Message ID: \<9210261637.AA12485@soda.berkeley.edu\>
+Reply To: \<199210260853.AA20086@well.sf.ca.us\>
+UTC Datetime: 1992-10-26 16:38:01 UTC
+Raw Date: Mon, 26 Oct 92 09:38:01 PPE
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 26 Oct 92 09:38:01 PPE
+To: cypherpunks@toad.com
+Subject: Registering Keys with Big Brother
+In-Reply-To: <199210260853.AA20086@well.sf.ca.us>
+Message-ID: <9210261637.AA12485@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Re: Some angles of attack
+
+George:
+>2nd amendment (original grounds: protection against tyrrany)
+
+I've thought for a year or so now that if the State Department was
+going to class cryptography as munitions, then they have _de jure_
+acknowledged that civilian use of cryptography is protected under the
+Second Amendment. Cryptography is not a weapon and should not be
+restricted for public safety reasons.
+
+>1st amendment. Re the latter, a lawyer I spoke with some years ago,
+>proposed the idea that freedom of speech in some cases depends on the
+>ability for the speaker to determine who will and who will not
+>receive what is said.
+
+This criterion may be valid, but I don't think it's needed. As I
+understand it, the restrictions on speech that do exist restrict 1)
+certain contents, not speech as such, and 2) speech which is public,
+not private. Encrypted text, by the fact that it is encrypted, is
+intended to be removed from the public domain. And restricting the
+transmission of encrypted text based on some assumed content is prior
+restraint.
+
+I'm not sure that any of these arguments really touch a key
+registration proposal, unfortunately. Guns may be sold, but also
+registered. It is not the speech that is restricted, but the privacy
+from the Justice Dept. which is restricted.
+
+What I suspect may be more effective is to argue, based on the Tenth
+(or Ninth? I get them confused) Amendment, that the Federal Government
+has not been granted specific power to require the registration of key
+material under any of its other powers.
+
+>Then of course there is always good oldfashioned civil disobedience.
+
+But the percentage of users of cryptography for communications is a
+small percentage of the total population as of yet.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 01:54:38 PPE) - [Re: Registering Keys with Big Brother](/years/1992/10/4e2d68b1b438d44805f4da04f132ea6afbc6804413a7808e5a4966e63ef11f13) - _George A. Gleason \_
+ + 1992-10-26 (Mon, 26 Oct 92 09:38:01 PPE) - Registering Keys with Big Brother - _Eric Hughes \_
+
diff --git a/_emails/1992/10/5184a453232950fa3db3e0f18588265df69df6e0f02e98bdb13d58186e115a15.md b/_emails/1992/10/5184a453232950fa3db3e0f18588265df69df6e0f02e98bdb13d58186e115a15.md
new file mode 100644
index 0000000000..cc8bf8a4b1
--- /dev/null
+++ b/_emails/1992/10/5184a453232950fa3db3e0f18588265df69df6e0f02e98bdb13d58186e115a15.md
@@ -0,0 +1,45 @@
+---
+layout: default
+---
+
+# 1992-10-31 - Please remove me from the mailing list!
+
+## Header Data
+
+From: Oren Mitz \
+To: cypherpunks@toad.com
+Message Hash: 5184a453232950fa3db3e0f18588265df69df6e0f02e98bdb13d58186e115a15
+Message ID: \<9211010151.AA18004@coma.huji.ac.il\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-31 20:51:56 UTC
+Raw Date: Sat, 31 Oct 92 13:51:56 PPE
+
+## Raw message
+
+```
+{% raw %}From: Oren Mitz
+Date: Sat, 31 Oct 92 13:51:56 PPE
+To: cypherpunks@toad.com
+Subject: Please remove me from the mailing list!
+Message-ID: <9211010151.AA18004@coma.huji.ac.il>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Sorry, can't handle the numer of messages every day
+. Thankx and out.
+
+ bye bye from O>_
+
diff --git a/_emails/1992/10/53eb0708e08670c4abdbbf06f961e58f5971cc0069188cb261e398a4377ea1f6.md b/_emails/1992/10/53eb0708e08670c4abdbbf06f961e58f5971cc0069188cb261e398a4377ea1f6.md
new file mode 100644
index 0000000000..4f9b1b44b9
--- /dev/null
+++ b/_emails/1992/10/53eb0708e08670c4abdbbf06f961e58f5971cc0069188cb261e398a4377ea1f6.md
@@ -0,0 +1,69 @@
+---
+layout: default
+---
+
+# 1992-10-04 - public vs. private
+
+## Header Data
+
+From: Judith Milhon \
+To: cypherpunks@toad.com
+Message Hash: 53eb0708e08670c4abdbbf06f961e58f5971cc0069188cb261e398a4377ea1f6
+Message ID: \<199210040152.AA17760@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-04 01:45:12 UTC
+Raw Date: Sat, 3 Oct 92 18:45:12 PDT
+
+## Raw message
+
+```
+{% raw %}From: Judith Milhon
+Date: Sat, 3 Oct 92 18:45:12 PDT
+To: cypherpunks@toad.com
+Subject: public vs. private
+Message-ID: <199210040152.AA17760@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+
+marc suggests:
+>>I *am* a little worried about publicizing the whole thing;
+>>perhaps it's okay to make it a showpiece but
+>>the real stuff needs to be done in a much more private way.
+
+Consider the phage model (which I & my roommate efrem lipkin have
+been considering for a longish while, since Community Memory) :
+
+The bacteriophage virus replicates itself by injecting its own
+information into an existing system. The more copies of the phage,
+the worse for the bacteria etc etc.
+SO: in private, the planning, the designing, the coding...
+for public distribution as widely as possible. If the technology is
+intrinsically transformative, and if the process of distribution is
+engaging, even exciting, the revolution is next tuesday.
+
+
+hughes is hoping that remailers will pop up everywhere, even before the
+encryption upgrades arrive... heh. And the more designers and coders we
+rope in, via publicizing, to produce immediate lively replicating
+phages, the better. Not so? If not so, I'll shut up forthwith.
+
+StJude
+
+PS: also it mindfucks the idea of conspiracy. hee hee.
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-04 (Sat, 3 Oct 92 18:45:12 PDT) - public vs. private - _Judith Milhon \_
+
diff --git a/_emails/1992/10/57fcf706442dc8d3909c841ec5e16168f5999c5cf8783dc221f48a8bce021a78.md b/_emails/1992/10/57fcf706442dc8d3909c841ec5e16168f5999c5cf8783dc221f48a8bce021a78.md
new file mode 100644
index 0000000000..5e7c7d5658
--- /dev/null
+++ b/_emails/1992/10/57fcf706442dc8d3909c841ec5e16168f5999c5cf8783dc221f48a8bce021a78.md
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+# 1992-10-15 - illegal objects
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 57fcf706442dc8d3909c841ec5e16168f5999c5cf8783dc221f48a8bce021a78
+Message ID: \<2952.2ADC70A6@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-15 00:26:19 UTC
+Raw Date: Wed, 14 Oct 92 17:26:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Wed, 14 Oct 92 17:26:19 PDT
+To: cypherpunks@toad.com
+Subject: illegal objects
+Message-ID: <2952.2ADC70A6@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Hell, there's real-world examples today that some of my friends have
+been harrassed for: "Obscene materials".
+
+OK, sexually explicit photographs are a trivial example. Friends have
+gotten harrassed (by US customs) for zines containing weird shit, not
+just sexually explicit. The US/Canada customs people are living in
+another century and reality plane.
+
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-15 (Wed, 14 Oct 92 17:26:19 PDT) - illegal objects - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/58b104e07d986881ca5858f4fc58afef98e1f49809cec9031d8443eb990416fc.md b/_emails/1992/10/58b104e07d986881ca5858f4fc58afef98e1f49809cec9031d8443eb990416fc.md
new file mode 100644
index 0000000000..2e982c9fa0
--- /dev/null
+++ b/_emails/1992/10/58b104e07d986881ca5858f4fc58afef98e1f49809cec9031d8443eb990416fc.md
@@ -0,0 +1,54 @@
+---
+layout: default
+---
+
+# 1992-10-21 - the acronym TEMPEST
+
+## Header Data
+
+From: Karl L. Barrus \
+To: cypherpunks@toad.com
+Message Hash: 58b104e07d986881ca5858f4fc58afef98e1f49809cec9031d8443eb990416fc
+Message ID: \<9210212026.AA00628@tree.egr.uh.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-21 20:26:56 UTC
+Raw Date: Wed, 21 Oct 92 13:26:56 PDT
+
+## Raw message
+
+```
+{% raw %}From: Karl L. Barrus
+Date: Wed, 21 Oct 92 13:26:56 PDT
+To: cypherpunks@toad.com
+Subject: the acronym TEMPEST
+Message-ID: <9210212026.AA00628@tree.egr.uh.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+> TEMPEST is an acronym. I don't remember for what.
+
+> Eric
+
+TEMPEST = Transient ElectronMagnetic Pulse Emission STandard. Pretty
+cool sounding acronym :-)
+
+/-----------------------------------\
+| Karl L. Barrus |
+| barrus@tree.egr.uh.edu (NeXTMail) |
+| elee9sf@menudo.uh.edu |
+\-----------------------------------/
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-21 (Wed, 21 Oct 92 13:26:56 PDT) - the acronym TEMPEST - _Karl L. Barrus \_
+
diff --git a/_emails/1992/10/58fccca06def004a4a67c7d0293183aaeba37be18ebc3ec80c42ddd4b6f8ed3d.md b/_emails/1992/10/58fccca06def004a4a67c7d0293183aaeba37be18ebc3ec80c42ddd4b6f8ed3d.md
new file mode 100644
index 0000000000..0cfe7069c9
--- /dev/null
+++ b/_emails/1992/10/58fccca06def004a4a67c7d0293183aaeba37be18ebc3ec80c42ddd4b6f8ed3d.md
@@ -0,0 +1,47 @@
+---
+layout: default
+---
+
+# 1992-10-25 - Removal from list
+
+## Header Data
+
+From: nathanf@cup.portal.com
+To: cypherpunks@toad.com
+Message Hash: 58fccca06def004a4a67c7d0293183aaeba37be18ebc3ec80c42ddd4b6f8ed3d
+Message ID: \<9210251610.1.16692@cup.portal.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 23:21:58 UTC
+Raw Date: Sun, 25 Oct 92 16:21:58 PPE
+
+## Raw message
+
+```
+{% raw %}From: nathanf@cup.portal.com
+Date: Sun, 25 Oct 92 16:21:58 PPE
+To: cypherpunks@toad.com
+Subject: Removal from list
+Message-ID: <9210251610.1.16692@cup.portal.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Please remove me from the list.
+My address is
+
+ nathanf@cup.portal.com
+
+ Thank you.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sun, 25 Oct 92 16:21:58 PPE) - Removal from list - _nathanf@cup.portal.com_
+
diff --git a/_emails/1992/10/59880107a8682ff630340193de22e9bf74179cc0b1399b38c188fa4c661518f3.md b/_emails/1992/10/59880107a8682ff630340193de22e9bf74179cc0b1399b38c188fa4c661518f3.md
new file mode 100644
index 0000000000..de279c32dd
--- /dev/null
+++ b/_emails/1992/10/59880107a8682ff630340193de22e9bf74179cc0b1399b38c188fa4c661518f3.md
@@ -0,0 +1,85 @@
+---
+layout: default
+---
+
+# 1992-10-13 - one time pads
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 59880107a8682ff630340193de22e9bf74179cc0b1399b38c188fa4c661518f3
+Message ID: \<9210131558.AA25287@soda.berkeley.edu\>
+Reply To: \<199210130821.AA03658@well.sf.ca.us\>
+UTC Datetime: 1992-10-13 15:51:51 UTC
+Raw Date: Tue, 13 Oct 92 08:51:51 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Tue, 13 Oct 92 08:51:51 PDT
+To: cypherpunks@toad.com
+Subject: one time pads
+In-Reply-To: <199210130821.AA03658@well.sf.ca.us>
+Message-ID: <9210131558.AA25287@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Previously I said about one-time pads: "High security, high cost."
+(Well, not exactly that...) I invoked it then in order to argue that
+I personally didn't need to use one-time pads. Implicit also in that
+statement is the claim that when the worth of security is high, the
+cost may be relatively cheap. George and I agree on this point.
+
+When you are fighting a military battle, when you have a government
+pissed off at you in a serious way, you need as good as you can get.
+Since you can get perfect end-to-end link encryption, you use it.
+
+All cryptography is economics. Repeat after me. All cryptography is
+economics.
+
+I don't need one-time pads. Sendero Luminoso does. It's as easy as
+that. It's merely a matter of scale. Large scale, high security.
+Small scale, pretty good security.
+
+Re: Mathematical breakthroughs. George missed my main point here. We
+don't know whether factoring is "fundamentally hard." (Project your
+own definition here.) We should not assume that when the breakthrough
+comes, that is will be found "easy." It may be that factoring is
+hard, and that RSA is secure for that reason. (The astute reader will
+see that these two are not exactly the same question.) My current
+thinking is that factoring is hard because of various randomness
+properties of primes, that in fact multiplying one large prime by
+another is like encrypting one prime with the other as a one-time pad!
+But I'm no number theorist.
+
+I do, however, agree with "caution in the face of an unknown." And
+for high stakes, George's "irrational caution" is not irrational at
+all.
+
+Re: Relative security. It seems I had an editing error. What I meant
+to say (paraphrased) was the following. Perfect security is not worth
+the cost when the marginal cost of perfect security is more than the
+marginal benefits of such security. This encompasses both the high
+end and the low end. I don't need one-time pads. Abu Nidal does.
+
+Repeat after me. Cryptography is all economics.
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-13 (Tue, 13 Oct 92 01:14:58 PDT) - [Re: one time pads](/years/1992/10/1afebd35d2386ecbd3e928fbe8238aa1ae87a785db7db042acce1e283ed3cd16) - _George A. Gleason \_
+ + 1992-10-13 (Tue, 13 Oct 92 08:51:51 PDT) - one time pads - _Eric Hughes \_
+
diff --git a/_emails/1992/10/599e64840d21644485578a5da2982b027487d576131050f67288e708c5d67a3f.md b/_emails/1992/10/599e64840d21644485578a5da2982b027487d576131050f67288e708c5d67a3f.md
new file mode 100644
index 0000000000..e7919a6c8e
--- /dev/null
+++ b/_emails/1992/10/599e64840d21644485578a5da2982b027487d576131050f67288e708c5d67a3f.md
@@ -0,0 +1,139 @@
+---
+layout: default
+---
+
+# 1992-10-04 - PGP echo conference...
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: pozar@kumr.lns.com
+Message Hash: 599e64840d21644485578a5da2982b027487d576131050f67288e708c5d67a3f
+Message ID: \<2573.2ACF6745@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-04 21:46:44 UTC
+Raw Date: Sun, 4 Oct 92 14:46:44 PDT
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Sun, 4 Oct 92 14:46:44 PDT
+To: pozar@kumr.lns.com
+Subject: PGP echo conference...
+Message-ID: <2573.2ACF6745@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Date: 03 Oct 92 17:22:42
+From: Christopher Baker on 374/14
+To: Tom Jennings on 125/111 Subj: PUBLIC_KEYS Echo announcement
+
+ * Forwarded from 1:374/14, Rights On! in Titusville FL
+ * Originally to All in the ECHO_REQ echo.
+
+attention all public-key encryption buffs:
+
+a new Echo has been started for discussion and distribution of public-key encryption info. since it was only born a couple hours ago, it is being distributed privately from 1:374/14 [9600+ HST/V32] and 1:374/26 [2400].
+
+ here are the details from the EListing:
+
+area PUBLIC_KEYS
+
+title Public-Key Encryption and Distribution Echo
+
+desc Provides a technical forum for discussion of public-key desc encryption techniques and programs and for the distribution desc of public-keys in FidoNet and other BBS and e-mail networks. desc PUBLIC_KEYS is Moderated by Christopher Baker at 1:374/14 desc [KeyID: 1024/4B9A59] and GK Pace at 1:374/26 [KeyID: desc 1024/B6B823]. The messages entered into the Echo are the sole desc responsibility of the person entering the messages. When in desc doubt about public-keys, contact the poster directly via Netmail. desc The Echo is open to anyone with an interest in public-key desc
+
+encryption issues and methods. The Echo Guidelines are contained desc in PUBKEYS.RUL available in ELRUL???.LZH as of 11/92.
+
+ mod C.Baker/GK.Pace, 1:374/14
+
+tot 2
+
+vol 10/week
+
+dist LOCAL, ZONE1
+
+SEEN 374/14 374/26
+
+PATH 374/14 374/26
+
+-30-
+
+here's the info from the .RUL file to be found in ELRUL as of 11/92:
+
+
+
+This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to post and find public-keys for data encryption within FidoNet and elsewhere and to discuss data and software encryption and the various schemes thereof.
+
+ This is a technical Echo with very few rules. Those very few rules are:
+
+1. Stay on-topic. Topics of keys and encryption are welcome. Others are not.
+
+ 2. No politics [except as it relates to privacy issues] and no religion.
+
+ 3. No personal attacks, slurs or innuendo. Stick to issues not
+
+ personalities.
+
+ 4. No Private flagged messages in Echomail! Encrypted traffic using
+
+ public-keys is permitted for the exercise so long as it is on-topic.
+
+ 5. This Echo may be traveling around the world so try to be concise. Avoid
+
+ excessive quoting for one-liner responses.
+
+ 6. Be aware that Echomail is NOT secure. Don't take anything at face value.
+
+ 7. The posts in this Echo are the sole responsiblity of the poster. If you
+
+ need verification, use Netmail.
+
+ 8. The Moderators will deal with off-topic traffic. Don't respond for them.
+
+ Links to this Echo will only be curtailed when absolutely necessary so
+
+ please don't make it necessary. [grin]
+
+The Moderators are Christopher Baker [KeyID: 1024/4B9A59 1992/10/03] and GK Pace [KeyID: 1024/B6B823 1992/09/28] at 1:374/14 and 1:374/26, respectively.
+
+ It is recommended that public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. This will avoid duplicate overwriting and make it easier to track the keys. Using a standard magic filename will make it easier to find keys on different systems.
+
+ This Echo is not currently on the Zone 1 Backbone distribution list but that is expected to change as soon as the word gets out. This Echo will be EListed in ELIST211 next month. Please feel free to announce and distribute this Echo to all interested participants in your area.
+
+ Thanks.
+
+ TTFN. Christopher Baker & GK Pace Moderators
+
+-30-
+
+any questions? anyone with Areafix already set for this system or for 1:374/26 may link in remotely. all others need to send a Netmail request. the Echo will be distributed privately until it is large enough for moving to the Zone 1 Backbone [or any other Backbones who want to get into it].
+
+ thanks.
+
+ TTFN. Chris & GK
+
+* Origin: Rights On! - Announcing ANOTHER Echo? - Titusville_FL (1:374/14)
+
+* Forwarded by Christopher Baker on 1:374/14, Rights On! in Titusville FL
+
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-04 (Sun, 4 Oct 92 14:46:44 PDT) - PGP echo conference... - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/5a6dd973fa99c3132334dbee22436ea38bfc60a674aea9f3847d204c2054988b.md b/_emails/1992/10/5a6dd973fa99c3132334dbee22436ea38bfc60a674aea9f3847d204c2054988b.md
new file mode 100644
index 0000000000..ea5973421f
--- /dev/null
+++ b/_emails/1992/10/5a6dd973fa99c3132334dbee22436ea38bfc60a674aea9f3847d204c2054988b.md
@@ -0,0 +1,81 @@
+---
+layout: default
+---
+
+# 1992-10-11 - Re: +-=*^
+
+## Header Data
+
+From: George A. Gleason \
+To: hughes@soda.berkeley.edu
+Message Hash: 5a6dd973fa99c3132334dbee22436ea38bfc60a674aea9f3847d204c2054988b
+Message ID: \<199210110757.AA22987@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-11 07:50:52 UTC
+Raw Date: Sun, 11 Oct 92 00:50:52 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Sun, 11 Oct 92 00:50:52 PDT
+To: hughes@soda.berkeley.edu
+Subject: Re: +-=*^
+Message-ID: <199210110757.AA22987@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Eric, good point about public keys and trust by association.
+
+More on OTPs.
+You say the key distribution problem for OTPs is "much worse" than for PKS
+and even other conventional ciphers. "Much worse" in what ways? The need
+for F2F meetings with all possible correspondents is something which exists
+with conventional ciphers. The cost of key storage is trivial: a fraction
+of the cost of the yearly (or less frequent) travel to meet each
+correspondent in person. Consider replaceable hard drive cartridges (30 meg
+for about a buck a meg), digital cassette formats including applications
+involving videocassettes, and so on. Yes, as you say, you have to exchange
+keys each time you run out of key; but you can keep ten years' with of key
+(error: "worth" not "with") on hand if you like, taking up less physical
+space than a box of cookies.
+
+"Bandwidth required is much higher..." In what way? Certainly not in terms
+of transmission; a stream cipher is a stream cipher. Perhaps in that each
+plaintext character requires one key character? This is just another
+formulation of the "storage" issue: and again, if you have a stack of 30MB
+cartridges, who cares? Not like we're talking about punched paper tape.
+
+I do agree that PKS offer convenience and features not available with
+conventional ciphers. However, RSA is just one mathematical breakthrough
+away from being obsolete, and we have no way of knowing when that
+breakthrough occurs. It may also be that massively parallel processors can
+be built through VLSI technology, allowing the cost of brute force solutions
+to come down to a reasonable level.
+
+All of this is not by way of getting down on PKS. I would suggest that we
+need a number of different systems, and need to keep them all in fairly
+constant use. I think we're already all in agreement that one of those
+systems should be RSA-based. Now I'm just suggesting that a One-Time system
+should be another one among the many.
+
+BTW, sorry I couldn't make today's meeting; various local tasks demanding
+attention; plus physical travel distance. Be back next time...
+
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-11 (Sun, 11 Oct 92 00:50:52 PDT) - Re: +-=*^ - _George A. Gleason \_
+ + 1992-10-11 (Sun, 11 Oct 92 11:52:00 PDT) - [one time pads](/years/1992/10/8236d653b8591abe4a4138bcd063e84c62d1551b1b3dd16fc430ea7f2987a312) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/5b1307bd6cd1d82f9aa5be1dab1a9e600468004448045f679d3a9d79b651d00d.md b/_emails/1992/10/5b1307bd6cd1d82f9aa5be1dab1a9e600468004448045f679d3a9d79b651d00d.md
new file mode 100644
index 0000000000..516c348cfe
--- /dev/null
+++ b/_emails/1992/10/5b1307bd6cd1d82f9aa5be1dab1a9e600468004448045f679d3a9d79b651d00d.md
@@ -0,0 +1,49 @@
+---
+layout: default
+---
+
+# 1992-10-27 - Re: Registering Keys with Big Brother
+
+## Header Data
+
+From: hkhenson@cup.portal.com
+To: cypherpunks@toad.com
+Message Hash: 5b1307bd6cd1d82f9aa5be1dab1a9e600468004448045f679d3a9d79b651d00d
+Message ID: \<9210270726.1.5339@cup.portal.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-27 16:21:45 UTC
+Raw Date: Tue, 27 Oct 92 09:21:45 PPE
+
+## Raw message
+
+```
+{% raw %}From: hkhenson@cup.portal.com
+Date: Tue, 27 Oct 92 09:21:45 PPE
+To: cypherpunks@toad.com
+Subject: Re: Registering Keys with Big Brother
+Message-ID: <9210270726.1.5339@cup.portal.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+One consequence of this proposal would be the capturing of *all* email
+traffic for (possible) subsequent decryption under a court order. After
+all, how could you complain? They couldn't read your messages of the
+last ten years unless they happened to get a court order. Knowing how
+easy it is to get a pliant judge to issue an order, this would be
+really chilling. Keith Henson
+
+(on the other hand, the media makers would love it.)
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-27 (Tue, 27 Oct 92 09:21:45 PPE) - Re: Registering Keys with Big Brother - _hkhenson@cup.portal.com_
+
diff --git a/_emails/1992/10/5bfc6f1533c89245e1861fdcc31a7a4307361eff7c89a023613b9c6ea4e70b48.md b/_emails/1992/10/5bfc6f1533c89245e1861fdcc31a7a4307361eff7c89a023613b9c6ea4e70b48.md
new file mode 100644
index 0000000000..d6baf94911
--- /dev/null
+++ b/_emails/1992/10/5bfc6f1533c89245e1861fdcc31a7a4307361eff7c89a023613b9c6ea4e70b48.md
@@ -0,0 +1,57 @@
+---
+layout: default
+---
+
+# 1992-10-25 - re: Re: pgp key distribution
+
+## Header Data
+
+From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+To: cypherpunks@toad.com
+Message Hash: 5bfc6f1533c89245e1861fdcc31a7a4307361eff7c89a023613b9c6ea4e70b48
+Message ID: \<3270.2AEAFD74@fidogate.FIDONET.ORG\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 20:08:18 UTC
+Raw Date: Sun, 25 Oct 92 13:08:18 PPE
+
+## Raw message
+
+```
+{% raw %}From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
+Date: Sun, 25 Oct 92 13:08:18 PPE
+To: cypherpunks@toad.com
+Subject: re: Re: pgp key distribution
+Message-ID: <3270.2AEAFD74@fidogate.FIDONET.ORG>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+ U> From: shipley@tfs.COM (Peter Shipley)
+ U> I maintain two public rings one is a collection I have
+ U> collected via direct contact (friends mostly) the other is
+ U> jyanowitz's list plus random other rings).
+
+I'm surprised by the number of people who, when they receive a key in
+the mail, certify it themselves. I leave mine also uncertified unless
+I got it directly. I don't sign nuttin.
+
+--- ReadMail
+ * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
+--
+Tom Jennings - via FidoNet node 1:125/555
+ UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
+INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sun, 25 Oct 92 13:08:18 PPE) - re: Re: pgp key distribution - _Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)_
+
diff --git a/_emails/1992/10/5c2f84179577fcc3c81253c80f2a075abdf82bb25a406786635763a78f143b8f.md b/_emails/1992/10/5c2f84179577fcc3c81253c80f2a075abdf82bb25a406786635763a78f143b8f.md
new file mode 100644
index 0000000000..16bbf81ffa
--- /dev/null
+++ b/_emails/1992/10/5c2f84179577fcc3c81253c80f2a075abdf82bb25a406786635763a78f143b8f.md
@@ -0,0 +1,123 @@
+---
+layout: default
+---
+
+# 1992-10-04 - Nuts & Acorns
+
+## Header Data
+
+From: Secret_Squirrel@Treehouse.ORG
+To: cypherpunks@toad.com
+Message Hash: 5c2f84179577fcc3c81253c80f2a075abdf82bb25a406786635763a78f143b8f
+Message ID: \<9210040546.AA10254@atdt.org\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-04 05:38:36 UTC
+Raw Date: Sat, 3 Oct 92 22:38:36 PDT
+
+## Raw message
+
+```
+{% raw %}From: Secret_Squirrel@Treehouse.ORG
+Date: Sat, 3 Oct 92 22:38:36 PDT
+To: cypherpunks@toad.com
+Subject: Nuts & Acorns
+Message-ID: <9210040546.AA10254@atdt.org>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+To: Tom Jennings
+
+>>
+Doesn't this imply that the unencrypted message would have to travel
+from the originator to the server? Or do you mean to send to X I'd
+request X's public key from the server, then encrypt, etc?
+<<
+
+Not at all. In its simplest form: We'd have a single
+secure-IRC-server. It would have its own public key, which ever
+secure-IRC-client would know. When I want to send a secure
+broadcast msg, I type it, my client encrypts it with the public key of
+the secure-IRC-server, and transmits it. The server picks it up,
+decrypts it in memory, then re-encrypts that original msg with the
+public key of each paritxxx participant in the particular room I'm in.
+So, if there are ten participants in the room, and I want all of them
+to know something, but not anyone else who might be tapping ixxx wires
+or catching packets somewhere in the ether, then I'd send a single
+broadcast msg to the server; the server would end up sending ten
+differently encrypted msgs -- one to each participant, encrypted with
+each of the participants' public keys (which the secure-irc-server
+would have to maintain; it would function as a key-server.)
+
+To send a private msg across the secure-IRC, I'd indicate that it was
+a "/msg", the recipeixxx recipient, and again, encrypt it with the
+public key of the server. The server would learn who the recipient
+was, and rebroadcast my message to that person, in that person's
+public key.
+
+>>
+I am considering becoming and "introducer" for parts of FidoNet. I
+can't seem to get past the problems of how to assign reliability to
+public keys I receive over an unsecured email channel to begin with.
+No other method is practical.
+<<
+
+Huh? I don't understand what you're pointing out. If I send you my
+public key -- even if I cc: dockmaster -- what does it matter that the
+NSA knows my public key (unoless they want to send me msgs, too)? The
+key itself is inherantly secure. Let your users decide on their
+public keys and register those keys with your key server. Not the
+other way around. Course, there's always the Kandinsky-Ogorov method
+of key exchange.
+
+To: St. Jude
+
+>>
+The bacteriophage virus replicates itself by injecting its own
+information into an existing system. The more copies of the phage,
+the worse for the bacteria etc etc.
+SO: in private, the planning, the designing, the coding...
+for public distribution as widely as possible. If the technology is
+intrinsically transformative, and if the process of distribution is
+engaging, even exciting, the revolution is next tuesday.
+<<
+
+Providing the numbe r of cells you have access to and can anticipate
+influencyxxx incxxx influencing is large enough, and it isn't.
+
+Anyway, look, let's put our words into action. What makes code
+(programming, I mean) didxxx different from spoken language? The fact
+that you can communicate with a machine, and it will _act_ on what you
+say, no matter what. Theres beauty and there's magic in that. (And
+some of us have the same effect on people that we have on machines.
+;-)) Instead of talking about all this, let's start doing it. What
+did I read the other day? "Hackers go where Angels fear to tread"?
+Let's have more ideas. This hopping remailer is exciting. So is
+passive encryption of electronic communications. When are we going
+totart xxx to start effecting de facto standards here? Once we start
+encrypting everything, then what? What do we do with this new tool?
+Communication of any kind (especially encrypted communication)
+presupposs that there are messages to be exchanged -- _ideas_! More
+ideas and less chatter.
+
+How can we have a revolution if we don't even know what we're trying
+to bring about? Maybe I was out of the loop. Maybe I was attending
+an Army/Navy game that day, but I don't know what we're trying to do
+here, exactly. What is this "revolution"?
+
+-- $33kr1t $kwurl.
+ K.R.A.P. (K-Rad. A.SCII P.Ossee)
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-04 (Sat, 3 Oct 92 22:38:36 PDT) - Nuts & Acorns - _Secret_Squirrel@Treehouse.ORG_
+ + 1992-10-05 (Sun, 4 Oct 92 19:51:17 PDT) - [introducers](/years/1992/10/9fc2028c643b11c13f6a26db39c8f6ce982be8753abdc307ed78ccbe14020521) - _Eric Hughes \_
+
diff --git a/_emails/1992/10/5d5b98b544ddca1167fefcf884fb753cc1d761f014b8e779949d089d9d8109ee.md b/_emails/1992/10/5d5b98b544ddca1167fefcf884fb753cc1d761f014b8e779949d089d9d8109ee.md
new file mode 100644
index 0000000000..28befab1f8
--- /dev/null
+++ b/_emails/1992/10/5d5b98b544ddca1167fefcf884fb753cc1d761f014b8e779949d089d9d8109ee.md
@@ -0,0 +1,61 @@
+---
+layout: default
+---
+
+# 1992-10-15 - Re: one time pads
+
+## Header Data
+
+From: George A. Gleason \
+To: gnu@toad.com
+Message Hash: 5d5b98b544ddca1167fefcf884fb753cc1d761f014b8e779949d089d9d8109ee
+Message ID: \<199210150922.AA09387@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-15 09:23:21 UTC
+Raw Date: Thu, 15 Oct 92 02:23:21 PDT
+
+## Raw message
+
+```
+{% raw %}From: George A. Gleason
+Date: Thu, 15 Oct 92 02:23:21 PDT
+To: gnu@toad.com
+Subject: Re: one time pads
+Message-ID: <199210150922.AA09387@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Re. your point about security and burglary. An intruder could copy a
+one-time pad, but of course an intruder can also copy the private key to an
+RSA system as well. I'll admit that physical key control is easier with
+public key systems: one just keeps one's key disc in one's personal
+possession at all times, and keeps a couple of backup copies in the hands of
+close trusted friends or family who understand and will take equal
+precautions. One could also design physical storage media which are
+intrusion resistant in the sense of self-destructing if tampered with or fed
+the wrong password; these would work as well for OTP keys as for RSA keys.
+
+In some conceivable applications, physical security can be insured as a
+matter of the vital interests of the participants.
+
+Again, I'm by no means trying to suggest that OTPs be considered for
+particularly wide application. Rather, that OTPs and a range of other
+systems be designed, implemented, and made available so that potential users
+can make their own informed choices.
+-gg
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-15 (Thu, 15 Oct 92 02:23:21 PDT) - Re: one time pads - _George A. Gleason \_
+ + 1992-10-16 (Thu, 15 Oct 92 17:08:10 PDT) - [Re: one time pads](/years/1992/10/6d1555d9ba7e7f5df99b0b1e6d959204e559a393d247f7263b6320400b221fe9) - _Eric Hollander \_
+ + 1992-10-16 (Thu, 15 Oct 92 18:03:41 PDT) - [Re: one time pads](/years/1992/10/12bc0f85f9a646add4c5603e08fe8e538363c6c8b9aa6e63490461eea74314a6) - _Peter Shipley \_
+
diff --git a/_emails/1992/10/5e5c033140b4a529047d8d51ff66f6cc0ca5ca290b0c7dadde8b5c0691e8f26f.md b/_emails/1992/10/5e5c033140b4a529047d8d51ff66f6cc0ca5ca290b0c7dadde8b5c0691e8f26f.md
new file mode 100644
index 0000000000..44253f0663
--- /dev/null
+++ b/_emails/1992/10/5e5c033140b4a529047d8d51ff66f6cc0ca5ca290b0c7dadde8b5c0691e8f26f.md
@@ -0,0 +1,459 @@
+---
+layout: default
+---
+
+# 1992-10-24 - ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill
+
+## Header Data
+
+From: fen@netcom.com (Fen Labalme)
+To: jjaloszyns@bluejay.mich.fred.org
+Message Hash: 5e5c033140b4a529047d8d51ff66f6cc0ca5ca290b0c7dadde8b5c0691e8f26f
+Message ID: \<9210242007.AA14367@netcom.netcom.com\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-24 20:09:09 UTC
+Raw Date: Sat, 24 Oct 92 13:09:09 PDT
+
+## Raw message
+
+```
+{% raw %}From: fen@netcom.com (Fen Labalme)
+Date: Sat, 24 Oct 92 13:09:09 PDT
+To: jjaloszyns@bluejay.mich.fred.org
+Subject: ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill
+Message-ID: <9210242007.AA14367@netcom.netcom.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+The following is the latest version of the FBI Digital Telephony
+Proposal, introduced in May 1992. This version removes the previous
+language that authorized the FCC to set standards and now places it
+solely in the hands of the Attorney General. Fines are $10,000/day for
+non compliance with services within the public switched network having
+18 months to comply and services outisde having three years. The
+proposal now manadates that the capability for remote government
+wiretapping must be included into the system.
+
+This proposal clearly enhances the ability of the FBI to monitor
+communications. It takes the unprecendented step of placing control
+over certification of telecommunications equipment in the hands of the
+Attorney General and requires that the equipment be constucted to allow
+government have the ability to monitor communications from a
+"government monitoring facility remote from the target facility." All
+telecommunications users should be concerned by the privacy and
+security implications of creating systems that have holes for the
+government or any other knowledgable user to plug into.
+
+
+102nd Congress
+ 2nd Session
+
+ S. _____
+ [H.R. _____]
+
+ IN THE SENATE
+ [IN THE HOUSE OF REPRESENTATIVES]
+
+
+M. ________________ introduced the following bill; which was
+referred to the Committee on__________________
+
+
+A BILL
+
+
+To ensure the continuing access of law enforcement to the content of
+wire and electronic communications when authorized by law and for other
+purposes.
+
+Be it enacted by the Senate and the House of Representatives of the
+United States of America in Congress assembled,
+
+
+SEC. 1. FINDINGS AND PURPOSES.
+ (a) The Congress finds:
+ (1) that telecommunications systems and networks are often used in
+the furtherance of criminal activities including organized crime,
+racketeering, extortion, kidnapping, espionage, terrorism, and
+trafficking in illegal drugs;
+ (2) that recent and continuing advances in telecommunications
+technology, and the introduction of new technologies and transmission
+modes by the telecommunications industry, have made it increasingly
+difficult for government agencies to implement lawful orders or
+authorizations to intercept wire and electronic communications and thus
+threaten the ability of such agencies effectively to enforce the laws
+and protect the national security; and
+ (3) that without the assistance and cooperation of providers of
+electronic communication services and private branch exchange
+operators, the introduction of new technologies and transmission modes
+into telecommunications systems without consideration and accommodation
+of the need of government agencies lawfully to intercept wire and
+electronic communications would impede the ability of such agencies
+effectively to carry out their responsibilities.
+ (b) The purposes of this Act are to clarify the responsibilities
+of providers of electronic communication services and private branch
+exchange operators to provide such assistance as necessary to ensure
+the ability of government agencies to implement lawful court orders or
+authorizations to intercept wire and electronic communications.
+
+SEC. 2.
+ (a) Providers of electronic communication services and private
+branch exchange operators shall provide within the United States
+capability and capacity for the government to intercept wire and
+electronic communications when authorized by law:
+ (1) concurrent with the transmission of the communication to the
+recipient of the communication;
+ (2) in the signal form representing the content of the
+communication between the subject of the intercept and any individual
+with whom the subject is communicating, exclusive of any other signal
+representing the content of the communication between any other
+subscribers or users of the electronic communication services provider
+or private branch exchange operator, and including information on the
+individual calls (including origin, destination and other call set-up
+information), and services, systems, and features used by the subject
+of the interception;
+ (3) notwithstanding the mobility of the subject of the intercept
+or the use by the subject of the intercept of any features of the
+telecommunication system, including, but not limited to, speed- dialing
+or call forwarding features;
+ (4) at a government monitoring facility remote from the target
+facility and remote from the system of the electronic communication
+services provider or private branch exchange operator;
+ (5) without detection by the subject of the intercept or any
+subscriber; and
+ (6) without degradation of any subscriber's telecommunications
+service.
+ (b) Providers of electronic communication services within the
+public switched network, including local exchange carriers, cellular
+service providers, and interexchange carriers, shall comply with
+subsection (a) of this section within eighteen months from the date of
+enactment of this subsection.
+ (c) Providers of electronic communication services outside of the
+public switched network, including private branch exchange operators,
+shall comply with subsection (a) of this section within three years
+>from the date of enactment of the subsection.
+ (d) The Attorney General, after consultation with the Department
+of Commerce, the Small Business Administration and Federal
+Communications Commission, as appropriate, may except from the
+application of subsections (a), (b) and (c) of this section classes and
+types of providers of electronic communication services and private
+branch exchange operators. The Attorney General may waive the
+application of subsections (a), (b) and (c) of this section at the
+request of any provider of electronic communication services or private
+branch exchange operator.
+ (e) The Attorney General shall have exclusive authority to
+enforce the provisions of subsections (a), (b) and (c) of this section.
+The Attorney General may apply to the appropriate United States
+District Court for an order restraining or enjoining any violation of
+subsection (a), (b) or (c) of this section. The District Court shall
+have jurisdiction to restrain and enjoin violations of subsections (a)
+of this section.
+ (f) Any person who willfully violates any provision of subsection
+(a) of this section shall be subject to a civil penalty of $10,000 per
+day for each day in violation. The Attorney General may file a civil
+action in the appropriate United States District Court to collect, and
+the United States District Courts shall have jurisdiction to impose,
+such fines.
+ (g) Definitions--As used in subsections (a) through (f) of this
+section--
+ (1) 'provider of electronic communication service' or 'private
+branch exchange operator' means any service or operator which provides
+to users thereof the ability to send or receive wire or electronic
+communication, as those terms are defined in subsections 2510(1) and
+2510(12) of Title 18, United States code, respectively, but does not
+include the government of the United States or any agency thereof;
+ (2) 'communication' means any wire or electronic communication,
+as defined in subsections 2510(1) and 2510(12), of Title 18, United
+States Code;
+ (3) 'intercept' shall have the same meaning as set forth in
+section 2510(4) of Title 18, United States Code; and
+ (4) 'government' means the Government of the United States and
+any agency or instrumentality thereof, any state or political
+subdivision thereof, the District of Columbia, and any commonwealth,
+territory or possession of the United States.
+
+DIGITAL TELEPHONY AND INTERCEPTION BY CRIMINAL LAW ENFORCEMENT AGENCIES
+ The telecommunications systems and networks are often used to
+further criminal activities including white collar and organized crime,
+racketeering, extortion, kidnapping, espionage, terrorism, and
+trafficking in illegal drugs. Accordingly, for many years, one of the
+most important tools in the investigation of crime for Federal and
+State criminal law enforcement agencies has been the court authorized
+interception of communications. As illustrated below, the majority of
+original authorizations to intercept wire or electronic communications
+are conducted by State criminal law enforcement agencies.
+
+ Interception Applications Authorized
+ State Federal Total
+1984 512 289 801
+1985 541 243 784
+1986 504 250 754
+1987 437 236 673
+1988 445 293 738
+1989 453 310 763
+1990 548 324 872
+Total 3440 1945 5385
+
+ Approximately, 3/8 of authorized interceptions were conducted by
+Federal agencies, while 5/8 of the authorized interceptions were
+conducted by State criminal law enforcement agencies.1
+ The recent and continuing advances in telecommunications
+technology, and the introduction of new technologies by the
+telecommunications industry, have made it increasingly difficult for
+government agencies to implement lawful orders or authorizations to
+intercept wire and electronic communications, as well as to implement
+pen register and trap-and-trace court orders or authorizations. These
+new technologies inadvertently undermine the ability of criminal law
+enforcement agencies to enforce effectively the criminal laws and
+protect the national security. Without the assistance and cooperation
+of the telecommunications industry, these new technologies will impede
+the ability of the telecommunications industry, these new technologies
+will impede the ability of the government to enforce the criminal law.
+Accordingly, the purpose of this bill is to clarify the existing
+responsibilities of electronic communication services providers and
+private branch exchange operators, as established, for example, in 18
+U.S.C. ____ 2518(4), 3124(A), (B), to provide such assistance as
+necessary to ensure the ability of government agencies to implement
+lawful orders or authorizations to intercept communications.
+ Over the past twenty-five years, the working relationship between
+the criminal law enforcement community, particularly the Federal Bureau
+of Investigation as the federal government's primary criminal law
+enforcement agency, and the telecommunications industry, in response to
+the appropriate court orders or authorizations, has provided government
+agencies with timely access to the signals containing the content of
+communications covered by the court orders or authorizations. As a
+general proposition, this has involved providing the means to acquire
+the communication as it occurs between two individual telephone users
+at a remote location, not dissimilar to a call in which the two
+originating parties do not know that a third party is listening, and in
+which the third party (the criminal law enforcement agency) records the
+authorized and relevant calls.
+ Historically, and with relatively few exceptions, the
+telecommunications industry has provided the criminal law enforcement
+community with the ability to monitor and record calls:
+
+ 1. at the same time asthe call is transmitted to the recipient;
+
+ 2. in the same form as the content of the call was transmitted
+through the network, notwithstanding the use by the target of custom
+features of the network;
+
+ 3. whether stationary or mobile;
+
+ 4. at the government monitoring facility;
+
+ 5. without detection by the target or other subscribers; and
+without degrading any subscriber's service.
+
+ However, the introduction of new technology has begun to erode the
+ability of the government to fully effectuate interceptions, pen
+registers and trap-and-race court orders or authorizations that are
+critical to detecting and prosecuting criminals. As technology has
+developed, the telecommunications industry has not always ensured the
+continued ability to provide the same services to the criminal law
+enforcement community. The telecommunications industry's introduction
+of certain types of new technology poses real problems for effective
+criminal law enforcement. Legislation is necessary to ensure that the
+government will be provided with this capability and capacity in the
+future by all providers and operators and to maintain a level playing
+field among competitive providers and operators in the
+telecommunications industry.
+
+ There have been instances in which court orders authorizing the
+interception of communications have not been fulfilled because of
+technical limitations within particular telecommunications networks.
+For example, as early as 1986, limited capabilities became apparent in
+at least one network which will only be corrected later in 1992. This
+technical deficiency in a new technology forced criminal law
+enforcement agencies to prioritize certain interceptions to the
+exclusion of other court orders. Accordingly, for approximately six
+years, there have been court orders that have not been sought by the
+criminal law enforcement community or executed by the
+telecommunications industry and, as a consequence, important criminal
+investigations have not been brought to fruition or have been less than
+efficiently concluded. This is one classic example of new technology
+affecting adversely the criminal law enforcement community: a
+microcosm of what may be expected on a nationwide basis without
+enactment of this legislation.
+ Section 1 of the bill states Congressional findings and purpose.
+ Section 2 is divided into seven subsections.. Subsection (a)
+establishes as a matter of law the responsibility of electronic
+communication services providers and private branch exchange operators
+to continue to provide, within the United States, the capability and
+capacity for criminal law enforcement agencies to intercept wire and
+electronic communications when authorized by law. These subsections
+delineate the existing attributes of wire or electronic communication
+interception.
+ 1. Concurrent with Transmission. The application for a court order
+to intercept telecommunications conversations or data transmissions is
+rarely a leisurely process. For example, on the Federal side, the
+development of the required affidavits, submission to the Criminal
+Division of the Department of Justice for approval, transmission of
+approval to the Assistant United States Attorney, the appearance of the
+Assistant before a judge to request the order and the delivery of the
+judge's order to the appropriate telecommunications company is
+frequently completed in a very short time. However, crime waits for no
+one and the system for approval of interceptions must and does conform
+with the realities of the activity that is sought to be investigated
+and, if appropriate, prosecuted as criminal offenses. Since time is of
+the essence, current law requires that service providers and operators
+provide the government forthwith all information, facilities and
+technical assistance necessary to accomplish its mission. It is
+critical that the telecommunications industry respond quickly to
+execute the court order or authorization. The ultimate problem of
+timeliness, however, is the real-time monitoring of the intercepted
+communications. As serious and potentially life- threatening criminal
+conduct is detected, it may be necessary to move quickly to protect
+innocent victims from that conduct. Accordingly, "real-time"
+monitoring is critical.
+ 2. Isolated Signal and Services Used. Nearly all of the
+communications network is partially "analog" at this time. In
+conducting an interception, for example, of a telephone conversation,
+the government is allowed to monitor and record criminal conversation
+such as a conspiracy, minimizing the acquisition of non-criminal or
+innocent conversation. When an electronic communication services
+provider or private branch exchange operator introduces a new
+technology--such as a digital signal--the communications are converted
+into a different and more efficient form for transmission, but a more
+difficult form to monitor during interception. The bill requires only
+that the provider or operator isolate and provide access to the
+electronic signal that represents the content of the communications of
+the target of the intercept2 from the stream of electronic signals
+representing other communications. This provision seeks to ensure
+that, in the new electronic environment in which signals are mixed for
+transmission and separated at another switch for distribution, the
+government does not receive the communications of any individual other
+than the individuals using the target's communications point of origin
+and receipt; the government must remain subject to the minimization
+standards of 18 U.S.C. __ 2518(5).
+ This provision also makes it clear that an electronic
+communication services provider or private branch exchange operator is
+not required to provide for reconversion of the isolated communication
+to analog or other form. The government expects that this process will
+be accomplished by the government.
+ 3. Mobility and Features. Increasingly, criminal acts are being
+conducted or discussed over cellular telephones or by using special
+telecommunications features. As this mobility is introduced, the
+electronic communication services providers and private branch exchange
+operators would be required to assure the capability and capacity for
+criminal law enforcement agencies to continue lawful interception.
+ Further, this subsection makes it clear that features used by the
+target do not defeat the court order or authorization. For example,
+communications which have been addressed to the telephone number of the
+target, but which may have been programmed through a call-forwarding
+feature to another, otherwise innocent, telephone number, must be
+captured and made available to criminal law enforcement authorities
+pursuant to court order or authorization. This requirement will
+obviate the need for applications for authority to monitor otherwise
+innocent telephone numbers that receive, only intermittently, calls
+forwarded by the target. The effect of this provision is to further
+minimize monitoring of calls of innocent parties. Similarly, certain
+speed dialing features that mask the telephone number called by the
+target must be identified for criminal law enforcement investigation.
+The ability to consistently determine the destination of calls is
+critical to minimizing the monitoring of innocent calls.
+ 4. Government Monitoring Facility. Government agencies do not
+normally request the use of telecommunications industry physical
+facilities to conduct authorized interceptions nor is it encourage by
+the industry. Normally, the government leases a line from the
+electronic communication services provider's or private branch exchange
+operator's switch to another location owned or operated by the
+government. This minimizes the cost and intrusiveness of
+interceptions, which benefits the service provider or operator, as well
+as the government. Accordingly, the ability to monitor intercepted
+communications remotely is critical.
+ 5. Without Detection. One of the reasons that governments operate
+their own facilities is to reduce the risk of detection of the
+interception, which would render the interception worthless. At the
+present time, the existence of an interception is unknown to any
+subscriber and is not detectable by the target, notwithstanding
+folklore and spy novels. This provision merely ensures that the
+secrecy of effective interceptions will be maintained.
+ 6. Without Degradation. Maintaining the quality of the telephone
+network is in the interest of the government, the industry and the
+public. Presently, the existence of an interception has no effect on
+the quality of the service provided by any network to the target or any
+subscriber. This provision ensures that the quality of the network
+will continue to be uncompromised. Absent the assistance delineated by
+this legislation, the execution of court orders and authorizations by
+the government could well disrupt service of the newer technological
+systems, a result that this legislation seeks to avoid.
+ Subsection (b) provides that electronic communication services
+providers and private branch exchange operators with the "public
+switched network" must be in compliance with the minimum intercept
+attributes within eighteen months after enactment. Thereafter, new
+technologies must continue to meet these minimum attributes.
+ Subsection (c) provides that electronic communication service
+providers and private branch exchange operators that are not within the
+"public switched network" must be in compliance with the minimum
+intercept attributes within eighteen months after enactment.
+Thereafter, new technologies must continue to meet these minimum
+attributes.
+ Subsection (d) provides that the Attorney General may grant
+exceptions to the affirmative requirements of subsection (a), as well
+as the implementation deadlines of subsections (b) and (c). In
+considering any request for exception, the Attorney General will
+consult with Federal Communications Commission, the Small Business
+Administration and the Department of Commerce, as appropriate.
+Accordingly, the Attorney General has the authority to except, for
+example, whole classes, categories or types of private branch exchange
+operators where no serious criminal law enforcement problems are likely
+to arise, such as hospital telephone systems.
+ This subsection also permits the Attorney General to waive the
+requirements of subsections (a), (b) and (c) on application by an
+electronic communication services provider or private branch exchange
+operator. Accordingly, if a particular company can not comply with one
+or more of the requirements of subsection (a), or needs time additional
+to that permitted under subsections (b) or (c), the Attorney General
+may grant an appropriate waiver.
+ Subsection (e) provides that the Attorney General has exclusive
+authority to enforce the provisions of the bill. While a number of
+States have authority to seek and execute interception orders, they
+will be required to seek the assistance of the Attorney General if
+enforcement of this legislation is required. This section also
+provides for injunctive relief from violations of the provisions of the
+bill.
+ Subsection (f) provides for enforcement of the provisions of the
+bill through imposition of civil fines against any company that is not
+excepted from the provisions of the bill, does not acquire a waiver of
+the provisions of the bill, and fails to meet the requirements of
+subsection (a) after the effective dates set out in subsection (b) or
+(c), as appropriate. A fine of up to $10,000 per day for each day in
+violation may be levied; for most companies in the telecommunications
+industry this amount is sufficient to ensure that compliance will be
+forthcoming. Although this provision is not expected to be used, it is
+critical to ensure that compliance with the provisions of the bill will
+occur after the effective dates of the requirements of subsection (a).
+ Subsection (g) carries forward a number of definitions from the
+current provisions for the interception of wire or electronic
+communications under "Title III." The definition of "government" that
+is currently in use includes all States, territories and possessions of
+the United States, as well as the United States, is made applicable to
+the bill.
+
+ [Footnotes] 1Interceptions for foreign intelligence and
+counterintelligence purposes are not counted within the figures used
+here, but would likewise benefit from enactment of the legislation.
+
+ 2 Whether the content is voice, facsimile, imagery (e.g. video),
+computer data, signalling information, or other forms of communication,
+does not matter; all forms of communication are intercepted.
+
+
+
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-24 (Sat, 24 Oct 92 13:09:09 PDT) - ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill - _fen@netcom.com (Fen Labalme)_
+
diff --git a/_emails/1992/10/5f88f40e56048dc684e34fc31f79e7a1a73f66a8cecc1c82fe0173e912f60644.md b/_emails/1992/10/5f88f40e56048dc684e34fc31f79e7a1a73f66a8cecc1c82fe0173e912f60644.md
new file mode 100644
index 0000000000..4a92a1dfda
--- /dev/null
+++ b/_emails/1992/10/5f88f40e56048dc684e34fc31f79e7a1a73f66a8cecc1c82fe0173e912f60644.md
@@ -0,0 +1,175 @@
+---
+layout: default
+---
+
+# 1992-10-26 - entropy, with code
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 5f88f40e56048dc684e34fc31f79e7a1a73f66a8cecc1c82fe0173e912f60644
+Message ID: \<9210261958.AA28999@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-26 19:58:58 UTC
+Raw Date: Mon, 26 Oct 92 12:58:58 PPE
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Mon, 26 Oct 92 12:58:58 PPE
+To: cypherpunks@toad.com
+Subject: entropy, with code
+Message-ID: <9210261958.AA28999@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+The entropy-calculating code is at the end of this message. I took
+the opportunity to calculate some sample entropies:
+
+entropy.c 5.283772 the source code
+entropy.asc 6.052222 entropy.c, encrypted and armored
+entropy.as2 6.012493 entropy.asc, with the wrappers removed
+entropy.pgp 7.830532 entropy.c, encrypted alone
+entropy.obj 6.112890
+entropy.exe 6.947111
+randseed.bin 4.584963 from pgp, 24 bytes long
+pubring.pgp 7.754017 my public key ring
+
+The entropy of the source code is in the high end of the range for
+English, which is not surprising given the amount of symbols in
+ordinary C code. The entropy increases with the object and the
+executable, each of which has less overt structure to it.
+
+The entropy of the encrypted and ascii armored source code is within
+1% of 6 bits, just as predicted. And with the wrappers removed, it's
+even closer! The binary version of the encrypted message has the
+highest entropy of all these tests.
+
+In randseed.bin, the entropy is much less than 8. But the length of
+the file is 24 bytes and log_2 24 = 4.584963, indicating that there
+are no duplicate bytes in the file. Hence the warning: entropy
+calculations with small samples _will_ be misleading.
+
+Note that the entropy subroutine can be used to calculate the
+frequencies of any distribution. This will allow all you code-writing
+cypherpunks to measure bit entropies, digram entropies, etc.
+
+Eric
+
+----------------------------------------------------------------
+
+/* entropy.c -- Calculate monogram entropies of standard input.
+ */
+
+#include
+#include
+
+/* This next define is to counteract the foolish C 7.00 runtime mapping
+ * of \x1A to EOF
+ */
+#define STUPID_NEWLINE_TRANSLATE 1
+
+#ifdef STUPID_NEWLINE_TRANSLATE
+#include
+#include
+#endif
+
+/*--------------------------------------*/
+#define NUMBER_OF_BYTES 256
+long byte_freq[ NUMBER_OF_BYTES ] ;
+
+void
+main()
+{
+ int c, verbose = 0 ;
+ unsigned int j ;
+ double entropy( long *, int ) ;
+
+#if STUPID_NEWLINE_TRANSLATE
+ _setmode( _fileno( stdin ), _O_BINARY ) ;
+#endif
+
+ for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) {
+ byte_freq[ j ] = 0 ;
+ }
+
+ while ( EOF != ( c = getchar() ) ) {
+ ++ byte_freq[ (unsigned int) c ] ;
+ }
+
+
+ if ( verbose ) {
+ for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) {
+ printf( "%3d=%-3d ", j, byte_freq[ j ] ) ;
+ if ( j % 8 == 7 ) printf( "\n" ) ;
+ }
+ }
+
+ printf( "%lf\n", entropy( byte_freq, NUMBER_OF_BYTES ) ) ;
+}
+
+/*--------------------------------------*/
+/* Calculates the entropy of the distribution given in list v of n elements.
+ * The list v gives counts. v is summed, and frequencies are assigned
+ * as v[i]/sum(v).
+ *
+ * Uses the following definitions and identities:
+ * A = \Sum_{i=0}^{n-1} v_i
+ * p_i = v_i / A
+ * H = \Sum_{i} - p_i \log p_i
+ * = log A - 1/A \Sum_{i} v_i \log v_i
+ * lim_{x \rightarrow 0} x \log x = 0
+ */
+
+double
+entropy( long *v, int n )
+{
+ double h ;
+ long sum ;
+ int j ;
+
+ /* first sum the array
+ */
+ sum = 0 ;
+ for ( j = 0 ; j < n ; ++j ) {
+ sum += v[ j ] ;
+ }
+
+ /* next calculate the entropy function
+ */
+ h = 0 ;
+ for ( j = 0 ; j < n ; ++ j ) {
+
+ /* If the frequency is zero, the entropy contribution is zero
+ */
+ if ( v[ j ] == 0 ) continue ;
+
+ h -= v[ j ] * log( v[ j ] ) ;
+ }
+ h /= sum ;
+ h += log( sum ) ;
+
+ /* Now adjust the base of the logarithm to base 2
+ */
+ h /= log( 2 ) ;
+
+ return h ;
+}
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-26 (Mon, 26 Oct 92 12:58:58 PPE) - entropy, with code - _Eric Hughes \_
+
diff --git a/_emails/1992/10/5fa0f250472bd360334c049f5e4c79e03c0fba148b5bf1c3af96c0a158c8a265.md b/_emails/1992/10/5fa0f250472bd360334c049f5e4c79e03c0fba148b5bf1c3af96c0a158c8a265.md
new file mode 100644
index 0000000000..494af1d500
--- /dev/null
+++ b/_emails/1992/10/5fa0f250472bd360334c049f5e4c79e03c0fba148b5bf1c3af96c0a158c8a265.md
@@ -0,0 +1,97 @@
+---
+layout: default
+---
+
+# 1992-10-22 - Keystone
+
+## Header Data
+
+From: Eric Hughes \
+To: cypherpunks@toad.com
+Message Hash: 5fa0f250472bd360334c049f5e4c79e03c0fba148b5bf1c3af96c0a158c8a265
+Message ID: \<9210221550.AA23915@soda.berkeley.edu\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-22 15:51:19 UTC
+Raw Date: Thu, 22 Oct 92 08:51:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: Eric Hughes
+Date: Thu, 22 Oct 92 08:51:19 PDT
+To: cypherpunks@toad.com
+Subject: Keystone
+Message-ID: <9210221550.AA23915@soda.berkeley.edu>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+
+Re: adding D-H key exchange to PC software
+
+gnu@cygnus.com writes:
+>Given a working Unix implementation, it would be relatively easy to
+>add to the terminal program, if source code for any decent terminal
+>programs was available.
+
+But source code is not available. The trouble is that all the decent
+terminal programs for PC's are shareware or commercial (or were
+originally shareware and have become commercial). I too would like to
+know of any source-available PC terminal programs, but I suspect there
+are none because of the prevailing shareware culture.
+
+
+Re: getting an author to license D-H key exchange
+
+The reason this will not happen is not the bootstrapping problem
+(chicken/egg), but that there is no perceived value to an encrypted
+link. The sysop is already has access to everything on the dedicated
+machine and may even have a policy of scanning all messages. External
+hackers can't really get in because shell access isn't really done
+remotely. The only ones you are protecting against are people with a
+hard tap on the phone line itself. For most people, this is not a
+concern.
+
+Since there's no perceived value and since all the software would
+require license from RSADSI, it won't happen that way.
+
+
+Re: using a protocol layer
+
+avalon@coombs.anu.edu.au writes:
+>Rather than rewrite the terminal progs, why not rewrite the BIOS level
+>drivers and such ? (if its possible).
+
+That's not possible either. Most terminal programs write directly to
+the hardware. This is single-tasking, standardized hardware,
+remember, and the original BIOS interface for the serial port was
+totally unusable. Some communications programs use FOSSIL drivers,
+but many (if not most) terminal programs don't support it. (FOSSIL is
+a BIOS-level serial port interface description which could hooked into
+or rewritten to support a protocol.)
+
+
+Look, I wish all this stuff were in use. Everyone should encrypt all
+their communications links as a matter of policy. (That includes
+voice, and if you thought the PC terminal program bootstrapping was
+difficult ...) Let's move incrementally, though. If we can get
+people to at least encrypt all of their e-mail, that will be an
+excellent start.
+
+One incentive would be for the BBS operators to phase in a policy that
+they will accept no e-mail which is _not_ encrypted. Comments?
+
+Eric
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-22 (Thu, 22 Oct 92 08:51:19 PDT) - Keystone - _Eric Hughes \_
+
diff --git a/_emails/1992/10/60d1b2f0f20831fd96fd692a170a7aa95a29990b55449f837f7922ba22bb7d85.md b/_emails/1992/10/60d1b2f0f20831fd96fd692a170a7aa95a29990b55449f837f7922ba22bb7d85.md
new file mode 100644
index 0000000000..c6399a0d0f
--- /dev/null
+++ b/_emails/1992/10/60d1b2f0f20831fd96fd692a170a7aa95a29990b55449f837f7922ba22bb7d85.md
@@ -0,0 +1,128 @@
+---
+layout: default
+---
+
+# 1992-10-17 - Re: Game items...
+
+## Header Data
+
+From: Arthur Abraham \
+To: hh@soda.berkeley.edu
+Message Hash: 60d1b2f0f20831fd96fd692a170a7aa95a29990b55449f837f7922ba22bb7d85
+Message ID: \<199210170146.AA14728@well.sf.ca.us\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-17 01:46:46 UTC
+Raw Date: Fri, 16 Oct 92 18:46:46 PDT
+
+## Raw message
+
+```
+{% raw %}From: Arthur Abraham
+Date: Fri, 16 Oct 92 18:46:46 PDT
+To: hh@soda.berkeley.edu
+Subject: Re: Game items...
+Message-ID: <199210170146.AA14728@well.sf.ca.us>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+ Abortion Pill's Potential Use on Tumors
+ Adds to Debate Over U.S. Market Entree
+ ----
+ By Ron Winslow
+ Staff Reporter of The Wall Street Journal
+DD 10/12/92
+SO WALL STREET JOURNAL (J), PAGE B8
+LP LOS ANGELES -- Medical researchers are studying a potential new
+ * use for the controversial French abortion pill RU-486: treatment
+of
+ * benign brain tumors.
+ A large-scale clinical trial was launched at the University of
+ * Southern California last week to determine whether the drug
+ effectively slows or halts growth of meningiomas, tumors that
+occur
+ * on the surface of the brain and spinal cord.
+TX The answer won't be known for several years, but the study adds
+ another dimension to the debate over whether the drug, known as
+ mifepristone, should be allowed on the market in the U.S.
+ Rousell-Uclaf, its manufacturer, hasn't sought marketing approval
+in
+ the U.S. because of the heat of the political battle over
+abortion.
+ The study raises the possibility that a drug that could benefit
+some
+ patients won't become available because of a political dispute
+over
+ another application.
+ "There is a good chance there will be legitimate uses for this
+ drug outside of contraception and abortion," said Steven Grunberg,
+ an oncologist at the USC School of Medicine. "Whether U.S.
+ regulatory officials feel this will be sufficient for licensing
+will
+ be up to them."
+ A study published last week found the drug to be effective as a
+ contraceptive when taken shortly after sexual intercourse. It is
+ already used in France, the United Kingdom and Sweden to induce
+ abortions within the first nine weeks of pregancy.
+ Meningiomas account for 15% to 18% of all tumors in the central
+ nervous system, and while they are benign -- meaning that they
+don't
+ spread to other parts of the body -- their growth can lead to such
+ problems as seizures, blindness or paralysis. Most can be removed
+by
+ * surgery, but some grow so close to crucial brain structures that
+ surgery isn't possible.
+ Dr. Grunberg told reporters at a science writers' conference
+ sponsored by the American Medical Association that the large-scale
+ * trial of RU-486 for the tumors comes after a small pilot study of
+28
+ patients turned up encouraging, though not definitive results.
+ In the small study, eight patients experienced improvement in
+ * symptoms or had minor reduction in tumor size, according to brain
+ scans. In a few other patients, growth of the tumor stabilized
+after
+ treatment began. While not overwhelming evidence of effectiveness,
+ the results were nevertheless sufficient to persuade the Food and
+ Drug Administration to approve a large study that will involve 200
+ patients at several U.S. medical centers, and will be based at
+USC,
+ Dr. Grunberg said.
+ Results from the trial aren't expected for at least four years,
+ and based on current medical practice, only a small number of
+people
+ * would probably benefit from use of RU-486 in meningiomas. The
+study
+ might have broader impact by drawing attention to other potential
+ benefits of a drug that isn't available in the U.S. because its
+ primary application is to induce abortion.
+ Dr. Grunberg said the drug is also being studied as a treatment
+ for breast cancer, endometriosis and a disorder called Cushing's
+ disease, which is characterized by obesity and hypertension.
+Several
+ other trials have been approved by the FDA, he added, though none
+ has progressed as far as the meningioma study.
+ * He said his research team came upon RU-486 as a candidate for
+ treating meningiomas because the drug blocks the action of
+ progesterone, a hormone that appears to promote growth of the
+ tumors. "We didn't set out to make a political statement for
+ * RU-486," he said. "It just appeared to fill the bill for what
+we're
+ trying to do."
+
+********************************************************************
+snarf
+
+-a2.
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-17 (Fri, 16 Oct 92 18:46:46 PDT) - Re: Game items... - _Arthur Abraham \_
+
diff --git a/_emails/1992/10/6115ca8faf4522b00345f547f7092e8d3eb00e56e294c4e5b757d2dec8166589.md b/_emails/1992/10/6115ca8faf4522b00345f547f7092e8d3eb00e56e294c4e5b757d2dec8166589.md
new file mode 100644
index 0000000000..f6dbec7069
--- /dev/null
+++ b/_emails/1992/10/6115ca8faf4522b00345f547f7092e8d3eb00e56e294c4e5b757d2dec8166589.md
@@ -0,0 +1,564 @@
+---
+layout: default
+---
+
+# 1992-10-08 - Hammill on public key
+
+## Header Data
+
+From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+To: cypherpunks@toad.com
+Message Hash: 6115ca8faf4522b00345f547f7092e8d3eb00e56e294c4e5b757d2dec8166589
+Message ID: \<1439@eternity.demon.co.uk\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-08 08:04:18 UTC
+Raw Date: Thu, 8 Oct 92 01:04:18 PDT
+
+## Raw message
+
+```
+{% raw %}From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
+Date: Thu, 8 Oct 92 01:04:18 PDT
+To: cypherpunks@toad.com
+Subject: Hammill on public key
+Message-ID: <1439@eternity.demon.co.uk>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+ FROM CROSSBOWS TO CRYPTOGRAPHY: THWARTING THE STATE VIA
+ TECHNOLOGY
+
+ Given at the Future of Freedom Conference, November 1987
+
+
+ You know, technology--and particularly computer
+technology--has often gotten a bad rap in Libertarian cir-
+cles. We tend to think of Orwell's 1984, or Terry Gilliam's
+Brazil, or the proximity detectors keeping East Berlin's
+slave/citizens on their own side of the border, or the so-
+phisticated bugging devices Nixon used to harass those on
+his "enemies list." Or, we recognize that for the price of
+a ticket on the Concorde we can fly at twice the speed of
+sound, but only if we first walk thru a magnetometer run by
+a government policeman, and permit him to paw thru our be-
+longings if it beeps.
+
+ But I think that mind-set is a mistake. Before there
+were cattle prods, governments tortured their prisoners with
+clubs and rubber hoses. Before there were lasers for
+eavesdropping, governments used binoculars and lip-readers.
+Though government certainly uses technology to oppress, the
+evil lies not in the tools but in the wielder of the tools.
+
+ In fact, technology represents one of the most promis-
+ing avenues available for re-capturing our freedoms from
+those who have stolen them. By its very nature, it favors
+the bright (who can put it to use) over the dull (who can-
+not). It favors the adaptable (who are quick to see the
+merit of the new( over the sluggish (who cling to time-
+tested ways). And what two better words are there to de-
+scribe government bureaucracy than "dull" and "sluggish"?
+
+ One of the clearest, classic triumphs of technology
+over tyranny I see is the invention of the man-portable
+crossbow. With it, an untrained peasant could now reliably
+and lethally engage a target out to fifty meters--even if
+that target were a mounted, chain-mailed knight. (Unlike
+the longbow, which, admittedly was more powerful, and could
+get off more shots per unit time, the crossbow required no
+formal training to utilize. Whereas the longbow required
+elaborate visual, tactile and kinesthetic coordination to
+achieve any degree of accuracy, the wielder of a crossbow
+could simply put the weapon to his shoulder, sight along the
+arrow itself, and be reasonably assured of hitting his tar-
+get.)
+
+ Moreover, since just about the only mounted knights
+likely to visit your average peasant would be government
+soldiers and tax collectors, the utility of the device was
+plain: With it, the common rabble could defend themselves
+not only against one another, but against their governmental
+masters. It was the medieval equivalent of the armor-
+piercing bullet, and, consequently, kings and priests (the
+medieval equivalent of a Bureau of Alcohol, Tobacco and
+Crossbows) threatened death and excommunication, respec-
+tively, for its unlawful possession.
+
+ Looking at later developments, we see how technology
+like the firearm--particularly the repeating rifle and the
+handgun, later followed by the Gatling gun and more advanced
+machine guns--radically altered the balance of interpersonal
+and inter-group power. Not without reason was the Colt .45
+called "the equalizer." A frail dance-hall hostess with one
+in her possession was now fully able to protect herself
+against the brawniest roughneck in any saloon. Advertise-
+ments for the period also reflect the merchandising of the
+repeating cartridge rifle by declaring that "a man on
+horseback, armed with one of these rifles, simply cannot be
+captured." And, as long as his captors were relying upon
+flintlocks or single-shot rifles, the quote is doubtless a
+true one.
+
+ Updating now to the present, the public-key cipher
+(with a personal computer to run it) represents an equiv-
+alent quantum leap--in a defensive weapon. Not only can
+such a technique be used to protect sensitive data in one's
+own possession, but it can also permit two strangers to ex-
+change information over an insecure communications
+channel--a wiretapped phone line, for example, or
+skywriting, for that matter)--without ever having previously
+met to exchange cipher keys. With a thousand-dollar com-
+puter, you can create a cipher that a multi-megabuck CRAY
+X-MP can't crack in a year. Within a few years, it should
+be economically feasible to similarly encrypt voice communi-
+cations; soon after that, full-color digitized video images.
+Technology will not only have made wiretapping obsolete, it
+will have totally demolished government's control over in-
+formation transfer.
+
+ I'd like to take just a moment to sketch the mathemat-
+ics which makes this principle possible. This algorithm is
+called the RSA algorithm, after Rivest, Shamir, and Adleman
+who jointly created it. Its security derives from the fact
+that, if a very large number is the product of two very
+large primes, then it is extremely difficult to obtain the
+two prime factors from analysis of their product. "Ex-
+tremely" in the sense that if primes p and q have 100
+digits apiece, then their 200-digit product cannot in gen-
+eral be factored in less than 100 years by the most powerful
+computer now in existence.
+
+ The "public" part of the key consists of (1) the prod-
+uct pq of the two large primes p and q, and (2) one fac-
+tor, call it x , of the product xy where xy = {(p-1) *
+(q-1) + 1}. The "private" part of the key consists of the
+other factor y.
+
+ Each block of the text to be encrypted is first turned
+into an integer--either by using ASCII, or even a simple
+A=01, B=02, C=03, ... , Z=26 representation. This integer
+is then raised to the power x (modulo pq) and the resulting
+integer is then sent as the encrypted message. The receiver
+decrypts by taking this integer to the (secret) power y
+(modulo pq). It can be shown that this process will always
+yield the original number started with.
+
+ What makes this a groundbreaking development, and why
+it is called "public-key" cryptography," is that I can
+openly publish the product pq and the number x , while
+keeping secret the number y --so that anyone can send me
+an encrypted message, namely
+ x
+ a (mod pq) ,
+but only I can recover the original message a , by taking
+what they send, raising it to the power y and taking the
+result (mod pq). The risky step (meeting to exchange cipher
+keys) has been eliminated. So people who may not even trust
+each other enough to want to meet, may still reliably ex-
+change encrypted messages--each party having selected and
+disseminated his own pq and his x , while maintaining
+the secrecy of his own y.
+
+ Another benefit of this scheme is the notion of a "dig-
+ital signature," to enable one to authenticate the source of
+a given message. Normally, if I want to send you a message,
+I raise my plaintext a to your x and take the result (mod
+your pq) and send that.
+
+ However, if in my message, I take the plaintext a and
+raise it to my (secret) power y , take the result (mod my
+pq), then raise that result to your x (mod your pq) and
+send this, then even after you have normally "decrypted" the
+message, it will still look like garbage. However, if you
+then raise it to my public power x , and take the result
+(mod my public pq ), so you will not only recover the ori-
+ginal plaintext message, but you will know that no one but I
+could have sent it to you (since no one else knows my secret
+y).
+
+ And these are the very concerns by the way that are to-
+day tormenting the Soviet Union about the whole question of
+personal computers. On the one hand, they recognize that
+American schoolchildren are right now growing up with com-
+puters as commonplace as sliderules used to be--more so, in
+fact, because there are things computers can do which will
+interest (and instruct) 3- and 4-year-olds. And it is pre-
+cisely these students who one generation hence will be going
+head-to-head against their Soviet counterparts. For the
+Soviets to hold back might be a suicidal as continuing to
+teach swordsmanship while your adversaries are learning
+ballistics. On the other hand, whatever else a personal
+computer may be, it is also an exquisitely efficient copying
+machine--a floppy disk will hold upwards of 50,000 words of
+text, and can be copied in a couple of minutes. If this
+weren't threatening enough, the computer that performs the
+copy can also encrypt the data in a fashion that is all but
+unbreakable. Remember that in Soviet society publicly ac-
+cessible Xerox machines are unknown. (The relatively few
+copying machines in existence are controlled more inten-
+sively than machine guns are in the United States.)
+
+ Now the "conservative" position is that we should not
+sell these computers to the Soviets, because they could use
+them in weapons systems. The "liberal" position is that we
+should sell them, in the interests of mutual trade and
+cooperation--and anyway, if we don't make the sale, there
+will certainly be some other nation willing to.
+
+ For my part, I'm ready to suggest that the Libertarian
+position should be to give them to the Soviets for free, and
+if necessary, make them take them . . . and if that doesn't
+work load up an SR-71 Blackbird and air drop them over
+Moscow in the middle of the night. Paid for by private sub-
+scription, of course, not taxation . . . I confess that this
+is not a position that has gained much support among members
+of the conventional left-right political spectrum, but, af-
+ter all, in the words of one of Illuminatus's characters, we
+are political non-Euclideans: The shortest distance to a
+particular goal may not look anything like what most people
+would consider a "straight line." Taking a long enough
+world-view, it is arguable that breaking the Soviet govern-
+ment monopoly on information transfer could better lead to
+the enfeeblement and, indeed, to the ultimate dissolution of
+the Soviet empire than would the production of another dozen
+missiles aimed at Moscow.
+
+ But there's the rub: A "long enough" world view does
+suggest that the evil, the oppressive, the coercive and the
+simply stupid will "get what they deserve," but what's not
+immediately clear is how the rest of us can escape being
+killed, enslaved, or pauperized in the process.
+
+ When the liberals and other collectivists began to at-
+tack freedom, they possessed a reasonably stable, healthy,
+functioning economy, and almost unlimited time to proceed to
+hamstring and dismantle it. A policy of political
+gradualism was at least conceivable. But now, we have
+patchwork crazy-quilt economy held together by baling wire
+and spit. The state not only taxes us to "feed the poor"
+while also inducing farmers to slaughter milk cows and drive
+up food prices--it then simultaneously turns around and sub-
+sidizes research into agricultural chemicals designed to in-
+crease yields of milk from the cows left alive. Or witness
+the fact that a decline in the price of oil is considered as
+potentially frightening as a comparable increase a few years
+ago. When the price went up, we were told, the economy
+risked collapse for for want of energy. The price increase
+was called the "moral equivalent of war" and the Feds swung
+into action. For the first time in American history, the
+speed at which you drive your car to work in the morning be-
+came an issue of Federal concern. Now, when the price of
+oil drops, again we risk problems, this time because Ameri-
+can oil companies and Third World basket-case nations who
+sell oil may not be able to ever pay their debts to our
+grossly over-extended banks. The suggested panacea is that
+government should now re-raise the oil prices that OPEC has
+lowered, via a new oil tax. Since the government is seeking
+to raise oil prices to about the same extent as OPEC did,
+what can we call this except the "moral equivalent of civil
+war--the government against its own people?"
+
+ And, classically, in international trade, can you imag-
+ine any entity in the world except a government going to
+court claiming that a vendor was selling it goods too
+cheaply and demanding not only that that naughty vendor be
+compelled by the court to raise its prices, but also that it
+be punished for the act of lowering them in the first place?
+
+ So while the statists could afford to take a couple of
+hundred years to trash our economy and our liberties--we
+certainly cannot count on having an equivalent period of
+stability in which to reclaim them. I contend that there
+exists almost a "black hole" effect in the evolution of
+nation-states just as in the evolution of stars. Once free-
+dom contracts beyond a certain minimum extent, the state
+warps the fabric of the political continuum about itself to
+the degree that subsequent re-emergence of freedom becomes
+all but impossible. A good illustration of this can be seen
+in the area of so-called "welfare" payments. When those who
+sup at the public trough outnumber (and thus outvote) those
+whose taxes must replenish the trough, then what possible
+choice has a democracy but to perpetuate and expand the tak-
+ing from the few for the unearned benefit of the many? Go
+down to the nearest "welfare" office, find just two people
+on the dole . . . and recognize that between them they form
+a voting bloc that can forever outvote you on the question
+of who owns your life--and the fruits of your life's labor.
+
+ So essentially those who love liberty need an "edge" of
+some sort if we're ultimately going to prevail. We obvi-
+ously can't use the altruists' "other-directedness" of
+"work, slave, suffer, sacrifice, so that next generation of
+a billion random strangers can live in a better world."
+Recognize that, however immoral such an appeal might be, it
+is nonetheless an extremely powerful one in today's culture.
+If you can convince people to work energetically for a
+"cause," caring only enough for their personal welfare so as
+to remain alive enough and healthy enough to continue
+working--then you have a truly massive reservoir of energy
+to draw from. Equally clearly, this is just the sort of ap-
+peal which tautologically cannot be utilized for egoistic or
+libertarian goals. If I were to stand up before you tonight
+and say something like, "Listen, follow me as I enunciate my
+noble "cause," contribute your money to support the "cause,"
+give up your free time to work for the "cause," strive
+selflessly to bring it about, and then (after you and your
+children are dead) maybe your children's children will actu-
+ally live under egoism"--you'd all think I'd gone mad. And
+of course you'd be right. Because the point I'm trying to
+make is that libertarianism and/or egoism will be spread if,
+when, and as, individual libertarians and/or egoists find it
+profitable and/or enjoyable to do so. And probably only
+then.
+
+ While I certainly do not disparage the concept of poli-
+tical action, I don't believe that it is the only, nor even
+necessarily the most cost-effective path toward increasing
+freedom in our time. Consider that, for a fraction of the
+investment in time, money and effort I might expend in try-
+ing to convince the state to abolish wiretapping and all
+forms of censorship--I can teach every libertarian who's in-
+terested how to use cryptography to abolish them
+unilaterally.
+
+ There is a maxim--a proverb--generally attributed to
+the Eskimoes, which very likely most Libertarians have al-
+ready heard. And while you likely would not quarrel with
+the saying, you might well feel that you've heard it often
+enough already, and that it has nothing further to teach us,
+and moreover, that maybe you're even tired of hearing it. I
+shall therefore repeat it now:
+
+ If you give a man a fish, the saying runs, you feed him
+for a day. But if you teach a man how to fish, you feed him
+for a lifetime.
+
+ Your exposure to the quote was probably in some sort of
+a "workfare" vs. "welfare" context; namely, that if you
+genuinely wish to help someone in need, you should teach him
+how to earn his sustenance, not simply how to beg for it.
+And of course this is true, if only because the next time he
+is hungry, there might not be anybody around willing or even
+able to give him a fish, whereas with the information on how
+to fish, he is completely self sufficient.
+
+ But I submit that this exhausts only the first order
+content of the quote, and if there were nothing further to
+glean from it, I would have wasted your time by citing it
+again. After all, it seems to have almost a crypto-altruist
+slant, as though to imply that we should structure our ac-
+tivities so as to maximize the benefits to such hungry
+beggars as we may encounter.
+
+ But consider:
+
+ Suppose this Eskimo doesn't know how to fish, but he
+does know how to hunt walruses. You, on the other hand,
+have often gone hungry while traveling thru walrus country
+because you had no idea how to catch the damn things, and
+they ate most of the fish you could catch. And now suppose
+the two of you decide to exchange information, bartering
+fishing knowledge for hunting knowledge. Well, the first
+thing to observe is that a transaction of this type
+categorically and unambiguously refutes the Marxist premise
+that every trade must have a "winner" and a "loser;" the
+idea that if one person gains, it must necessarily be at the
+"expense" of another person who loses. Clearly, under this
+scenario, such is not the case. Each party has gained some-
+thing he did not have before, and neither has been dimin-
+ished in any way. When it comes to exchange of information
+(rather than material objects) life is no longer a zero-sum
+game. This is an extremely powerful notion. The "law of
+diminishing returns," the "first and second laws of
+thermodynamics"--all those "laws" which constrain our possi-
+bilities in other contexts--no longer bind us! Now that's
+anarchy!
+
+ Or consider another possibility: Suppose this hungry
+Eskimo never learned to fish because the ruler of his
+nation-state had decreed fishing illegal. Because fish
+contain dangerous tiny bones, and sometimes sharp spines, he
+tells us, the state has decreed that their consumption--and
+even their possession--are too hazardous to the people's
+health to be permitted . . . even by knowledgeable, willing
+adults. Perhaps it is because citizens' bodies are thought
+to be government property, and therefore it is the function
+of the state to punish those who improperly care for govern-
+ment property. Or perhaps it is because the state gener-
+ously extends to competent adults the "benefits" it provides
+to children and to the mentally ill: namely, a full-time,
+all-pervasive supervisory conservatorship--so that they need
+not trouble themselves with making choices about behavior
+thought physically risky or morally "naughty." But, in any
+case, you stare stupefied, while your Eskimo informant re-
+lates how this law is taken so seriously that a friend of
+his was recently imprisoned for years for the crime of "pos-
+session of nine ounces of trout with intent to distribute."
+
+ Now you may conclude that a society so grotesquely
+oppressive as to enforce a law of this type is simply an
+affront to the dignity of all human beings. You may go far-
+ther and decide to commit some portion of your discretion-
+ary, recreational time specifically to the task of thwarting
+this tyrant's goal. (Your rationale may be "altruistic" in
+the sense of wanting to liberate the oppressed, or
+"egoistic" in the sense of proving you can outsmart the
+oppressor--or very likely some combination of these or per-
+haps even other motives.)
+
+ But, since you have zero desire to become a martyr to
+your "cause," you're not about to mount a military campaign,
+or even try to run a boatload of fish through the blockade.
+However, it is here that technology--and in particular in-
+formation technology--can multiply your efficacy literally a
+hundredfold. I say "literally," because for a fraction of
+the effort (and virtually none of the risk) attendant to
+smuggling in a hundred fish, you can quite readily produce a
+hundred Xerox copies of fishing instructions. (If the tar-
+geted government, like present-day America, at least permits
+open discussion of topics whose implementation is re-
+stricted, then that should suffice. But, if the government
+attempts to suppress the flow of information as well, then
+you will have to take a little more effort and perhaps write
+your fishing manual on a floppy disk encrypted according to
+your mythical Eskimo's public-key parameters. But as far as
+increasing real-world access to fish you have made genuine
+nonzero headway--which may continue to snowball as others
+re-disseminate the information you have provided. And you
+have not had to waste any of your time trying to convert id-
+eological adversaries, or even trying to win over the unde-
+cided. Recall Harry Browne's dictum from "Freedom in an
+Unfree World" that the success of any endeavor is in general
+inversely proportional to the number of people whose persua-
+sion is necessary to its fulfilment.
+
+ If you look at history, you cannot deny that it has
+been dramatically shaped by men with names like Washington,
+Lincoln, . . . Nixon . . . Marcos . . . Duvalier . . .
+Khadaffi . . . and their ilk. But it has also been shaped
+by people with names like Edison, Curie, Marconi, Tesla and
+Wozniak. And this latter shaping has been at least as per-
+vasive, and not nearly so bloody.
+
+ And that's where I'm trying to take The LiberTech
+Project. Rather than beseeching the state to please not en-
+slave, plunder or constrain us, I propose a libertarian net-
+work spreading the technologies by which we may seize
+freedom for ourselves.
+
+ But here we must be a bit careful. While it is not (at
+present) illegal to encrypt information when government
+wants to spy on you, there is no guarantee of what the fu-
+ture may hold. There have been bills introduced, for exam-
+ple, which would have made it a crime to wear body armor
+when government wants to shoot you. That is, if you were to
+commit certain crimes while wearing a Kevlar vest, then that
+fact would constitute a separate federal crime of its own.
+This law to my knowledge has not passed . . . yet . . . but
+it does indicate how government thinks.
+
+ Other technological applications, however, do indeed
+pose legal risks. We recognize, for example, that anyone
+who helped a pre-Civil War slave escape on the "underground
+railroad" was making a clearly illegal use of technology--as
+the sovereign government of the United States of America at
+that time found the buying and selling of human beings quite
+as acceptable as the buying and selling of cattle. Simi-
+larly, during Prohibition, anyone who used his bathtub to
+ferment yeast and sugar into the illegal psychoactive drug,
+alcohol--the controlled substance, wine--was using technol-
+ogy in a way that could get him shot dead by federal agents
+for his "crime"--unfortunately not to be restored to life
+when Congress reversed itself and re-permitted use of this
+drug.
+
+ So . . . to quote a former President, un-indicted co-
+conspirator and pardoned felon . . . "Let me make one thing
+perfectly clear:" The LiberTech Project does not advocate,
+participate in, or conspire in the violation of any law--no
+matter how oppressive, unconstitutional or simply stupid
+such law may be. It does engage in description (for educa-
+tional and informational purposes only) of technological
+processes, and some of these processes (like flying a plane
+or manufacturing a firearm) may well require appropriate li-
+censing to perform legally. Fortunately, no license is
+needed for the distribution or receipt of information it-
+self.
+
+ So, the next time you look at the political scene and
+despair, thinking, "Well, if 51% of the nation and 51% of
+this State, and 51% of this city have to turn Libertarian
+before I'll be free, then somebody might as well cut my
+goddamn throat now, and put me out of my misery"--recognize
+that such is not the case. There exist ways to make your-
+self free.
+
+ If you wish to explore such techniques via the Project,
+you are welcome to give me your name and address--or a fake
+name and mail drop, for that matter--and you'll go on the
+mailing list for my erratically-published newsletter. Any
+friends or acquaintances whom you think would be interested
+are welcome as well. I'm not even asking for stamped self-
+addressed envelopes, since my printer can handle mailing la-
+bels and actual postage costs are down in the noise compared
+with the other efforts in getting an issue out. If you
+should have an idea to share, or even a useful product to
+plug, I'll be glad to have you write it up for publication.
+Even if you want to be the proverbial "free rider" and just
+benefit from what others contribute--you're still welcome:
+Everything will be public domain; feel free to copy it or
+give it away (or sell it, for that matter, 'cause if you can
+get money for it while I'm taking full-page ads trying to
+give it away, you're certainly entitled to your capitalist
+profit . . .) Anyway, every application of these principles
+should make the world just a little freer, and I'm certainly
+willing to underwrite that, at least for the forseeable fu-
+ture.
+
+ I will leave you with one final thought: If you don't
+learn how to beat your plowshares into swords before they
+outlaw swords, then you sure as HELL ought to learn before
+they outlaw plowshares too.
+
+ --Chuck Hammill
+
+ THE LIBERTECH PROJECT
+ 3194 Queensbury Drive
+ Los Angeles, California
+ 90064
+ 310-836-4157
+
+[The above LiberTech address was updated June 1992, with the
+ permission of Chuck Hammill, by:
+
+Russell Earl Whitaker whitaker@eternity.demon.co.uk
+Communications Editor 71750.2413@compuserve.com
+EXTROPY: The Journal of Transhumanist Thought AMIX: RWHITAKER
+Board member, Extropy Institute (ExI)
+[.sig revised 11 September 1992 /// Send mail to eternity node]
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.0
+
+mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
+pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
+lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
+tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
+by51az4=
+=LOCL
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-08 (Thu, 8 Oct 92 01:04:18 PDT) - Hammill on public key - _whitaker@eternity.demon.co.uk (Russell E. Whitaker)_
+
diff --git a/_emails/1992/10/616251ebb198febeb8ca5f445c9d0aae670d07a1afdd5411fa6d39884ed2ba03.md b/_emails/1992/10/616251ebb198febeb8ca5f445c9d0aae670d07a1afdd5411fa6d39884ed2ba03.md
new file mode 100644
index 0000000000..9974c1e640
--- /dev/null
+++ b/_emails/1992/10/616251ebb198febeb8ca5f445c9d0aae670d07a1afdd5411fa6d39884ed2ba03.md
@@ -0,0 +1,49 @@
+---
+layout: default
+---
+
+# 1992-10-24 - Removal From Mailing list
+
+## Header Data
+
+From: deckard@chezrob.pinetree.org (Stephen Pandke)
+To: cypherpunks@toad.com
+Message Hash: 616251ebb198febeb8ca5f445c9d0aae670d07a1afdd5411fa6d39884ed2ba03
+Message ID: \
+Reply To: _N/A_
+UTC Datetime: 1992-10-24 21:49:54 UTC
+Raw Date: Sat, 24 Oct 92 14:49:54 PDT
+
+## Raw message
+
+```
+{% raw %}From: deckard@chezrob.pinetree.org (Stephen Pandke)
+Date: Sat, 24 Oct 92 14:49:54 PDT
+To: cypherpunks@toad.com
+Subject: Removal From Mailing list
+Message-ID:
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+Unfortunately, I must request that I be removed from your
+mailing list. ]
+
+Stephen Pandke
+
+---
+ Stephen Pandke - deckard@chezrob.pinetree.org
+ C.R.I.M.E. BBS - (Chez Rob's Int'l Mail Exchange) 613/230-5307 (data)
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-24 (Sat, 24 Oct 92 14:49:54 PDT) - Removal From Mailing list - _deckard@chezrob.pinetree.org (Stephen Pandke)_
+
diff --git a/_emails/1992/10/63887eadbd08ad02760869b6af2f35f6deb7ee07835ab01a95b64ccacadc0011.md b/_emails/1992/10/63887eadbd08ad02760869b6af2f35f6deb7ee07835ab01a95b64ccacadc0011.md
new file mode 100644
index 0000000000..ac5b61ca2b
--- /dev/null
+++ b/_emails/1992/10/63887eadbd08ad02760869b6af2f35f6deb7ee07835ab01a95b64ccacadc0011.md
@@ -0,0 +1,47 @@
+---
+layout: default
+---
+
+# 1992-10-25 - Re: remove from mailing list
+
+## Header Data
+
+From: Hal \<74076.1041@CompuServe.COM\>
+To: \
+Message Hash: 63887eadbd08ad02760869b6af2f35f6deb7ee07835ab01a95b64ccacadc0011
+Message ID: \<921025044014_74076.1041_DHJ64-1@CompuServe.COM\>
+Reply To: _N/A_
+UTC Datetime: 1992-10-25 04:47:19 UTC
+Raw Date: Sat, 24 Oct 92 21:47:19 PDT
+
+## Raw message
+
+```
+{% raw %}From: Hal <74076.1041@CompuServe.COM>
+Date: Sat, 24 Oct 92 21:47:19 PDT
+To:
+Subject: Re: remove from mailing list
+Message-ID: <921025044014_74076.1041_DHJ64-1@CompuServe.COM>
+MIME-Version: 1.0
+Content-Type: text/plain
+
+
+What we _ought_ to do is to remind people that they should send
+their unsubscribe notices to cyherpunks-request@toad.com, _not_
+to the list address. That way we wouldn't all have to be bothered
+by reading these messages, and the list volume would be that much
+lower!
+
+
+
+
+
+{% endraw %}
+```
+
+## Thread
+
++ Return to [October 1992](/years/1992/10)
+
++ 1992-10-25 (Sat, 24 Oct 92 21:47:19 PDT) - Re: remove from mailing list - _Hal \<74076.1041@CompuServe.COM\>_
+
diff --git a/_emails/1992/10/6531dc9cfb41ffe59293b1364cb394d8c4abfebd215a68c3a3445018114f5dc2.md b/_emails/1992/10/6531dc9cfb41ffe59293b1364cb394d8c4abfebd215a68c3a3445018114f5dc2.md
new file mode 100644
index 0000000000..c9053536a6
--- /dev/null
+++ b/_emails/1992/10/6531dc9cfb41ffe59293b1364cb394d8c4abfebd215a68c3a3445018114f5dc2.md
@@ -0,0 +1,66 @@
+---
+layout: default
+---
+
+# 1992-10-05 - introducing public keys
+
+## Header Data
+
+From: Eric Hughes \