cypherpunks-legacy
Threads by month
- ----- 2025 -----
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1996 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1995 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1994 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1993 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1992 -----
- December
- November
- October
- September
December 2003
- 8635 participants
- 56359 discussions
Sean Roach said:
> As of sometime in the last 96 hours I have been forcefully unsubscribed from
> this list. This action was not of my free will and not one that I think was
> perpretrated by those in charge of the list.
Everybody relax, take a deep breath, and calm down a bit. Paranoia seems
epidemic on the list these days.
I removed your address from the mailing list because it was producing
a bounce message for every message to cypherpunks. I regularly
remove addresses when this occurs; the alternative is to receive
thousands of bounce messages each day from non-working addresses.
I'll append the set of addresses that I removed on the same day
as you, for your edification.
I'll also enclose one of the bounces.
If you fix your mail so it doesn't bounce, you are welcome to
re-subscribe.
John Gilmore
1997/2/9 - gnu - bounces
snowdog(a)iconn.net (cp-ann)
se03565(a)els.url.es (cp-ann)
drjarmon(a)ingr.com (cp-ann)
ycz(a)alpha4.cs.nthu.edu.tw
yu123110(a)yorku.ca
bishop.trish(a)sympatico.ca
106076.1155(a)compuserve.com (by request)
security(a)harter.pg.md.us
omega(a)bigeasy.com
roach_s(a)alph.swosu.edu (cp-unedited)
lupus(a)hempseed.com (cp-ann)
THRPWC(a)smtpgate.lfwc.lockheed.com
al.tan(a)usa.net
vickeryk(a)tyrell.net
crash(a)eramp.net
phreaker(a)scholars.bellevue.edu
alexc(a)firefly.net
malaficia(a)mindspring.com
BadAppleDH(a)aol.com
otsge_mail(a)usa.net (for bounces re mecca_inc(a)msn.se)
under(a)ground.net
>From MAILER-DAEMON Sun Feb 9 20:03:36 1997
Received: from alph.swosu.edu (alph.swosu.edu [164.58.32.9]) by toad.com (8.7.5/8.7.3) with SMTP id UAA17045; Sun, 9 Feb 1997 20:03:33 -0800 (PST)
Message-Id: <199702100403.UAA17045(a)toad.com>
Date: Sun, 9 Feb 1997 22:03:48 -0600 (CST)
From: Postmaster(a)alph.swosu.edu
Subject: Undeliverable Mail
To: <cypherpunks-errors(a)toad.com>
Bad address -- <roach_s>
Error -- Message too old:
%MAIL-E-SENDERR, error sending to user ROACH_S
-MAIL-W-WRITEERR, error writing DKA0:[STDUSERS.ROACH_S]MAIL.MAI
-RMS-E-EXT, ACP file extend failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
-PLI-F-NOMSG, Message number 001EBB8C
Start of returned message
Received: from toad.com by alph.swosu.edu with SMTP;
Sun, 9 Feb 1997 18:03:43 -0600 (CST)
Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id PAA11855; Sun, 9 Feb 1997 15:55:29 -0800 (PST)
Received: from mail.pacifier.com (root(a)mail.pacifier.com [199.2.117.164]) by toad.com (8.7.5/8.7.3) with ESMTP id PAA11850; Sun, 9 Feb 1997 15:55:26 -0800 (PST)
Received: from ip250.van8.pacifier.com (ip250.van8.pacifier.com [206.163.4.250])
by mail.pacifier.com (8.8.5/8.8.4) with SMTP
id PAA12294 for <cypherpunks(a)toad.com>; Sun, 9 Feb 1997 15:55:23 -0800 (PST)
Message-Id: <199702092355.PAA12294(a)mail.pacifier.com>
X-Sender: jimbell(a)mail.pacifier.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 09 Feb 1997 15:53:43 -0800
To: cypherpunks(a)toad.com
From: jim bell <jimbell(a)pacifier.com>
Subject: ComLaw> URGENT!! SET UP IN PROGRESS!! (fwd)
Sender: owner-cypherpunks(a)toad.com
Precedence: bulk
I'm forwarding this from the commonlaw list because of the usage of the
name, "cypherpunks."
...
1
0
From: "Curt Denny" <adr016(a)clc.cc.il.us>
The heaviest element known to science was recently discovered by GM
Research physicists. The element, tentatively named Administratium, has
no protons or electrons and thus has an atomic number of zero. However,
it does have one neutron, 125 assistant neutrons, 75 vice neutrons, and
111 assistant vice neutrons. This gives it an atomic number of 312.
These particles are held together by a force that involves the
continuous exchange of meson-like particles known as morons.
Since it has no electrons, Administratium is inert. However, it can be
detected chemically because it impedes every reaction it comes in
contact with. According to the discoverers, a minute amount of
Administratium caused one reaction to take four days to complete when it
would have normally occurred in less than one second. Administratium
has a normal half-life of approximately three years, at which time it
does not actually decay, but instead undergoes a reorganization in which
assistant neutrons exchange places. Some studies have shown that the
atomic mass actually increases after each organization.
Research at other laboratories indicates that Administratium occurs
naturally in the atmosphere. It tends to concentrate at certain points
such as government agencies, large corporations and universities, and
can usually be found in the newest, best appointed and best maintained
buildings.
Scientists point out that Administratium is known to be toxic at any
detectable level of concentratitroy any productive
reaction where it is allowed to accumulate. Attempts are being made to
determine how Administratium can be controlled to prevent irreversible
damage, but results to date are not promising.
Check us out at:
http://www.clc.cc.il.us
"There is no limit to the amount of good that people can accomplish if they don't care who gets the credit!"
Curtis L. Denny
College of Lake County
Director of Admission and Records
19351 West Washington Street
Grayslake, IL 60030-1198
Phone: (847) 223-6601, Ext. 2384
Fax: (847) 223-1017
E-Mail: CurtDenny(a)clc.cc.il.us
---2143972336-1320482045-855671591=:18392--
1
0
FOR IMMEDIATE RELEASE
6 February 1997
Aegean Park Press proudly announces publication of CLASSICAL
CRYPTOGRAPHY COURSE - VOLUME II by Randall K. Nichols
[LANAKI]. [ISBN: 0-89412-264-9, 1997, 464 pages, $US 40.80 ]
Volume II presents Lectures 11 - 22 (of a total of
twenty five) from his successful course in Classical
Cryptography taught in 1995 and 1996 to 391 students via
the Internet and an additional 65 via regular mail.
Volume II covers polyalphabetic substitutions ciphers in
the Vigenere family (Viggy, Variant, Beaufort, Porta,
Gronsfeld, Portax, Gromark), decimation, principles of
symmetry, isologs and superimposition solution
techniques. Volume II describes the difficult aperiodic
cipher systems (Interrupted key, Autoclave, Progressive,
Running Key used in cipher machines) and their analysis
by isomorphs, and repetitions. Cryptarithm solutions for
extended bases are presented. The theory of coincidences
and statistical attacks (Kappa, Chi, Phi) derived from
this important theory are detailed. Transposition
theory and a variety of transposition ciphers are solved
(Columnar, Amsco, Myszkowski, Cadenus, Grille, Swagman,
Auto-Transposition). Volume II has two chapters on the
difficult cipher systems invented by the famous French
cryptographer Delastelle: Foursquare, Bifid and Trifid.
Volume II presents a detailed chapter on passwords, law
and data protection. Volume II ends with a historical
look at codes, commercial code systems, and famous
cipher machines. Volume II is a potpourri of advanced
topics in classical cryptography.
The Cryptographic Resources and References section has
been expanded to cover all phases of involvement with
cryptography: cryptanalysis, history, legal, social,
classical, modern, NSA, mathematical techniques,
recreational, intelligence, tactical, strategic,
National Defense, INFOSEC: offensive and defensive,
hardware, software, standards, public key cryptography,
web sources, and applicable Senate and House bills.
Readers are encouraged to expand their knowledge in the
many directions possible to them through this section.
For orders or Information Contact: Aegean Park Press, P.O.
Box 2837, Laguna Hills, Ca. 92654. Telephone: 1-800-736-3587;
Fax: 1-714-586-8269. Group discounts available.
REVIEW OF CLASSICAL CRYPTOGRAPHY COURSE, VOLUME I
By the Honorable David Kennedy, Director of Research,
NCSA.
Classical Cryptography Course, Volume I. By
Randall K. Nichols; published by Aegean Park Press,
(714) 586-8811 (phone) (714) 586-8269 (fax); (800) 736
- 3587; 301 pages (with index); $34.80 (American
Cryptogram Association members receive a 20% discount
through ACA or NCSA Members receive a 10% discount if
purchased from the NCSA Bookstore)
In Classical Cryptography Course, Volume I, author
Randall K. Nichols has created a benchmark for serious
students of the science of cryptography. This is a
text. It is for learning, and with it one cannot help
but learn about the foundations of the science. An
outgrowth of Nichols' admitted "labor of love" in the
online Cryptography Courses he teaches over the
Internet, Volume I creates the foundation for
understanding the development of the science.
The ten chapters of this volume lead the student
through simple substitutions, substitutions with
variants, multiliteral substitutions, xenocrypts
(foreign language substitutions), cryptarithms, the
Enigma machine (separate Enigma95 program disk available
direct from the author) and finally to polyalphabetic
substitutions. Seven chapters conclude with problems;
solutions and discussions are provided in an appendix.
The text is indexed with twenty-four pages of references
for further study.
I found Nichols' sense of the history of
cryptography particularly noteworthy. The volume is
liberally salted with citations from history with
applications of the methods developed in the text. From
Revolutionary France through the American Civil War, the
Tammany Hall scandal, Revolutionary Soviet ciphers and
Japanese successes against Chinese codes prior to Pearl
Harbor, the text provides touchstones for student to
understand and relate to.
Phil Zimmermann observed in the documentation to
his Pretty Good Privacy Program to "Beware of Snake
Oil." Among his arguments is this anecdote:
I remember a conversation with Brian Snow, a highly
placed senior cryptographer with the NSA. He said he
would never trust an encryption algorithm designed by
someone who had not "earned their bones" by first
spending a lot of time cracking codes.
Where Schneier's Applied Cryptography is a crash
course in some encryption protocols and algorithms in
use today, Nichols' text begins the teaching of Snake
Oil detection and prevention.
Learning the fundamentals, developed throughout the
text, brings a richer understanding of the science, it's
history and insight into it's possibilities and some
vulnerabilities lurking for the unwary.
Nichols plans for release Volume II in the series
with advanced material on from the online course which
includes statistical attacks and transposition in
February, 1997.
Reviewer: Dave Kennedy, CISSP, is Director of Research
for the National Computer Security Association,
Carlisle, PA. He is a retired Army military police
officer and member of NCSA, ASIS, ISSA and the Computer
Security Institute.
reposted from cryptography(a)c2.org
Brian
1
0
--- begin forwarded text
X-Sender: leroux(a)mail.vdl2.ca
Date: Mon, 10 Feb 1997 13:05:08 -0500
To: dcsb(a)ai.mit.edu
From: Philippe Le Roux <leroux(a)vdl2.ca>
Subject: Interesting ressource
Mime-Version: 1.0
Sender: bounce-dcsb(a)ai.mit.edu
Precedence: bulk
Reply-To: Philippe Le Roux <leroux(a)vdl2.ca>
The IEEE published a special issue of Spectrum
(http://www.spectrum.ieee.org/contents/) about digital commerce and ecash.
This is the index :
Electronic money: toward a virtual wallet
By Tekla S. Perry
Hard currency is disappearing from many everyday transactions along the
road to electronic money.
Future of electronic money: a regulator's perspective
By Edward W. Kelley Jr.
The way electronics will fit into the evolution of money--from acting as a
niche player
to wreaking major changes in payment systems--has yet to be determined.
Credits and debits on the Internet
By Marvin A. Sirbu
CyberCash, First Virtual, GC Tech, NetBill--these and other systems have
been developed to enable electronic transfers of payments across the
Internet.
'Minting' electronic cash
By David Chaum & Stefan Brands
Electronic cash can offer transaction privacy to honest users, affords
convenient storage and transportation, and protects against loss.
Traceable e-cash
By Peter S. Gemmell
One method of making electronic cash transactions private for honest users but
traceable by law enforcement agencies involves the use of trustees.
Crime and prevention: a Treasury viewpoint
By Stanley E. Morris
The speed and anonymity of electronic payment systems make them attractive
to those pursuing illicit activities.
Locking the e-safe
By Robert W. Baldwin & C. Victor Chang
Existing encryption-based security mechanisms can be combined to minimize a
wide range of threats to electronic commerce.
In your pocket: smartcards
By Carol Hovenga Fancher
A wallet full of cash, credit, and identification cards may, in the future,
be replaced
with two or three smartcards, each containing an IC, as a recent flurry of
market
tests and smartcard rollouts demonstrates.
Banking in cyberspace: an investment in itself
By Michael C. McChesney
While home banking has been around for some time, Internet banking is a new
concept, and has a number of advantages.
Technology takes to securities trading
By Steven M. H. Wallman
>From stock offerings conducted entirely over the Internet, to the
automation of traditional exchanges, technology is changing the way stock
markets work.
Nasdaq's technology floor: its president takes stock
By Alfred R. Berkeley III
This screen-based stock market has been particularly sensitive to the
effects of new
computer and communications capabilities.
The economics of e-cash
By Mike Ter Maat
Electronic cash can create profits for its issuers, and launch competition
for today's
government-controlled currency systems.
Money and the Internet: a strange new relationship
By Howard Anderson
This visionary sees the e-money revolution as inevitable, with "e-mail for
money"
becoming as ubiquitous in the future as e-mail messages are already today.
*PLR!
------------------------------------------------------------------------------
Philippe Le Roux
Associe de V(DL)2 Inc.
Membre du SCIP (Society of Competitive Intelligence Professionals)
Co-Auteur d'Internet Secrets (IDG - 95)
Chroniqueur a Benefice.Net
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
Comment: Requires PGP version 2.6 or later.
mQBNAjLyVpEAAAECAKiVNKY2l2moieX3JsvrXKSvHqwF0Hq24cKh1p1VDaFEwWPs
/C6fMmo47FZIpV6xC/uRBiHVfW5d26AvJz1Ww7EABRG0IVBoaWxpcHBlIExlIFJv
dXggPGxlcm91eEB2ZGwyLmNhPokAVQIFEDLyVpHboC8nPVbDsQEBtwcB/An4zBwC
g9e1lFsVhVgmplxfUYAv3T7D7fAdCTeD51cJjns+Yh/3MoZQa7zns0BQFtRLoInL
HY4WrDBs9wSXZ70=
=tEnk
-----END PGP PUBLIC KEY BLOCK-----
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from the dcsb list, send a letter to: Majordomo(a)ai.mit.edu
In the body of the message, write: unsubscribe dcsb
Or, to subscribe, write: subscribe dcsb
If you have questions, write to me at Owner-DCSB(a)ai.mit.edu
--- end forwarded text
-----------------
Robert Hettinga (rah(a)shipwright.com) Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Never attribute to conspiracy what can be
explained by stupidity." -- Jerry Pournelle
1
0
[Excerpts from Winn Schwartau's 2/9 "InfoWar Digest," with responses to
Paul Strassmann's diatribe on the RSADS Secret-Key Challenge. Burt
Kaliski, Tim May, Padgett Peterson -- among others -- toss in their two
bits. Longish.
[FYI: RSADS still has 12 open Challenges pending, offering cash rewards for
anyone who can decrypt 56-bit DES -- or any of eleven _other_ RC5
cyphertext samples, encrypted with keys of varied lengths, ranging from
48-bit through 128-bits. Details somewhere on the RSA site:
<http://www.rsa.com> ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: Burt Kaliski <burt(a)RSA.COM>
To: "'infowar(a)infowar.com'" <infowar(a)infowar.com>
Subject: Further to Goldberg's Cracking Accomplishments
Date: Wed, 5 Feb 1997 13:58:53 -0800
Paul A. Strassmann <paul(a)strassmann.com> quoted a UC Berkeley press
release on Ian Goldberg's successful effort to discover the unknown 40-bit
key to an RC5 ciphertext offered in the RSA Data Security Secret-Key
Challenge, and raised a number of justifiable concerns about whether a
contest like the Challenge is an appropriate measure of the security of a
40-bit encryption algorithm in an InfoWar environment.
>>As I suspected (see earlier private comment), the
>>highly promoted RSA cracking contest offered
>>a number of clues that ordinarly would not be
>>volunteered by info-terrorists or info-criminals to
>>IW Defense teams.
>>
>>These clues made the cracking significantly easier,
>>because it made it possible to eliminate an enormous
>>range of possible searches.
Mr. Strassmann is a well known scholar of the InfoWar threat environment. I
am not, so I cannot address those specific concerns directly -- but I would
like to offer some rationale as to why the Challenge was structured as it
was.
The RSA Data Security Secret-Key Challenge
<http://www.rsa.com/rsalabs/97challenge/>, started last week, is an open
contest sponsored by RSA Laboratories that offers cash prizes for the
successful recovery of encryption keys for the DES and RC5 block ciphers.
Following the model of the RSA Factoring Challenge which for several years
has provided an assessment of the security of the RSA public-key algorithm
at various key sizes, the Secret-Key Challenge is intended to measure of
the security of secret-key algorithms at various key sizes.
As was the case with the Factoring Challenge, full details of the algorithms
and key sizes are provided. In addition, three plaintext-ciphertext pairs
(the ciphertext encrypted with the key of interest) are provided for each key
to be recovered.
Last week, the first of the keys in the Challenge, a 40-bit RC5 key, was
recovered by Ian Goldberg, a U.C. Berkeley graduate student. His effort
involved about 250 workstations and took 3.5 hours. When I called Mr.
Goldberg to congratulate him in a teleconference during the RSA Data
Security Conference last week, he explained that he had discovered the
valid key with a search of about 350 billion keys, using a university
computer network to search at a rate of 100 billion keys/hour.
There are about 1 trillion 40-bit keys, for any algorithm. Mr.
Goldberg's search method involved simple brute-force; that is, the known
plaintext was encrypted with each key, and then compared to the available
ciphertext, looking for a match.
The overall effort was essentially what was expected for the 40-bit key size,
and as one would expect, the recovery of a key for the other RC5 key sizes
(from 48 bits to 128 bit), or for DES (56 bits), will involve much more work.
With the same "brute force" method employed by Mr. Goldberg last week, one
would expect a 256-fold increase in effort for each eight-bit increase in
key size. Special-purpose hardware may reduce the actual time, of course,
but the total number of possible keys to be tested will grow at that rate.
Mr. Strassman expressed concern as to whether the successful recovery of
a 40-bit key in 3.5 hours is a realistic measure of the strength of 40-bit
keys in an InfoWar environment, where full details of the algorithm and
plaintext blocks are not necessarily known. Again, not being acquainted
with the threat environment, I cannot address his concerns directly.
Nevertheless, RSA Laboratories does consider this type of contest to be
appropriate as a general measure of cryptographic strength -- for RSA's
products and those of any other vendor in the international crytographic
community.
The information provided to RSA Secret-Key Challenge contestants is no more
than is common and conventional for any open contest to test the strength
of a cryptographic algorithm. These conventions have evolved within the
international community of cryptographers seeking, on the basis of several
acknowledged principles, to develop common criteria for measuring the
relative strength or security of any particular cryptographic algorithm
with a given key size. Our rationale for the structure of the Challenge is
reflected in the following observations:
* Knowledge of the algorithm and key size (as per Kerchoffs' principle), as
well as the availability of known plaintext, are standard assumptions in
modern cryptanalysis. Since an opponent may obtain this information
eventually, it is preferable not to rely on its secrecy when assessing
cryptographic strength.
* The implementation of large-scale key-search engines is simplified under
the standard assumptions. This makes the contest accessible to a wider
variety of contributors, than if we required contributors to know, for
instance, a particular language, or language statistics, or other
characteristics of the plaintext. (Perhaps another challenge where we didn't
provide plaintext samples would be a worthwhile follow-up.)
* In practice -- even if the plaintext is not known -- significant
information about it is likely to be, such as character distributions (ASCII,
English), header values (e.g., BER tag and length), or padding. The cost (in
time, effort, and computing resources) of a key search with even a small
amount of information of this kind is not significantly more than the cost
with known plaintext.
For instance, if it is known that the characters are represented in ASCII,
for instance, then one can decrypt available ciphertext with each key and
check that the recovered plaintext follows ASCII conventions (most
significant bit of each byte 0). The chance that an incorrect key produces
plaintext that passes the test is 1/2^k where k is the number of plaintext
bytes recovered. This means, for example, that of 2^40 keys tried, we expect
only 2^32 to pass the check for a single eight-byte block. The 2^32 keys must
then be tested further against other ciphertext blocks.
So instead of 2^40 encryptions -- as in the case when the plaintext is known
-- a cryptanalyst would need to search within 2^40+2^32+2^24+2^16+2^8+1
(roughly) keys, to find the correct key. But this represents an increase in
effort of less than 0.5 percent.
RSA Laboratories appreciates the InfoWar Community's interest in the RSA
Data Security Secret-Key Challenge, and Mr. Strassmann's comments in
particular. We look forward to further suggestions and critiques of our
efforts.
-- Burt Kaliski
>Chief Scientist
>RSA Laboratories
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 3 Feb 1997 21:42:24 -0800
To: infowar(a)infowar.com
From: "Timothy C. May" <tcmay(a)got.net>
Subject: Re: Infowar Digest Volume 02: Number 04 - Crypto and Goldberg
I seldom read your newsletter carefully. I did tonight, and discovered two
of the items you included contain serious errors.
(Of course, as a strong advocate of "infowar" I suppose I'm pleased to see
your subscribers in the government misled by these errors...it makes our
job a little easier in the long run.)
>To: infowar(a)infowar.com
>From: Patrick Galley <Patrick.Galley(a)studi.epfl.ch
>Subject: New crypto attack
>Date: Mon, 27 Jan 1997 07:56:39 +0000
>
>Hello
>
>A friend of mine told me to look at the WWW site "John Douglass'
>CryptoMaverick Page").
>
>There I've found a paper from John Douglass which says that if RSA
>products are sold worldwide it because there is a backdoor inside. He
>said the same thing for DES and PGP.
.....
>If this guy is right. It would be better for is security that everybody
>knows the truth.
>
>I think it would be nice if you could look at this doc and talk about it
>in infowar.com.
I looked at the site and it's a mixture of conspiracy theory rantings and
misinformation.
As to the security of various RSA algorithms (and PGP, for example), the
security of many of these algorithms lies in the publishing of the source
code, with digital signatures on the released binaries to allow independent
verification.
If a real security hole is found in, say, PGP or Netscape, expect it to be
publicized loudly and quickly. (Indeed, certain flaws have been found, and
quickly publicized. The same Ian Goldberg involved in later message was one
of those who isolated a flaw in the random number generator used in an
earlier version of Netscape.)
The web site mentioned here doesn't cut it, and this message here is just
more "disinformation" (itself a part of infowar, so I guess the author is
practicing his skills).
>Date: Thu, 30 Jan 1997 20:10:36 -0500
>To: "Wright Larry" <Wright_Larry(a)bah.com>
>From: "Paul A. Strassmann" <paul(a)strassmann.com>
>Subject: Further to Goldberg's Cracking Accomplishments
>Gentlemen:
>
>As I suspected (see earlier private comment), the
>highly promoted RSA cracking contest offered
>a number of clues that ordinarly would not be
>volunteered by info-terrorists or info-criminals to
>IW Defense teams.
Paul Strassmann is simply missing the central point of cracking the 40-bit
export-allowed version. It is not based on a known plaintext attack, but on
exhaustive search of the 40-bit keyspace. What Goldberg and his colleagues
who contributed CPU time on the "NOW" (Network of Workstations) did was to
search approximately 100 billion keys per hour. As there are about a
trillion keys in the 40-bit keyspace, it was a foregone conclusion they
would find the key within 10 hours (modulo any screwups at their end), with
about half the time being the most likely time. As it was, they found the
key a tad bit early, by the luck of the draw (so to speak).
RSA certainly knows how long it takes to brute force the keyspace. They
just didn't know who would find the key first. (And at least one other
group reported a solution within minutes of Goldberg's report.)
So, Paul is simply throwing disinformation--or lack of understanding--into
the air by claiming that this crack does not mean a 40-bit key is "weak."
Simply put, it is. Anyone who looks at the math understands this. The
keyspace is simply too small for real security.
(Does the NSA use 40-bit keys? Of course not. Hmmmhhh.)
As the select panel of cryptographers empaneled to study key lengths
concluded, 56 bits is already too weak, 80 bits is better and should be
adopted forthwith for export, and >96 bits is preferable.
As an "infowarrior" of sorts myself, I can assure you that we don't give a
hoot in hell what the regs say is "allowed." When any tourist on his way to
Europe can carry as many CD-ROMSs and DAT tapes in his luggage as he
wishes, with absolutely no "exit checks," who really cares what the "export
laws" allow?
(I carried 5 gigabytes of data, some of it crypto-related, to a meeting
with cryptographers and crypto anarchists in Monte Carlo a while back.
Obviously I was not searched or even glanced at on my way out, nor on my
arrival at Charles de Gaulle airport, etc. Only upon my return to San
Francisco was I asked what my business had been. The Customs Officer gave
me a blank look when I told him I was meeting with cryptographers in Monte
Carlo (I told him the truth, knowing I was breaking no laws whatsoever). He
had no idea what I was talking about, and was bored. He then asked me if I
was bringing back any stuff I bought in shops over there. "No," I told him.
He just waved me through.)
Not to mention the ease with which stuff is shipped out over the Internet.
(I made a bet a couple of years ago that each major new cipher would arrive
at offshore non-U.S. sites within 3 hours of release in the U.S. Remailers
make it so easy to bounce stuff around.)
And of course I was the one in 1988 who first proposed the now-popular
method of using the least significant bits (LSBs) of CDs and DATs filled
with music, and LSBs of GIF images, to transparently export megabytes of
data undetectably. (To any sniffers, the LSBs are formally and
statistically identical to the ordinary noise of microphones and recording
electronics.) A normal 2-hour DAT tape of a recording I made off the radio
or off of one of my CDs can carry 160 megabytes of "data" riding in just
the LSBs alone. That's equivalent to 16 copies of the Bible, or a
significant chunk of the B-2 Stealth bomber CAD database.
I'd like to see your list get involved in more accurate and less
scare-mongering discussions.
--Tim May
Just say "No" to "Big Brother Inside"
We got computers, we're tapping phone lines, I know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets,
Higher Power: 2^1398269 | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Tue, 4 Feb 1997 00:52:28 -0500 (EST)
From: "Craig H. Rowland" <crowland(a)psionic.com>
To: "Betty G. O'Hearn" <betty(a)infowar.com>
Subject: RSA
> Date: Thu, 30 Jan 1997 20:10:36 -0500
> To: "Wright Larry" <Wright_Larry(a)bah.com>
> From: "Paul A. Strassmann" <paul(a)strassmann.com>
> Subject: Further to Goldberg's Cracking Accomplishments
> Gentlemen:
>
> As I suspected (see earlier private comment), the
> highly promoted RSA cracking contest offered
> a number of clues that ordinarly would not be
> volunteered by info-terrorists or info-criminals to
> IW Defense teams.
>
> These clues made the cracking significantly easier,
> because it made it possible to eliminate an enormous
> range of possible searches.
You are talking about implementing security through obscurity. You can
never assume that an enemy does not know what security precautions are in
place to protect information, or in this case, what cipher
you have chosen to protect your data. The security of your in-place
mechanisms should be able to stand on their own merits under a worst
case scenario of full public disclosure.
>
> The following was extracted verbatim from the
> <The RSA Data Security Secret-Key Challenge>
> posted on <http://www.rsa.com/rsalabs/97challenge/>:
>
> Clue #1:
>
> " ...all the RC5 contests posted as part of the RSA Secret-Key Challenge
> will use
> 12-round RC5 with a 32-bit word size. "
>
> Clue #2:
>
> " ...The first RC5 contest will consist of some unknown plaintext
> encrypted using a 40-bit key;."
>
> Clue #3: (a giveway!)
>
> " ... For each contest, the unknown plaintext message is preceded by three
> known blocks of text that contain the 24-character phrase "The
> unknown message is: .....".
Let me address 1, 2, and 3 all together as they all suffer
from the same flaw in logic as discussed above.
First, the ciphers in this contest includes more than RC5, the main
point of the contest is not to illustrate the security of a particular
cipher from cryptanalytic attack, but rather to show that key lengths that
are too short are insecure against a brute force attack. The fact that the
cipher is known does not affect the overall purpose of the contest.
Second, you are again assuming the cipher is unknown by your enemy.
Suppose you are a financial institution, I can be almost 100% assured that
your communications are protected with DES as the cipher. If I can
discover what equipment you are using and what modes the cipher runs in
(CBC, ECB, etc) I can then attempt a similiar brute-force attack using
the widely available DES specifications. Commercial organizations using
exportable software systems suffer the same fate. You are also assuming
that a mathmatical analysis of the encrypted data stream will not reveal
what cipher is being used. Various statistical attacks could reveal key
pieces of information that could quickly unveil what cipher you are using
and what mode it is being run in.
Third, just because part of a message is known does not mean the contest
is invalid. Many network communication protocols use a fixed set of
characters to establish and end communication sessions. An attacker, aware
of how the protocols work, can often discern what a message may contain
when it is initiated. An example of this could include SMTP traffic which
includes a standard set of protocol keywords, or an electronic funds
transfer which includes unique bank identification numbers or other
similar data. This is called a known plaintext attack and is very common.
>
> In summary: The claim of exportable cryptography being totally
> insecure, because it can be cracked in 3.5 hours is not
> realistic. The three clues announced in the contest
> would not apply under infowar conditions.
Again, this is not correct. You are assuming total ignorance by the enemy
which is rarely the case.
>
> What other clues may have been provided to Goldberg
> to support private agendas and gain shrill headlines
> is also a matter of speculation, but I rest my case.
Why does one even need a "clue" about this key size? It should be obvious
to anyone remotely educated/interested in the field of cryptography that
the reason the NSA limits exportable key length to 40 bits or less to
begin with is so they can do the same thing at Ft. Meade on their
internal computers that was done here publically.
The whole debate over exportable encryption rarely rests on the cipher,
but rather on the *length* of the keys used. This *alone* should be enough
to convince the reader that key length is in fact a very vital issue for
both the NSA and the Internet community.
> I certainly cannot assert that a 40 bit key cannot be decyphered.
> However, I do not think that the RSA unqualified claims
> offer full and appropriate disclosure.
Nonsense..RSA sells cipher technology that uses both 40 bit encryption and
higher, they make their money either way...their only bias in this area is
that they have their exportable software crippled in such a way as to make
it useless to foreign buyers. Luckily companies in Finland, Switzerland,
and Germany are starting to take up the slack and provide strong
cryptographic products of their own.
-- Craig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Tue, 4 Feb 1997 12:49:25 -0500 (EST)
To: infowar(a)infowar.com
From: Bob Stratton <strat(a)wheelgroup.com>
Subject: RSA's Challenge Claims and the Real World
In Infowar Digest Volume 02, Number 04, Paul Strassman writes:
>In summary: The claim of exportable cryptography being totally
>insecure, because it can be cracked in 3.5 hours is not
>realistic. The three clues announced in the contest
>would not apply under infowar conditions.
>
>What other clues may have been provided to Goldberg
>to support private agendas and gain shrill headlines
>is also a matter of speculation, but I rest my case.
>
>I certainly cannot assert that a 40 bit key cannot be decyphered.
>However, I do not think that the RSA unqualified claims
>offer full and appropriate disclosure.
I feel compelled to respectfully submit what may be considered a rebuttal.
In general, I tend to dismiss claims of anything being "totally" anything,
but in this particular instance, I think further discussion may be warranted.
I admit to being a little surprised by this tack on the part of RSA. RSA
Labs (the research side of that house) has earned my respect over time by
doing serious cryptological work and publishing it in a thoughtful, academic
manner worthy of note.
The histrionics of press releases notwithstanding, I think these comments
merit further examination:
I may concede that the "three clues...would not apply under infowar
conditions". In doing so, I must also ask for further clarification as to
exactly which infowar Mr.Strassman is referring. Given this forum's
consideration of the national security implications of attack on the
financial infrastructure, it seems a fair question.
In any event, I question whether this is relevant within the context of the
challenge, and the purposes behind it. RSA's purpose in posting this
challenge was presumably to enlighten the public and others as to the
_relative_ strength of currently exportable cryptosystems.
I have no doubt that the agenda behind this is to encourage resistance to
current U.S. policies on cryptographic export, a stance designed to maximize
share value in what is admittedly a commercial venture. I'm also willing to
note that I have a general distaste for INFOSEC "challenges" of any sort.
I would, however, like to explore the assertion that the clues posted in the
challenge were not offered in the spirit of full and fair disclosure. I will
concede in any case that this was not an exhaustive, controlled study.
"Challenges" such as these have a place. Within the INFOSEC environment,
cryptanalytic attack appears to be one of the more reasonable areas for them.
Compared to "challenges" against network "firewalls", for example,
cryptanalysis is an area where there is the opportunity to adequately define
the goal and to measure the result. In this case, RSA was not attempting to
prove a negative, as have so many (too many) other firms offering so-called
"challenges".
If we restrict our focus for purposes of argument to commercially available
cryptographic software, the clues become significantly less onerous and
mysterious.
Clue #1, the disclosure of 12-round RC5 with a 32-bit word size, is
certainly the most arcane of the lot. Speaking as a former commercial
software developer, I would be quite surprised if vendors would not
routinely disclose information of this sort. Certainly vendors using
standard algorithms would tend to be more willing to do so than those using
proprietary ones, which only bolsters my later arguments, as you will see
below.
If we may depart for just a moment to other algorithms, almost any
_standard_ implementation of an algorithm which is interoperable with other
implementations would, by definition, disclose or facilitate disclosure of
this sort of information, by its very nature. Again, in a commercial
environment, interoperability is key (no pun intended), so it's likely that
implementation details are either available, or readily deducible.
Clue 2, the disclosure of key size, again meets the standards just
discussed. In the case of products recently exportable from the U.S., one of
two things is generally true. Either the key size is actually 40 bits, or
the key size is larger than 40 bits, but steps are taken to make all key
information beyond 40 bits accessible to observers of the tool. Again, in a
commercial environment, this is no secret.
Clue 3 is perhaps where I'm most inclined to agree with Mr. Strassman.
Disclosure of known plaintext, in this case the phrase "The unknown message
is:" is certainly quite serious in that it may significantly aid
cryptanalytic attack. My only comment here is that in the commercial arena,
interoperability demands standards, and standards define consistent
protocols. Those protocols will almost always result in some manner of
reproducible content, most readily exemplified by message headers in
electronic mail systems. While mechanisms exist for enhanced cryptographic
protection of said content, in general the commercial environment has lagged
behind the military, and perhaps rightly so.
In none of the aforementioned cases, however, do I see information that
fundamentally invalidates the significance of RSA's Challenge TO THE
CIVILIAN COMMERCIAL INFOSEC COMMUNITY. That community has serious, current
INFOSEC needs, and one must question (as I know many of us do every day) to
what degree we're willing to lay our economic fabric open to subversion in
order to lessen the cost of intelligence collection.
--Bob Stratton
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Tue, 4 Feb 1997 9:25:21 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security"
<PADGETT(a)hobbes.orl.mmc.com>
To: infowar(a)infowar.com
Subject: RSA challenge
Paul rote:
>As I suspected (see earlier private comment), the
>highly promoted RSA cracking contest offered
>a number of clues that ordinarly would not be
>volunteered by info-terrorists or info-criminals to
>IW Defense teams.
...
>Clue #3: (a giveway!)
> " ... For each contest, the unknown plaintext message is preceded by three
> known blocks of text that contain the 24-character phrase "The
> unknown message is: .....".
Those who follow my hobby may have noticed that about two years ago I began
using the "3.5 hour" figure to assign a maximun value of $250 to any
information sent via a 40 bit code. The advent of multiple parallel machines
(via networks) capable of operating entirely out of L1 cache just made
the technology available.
However, such attacks do rely on known plain text for speed (final test
is a simple XOR/alarm if zero. The same technology was used in Colossis
back in 1944. It was just a touch slower.
The simle answer is message compression prior to encryption which would
make deciding when the message was broken much more difficult.
Naysayers claim "there is always KPT" but this does not need to be true.
- whole months of Enigma traffic went undecoded because there was no
crib available but eventually human error gave the BP team a clue. Today,
electronic systems can remove such errors from human hands.
Personally believe that 56 bits is "good enough" today though it makes
little sense from a programming standpoint not to use 64 *so long as
a different key is used for every message and every message, no matter
how trivial, is encrypted*.
Or you could use a "shared secret" book code: a simple XOR with a
digital satellite data stream transmitting compressed video should
do nicely. All that is needed is to know which stream and when to
start. I call that an "unwitting key provider".
So as Paul says, the contest proves little except to confirm my 3.5
hour estimate (remember the gentleman in France who broke the 40 bit
NS code last year and what his time was...) - but that was for equipment
available several years ago.
Today I use the figure of one gig kps (keys per second) for 1997 equipment
per seive. A single one would break 40 bits in an average of under 10 min.
DES would fall in a day to 400 in parallel. But the question remains:
without KPT, how can you tell when the break occured ? Is a world of
difference between an XOR and decompression. And if every message uses a
differnt key...
Warmly,
Padgett
ps WORD virus anti-virus macro is avaliable: http://www.netmind.com/~padgett/
under "Anti-Virus hobby". FreeWare.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1
0
-----BEGIN PGP SIGNED MESSAGE-----
The Mining Co. (http://www.miningco.com) is looking
for "siteguides".
There will surely be a guide needed for cryptography.
Pay is commensurate with hit volume, but it isn't too shabby,
at about 3K per month after about a year.
There is the original posting from Sideman's Online Insider following
this post to acquaint you with the particulars.
Good Luck to whomever from this list (for I'm sure someone will)
takes the aformentioned position. I would, but I'm applying for a
different site in the Culture/Beliefs section.
On one other note, the PGP Plugin for Eudora is MARVELOUS!
THIS I can even teach a clueless newbie!
Carol Anne Cypherpunk
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Uncensored from heavily.censored.org
iQCVAwUBMwAfd4rpjEWs1wBlAQG3YwP/XXgJfqD06KTLfdDfj2mAweBrFAASsRR8
q37l43InJU/AVhRJ0MKkcmxto7sfO1jHNW6O0+0HjrnMRZAmnw7YH806+mCCerUG
CeTT5U97Cp/V5Yud6r6f0vqP/BPk8etGIZnGgWKajJ49rFTGlk01AgQz1xE49mmI
i962UdPbyVs=
=69D8
-----END PGP SIGNATURE-----
==========================================================================
Seidman's Online Insider - Vol. 4, Issue 6
Brought to you by NetGuide Magazine< http://www.netguide.com >
==========================================================================
Copyright (C) 1997 Robert Seidman and CMP Media Inc. All rights reserved.
May be reproduced in any medium for noncommercial purposes as long as
attribution is given.
Kurnit is Back and Mining the Internet
======================================
"Like Arnold, he'll be back. I've been listening to what
he has to say for a long time. If you listen to him, you'll
hear how the Web is the way and that the proprietary services
are a dead model. If you listen between-the-lines, you'll hear
a modified version of that vision. A best of both worlds
vision. You'll hear that he wants to develop easy to use,
functional services on the Web. Like easy to use chat.
Like easy to use bulletin boards.
Like AOL, but on the Web."
-Thoughts on Scott Kurnit in a piece regarding the failed MCI/News Corp
joint venture from Seidman's Online Insider for the Week Ending February
9, 1996.
Kurnit's back, and almost exactly a year to the day since the clip above
was written. On Monday February 10, the new company Kurnit founded, The
Mining Company, will announce their plans to basically build AOL on the
Web. I'm not sure about the choice of February 10 as the day to announce
this. It is a day with special significance for me.
On February 10, 1972 I had a dilemma. I was hungry for breakfast and
wanted some cereal. I had cereal, but no milk. So I called my mom at
work and asked her if I could run across the street to the convenience
store. My mom said no because "the street" was more like a highway and
because I was 9 years old.
"You'll get hit by a car," my mom said. As you might imagine, I went
anyway. And as you also might have guessed by now my mother was right,
except no car was good enough for me. I had to face off with a
ten-wheeler (it was an Amoco < http://www.amoco.com > Oil tanker.)
Twenty-two stitches in the head, a healed broken wrist and 25 years later,
I'm still hanging in there. I don't remember anything about it, including
seeing the truck. I've always wondered if I was pushed. What I do
remember was waking up in the ambulance with quite a headache. But since
then, seeing how I lived and all, I've always viewed February 10 as a GOOD
day.
The Mining Company may not be a truck setting its sights on running down
AOL or even other Web content aggregators (even to some degree NetGuide
Live), but it is an interesting model.
*What It Is*
In effect, The Mining Company wants to be the biggest online service on
the Web, ultimately offering 4,000 special-interest areas in an
integrated, easy-to-use interface. Whether you call these special areas
channels, departments or categories -- it's all the same thing. Kurnit
wants to capitalize on the fact that it takes too long to find what you
want on the Net. He wants to put it all in one place with one consistent
interface so that you can easily find what you're looking for and interact
with those who have common interests.
Each "channel" will have content, bulletin boards, online chats, links to
other good stuff on the Web in the particular area of interest. You'll
also be able to search a site via Verity's search engine or search the
entire Net via Digital's Alta Vista.
While they are currently testing another chat product, they have decided
to move to the iChat chat client.
In the test system I had access to, the bulletin board system was very
easy to use, but painfully slow. I'll cut them some slack since they are
still in beta, but users will need to be able to move around the boards
quicker than what I experienced or they will likely be put off.
*And Now for Something Really Different*
When Kurnit first ran the vision by me a couple of weeks ago, I said "To
me it seems like this is..."
"AOL on the Web," Kurnit interrupted.
"Not exactly," I said, "It's like AOL on the Web with a hint of Amway
thrown in."
One of the problems with providing editorial context for the Net is that
it winds up costing a lot of money. Kurnit's previous venture with
MCI/Newscorp was iGuide. They built a great guide to the Net, but
ultimately they scaled it back to just become a guide to entertainment on
the Net. You've read the reports all over the place about scaled back
editorial efforts and rightsizing. Good editorial doesn't come cheap, at
least not when done traditionally.
The Mining Company isn't going after the traditional model of hiring a
bunch of full-time editors and bringing them in house. They plan to use
folks already out there on the Net.
Once upon a time while I was at IBM, I helped recruit Chris Locke, of
MecklerWeb notoriety away from the MCI/News Corp effort Kurnit was
running.
While there are many things Chris and I do not agree on, I was very much
in synch with Chris when it came to the idea of communities of interest on
the Web. Give remote people the tools to produce the content, Locke would
say, and you'd be able to easily build hundreds if not thousands of
communities of interest very inexpensively. Locke who is now with a
hardware company in Colorado will no doubt take interest in what Kurnit
and the gang at The Mining Company are up to, because they are all about
providing the tools to produce the communities of interest inexpensively!
If your chosen as one of its forum moderators (they call them Guides),
you'll be given access to all the tools you need to build a site on the
service.
Now you may be thinking, "Ah, GeoCities does that already!" GeoCities
< http://www.geocities.com > gives free web pages and is organized around
certain communities of interest. But their homesteader program is not
about setting up an all-encompassing online service. And while it is a
great place to create a free web page, there's no real business model for
the person creating the page. If you build a great site there, GeoCities
gets the revenue on all the traffic that goes there. Because it has a lot
of traffic, GeoCities can send some traffic to your Web site. But in the
end, the model for GeoCities is one to give you a free page on the Web.
This is good for you if you're just in it for the fun of it, and good for
GeoCities too. I think GeoCities is great, but if I am looking for
something in particular, I wouldn't think to look there first. The Mining
Company wants to create a space that no matter what it is you hope to
find, you'll look there first.
*They Call them Guides*
The Mining Company wants to create quality communities of interest. And
for every community (channel) created, there will be a unique
moderator/editor. The Mining Company calls them Guides. It's looking for
more than just a few quality folks to become Guides and form their
service. Starting Monday, they will begin accepting applications to
become Guides on the service. There could be multiple sites about the
same thing during the start-up phase, but ultimately it will be whittled
down to one Guide/site per special interest.
To ensure quality, they'll be a review committee set-up to make sure
quality standards are up to snuff, including some folks from the community
of Guides. Kurnit believes between that, the natural inclination for
other Guides to point out areas of, um, weakness and user feedback,
they'll have a good handle on quality.
Additionally, there will be some in-house editorial to oversee major
groupings (like Technology, Personal Finance, etc.)
"The Mining Company is dedicated to serving the needs of its Guides and
users," said Kurnit. "We give the tools and support to the Guides to help
users find what they want, trust what they find, and connect them with the
most valuable sites on the Net and with other interesting people."
"This model is now only possible because of the team effort at The Mining
Company to integrate the latest improvements in Internet technology and
the newly identified needs of users and independent Web producers," adds
Kurnit.
*Getting the Guides*
Will it be easy to get the ultimately thousands of Guides necessary to run
this service?
"How much talent is out there," asks Kurnit. "We look at the thousands
of pages out there on AOL, GeoCities, etc., and the rest of the Internet,"
Kurnit said. "All we think we need to get is 2%-3% of the talent pool."
In certain areas it will likely be very competitive. Everyone will want
to get there first.
"First there's the application process," said Scott Kurnit in a phone
Interview. "You're going to show us your bio and you're going to write
some columns so we can see your writing style. If you make the grade, you
make it to our orientation process," Kurnit said.
The Mining Company places its focus on training the Guides and giving them
the tools they need to make a site. If you "make the grade" you
basically have 3 weeks (2 of which are the "orientation") to get a site
up-and-running on the service.
"The fact is, if you can't get it done in a reasonable time then you
probably don't have the dedication or time to get it done," says Kurnit.
Just how much time will it take for Guides to put together sites? "We're
not looking for anyone to quite their day jobs," said Kurnit. "We're
looking at about a 10 hour a week commitment to produce the sites." But
Kurnit also says that though there will be only one Guide per site, the
Guides will be able to line up assistants.
*What's in it for You?*
So why The Mining Company then? Why not GeoCities or doing it on your
own? Well, there are a couple of reasons. One is the promise of
exposure, the other is the promise of MONEY.
There is a model here, especially if you're not looking to quit your day
job. While I imagine it will have to shift its model somewhat, there are
some opportunities to make a buck or two for the Guides. It might not be
much money, but if you're already throwing 10 hours or so a week towards
maintaining a Web page that lines up around a special interest or two, any
money is better than what you're probably getting now.
Basically, The Mining Company is looking to allocate 40% of all
advertising revenues back to the Guides themselves. The real pool here is
30%, with the additional 10% being used for things like bonuses. So, how
does it work?
Kurnit is looking to get quickly to a million or so page views a day (each
of the pages I saw had 2 advertisements. By the end of the year, Kurnit
hopes to be in the 10 million - 15 million page views. It sounds a little
ambitious, but if they're successful lining up quality Guides, it could
become a reality. So let's say they're getting 5 million page views per
day. Based on what I saw, that would net out to be about 300 million ads
running per month.
Lets say ad sales average out to $30/1000 (a $30 CPM). Based on that,
you're looking at a cool $9 million a month in advertising revenue. So
$3.6 million is in the Guide pool, but only $2.7 million is for the true
revenue split. Now, let's say you're a Guide who got one-tenth of 1
percent of The Mining Company's overall traffic. You'd make a cool $2,700
a month for your efforts. If you happen to be a guide in one of the
"killer categories" whether it be a parents site or a kids site or a
computing site, it's not unreasonable to think that you might get as much
as 1%. That would be $27,000 per month!!
Some people will balk at the 40%-60% share, but I think that's pretty
fair. Where I'd predict the model will have to change, however, is in the
cases where the cost per thousand (CPM) view being charged the advertisers
is much higher than the average of the overall site. If the overall site
average is $30/1000, but your site is generating a CPM of around $90,
you're probably not going to want to be paid based on averages.
*Will it Work?*
In short, I think this could work quite nicely. The premise of a front
door that links to content that is all packaged with a consistent look and
feel is a winning premise. With AOL's recent move to flat-fee, one big
advantage a Net service has over a proprietary model like AOL is the
ability to create content far more easily and inexpensively. Much coverage
has been given this week regarding AOL beginning to charge its partners in
its Company Connection a $55,000 fee each year to participate.
Some in AOL are saying its reasonable since the areas amount to "free"
advertising for the companies, but realistically speaking, I think it is a
maintenance fee AOL is charging to offset the cost of dealing with these
forums. I think it is reasonable to expect to see AOL begin to charge
similar fees for any content that isn't "must have" for them, now that the
hourly charges that once subsidized these areas are gone. There is a cost
of throwing in-house support at these online areas and much of the cost is
due to the fact that it's a proprietary system. Setting up new "forms"
and new looks just isn't easily accomplished by the content providers
themselves. So, the timing may be good for The Mining Company.
There are at least two tricks Kurnit and Co. must pull off. First, they
have to get the Guides. That starts on Monday, when they begin accepting
applications. The next will be to market the site in a way that gets
people to the front door. Internet of the people, for the people and by
the people, it has a nice ring to it... I'm sure we'll hear more about
this when the site officially launches in April.
For more info, check out < http://www.miningco.com >, sometime on Monday,
they will make a lot more information available there than the "coming
soon" that was there as of this writing.
Member Internet Society - Certified BETSI Programmer - Webmistress
***********************************************************************
Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96
My Homepage
The Cyberdoc
***********************************************************************
1
0
-----BEGIN PGP SIGNED MESSAGE-----
Here an page, that deals with various intelligence and military
institutions...
In> Subject: GOVT> AJAX, Government and Military Intelligence
In> http://204.180.198.56:80/ajax/ajax.htm
In> United States and International Government Military and Intelligence
In> Agency Access
In> Certain Locations Or Sections Thereof May Be Closed To
In> Unauthorized Use.
In> PLEASE READ ACCESS WARNINGS, IF ANY, AND ABIDE BY THEM.
In> (If You Prefer A Frameless Environment, Click HERE.)
In> Last update: 7 FEBRUARY 1997. All accesses verified at
In> time of inclusion.
In> CIA Central Intelligence Agency
In> DIA Defense Intelligence Agency
In> NRO National Reconnaissance Office
In> NSA National Security Agency
In> SS Secret Service
In> USCSOI U.S. Customs Service Office of Investigation
In> ATF Bureau of Alcohol, Tobacco and Firearms
In> BOP Federal Bureau of Prisons
In> CID U.S. Army Criminal Investigation Command
In> COURTS U.S. Federal Courts
In> FBI Federal Bureau of Investigation
In> FINCEN Financial Crimes Enforcement Network
In> FLETC Federal Law Enforcement Training Center
In> MARSHALS U.S. Marshals Service
In> NIJ National Institute of Justice
In> ACC Air Combat Command
In> AFSPC Air Force Space Command
In> BMDO Ballistic Missile Defense Organization
In> DEFENSE Defense Department
In> DISA Defense Information Systems Agency
In> DRMS Defense Reutilization and Marketing Service
In> DTIC Defense Technical Information Center
In> JCS Joint Chiefs of Staff
In> NAVWAN Naval Aviation Systems Team Wide Area Network
In> NAWCWPNS Naval Air Warfare Center Weapons Division
In> NSWC Naval Surface Warfare Center
In> USAFA United States Air Force Academy
In> AHPCRC Army High Performance Computing Research Center
In> ARPA Advanced Research Projects Agency
In> LABLINK U.S. Department of Defense Laboratory System
In> NRL The Naval Research Laboratory RL
In> USAF Rome Laboratory for C41 Technology
In> USACIL U.S. Army Criminal Investigation Laboratory
In> NATGUARD Army and Air National Guards
In> USA United States Army
In> USAF United States Air Force
In> USCG United States Coast Guard
In> USMC United States Marine Corps
In> USN United States Navy
In> EPA U.S. Environmental Protection Agency
In> FAA Federal Aviation Administration Technical Center
In> FCC Federal Communications Commission
In> FTC Federal Trade Commission
In> NMFS National Marine Fisheries Service
In> NRC Nuclear Regulatory Commission
In> SEC Securities and Exchange Commission
In> CDC Centers for Disease Control and Prevention
In> CENSUS U.S. Department of Commerce Bureau of the Census
In> CONGRESS U.S. House of Representatives
In> CUSTOMS U.S. Customs Service
In> DOE U.S. Department of Energy National Laboratories
In> & Programs
In> EXECUTIVE The White House
In> FDIC Federal Deposit Insurance Corporation
In> FEMA Federal Emergency Management Agency
In> FMS Financial Management Service
In> GPO U.S. Government Printing Office
In> GSA U.S. General Services Administration
In> HHS U.S. Department of Health and Human Services
In> HPCC NOAA High Performance Computing and
In> Communications IRS Internal Revenue Service
In> JUSTICE Justice Department
In> NARA National Archives and Records Administration
In> NASA National Aeronautics and Space Administration
In> NCDC National Climatic Data Center
In> NIMH National Institute of Mental Health
In> NOAA National Oceanic & Atmospheric Administration
In> NSF National Science Foundation
In> NTIS National Technical Information Service
In> SBA Small Business Administration
In> SEL Space Environment Laboratory
In> STATE State Department
In> TREASURY Treasury Department
In> USCODE U.S. House of Representatives
In> Internet Law Library U.S. Code
In> CANADA
In> CSE Communications Security Establishment
In> CISC Criminal Intelligence Service Canada
In> CSIS Canadian Security Intelligence Service
In> SIRC Security Intelligence Review Committee
In> UNITED KINGDOM CIM Central Intelligence Machinery
In> CANADA
In> DJC Department of Justice of Canada
In> FORENSIC The Forensic Web
In> RCMP Royal Canadian Mounted Police
In> SGC Solicitor General of Canada
In> UNITED NATIONS UNCPCJ United Nations Crime Prevention &
In> Criminal Justice
In> CANADA
In> CFC Canadian Forces College
In> DREO Defense Research Establishment, Ottawa
In> UNITED KINGDOM
In> ARMY The British Army
In> CDA Centre for Defence Analysis
In> DRA Defence Research Agency
In> NATO North Atlantic Treaty Organization
In> SACLANT Supreme Allied Commander, Atlantic
In> SHAPE Supreme Headquarters Allied Powers Europe
In> BECCA Business Espionage Controls & Countermeasures
In> Association
In> CRYPTOLOG Internet Guide to Cryptography
In> DCJFTF Washington, D.C. Joint Fugitive Task Force
In> WANTED "The World's Most Wanted" (Fugitives and
In> Unsolved Crimes)
Ciao
Harka
/*************************************************************/
/* This user supports FREE SPEECH ONLINE ...more info at */
/* and PRIVATE ONLINE COMMUNICATIONS! --> http://www.eff.org */
/* E-mail: harka(a)nycmetro.com (PGP-encrypted mail preferred) */
/* PGP public key available upon request. [KeyID: 04174301] */
/* F-print: FD E4 F8 6D C1 6A 44 F5 28 9C 40 6E B8 94 78 E8 */
/*<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>*/
/* May there be peace in this world, may all anger dissolve */
/* and may all living beings find the way to happiness... */
/*************************************************************/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQEVAgUBMv7aGjltEBIEF0MBAQF1CAf+MyLUa3sBKCAuxhzCZ0tQqP3jxAjQpIuV
WdsTCW9L3jPwLdZ9BmqeqAuaIU4JQzCpEx5bgKdzGThF5mG2U4XaeOcD4gBpWZyz
sYOZzcoYNe6CX6m55a9UqiEpZu4mK9TBkO7OXSfV3J3CygVAbo7zjC+lW2r7L9F8
3vTqrxbOCb3SMEl4k3L5QVtKOGVSh7MMIesBtmQ2SNhhvSfrdFYBnCcvtmnvYi8j
6YpI5wrkiNzueuFwoD9YoRR7UugE5kcCyJ3FFHym7RzQUL8XsHRhsk1XoTBHvXni
2Tfno7DH5+T4FuVZTWeaAVhD7OTfK2n0lBCf0x2I5F1iEUurbdddig==
=s4om
-----END PGP SIGNATURE-----
If encryption is outlawed, only outlaws will have encryption...
1
0
I operate a remailer pinging service which collects detailed
information about remailer features and reliability.
To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu
There is also a Web version of the same information, plus lots of
interesting links to remailer-related resources, at:
http://www.cs.berkeley.edu/~raph/remailer-list.html
This information is used by premail, a remailer chaining and PGP
encrypting client for outgoing mail. For more information, see:
http://www.c2.org/~raph/premail.html
For the PGP public keys of the remailers, finger
pgpkeys(a)kiwi.cs.berkeley.edu
This is the current info:
REMAILER LIST
This is an automatically generated listing of remailers. The first
part of the listing shows the remailers along with configuration
options and special features for each of the remailers. The second
part shows the 12-day history, and average latency and uptime for each
remailer. You can also get this list by fingering
remailer-list(a)kiwi.cs.berkeley.edu.
$remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special";
$remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?";
$remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek";
$remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp';
$remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp';
$remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk mix pgp hash latent cut ek";
$remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek";
$remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek";
$remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek";
$remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek";
$remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord";
$remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp';
$remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek";
$remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek";
$remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord ?";
$remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp';
$remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle ?";
$remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp';
$remailer{"death"} = "<x(a)deathsdoor.com> cpunk pgp hash latent post";
$remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?";
$remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek";
$remailer{"shaman"} = "<mix(a)mix.nymserver.com> cpunk mix pgp. hash latent cut";
catalyst(a)netcom.com is _not_ a remailer.
lmccarth(a)ducie.cs.umass.edu is _not_ a remailer.
usura(a)replay.com is _not_ a remailer.
remailer(a)crynwr.com is _not_ a remailer.
There is no remailer at relay.com.
Groups of remailers sharing a machine or operator:
(cyber mix)
(weasel squirrel)
The alpha and nymrod nymservers are down due to abuse. However, you
can use the nym or weasel (newnym style) nymservers.
The cyber nymserver is quite reliable for outgoing mail (which is
what's measured here), but is exhibiting serious reliability problems
for incoming mail.
The squirrel and winsock remailers accept PGP encrypted mail only.
403 Permission denied errors have been caused by a flaky disk on the
Berkeley WWW server. This seems to be fixed now.
The penet remailer is closed.
Last update: Mon 10 Feb 97 6:46:24 PST
remailer email address history latency uptime
-----------------------------------------------------------------------
nym config(a)nym.alias.net **-#+*#*#*## 1:59 100.00%
jam remailer(a)cypherpunks.ca ****** 8:22 99.98%
wazoo remailer(a)wazoo.com *+++++ 33:48 99.97%
weasel config(a)weasel.owl.de ++++++-++++ 1:05:51 99.84%
lucifer lucifer(a)dhp.com ++++++++++++ 37:45 99.78%
dustbin dustman(a)athensnet.com ----+-- .+++ 2:42:13 99.65%
balls remailer(a)huge.cajones.com +-- **### *# 2:12 99.60%
cyber alias(a)alias.cyberpass.net ++*+++*** *+ 30:13 99.59%
haystack haystack(a)holy.cow.net *#-+###*##* 4:06 99.42%
squirrel mix(a)squirrel.owl.de ++ +++-+ ++ 1:05:29 99.26%
exon remailer(a)remailer.nl.com #* * ## **# 1:21 99.18%
middle middleman(a)jpunix.com ---+-. +++ 2:51:34 98.78%
replay remailer(a)replay.com +-***+*---+* 27:45 98.57%
extropia remail(a)miron.vip.best.com .- ------- 4:46:55 98.08%
reno middleman(a)cyberpass.net --+- .++ 1:27:14 96.63%
mix mixmaster(a)remail.obscura.com +_ __.-*+ 22:42:38 93.53%
winsock winsock(a)rigel.cyberpass.net ----.--- + 5:48:14 75.89%
shaman mix(a)mix.nymserver.com 2:46 9.00%
History key
* # response in less than 5 minutes.
* * response in less than 1 hour.
* + response in less than 4 hours.
* - response in less than 24 hours.
* . response in more than 1 day.
* _ response came back too late (more than 2 days).
cpunk
A major class of remailers. Supports Request-Remailing-To:
field.
eric
A variant of the cpunk style. Uses Anon-Send-To: instead.
penet
The third class of remailers (at least for right now). Uses
X-Anon-To: in the header.
pgp
Remailer supports encryption with PGP. A period after the
keyword means that the short name, rather than the full email
address, should be used as the encryption key ID.
hash
Supports ## pasting, so anything can be put into the headers of
outgoing messages.
ksub
Remailer always kills subject header, even in non-pgp mode.
nsub
Remailer always preserves subject header, even in pgp mode.
latent
Supports Matt Ghio's Latent-Time: option.
cut
Supports Matt Ghio's Cutmarks: option.
post
Post to Usenet using Post-To: or Anon-Post-To: header.
ek
Encrypt responses in reply blocks using Encrypt-Key: header.
special
Accepts only pgp encrypted messages.
mix
Can accept messages in Mixmaster format.
reord
Attempts to foil traffic analysis by reordering messages. Note:
I'm relying on the word of the remailer operator here, and
haven't verified the reord info myself.
mon
Remailer has been known to monitor contents of private email.
filter
Remailer has been known to filter messages based on content. If
not listed in conjunction with mon, then only messages destined
for public forums are subject to filtering.
Raph Levien
1
0

DCSB: Online Government & Electronic Commerce - Legislation andPublic Sector Initiatives
by Robert Hettinga 17 Dec '03
by Robert Hettinga 17 Dec '03
17 Dec '03
-----BEGIN PGP SIGNED MESSAGE-----
The Digital Commerce Society of Boston
Presents
Daniel Greenwood, Esq.
Deputy General Counsel
Information Technology Division
Commonwealth of Massachusetts
"Online Government & Electronic Commerce -
Legislation and Public Sector Initiatives"
Tuesday, March 4, 1997
12 - 2 PM
The Downtown Harvard Club of Boston
One Federal Street, Boston, MA
Dan will give us an update on recent information age legislative and
operational developments in the public sector. Special attention will be
paid to: Electronic Signature and Record Legislation; Joint
Government/Private Sector Attempts to Set Certification Authority
Standards; Cutting Edge Public Sector PKI Projects; Recent Coordinated
State-Federal-Foreign Electronic Commerce Policy Initiatives; and much,
much more . . .
Speaker:
Daniel Greenwood, Esq.
Information Technology Division, Deputy General Counsel
Commonwealth of Massachusetts
Office: http://www.state.ma.us/itd/legal
home: http://www.tiac.net/biz/danielg
Mr. Greenwood practices information technology law for the Commonwealth
of Massachusetts. Recent relevant activities include:
* Co-Author of the Draft 1997 Mass. Electronic Records and Signature Act
* Chairman of the Commonwealth of Mass. PKI Task Force
* Chairman of the ABA Info. Security Comm., Legislative Sub-Committee
* Co-Chair of the ABA Cyberspace Law Comm., Legislative Work Group
* Contributing Author: ABA Digital Signature Guidelines
* Negotiator of Contracts for Internet Security and Payment Systems
* Board Member of SigNet.Org and Chair of Legal Special Interest Group
* Director of the Virtual State House Project (MIT/Stanford Law School)
* Faculty Member: MCLE Health Care & Info. Technology Program
* Guest Lecturer for Suffolk Law School High Tech. Symposium
* Selection Board Chairman for First Commonwealth of Mass. C/A Business
This meeting of the Digital Commerce Society of Boston will be held on
Tuesday, March 4, 1997 from 12pm - 2pm at the Downtown Branch of the
Harvard Club of Boston, One Federal Street. The price for lunch is
$27.50. This price includes lunch, room rental, and the speaker's lunch.
;-). The Harvard Club *does* have dress code: jackets and ties for men,
and "appropriate business attire" for women.
We will attempt to record this meeting and put it on the web in RealAudio
format at some future date
We need to receive a company check, or money order, (or, if we *really*
know you, a personal check) payable to "The Harvard Club of Boston", by
Saturday, March 1, or you won't be on the list for lunch. Checks
payable to anyone else but The Harvard Club of Boston will have to be
sent back.
Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston,
Massachusetts, 02131. Again, they *must* be made payable to "The Harvard
Club of Boston".
If anyone has questions, or has a problem with these arrangements (We've
had to work with glacial A/P departments more than once, for instance),
please let us know via e-mail, and we'll see if we can work something
out.
Planned speakers for DCSB are:
March Daniel Greenwood The Role of State Government in Digital Commerce
April Stewart Baker Encryption Policy and Digital Commerce
We are actively searching for future speakers. If you are in Boston on
the first Tuesday of the month, and you would like to make a
presentation to the Society, please send e-mail to the DCSB Program
Commmittee, care of Robert Hettinga, <mailto: rah(a)shipwright.com> .
For more information about the Digital Commerce Society of Boston, send
"info dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> .
If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in
the body of a message to <mailto: majordomo(a)ai.mit.edu> .
Looking forward to seeing you there!
Cheers,
Robert Hettinga
Moderator,
The Digital Commerce Society of Boston
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMwB+VvgyLN8bw6ZVAQEsRAQAiInZXDXlzdMn0B+b9A6zgWHH5POJku5v
k9HIZK286Paw1KWKYsw8VyYjUoG4vq/LAh1CagWkwL4EN9Ysg7kbU+LP0W4u04vb
/QoKk5rWpmXuplXx1Fp9IhIe2O6oV0vTInJqPV3zkXk4qGzYUrQ0bqLbQn769iMO
7pwwVbkioSc=
=m5Pz
-----END PGP SIGNATURE-----
-----------------
Robert Hettinga (rah(a)shipwright.com) Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Never attribute to conspiracy what can be
explained by stupidity." -- Jerry Pournelle
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/
1
0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SANDY SANDFORT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C'punks,
You have probably just read John's post. I truly hope YOU (each
and every one of you) can rise to his challenge. If you have
offered nothing in the past but criticism, it's now time to get a
bit more real. What will it be, your money, time, equipment?
I would hope that the loudest advocates of "free speech" turn out
to be the most generous, but I'm not holding my breath. Maybe
the solution(s) will come from you lurkers. I hope you can put
down your beer long enough to get involved.
Finally, if anyone wants to discuss why the Cypherpunk list has
come to this, or what I did right or wrong as a moderator, let's
talk about--on the new list(s) YOU create. For now, though, it's
off-topic. We have work to do.
S a n d y
P.S. To all those people who privately supported me in
my attempt to help the list deal with its problems,
thank you. I wouldn't have come back without your
and John's encouragement.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7
9